- 23 Sep, 2016 2 commits
-
-
Daniel Schultz authored
When 'component_bind_all' fails it should not try to unbind components in the error handling. This will produce a null pointer kernel panic when no component exist. This patch changes the order of the error handling. Now, it will only unbind components if the are bound. Otherwise, the module will jump to an error label below. Signed-off-by:
Daniel Schultz <d.schultz@phytec.de> Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
Jyri Sarha <jsarha@ti.com>
-
Markus Elfring authored
Return directly after a memory allocation failed in this function at the beginning. Signed-off-by:
Markus Elfring <elfring@users.sourceforge.net> Signed-off-by:
-
- 22 Sep, 2016 4 commits
-
-
Jyri Sarha authored
Remove "default" keyword from blue-and-red-wiring devicetree property binding document. The code does not support and there is no intention to support it. Reported-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Wei Yongjun authored
Fixes the following sparse warning: drivers/gpu/drm/tilcdc/tilcdc_drv.c:64:5: warning: symbol 'tilcdc_atomic_check' was not declared. Should it be static? Signed-off-by:
Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by:
-
Baoyou Xie authored
We get 3 warnings when building kernel with W=1: drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c:142:29: warning: no previous prototype for 'tilcdc_get_overlay' [-Wmissing-prototypes] drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c:198:13: warning: no previous prototype for 'tilcdc_convert_slave_node' [-Wmissing-prototypes] drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c:264:12: warning: no previous prototype for 'tilcdc_slave_compat_init' [-Wmissing-prototypes] In fact, these functions are only used in the file in which they are declared and don't need a declaration, but can be made static. So this patch marks these functions with 'static'. Signed-off-by:
Baoyou Xie <baoyou.xie@linaro.org> Signed-off-by:
-
Baoyou Xie authored
We get 4 warnings when building kernel with W=1: drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:393:12: warning: no previous prototype for 'tilcdc_tfp410_init' [-Wmissing-prototypes] drivers/gpu/drm/tilcdc/tilcdc_tfp410.c:398:13: warning: no previous prototype for 'tilcdc_tfp410_fini' [-Wmissing-prototypes] drivers/gpu/drm/tilcdc/tilcdc_panel.c:443:12: warning: no previous prototype for 'tilcdc_panel_init' [-Wmissing-prototypes] drivers/gpu/drm/tilcdc/tilcdc_panel.c:448:13: warning: no previous prototype for 'tilcdc_panel_fini' [-Wmissing-prototypes] In fact, these functions are declared in drivers/gpu/drm/tilcdc/tilcdc_tfp410.h, drivers/gpu/drm/tilcdc/tilcdc_panel.h, so this patch adds missing header dependencies. Signed-off-by:
-
- 07 Sep, 2016 6 commits
-
-
Jyri Sarha authored
WARN if CRTC is touched without CRTC lock. The crtc functions should not be called simultaneously from multiple threads. Having the DRM CRTC lock should take care of that. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com>
-
Jyri Sarha authored
Take CRTC lock when calling tilcdc_crtc_disable() in tilcdc_crtc_destroy(). In theory there could still be some operation ongoing, which should finish before destroying the CRTC. However, the main reason for adding this is to be able to add WARNing in tilcdc_crtc_disable() if CRTC is not locked. Signed-off-by:
-
Jyri Sarha authored
Remove unnecessary tilcdc_crtc_disable() from tilcdc_unload(). The tilcdc_crtc_disable() called via tilcdc_crtc_destroy() by drm_mode_config_cleanup() couple of lines later. The early call to tilcdc_crtc_disable() was a wrong fix (that worked) for calling drm_flip_work_cleanup() before flushing the flip-work queue. Signed-off-by:
-
Jyri Sarha authored
Flush flip-work workqueue before drm_flip_work_cleanup(). It causes a nasty warning if there is unfinished flip-work in the queue when drm_flip_work_cleanup() is called. The flush_workqueue() has to be called before drm_crtc_cleanup() for unref_worker() to be able to do its job. Signed-off-by:
-
Jyri Sarha authored
Clean up LCDC functional clock rate setting code. The LCDC functional clock is set by two functions: mode_set_nofb() and cpufreq_transition(). When tilcdc_crtc_mode_set_nofb() is called in atomic commit phase the drm atomic helpers have taken all the necessary drm locks and turned off the crtc, while tilcdc_commit() is keeping LCDC powered on. For mode_set_nofb() just a simple clock setting function without any locking or power management code is enough. The new tilcdc_crtc_set_clk() is implemented for that purpose. cpufreq_transition() on the other hand is called from outside DRM and it needs to take the necessary locks and turn off the CRTC while keeping the LCDC powered. The reimplemented tilcdc_crtc_update_clk() is for that purpose and it uses the new tilcdc_crtc_set_clk() to actually set the clock. Signed-off-by:
-
Jyri Sarha authored
Take crtc modeset lock while updating the crtc clock rate. To avoid a race in tilcdc_crtc_update_clk(), we do not want crtc mode to change while we update crtc clock. Signed-off-by:
-
- 01 Sep, 2016 7 commits
-
-
Jyri Sarha authored
Choose console BPP that supports RGB and remove the old fbdev bpp selection code. LCDC on AM335x has red and blue wires switched between 24 bit and 16 bit colors. If 24 format is wired for RGB colors, the 16 bit format is wired for BGR. drm_fbdev_cma_init() does not currently like anything else but RGB formats, so we must choose such bytes per pixel value that supports RGB. Signed-off-by:
-
Jyri Sarha authored
Add "blue-and-red-wiring"-device tree property and update devicetree binding document. The red and blue components are reversed between 24 and 16 bit modes on am335x LCDC output pins. To get 24 RGB format the red and blue wires has to be crossed and this in turn causes 16 colors output to be in BGR format. With straight wiring the 16 color is RGB and 24 bit is BGR. The new property describes whether the red and blue wires are crossed or not. If the property is not present or its value is not recognized the legacy mode is assumed. The legacy configuration supports RGB565, RGB888 and XRGB8888 formats. However, depending on wiring, the red and blue colors are swapped in either 16 or 24-bit color modes. For more details see section 3.1.1 in AM335x Silicon Errata: http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360Signed-off-by:
-
Jyri Sarha authored
Write DMA base and ceiling address with a single instruction, if available. This should make it more unlikely that LCDC would fetch the DMA addresses in the middle of an update. Having bad combination of addresses in dma base and ceiling (e.g base > ceiling) can cause unpredictaple behavior in LCDC. Signed-off-by:
-
Jyri Sarha authored
drm_helper_disable_unused_functions() should not be called by atomic drivers. Signed-off-by:
-
Karl Beldan authored
This got accidentally dropped in the fixed commit and is required for the driver to properly work on the rev1 IP, such as found on the LCDK. Fixes: 2b2080d7 ("drm/tilcdc: Get rid of complex ping-pong mechanism") Signed-off-by:
Karl Beldan <kbeldan@baylibre.com> Signed-off-by:
-
Karl Beldan authored
The LCDC seems to expect its framebuffer ceiling address pointer to be an inclusive bound. The IP rev2 seems to cope with that but rev1 (as found on the LCDK) don't. Also note that this is what the framebuffer code does in da8xx-fb.c. Since, as the TRM puts it, "The 2 LSBs are hardwired to 00b", the dma_addr_t can be decremented without cast. I tested it with a v2 (AM335x, rev 0x4F201000) and an LCDK (v1). Signed-off-by:
-
Teresa Remmet authored
In function tilcdc_get_external_components the check for the remote port parent is not correct. We need a '||' instead of an '&&'. Signed-off-by:
Teresa Remmet <t.remmet@phytec.de> Signed-off-by:
-
- 31 Aug, 2016 3 commits
-
-
Dave Airlie authored
This reverts commit d10571fc. This isn't how we get to do this unfortunately. Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
More -misc stuff - moar drm_crtc.c split up&documentation - some fixes for the simple kms helpers (Andrea) - I included all the dri1 patches from David - we're not removing any code or drivers, and it seems to have worked as a wake-up call to motivate a few more people to upstream kms conversions for these. Feel free to revert if you disagree strongly. - a few other single patches * tag 'topic/drm-misc-2016-08-31' of git://anongit.freedesktop.org/drm-intel: (24 commits) drm: drm_probe_helper: Fix output_poll_work scheduling drm: bridge/dw-hdmi: Fix colorspace and scan information registers values drm/doc: Polish docs for drm_property&drm_property_blob drm: Unify handling of blob and object properties drm: Extract drm_property.[hc] drm: move drm_mode_legacy_fb_format to drm_fourcc.c drm/doc: Polish docs for drm_mode_object drm: Remove drm_mode_object->atomic_count drm: Extract drm_mode_object.[hc] drm/doc: Polish kerneldoc for encoders drm: Extract drm_encoder.[hc] drm/fb-helper: don't call remove_conflicting_framebuffers for FB=m && DRM=y drm/atomic-helper: Add NO_DISABLE_AFTER_MODESET flag support for plane commit drm/atomic-helper: Disable appropriate planes in disable_planes_on_crtc() drm/atomic-helper: Add atomic_disable CRTC helper callback drm: simple_kms_helper: add support for bridges drm: simple_kms_helper: make connector optional at init time drm/bridge: introduce bridge detaching mechanism drm/simple-helpers: Always add planes to the state update drm: reduce GETCLIENT to a minimum ...
-
Peter Ujfalusi authored
drm_kms_helper_poll_enable_locked() should check if we have delayed event pending and if we have, schedule the work to run without delay. Currently the output_poll_work is only scheduled if any of the connectors have DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT with DRM_OUTPUT_POLL_PERIOD delay. It does not matter if we have delayed event already registered to be handled. The detection will be delayd by DRM_OUTPUT_POLL_PERIOD in any case. Furthermore if none of the connectors are marked as POLL_CONNECT or POLL_DISCONNECT because all connectors are either POLL_HPD or they are always connected: the output_poll_work will not run at all even if we have delayed event marked. When none of the connectors require polling, their initial status change from unknown to connected/disconnected is not going to be handled until the first kms application starts or if we have fb console enabled. Note that in general the output poll work should be enabled already when this happens, but at driver load usually the first probe happens before the output polling is enabled. This patch fixes this case. Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> [danvet: Note when exactly this is an issue, since the probe code schedules the poll work itself already.] Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20160831110905.31289-1-peter.ujfalusi@ti.com
-
- 30 Aug, 2016 1 commit
-
-
Jose Abreu authored
Colorspace and scan information values were being written in wrong offsets. This patch corrects this and writes the values at the offsets specified in the databook. Signed-off-by:
Jose Abreu <joabreu@synopsys.com> Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Cc: Carlos Palminha <palminha@synopsys.com> Cc: Archit Taneja <architt@codeaurora.org> Cc: David Airlie <airlied@linux.ie> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/96fd0f06b7ebc2ee5cb8239a99648f3107e24497.1471530573.git.joabreu@synopsys.com
-
- 29 Aug, 2016 16 commits
-
-
Daniel Vetter authored
- remove kerneldoc for drm-internal functions - drm_property_replace_global_blob isn't actually atomic, and doesn't need to be. Update docs&comments to match - document all the types and try to link things a bit better - nits all over v2: Appease checkpatch in the moved code (Archit) Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160829082757.17913-9-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
They work exactly the same now, after the refcounting unification a bit ago. The only reason they're distinct is backwards compat with existing userspace. Cc: Daniel Stone <daniels@collabora.com> Reviewed-by:
-
Daniel Vetter authored
This just contains the base property classes and all the code to handle blobs. I think for any kind of standardized/shared properties it's better to have separate files - this is fairly big already as-is. v2: resurrect misplaced hunk (Daniel Stone) Cc: Daniel Stone <daniel@fooishbar.org> Reviewed-by:
-
Daniel Vetter authored
It's part of the drm fourcc handling code, mapping the old depth/bpp values to new fourcc codes. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Daniel Vetter authored
I figured an overview section here is overkill, and better to just document the 2 structures themselves well enough. v2: Review from Archit: - Appease checkpatch in moved code. - Spelling fixes in the kerneldoc. Reviewed-by:
-
Daniel Vetter authored
It's only used in drm_mode_object_get_properties, and we can compute it there directly with a bit of code shuffling. Reviewed-by:
-
Daniel Vetter authored
Just for the struct drm_mode_object base class. The header file was already partially extracted to help untangle the include loops. v2: - Also move the generic get/set property ioctls. At first this seemed like a bad idea since it requires making drm_mode_crtc_set_obj_prop non-static. But eventually that will get split away too (like the connector version already is) for both crtc and planes. Hence I reconsidered. - drm_mode_object.[hc] instead of drm_modeset.[hc], which requires renaming the drm_modeset.h header I already started building up. This is more consistent (matches the name of the main structure), and I want to be able to use drm_modeset.[hc] for the basic modeset init/cleanup functionality like drm_mode_config_init. Reviewed-by:
-
Daniel Vetter authored
- Move missing bits into struct drm_encoder docs. - Explain that encoders are 95% internal and only 5% uapi, and that in general the uapi part is broken. - Remove verbose comments for functions not exposed to drivers. v2: Review from Archit: - Appease checkpatch in the moved code. - Make it clearer that bridges are not exposed to userspace. Reviewed-by:
-
Daniel Vetter authored
Same treatment as before. Only hiccup is drm_crtc_mask, which unfortunately can't be resolved until drm_crtc.h is less of a monster. Untangle the header loop with a forward declaration for that static inline. Reviewed-by:
-
Arnd Bergmann authored
When CONFIG_DRM_KMS_FB_HELPER is disabled, we can have a configuration in which some DRM drivers are built-in, but the framebuffer core is a loadable module. This results in a link error, such as: drivers/gpu/drm/radeon/radeon.o: In function `radeon_pci_probe': radeon_kfd.c:(.text.radeon_pci_probe+0xbc): undefined reference to `remove_conflicting_framebuffers' drivers/gpu/drm/amd/amdgpu/amdgpu.o: In function `amdgpu_pci_probe': amdgpu_mn.c:(.text.amdgpu_pci_probe+0xa8): undefined reference to `remove_conflicting_framebuffers' drivers/gpu/drm/mgag200/mgag200.o: In function `mga_vram_init': mgag200_ttm.c:(.text.mga_vram_init+0xa8): undefined reference to `remove_conflicting_framebuffers' drivers/gpu/drm/mgag200/mgag200.o: In function `mga_pci_probe': mgag200_ttm.c:(.text.mga_pci_probe+0x88): undefined reference to `remove_conflicting_framebuffers' Makefile:969: recipe for target 'vmlinux' failed This changes the compile-time check to IS_REACHABLE, which means we end up not calling remove_conflicting_framebuffers() in the configuration, which seems good enough, as we know that no framebuffer driver is loaded by the time that the built-in DRM driver calls remove_conflicting_framebuffers. We could alternatively avoid the link error by forcing CONFIG_FB to not be a module in this case, but that wouldn't change anything at runtime, and just make the already convoluted set of dependencies worse here. I could not find out what happens if the fbdev driver gets loaded as a module after the DRM driver is already initialized, but that is a case that can happen with or without this patch. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 0a3bfe29 ("drm/fb-helper: Fix the dummy remove_conflicting_framebuffers") Signed-off-by:
-
Liu Ying authored
Drivers may set the NO_DISABLE_AFTER_MODESET flag in the 'flags' parameter of the helper drm_atomic_helper_commit_planes() if the relevant display controllers(e.g., IPUv3 for imx-drm) require to disable a CRTC's planes when the CRTC is disabled. The helper would skip the ->atomic_disable call for a plane if the CRTC of the old plane state needs a modesetting operation. Of course, the drivers need to disable the planes in their CRTC disable callbacks since no one else would do that. Suggested-by:
Liu Ying <gnuiyl@gmail.com> Signed-off-by:
-
Liu Ying authored
Currently, the helper drm_atomic_helper_disable_planes_on_crtc() calls ->atomic_disable for all planes _to be_ enabled on a particular CRTC. This is obviously wrong for those planes which are not scanning out frames when the helper is called. Instead, it's sane to disable active planes of old_crtc_state in the helper. Suggested-by:
-
Liu Ying authored
Some display controllers need plane(s) to be disabled together with the relevant CRTC, e.g., the IPUv3 display controller for imx-drm. This patch adds atomic_disable CRTC helper callback so that old_crtc_state(as a parameter of the callback) could be used to get the active plane(s) of the old CRTC state for disable operation. Suggested-by:
-
Andrea Merello authored
Introduce drm_simple_display_pipe_attach_bridge() and drm_simple_display_pipe_detach_bridge() in order to make it possible to use drm encoders with the simple display pipes managed by simple_kms_helpers Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Andrea Merello <andrea.merello@gmail.com> Reviewed-by:
-
Andrea Merello authored
drm_simple_display_pipe_init() pretends to attach a connector to the display pipe. In case a drm bridge has to be used, then it's the bridge that takes care of connectors. This patch makes the connector parameter optional for drm_simple_display_pipe_init(), so that a drm bridge could handle connector by itself later. Signed-off-by:
-
Andrea Merello authored
Up to now, once a bridge has been attached to a DRM device, it cannot be undone. In particular you couldn't rmmod/insmod a DRM driver that uses a bridge, because the bridge would remain bound to the first (dead) driver instance. This patch fixes this by introducing drm_encoder_detach() and a ->detach callback in drm_bridge_funcs for the bridge to be notified about detaches. It's DRM/KMS driver responsibility to call drm_encoder_detach(). While adding the bridge detach callback, with its kerneldoc, I also added kerneldoc for attach callback. Few other kerneldocs fixes around there are included. Suggested-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
- 25 Aug, 2016 1 commit
-
-
Daniel Vetter authored
Our update function is hooked to the single plane, which might not get called for crtc-only updates. Which is surprising, so fix this by always adding the plane. While at it document how&when the event should be sent out better in the kerneldoc. Cc: Noralf Trønnes <noralf@tronnes.org> Cc: andrea.merello@gmail.com Tested-and-Reported-by: andrea.merello@gmail.com Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
-
