- 13 6月, 2015 2 次提交
-
-
由 Laurent Pinchart 提交于
The omapdrm driver implements a mechanism to apply new settings (due to plane update, plane disable, plane property set, CRTC mode set or CRTC DPMS) asynchronously. While this improves performance, it adds a level of complexity that makes transition to the atomic update API close to impossible. Furthermore the atomic update API requires part of the apply operations to be synchronous (such as pinning the framebuffers), so the current implementation needs to be changed. Simplify the CRTC and plane code by making updates synchronous to prepare for the switch to the atomic update API. Asynchronous update will be implemented in a second step. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Laurent Pinchart 提交于
Rotation is a standard property, store it in dev->mode_config.rotation_property. While at it, extract the properties initialization code to a separate function instead of running it for every plane. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 24 3月, 2015 5 次提交
-
-
由 Tomi Valkeinen 提交于
We store the fb being page-flipped to 'old_fb' field, but we don't increase the ref count of the fb when doing that. While I am not sure if it can cause problem in practice, it's still safer to keep a ref when storing a pointer to a fb. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
We need to ignore DIGIT SYNC LOST error when enabling/disabling TV output. The code does that, but it ignores the DIGI SYNC LOST when enabling any output. Normally this does no harm, but it could make us miss DIGIT SYNC LOST on some rare occasions. Fix the code to only ignore DIGIT SYNC LOST when enabling/disabling TV. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
omapdrm tries to avoid error floods by unregistering the error irq when an error happens, and then registering the error irq again later. However, the code is racy, as it sometimes tries to unregister the error irq when it's already unregistered, leading to WARN(). Also, the code only registers the error irq again when something is done on that particular output, i.e. if only TV is used to flip the buffers, and LCD is showing a same buffer, an error on LCD will cause the LCD error irq to be unregistered and never registered again. To fix this, let's keep the error irqs always enabled and trust the DRM_ERROR_RATELIMITED to limit the flood. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
omapdrm uses normal DRM_ERROR() print when the HW reports an error. As we sometimes may get a flood of errors, let's rather use DRM_ERROR_RATELIMITED(). Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
The DRM documentation says: "If a page flip is already pending, the page_flip operation must return -EBUSY." Currently omapdrm returns -EINVAL instead. Fix omapdrm by returning -EBUSY. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 20 3月, 2015 8 次提交
-
-
由 Laurent Pinchart 提交于
The next commit will need functions to be reordered. Do it separately to help review. This only moves functions without any change to the code. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
由 Laurent Pinchart 提交于
The function will convert the Q16 source coordinates to integers, avoid converting integers to Q16 first and perform the opposite conversion. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
由 Laurent Pinchart 提交于
Move the set_enabled function to avoid the forward declaration. While at it prefix it with omap_crtc_ like most other functions in the file, and fix the comment stating in which contexts the function is called. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
由 Laurent Pinchart 提交于
The full_update field is always set to true before calling omap_crtc_appy(), resulting in its value always being true in the single location where it is tested, in omap_crtc_pre_apply(). Remove it. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
由 Laurent Pinchart 提交于
The vblank interrupt is used by the driver as a completion signal when applying new settings. A race condition exist between enabling the vblank interrupt and applying new settings to the hardware by setting the GO bit. If a vblank interrupt occurs in-between, the driver will incorrectly consider the new settings to be applied. Fix this by enabling the interrupt after setting the GO bit. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
由 Laurent Pinchart 提交于
The planes don't care about DPMS states, don't propagate it unnecessarily to the plane functions. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
由 Laurent Pinchart 提交于
Remove the CRTC private planes by switching to the universal plane API. This results in a merge of the CRTC private plane created by the driver (omap_crtc->plane) and the CRTC primary plane created by the DRM core (crtc->primary). Reference counting of the framebuffers in the update plane operation is thus simplified as no reference needs to be stored in the private plane anymore. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
由 Laurent Pinchart 提交于
Indenting by one tab is enough. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
-
- 05 11月, 2014 1 次提交
-
-
由 Daniel Vetter 提交于
Just a bit of OCD cleanup on headers - this function isn't the core interface any more but just a helper for drivers who haven't yet transitioned to universal planes. Put the declaration at the right spot and sprinkle necessary #includes over all drivers. Maybe this helps to encourage driver maintainers to do the switch. v2: Fix #include ordering for tegra, reported by 0-day builder. v3: Include required headers, reported by Thierry. Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Thierry Reding <treding@nvidia.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NSean Paul <seanpaul@chromium.org> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
- 05 6月, 2014 1 次提交
-
-
由 Rob Clark 提交于
For atomic, it will be quite necessary to not need to care so much about locking order. And 'state' gives us a convenient place to stash a ww_ctx for any sort of update that needs to grab multiple crtc locks. Because we will want to eventually make locking even more fine grained (giving locks to planes, connectors, etc), split out drm_modeset_lock and drm_modeset_acquire_ctx to track acquired locks. Atomic will use this to keep track of which locks have been acquired in a transaction. v1: original v2: remove a few things not needed until atomic, for now v3: update for v3 of connection_mutex patch.. v4: squash in docbook v5: doc tweaks/fixes Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 15 4月, 2014 4 次提交
-
-
由 Archit Taneja 提交于
The vblank_cb callback and the page_flip ioctl can occur together in different CPU contexts. vblank_cb uses takes tje drm device's event_lock spinlock when sending the vblank event and updating omap_crtc->event and omap_crtc->od_fb. Use the same spinlock in page_flip, to make sure the above omap_crtc parameters are configured sequentially. Signed-off-by: NArchit Taneja <archit@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Archit Taneja 提交于
omap_crtc->old_fb is used to check whether the previous page flip has completed or not. However, it's never initialized to anything, so it's always NULL. This results in the check to always succeed, and the page_flip to proceed. Initialize old_fb to the fb that we intend to flip to through page_flip, and therefore prevent a future page flip to proceed if the last one didn't complete. Signed-off-by: NArchit Taneja <archit@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Archit Taneja 提交于
The channel_names list didn't have a string populated for LCD3 manager, this results in a crash when the display's output is connected to LCD3. Add an entry for LCD3. Reported-by: NSomnath Mukherjee <somnath@ti.com> Signed-off-by: NArchit Taneja <archit@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
All the planes, including primary planes, are now destroyed by the drm framework. Thus we no longer need the explicit call to plane->destroy from the crtc's destroy function. This patch removes the call, thus fixing the crash caused by double freeing the plane. remove omap_crtc->plane->funcs->destroy(omap_crtc->plane) Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 14 4月, 2014 4 次提交
-
-
由 Tomi Valkeinen 提交于
At the moment the omap_crtc_pre_apply() handles the enabling, disabling and configuring of encoders and panels separately from the CRTC (i.e. the overlay manager). However, this doesn't work correctly. The encoder driver has to be in control of its video input (i.e. the crtc) for correct operation. This problem causes bugs with (at least) HDMI: the HDMI encoder supplies pixel clock for DISPC, and DISPC supplies video stream for HDMI. The current code first enables the HDMI encoder, and CRTC after that. However, the encoder expects the video stream to start during the encoder's enable, and if it doesn't, there will be sync lost errors. The encoder enables its video source by calling src->enable(), and this call goes to omapdrm (omap_crtc_enable), but omapdrm doesn't do anything in that function. Similarly for disable, which goes to omap_crtc_disable(). This patch moves the code to setup and enable/disable the crtc to omap_crtc_enable. and omap_crtc_disable(). Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: NRob Clark <robdclark@gmail.com>
-
由 Tomi Valkeinen 提交于
When an encoder is no longer connected to a crtc, the driver will leave the encoder enabled. This patch adds code to track the encoder used for a crtc, and when the encoder changes, the old one is disabled. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: NRob Clark <robdclark@gmail.com>
-
由 Tomi Valkeinen 提交于
At module unload, omap_fbdev_free() gets called which releases the framebuffers. However, the framebuffers are still used by crtcs, and will be released only later at vsync. The driver doesn't wait for this, and goes on to release the rest of the resources, which often causes a crash. This patchs adds a omap_crtc_flush() function which waits until the crtc has finished with its apply queue and page flips. The function utilizes a simple polling while-loop, as the performance is not an issue here. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: NRob Clark <robdclark@gmail.com>
-
由 Tomi Valkeinen 提交于
At the moment it's quite easy to get the following errors when the HDMI output is enabled or disabled: [drm:omap_crtc_error_irq] *ERROR* tv: errors: 00008000 The reason for the errors is that the omapdrm driver doesn't properly handle the sync-lost irqs that happen when enabling the DIGIT crtc, which is used for HDMI and analog TV. The driver does disable the sync-lost irq properly, but it fails to wait until the output has been fully enabled (i.e. the first vsync), so the sync-lost errors are still seen occasionally. This patch makes the omapdrm act the same way as the omapfb does: - When enabling a display, we'll wait for the first vsync. - When disabling a display, we'll wait for framedone if available, or odd and even vsyncs. These changes make sure the output is fully enabled or disabled at the end of the function. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Reported-by: NSanjay Singh Rawat <sanjay.rawat@linaro.org> Reviewed-by: NRob Clark <robdclark@gmail.com>
-
- 02 4月, 2014 1 次提交
-
-
由 Matt Roper 提交于
Now that CRTC's have a primary plane, there's no need to track the framebuffer in the CRTC. Replace all references to the CRTC fb with the primary plane's fb. This patch was generated by the Coccinelle semantic patching tool using the following rules: @@ struct drm_crtc C; @@ - (C).fb + C.primary->fb @@ struct drm_crtc *C; @@ - (C)->fb + C->primary->fb v3: Generate patch via coccinelle. Actual removal of crtc->fb has been moved to a subsequent patch. v2: Fixup several lingering crtc->fb instances that were missed in the first patch iteration. [Rob Clark] Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NRob Clark <robdclark@gmail.com>
-
- 09 1月, 2014 2 次提交
-
-
由 Archit Taneja 提交于
With the omapdss device model changes. omapdrm is required to call dssdriver's connect() op to register a panel. This is currently done in omap_modeset_init() A call to connect() can fail if the omapdss panels or the encoders(HDMI/DPI) they connect to have some resource(like regulators, I2C adapter) missing. If this happens, the correct approach is to defer omapdrm's probe. omapdrm currently ignores those panels which return a non zero value when connected. This could result in omapdrm ignoring all panels on an omap board. The right approach would be for omapdrm to request for probe deferral when a panel's connect op returns -EPROBE_DEFER. In order to do this, we need to call connect() much earlier during omapdrm's probe to prevent too many things are already done by then. We now connect the panels during pdev_probe(), before anything else is initialized, so that we don't need to undo too many things if a defer was requested. Now when we enter omap_modeset_init(), we have a set of panels that have been connected. We now proceed with registering only those panels that are already connected. A special case has to be considered when no panels are available to connect when omapdrm probes. In this case too, we defer probe and expect that a panel will be available to connect the next time. Checking whether the panel has a driver or whether it has get_timing/read_edid ops in omap_modeset_init() are redundant with the new display model. These can be removed since a dssdev device will always have a driver associated with it, and all dssdev drivers have a get_timings op. This will mainly fix cases when omapdrm is built-in the kernel, since that's generally where resources like regulators or I2C are unavailable because of probe order dependencies. In particular this fixes boot with omapdrm built-in on an omap4 panda ES board. The regulators used by HDMI(provided by I2C based TWL regulators) aren't initialized because I2C isn't initialized, I2C isn't initialized as it's pins are not configured because pinctrl is yet to probe. Signed-off-by: NArchit Taneja <archit@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
omapdrm (un)registers irqs inside an irq handler. The problem is that the (un)register function uses dispc_runtime_get/put() to enable the clocks, and those functions are not irq safe by default. This was kind of fixed in 48664b21 (OMAPDSS: DISPC: set irq_safe for runtime PM), which makes dispc's runtime calls irq-safe. However, using pm_runtime_irq_safe in dispc makes the parent of dispc, dss, always enabled, effectively preventing PM for the whole DSS module. This patch makes omapdrm behave better by adding new irq (un)register functions that do not use dispc_runtime_get/put, and using those functions in interrupt context. Thus we can make dispc again non-irq-safe, allowing proper PM. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com> Cc: Rob Clark <robdclark@gmail.com>
-
- 30 8月, 2013 1 次提交
-
-
由 Keith Packard 提交于
This lets drivers see the flags requested by the application [airlied: fixup for rcar/imx/msm] Signed-off-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NDave Airlie <airlied@gmail.com>
-
- 17 6月, 2013 4 次提交
-
-
由 Tomi Valkeinen 提交于
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: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
We currently have two steps in panel initialization and startup: probing and enabling. After the panel has been probed, it's ready and can be configured and later enabled. This model is not enough with more complex display pipelines, where we may have, for example, two panels, of which only one can be used at a time, connected to the same video output. To support that kind of scenarios, we need to add new step to the initialization: connect. This patch adds support for connecting and disconnecting panels. After probe, but before connect, no panel ops should be called. When the connect is called, a proper video pipeline is established, and the panel is ready for use. If some part in the video pipeline is already connected (by some other panel), the connect call fails. One key difference with the old style setup is that connect() handles also connecting to the overlay manager. This means that the omapfb (or omapdrm) no longer needs to figure out which overlay manager to use, but it can just call connect() on the panel, and the proper overlay manager is connected by omapdss. This also allows us to add back the support for dynamic switching between two exclusive panels. However, the current panel device model is not changed to support this, as the new device model is implemented in the following patches and the old model will be removed. The new device model supports dynamic switching. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Tomi Valkeinen 提交于
Currently omapdrm creates crtcs, which map directly to DSS overlay managers, only on demand at init time. This would make it difficult to manage connecting the display entities in the future, as the code cannot just search for a suitable overlay manager. We cannot fix this the sane way, which would be to create crtcs for each overlay manager, because we need an overlay for each crtc. With limited number of overlays, that's not possible. So the solution for now is to detach the overlay manager from the crtc. crtcs are still created on demand at init time, but all overlay managers are always initialized by the omapdss. This way we can create and connect whole display pipelines from the overlay manager to the display, regardless of which crtcs omapdrm would create. Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
由 Ville Syrjälä 提交于
Many of the drivers didn't implement palette/gamma handling, but were forced to provide stubs for the hooks to avoid drm_fb_helper from oopsing. Now that the hooks are optional, we can eliminate all the stubs. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDave Airlie <airlied@gmail.com>
-
- 11 4月, 2013 1 次提交
-
-
由 Archit 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: NArchit Taneja <archit@ti.com> Signed-off-by: NTomi Valkeinen <tomi.valkeinen@ti.com>
-
- 17 2月, 2013 2 次提交
-
-
由 Daniel Vetter 提交于
Omapdrm doesn't do anything nefarious with crtc load detection or has any shared resources, so this is enough. We also need to adjust the WARN_ON. Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NRob Clark <robdclark@gmail.com>
-
由 Rob Clark 提交于
Now that the omapdss interface has been reworked so that omapdrm can use dispc directly, we have been able to fix the remaining functional kms issues with omapdrm. And in the mean time the PM sequencing and many other of that open issues have been solved. So I think it makes sense to finally move omapdrm out of staging. Signed-off-by: NRob Clark <robdclark@gmail.com>
-
- 12 2月, 2013 1 次提交
-
-
由 Joe Perches 提交于
alloc failures already get standardized OOM messages and a dump_stack. For the affected mallocs around these OOM messages: Converted kzallocs with multiplies to kcalloc. Converted kmallocs with multiplies to kmalloc_array. Converted a kmalloc/strlen/strncpy to kstrdup. Moved a spin_lock below a removed OOM message and removed a now unnecessary spin_unlock. Neatened alignment and whitespace. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 21 1月, 2013 1 次提交
-
-
由 Daniel Vetter 提交于
I've left the locking in the debugfs code as-is, it's essentially just used to keep the framebuffer object alive (which won't be necessary any more later on). We don't need fb refcounting either, since the new mode_config.fb_lock ensures that the framebuffers can't disappear (once mode_config.mutex doesn't guarantee this any more later on in the series). The fbcon restore needs all modeset locks. The crtc callbacks seem to only need the crtc locks, but I've quickly discussed things with Rob Clark and he's fine with just using modeset_lock_all for those, too. He'll look into converting things over later. Reviewed-by: NRob Clark <rob@ti.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 08 1月, 2013 1 次提交
-
-
由 Rob Clark 提交于
This patch changes the omapdrm KMS to bypass the omapdss "compat" layer and use the core omapdss API directly. This solves some layering issues that would cause unpin confusion vs GO bit status, because we would not know whether a particular pageflip or overlay update has hit the screen or not. Now instead we explicitly manage the GO bits in dispc and handle the vblank/framedone interrupts ourself so that we always know which buffers are being scanned out at any given time, and so on. As an added bonus, we no longer leave the last overlay buffer pinned when the display is disabled, and have been able to add the previously missing vblank event handling. v1: original v2: rebased on latest staging-next and omapdss patches from Tomi and review comments from Archit Taneja Signed-off-by: NRob Clark <robdclark@gmail.com> Reviewed-by: NArchit Taneja <archit@ti.com> Reviewed-by: NSumit Semwal <sumit.semwal@ti.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 15 11月, 2012 1 次提交
-
-
由 YAMANE Toshiaki 提交于
The following warning fixed. - WARNING: braces {} are not necessary for single statement blocks Signed-off-by: NYAMANE Toshiaki <yamanetoshi@gmail.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-