summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2019-03-25Merge tag 'du-next-20190318' of git://linuxtv.org/pinchartl/media into drm-nextDave Airlie
Renesas display drivers changes for v5.2: - Display writeback (includes VSP changes and DRM/KMS API changes) (All v4l patches acked by Mauro) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190318153613.GE12707@pendragon.ideasonboard.com
2019-03-25Merge tag 'omapdrm-5.2' of ↵Dave Airlie
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next omapdrm changes for 5.2 - Implement drm_bridge and drm_panel support for omapdrm - Drop omapdrm's panel-dpi, tfp410 and connector-dvi drivers - New DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags - Improvements to tfp410 driver - OSD070T1718-19TS panel support to simple-panel - panel-tpo-td028ttec1 backlight support Signed-off-by: Dave Airlie <airlied@redhat.com> From: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/670dc1ce-feaf-b88e-780f-b99251b88a82@ti.com
2019-03-22Merge branch 'drm-fixes-5.1' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-fixes - Parially revert a bulk move clean up change to fix a ref count bug - Fix invalid use of change_bit that caused a crash on PPC64 and ARM64 Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190321020933.3508-1-alexander.deucher@amd.com
2019-03-22Merge branch 'vmwgfx-fixes-5.1' of ↵Dave Airlie
git://people.freedesktop.org/~thomash/linux into drm-fixes Two fixes CC'd stable. One fix for a long-standing a bit hard-to-trigger fbdev modesetting bug and one out-of-bo-id fix. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Hellstrom <thellstrom@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190321112026.114328-1-thellstrom@vmware.com
2019-03-22Merge tag 'exynos-drm-fixes-for-5.1-rc2' of ↵Dave Airlie
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes - Fix page fault issue at Mixer device . This patch fixes the page fault issue by correcting sychronization method for updating shadow registers for Mixer device. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Inki Dae <inki.dae@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/1553162223-10090-1-git-send-email-inki.dae@samsung.com
2019-03-22Merge tag 'drm-intel-fixes-2019-03-20' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes A protection on our mmap against attempts to map past the end of the object; plus a fix off-by-one in our hang report and a protection; and a fix for eDP panels on Gen9 platforms on VBT absence. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190320201451.GA7993@intel.com
2019-03-22Merge branch 'linux-5.1' of git://github.com/skeggsb/linux into drm-fixesDave Airlie
Some minor nouveau dmem and other fixes. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/CABDvA==kMkD6n-cS9KpQBcTU1E8p7Wc+H1ZuOhSfD7yTFJVvkw@mail.gmail.com
2019-03-22drm/nouveau/dmem: empty chunk do not have a buffer object associated with them.Jérôme Glisse
Empty chunk do not have a bo associated with them so no need to pin/unpin on suspend/resume. This fix suspend/resume on 5.1rc1 when NOUVEAU_SVM is enabled. Signed-off-by: Jérôme Glisse <jglisse@redhat.com> Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Tested-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-03-22drm/nouveau/debugfs: Fix check of pm_runtime_get_sync failureYueHaibing
pm_runtime_get_sync returns negative on failure. Fixes: eaeb9010bb4b ("drm/nouveau/debugfs: Wake up GPU before doing any reclocking") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-03-22drm/nouveau/dmem: Fix a NULL vs IS_ERR() checkDan Carpenter
The hmm_devmem_add() function doesn't return NULL, it returns error pointers. Fixes: 5be73b690875 ("drm/nouveau/dmem: device memory helpers for SVM") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-03-22drm/nouveau/dmem: remove set but not used variable 'drm'YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning: drivers/gpu/drm/nouveau/nouveau_dmem.c: In function 'nouveau_dmem_free': drivers/gpu/drm/nouveau/nouveau_dmem.c:103:22: warning: variable 'drm' set but not used [-Wunused-but-set-variable] struct nouveau_drm *drm; ^ Signed-off-by: YueHaibing <yuehaibing@huawei.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2019-03-21drm/exynos/mixer: fix MIXER shadow registry synchronisation codeAndrzej Hajda
MIXER on Exynos5 SoCs uses different synchronisation method than Exynos4 to update internal state (shadow registers). Apparently the driver implements it incorrectly. The rule should be as follows: - do not request updating registers until previous request was finished, ie. MXR_CFG_LAYER_UPDATE_COUNT must be 0. - before setting registers synchronisation on VSYNC should be turned off, ie. MXR_STATUS_SYNC_ENABLE should be reset, - after finishing MXR_STATUS_SYNC_ENABLE should be set again. The patch hopefully implements it correctly. Below sample kernel log from page fault caused by the bug: [ 25.670038] exynos-sysmmu 14650000.sysmmu: 14450000.mixer: PAGE FAULT occurred at 0x2247b800 [ 25.677888] ------------[ cut here ]------------ [ 25.682164] kernel BUG at ../drivers/iommu/exynos-iommu.c:450! [ 25.687971] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM [ 25.693778] Modules linked in: [ 25.696816] CPU: 5 PID: 1553 Comm: fb-release_test Not tainted 5.0.0-rc7-01157-g5f86b1566bdd #136 [ 25.705646] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 25.711710] PC is at exynos_sysmmu_irq+0x1c0/0x264 [ 25.716470] LR is at lock_is_held_type+0x44/0x64 v2: added missing MXR_CFG_LAYER_UPDATE bit setting in mixer_enable_sync Reported-by: Marian Mihailescu <mihailescu2m@gmail.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2019-03-20drm/vmwgfx: Don't double-free the mode stored in par->set_modeThomas Zimmermann
When calling vmw_fb_set_par(), the mode stored in par->set_mode gets free'd twice. The first free is in vmw_fb_kms_detach(), the second is near the end of vmw_fb_set_par() under the name of 'old_mode'. The mode-setting code only works correctly if the mode doesn't actually change. Removing 'old_mode' in favor of using par->set_mode directly fixes the problem. Cc: <stable@vger.kernel.org> Fixes: a278724aa23c ("drm/vmwgfx: Implement fbdev on kms v2") Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Deepak Rawat <drawat@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2019-03-20drm/vmwgfx: Return 0 when gmrid::get_node runs out of ID'sDeepak Rawat
If it's not a system error and get_node implementation accommodate the buffer object then it should return 0 with memm::mm_node set to NULL. v2: Test for id != -ENOMEM instead of id == -ENOSPC. Cc: <stable@vger.kernel.org> Fixes: 4eb085e42fde ("drm/vmwgfx: Convert to new IDA API") Signed-off-by: Deepak Rawat <drawat@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
2019-03-19drm/amdgpu: fix invalid use of change_bitChristian König
We only need to clear the bit in a 32bit integer. This fixes a crah on ARM64 and PPC64LE caused by "drm/amdgpu: update the vm invalidation engine layout V2" Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-03-19drm/amdgpu: revert "cleanup setting bulk_movable"Christian König
This reverts commit 8466cc61da89d33441e0d7a98de1ba98697cd465. It can trigger a reference counter bug in TTM. Need to investigate further, but for now revert the offending change. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Tested-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2019-03-18drm/i915: Sanity check mmap length against object sizeChris Wilson
We assumed that vm_mmap() would reject an attempt to mmap past the end of the filp (our object), but we were wrong. Applications that tried to use the mmap beyond the end of the object would be greeted by a SIGBUS. After this patch, those applications will be told about the error on creating the mmap, rather than at a random moment on later access. Reported-by: Antonio Argenziano <antonio.argenziano@intel.com> Testcase: igt/gem_mmap/bad-size Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Antonio Argenziano <antonio.argenziano@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190314075829.16838-1-chris@chris-wilson.co.uk (cherry picked from commit 794a11cb67201ad1bb61af510bb8460280feb3f3) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-03-18drm/i915: Fix off-by-one in reporting hanging processChris Wilson
ffs() is 1-indexed, but we want to use it as an index into an array, so use __ffs() instead. Fixes: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on struct_mutex") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190315163933.19352-1-chris@chris-wilson.co.uk (cherry picked from commit 9073e5b26743b8b675cc44a9c0c8f8c3d584e1c0) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-03-18drm/i915/bios: assume eDP is present on port A when there is no VBTThomas Preston
We rely on VBT DDI port info for eDP detection on GEN9 platforms and above. This breaks GEN9 platforms which don't have VBT because port A eDP now defaults to false. Fix this by defaulting to true when VBT is missing. Fixes: a98d9c1d7e9b ("drm/i915/ddi: Rely on VBT DDI port info for eDP detection") Signed-off-by: Thomas Preston <thomas.preston@codethink.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190306200618.17405-1-thomas.preston@codethink.co.uk (cherry picked from commit 2131bc0ced6088648e47f126566c3da58b07e4ef) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2019-03-18drm: rcar-du: Add writeback support for R-Car Gen3Laurent Pinchart
Implement writeback support for R-Car Gen3 by exposing writeback connectors. Behind the scene the calls are forwarded to the VSP backend. Using writeback connectors will allow implemented writeback support for R-Car Gen2 with a consistent API if desired. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2019-03-18drm: rcar-du: vsp: Extract framebuffer (un)mapping to separate functionsLaurent Pinchart
The rcar_du_vsp_plane_prepare_fb() and rcar_du_vsp_plane_cleanup_fb() functions implement the DRM plane .prepare_fb() and .cleanup_fb() operations. They map and unmap the framebuffer to/from the VSP internally, which will be useful to implement writeback support. Split the mapping and unmapping out to separate functions. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2019-03-18drm: rcar-du: Store V4L2 fourcc in rcar_du_format_info structureLaurent Pinchart
The mapping between DRM and V4L2 fourcc's is stored in two separate tables in rcar_du_vsp.c. In order to make it reusable to implement writeback support, move it to the rcar_du_format_info structure. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2019-03-18drm: rcar-du: Fix rcar_du_crtc structure documentationLaurent Pinchart
The rcar_du_crtc structure index field contains the CRTC hardware index, not the hardware and software index. Update the documentation accordingly. Fixes: 5361cc7f8e91 ("drm: rcar-du: Split CRTC handling to support hardware indexing") Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2019-03-18drm: writeback: Add job prepare and cleanup operationsLaurent Pinchart
As writeback jobs contain a framebuffer, drivers may need to prepare and cleanup them the same way they can prepare and cleanup framebuffers for planes. Add two new optional connector helper operations, .prepare_writeback_job() and .cleanup_writeback_job() to support this. The job prepare operation is called from drm_atomic_helper_prepare_planes() to avoid a new atomic commit helper that would need to be called by all drivers not using drm_atomic_helper_commit(). The job cleanup operation is called from the existing drm_writeback_cleanup_job() function, invoked both when destroying the job as part of a aborted commit, or when the job completes. The drm_writeback_job structure is extended with a priv field to let drivers store per-job data, such as mappings related to the writeback framebuffer. For internal plumbing reasons the drm_writeback_job structure needs to store a back-pointer to the drm_writeback_connector. To avoid pushing too much writeback-specific knowledge to drm_atomic_uapi.c, create a drm_writeback_set_fb() function, move the writeback job setup code there, and set the connector backpointer. The prepare_signaling() function doesn't need to allocate writeback jobs and can ignore connectors without a job, as it is called after the writeback jobs are allocated to store framebuffers, and a writeback fence with a framebuffer is an invalid configuration that gets rejected by the commit check. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
2019-03-18drm: writeback: Fix leak of writeback jobLaurent Pinchart
Writeback jobs are allocated when the WRITEBACK_FB_ID is set, and deleted when the jobs complete. This results in both a memory leak of the job and a leak of the framebuffer if the atomic commit returns before the job is queued for processing, for instance if the atomic check fails or if the commit runs in test-only mode. Fix this by implementing the drm_writeback_cleanup_job() function and calling it from __drm_atomic_helper_connector_destroy_state(). As writeback jobs are removed from the state when they're queued for processing, any job left in the state when the state gets destroyed needs to be cleaned up. The existing declaration of the drm_writeback_cleanup_job() function without an implementation hints that this problem was considered, but never addressed. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Brian Starkey <brian.starkey@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com>
2019-03-18drm: writeback: Cleanup job ownership handling when queuing jobLaurent Pinchart
The drm_writeback_queue_job() function takes ownership of the passed job and requires the caller to manually set the connector state writeback_job pointer to NULL. To simplify drivers and avoid errors (such as the missing NULL set in the vc4 driver), pass the connector state pointer to the function instead of the job pointer, and set the writeback_job pointer to NULL internally. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Brian Starkey <brian.starkey@arm.com> Acked-by: Eric Anholt <eric@anholt.net> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
2019-03-18media: vsp1: drm: Extend frame completion API to the DU driverLaurent Pinchart
The VSP1 driver will need to pass extra flags to the DU through the frame completion API. Replace the completed bool flag by a bitmask to support this. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
2019-03-18drm/omap: panel-tpo-td028ttec1: add backlight supportAndreas Kemnade
This panel has a backlight, so fetch it from devicetree using the corresponding property as documented in panel-common.txt. It is implemented the same way as in panel-dpi.c This ensures the backlight is also disabled when the display is turned off like when doing xset dpms force off. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: dsi: Fix PM for display blank with paired dss_pll callsTony Lindgren
Currently dsi_display_init_dsi() calls dss_pll_enable() but it is not paired with dss_pll_disable() in dsi_display_uninit_dsi(). This leaves the DSS clocks enabled when the display is blanked wasting about extra 5mW of power while idle. The clock that is left on by not calling dss_pll_disable() is DSS_CLKCTRL bit 10 OPTFCLKEN_SYS_CLK that is the source clock for DSI PLL. We can fix this issue by by making the current dsi_pll_uninit() into dsi_pll_disable(). This way we can just call dss_pll_disable() from dsi_display_uninit_dsi() and the code becomes a bit easier to follow. However, we need to also consider that DSI PLL can be muxed for DVI too as pointed out by Tomi Valkeinen <tomi.valkeinen@ti.com>. In the DVI case, we want to unconditionally disable the clocks. To get around this issue, we separate out the DSI lane handling from dsi_pll_enable() and dsi_pll_disable() as suggested by Tomi in an earlier experimental patch. So we must only toggle the DSI regulator based on the vdds_dsi_enabled flag from dsi_display_init_dsi() and dsi_display_uninit_dsi(). We need to make these two changes together to avoid breaking things for DVI when fixing the DSI clock handling. And this all causes a slight renumbering of the error path for dsi_display_init_dsi(). Suggested-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Remove panel-dpi driverLaurent Pinchart
Panels are now supported through the drm_panel infrastructure, remove the omapdrm-specific driver. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Remove TFP410 and DVI connector driversLaurent Pinchart
Those components are supported by the drm_bridge infrastructure, remove the omapdrm-specific driver. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Whitelist DT nodes to fixup with omapdss, prefixLaurent Pinchart
The omapdss driver patches DT at runtime to prepend an "omapdss," prefix to the compatible string of all encoders, panels and connectors. This mechanism ensures they get bound to the omapdss-specific drivers instead of generic drivers. Now that we have drm_bridge support in omapdrm, we need to selectively disable this mechanism. Add a whitelist of compatible strings to patch, and fill it with all the devices we support. They will be removed one by one once corresponding drm_bridge drivers become available and get successfully tested with omapdrm. The omapdss components load check code is updated accordingly to ignore devices managed by external bridge drivers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Add support for drm_panelLaurent Pinchart
Hook up drm_panel support in the omapdrm driver. The change is relatively simply as the way has been paved by drm_bridge support already. In addition to looking up, attaching to and detaching from the panel, we only need to add panel support in the connector .get_modes() handler, take connector bus flags (set by the panel) into account, and enable/disable the panel in the encoder enable/disable operations handlers. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Add support for drm_bridgeLaurent Pinchart
Hook up drm_bridge support in the omapdrm driver. Despite the recent extensive preparation work, this is a rather intrusive change, as the management of outputs needs to be adapted through the driver to handle both omap_dss_device and drm_bridge. Connector creation is skipped when using a drm_bridge, as the bridge creates the connector internally. This creates issues with systems that split connector operations (such as modes retrieval and hot-plug detection) across different bridges. These systems can't be supported using drm_bridge for now (their support through the omap_dss_device infrastructure is not affected), this will be fixed in subsequent changes. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/panel: simple: Add OSD070T1718-19TS panel supportLaurent Pinchart
Add support for the OSD070T1718-19TS 7" 800x480 panel from One Stop Displays to the panel-simple driver. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/bridge: ti-tfp410: Report input bus config through bridge timingsLaurent Pinchart
The TFP410 supports configurable pixel clock sampling edge and data de-skew adjustments. The configuration can be set through I2C or dedicated chip pins. Report the configuration through the drm_bridge timings. As the ti-tftp410 driver doesn't support configuring the chip through I2C, we simply use the default configuration in that case. When the chip is configured through dedicated pins, we parse the configuration from DT. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Jyri Sarha <jsarha@ti.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/bridge: ti-tfp410: Add support for the powerdown GPIOLaurent Pinchart
The TFP410 has a powerdown pin that can be connected to a GPIO to control power saving. The DT bindings define a corresponding property, but the driver doesn't implement support for it. Fix that. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Jyri Sarha <jsarha@ti.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/bridge: ti-tfp410: Set connector type based on DT connector nodeLaurent Pinchart
The TI TFP410 is a DVI encoder, not a full HDMI encoder. Its output can be routed to a DVI-D connector, even if in many cases embedded systems will use an HDMI connector to carry the DVI signals. Instead of hardcoding the connector type to HDMI, retrieve the connector type from its DT node. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by: Jyri Sarha <jsarha@ti.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/bridge: use bus flags in bridge timingsStefan Agner
The DRM bus flags convey additional information on pixel data on the bus. All current available bus flags might be of interest for a bridge. Remove the sampling_edge field and use bus_flags. In the case at hand a dumb VGA bridge needs a specific data enable polarity (DRM_BUS_FLAG_DE_LOW). Signed-off-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flagsLaurent Pinchart
The DRM_BUS_FLAG_PIXDATA_(POS|NEG)EDGE and DRM_BUS_FLAG_SYNC_(POS|NEG)EDGE flags are deprecated in favour of the new DRM_BUS_FLAG_PIXDATA_(DRIVE|SAMPLE)_(POS|NEG)EDGE and new DRM_BUS_FLAG_SYNC_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags. Replace them through the code. This effectively changes the value of the .sampling_edge bridge timings field in the dumb-vga-dac driver. This is safe to do as no driver consumes these values yet. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Stefan Agner <stefan@agner.ch> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Merge omap_dss_device type and output_type fieldsLaurent Pinchart
The omap_dss_device type and output_type fields differ mostly for historical reasons. The output_type field is required for all devices but the display at the end of the pipeline, and must be set to OMAP_DISPLAY_TYPE_NONE for the latter. The type field is required for all devices but the internal encoder, for which it is ignored. The only reason why the output_type field must be set to OMAP_DISPLAY_TYPE_NONE for the display at the end of the pipeline is to identify omap_dss_device instances corresponding to displays. This is not documented and confusing. Clean the code by adding a new display field to the omap_dss_device structure to identify displays, and merge the type and output_type fields. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Refactor initialization sequenceLaurent Pinchart
The omapdrm driver initialization procedure starts by connecting all available pipelines, gathering related information (such as output and display DSS devices, and DT aliases), sorting them by alias, and finally creates all the DRM/KMS objects. When using DRM bridges instead of DSS devices, we will need to attach to the bridges before getting the aliases. As attaching to bridges requires an encoder object, we have to reorganize the initialization sequence to create encoders before getting aliases and sorting the pipelines. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Simplify OF lookup of DSS devicesLaurent Pinchart
Now that the direction of OF graph walk has been reversed, there's no need to lookup devices by port as we have no sink device connected through multiple sink ports. Simplify OF lookup of the DSS devices to look them up by node only. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Store pixel clock instead of full mode in DPI and SDI encodersLaurent Pinchart
The DPI and SDI encoders store the full videomode upon mode set, to only use the value of the pixel clock when enabling the encoder. This wastes memory. Store the pixel clock value only. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: venc: Use drm_display_mode nativelyLaurent Pinchart
Replace internal usage of struct videomode with struct drm_display_mode in order to avoid converting needlessly between the data structures. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Pass drm_display_mode to .check_timings() and .set_timings()Laurent Pinchart
The omap_dss_device .check_timings() and .set_timings() operations operate on struct videomode, while the DRM API operates on struct drm_display_mode. This forces conversion from to videomode in the callers. While that's not a problem per se, it creates a difference with the drm_bridge API. Replace the videomode parameter to the .check_timings() and .set_timings() operations with a drm_display_mode. This pushed the conversion to videomode down to the DSS devices in some cases. If needed they will be converted to operate on drm_display_mode natively. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Factor out common mode validation codeLaurent Pinchart
The encoder .atomic_check() and connector .mode_valid() operations both walk through the dss devices in the pipeline to validate the mode. Factor out the common code in a new omap_drm_connector_mode_fixup() function. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: venc: Simplify mode setting by caching configurationLaurent Pinchart
The mode setting handler of the VENC stores the video mode internally, to then convert it to a configuration when programming the hardware. The stored mode is otherwise unused. Cache the configuration directly instead. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Move DISPC timing checks to CRTC .mode_valid() operationLaurent Pinchart
The DISPC timings checks relate to the CRTC, but they're performed in the encoder and connector .atomic_check() and .mode_valid() operations. Move them to the CRTC .mode_valid() operation. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2019-03-18drm/omap: Remove src field from omap_dss_device structureLaurent Pinchart
The field is only used to check whether the device is connected, and we can do so by checking the dss field instead. Remove the src field. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>