Add support to load physical size information from DT using
the properties defined by the common panel binding.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Add support for regulators used by panels found inside
of the Nokia N950, N9 and Motorola Droid 4.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
This adds support for get_timings() and check_timings()
to get the driver working and properly initializes the
timing information from DT.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
While physical size information is automatically parsed for EDID
based displays, we need to provide it manually for displays providing
one fixed mode.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The wrappers have been removed in commit 5a35876e28
(drm: omapdrm: Remove manual update display support)
and will not be reintroduced, since the normal sys
functions properly call the dirty callback.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
If we have memory bandwidth limit configured, reject the modes which would
require more bandwidth than the limit if it is used with one full
resolution plane (most common use case).
This filtering is not providing full protection as it is possible that
application would pick smaller crtc resolution with high resolution planes
and down scaling, or can enable more smaller planes where the sum of their
bandwidth need would be higher than the limit.
This patch only allows us to filter out modes which would need more
bandwidth if they were used with one full screen plane.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The get_memory_bandwidth_limit() in dispc_ops can be used to query the
memory bandwidth limit of dispc by upper layers.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
to make it easier to keep in sync with the OF device table.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
The vendor name was "toppoly" but other panels and the vendor list
have defined it as "tpo". So let's fix it in driver and bindings.
We keep the old definition in parallel to stay compatible with
potential older DTB setup.
Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
nouveau regression fixes, and some minor fixes.
* 'linux-4.15' of git://github.com/skeggsb/linux:
drm/nouveau: use alternate memory type for system-memory buffers with kind != 0
drm/nouveau: avoid GPU page sizes > PAGE_SIZE for buffer objects in host memory
drm/nouveau/mmu/gp10b: use correct implementation
drm/nouveau/pci: do a msi rearm on init
drm/nouveau/imem/nv50: fix refcount_t warning
drm/nouveau/bios/dp: support DP Info Table 2.0
drm/nouveau/fbcon: fix NULL pointer access in nouveau_fbcon_destroy
Fixes bug on Tegra where we'd strip kind information from system memory
(ie. all) buffers, resulting in misrendering.
Behaviour on dGPU should be unchanged.
Reported-by: Thierry Reding <treding@nvidia.com>
Fixes: d7722134b8 ("drm/nouveau: switch over to new memory and vmm interfaces")
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Tested-by: Thierry Reding <treding@nvidia.com>
While the Tegra (GK20A, GM20B, GP10B) MMUs support large pages in host
memory, we're currently lacking IOMMU support for merging system pages
into large enough chunks to be mapped as such by the GPU.
The core VMM code actually supports automatically determining the best
page size to map with, which is intended for these situations, but for
various complicated reasons the DRM is currently forcing the page size
selection on a per-BO basis.
This should fix breakage reported on Tegra GPUs in the meantime, until
one or both of the above issues are resolved properly.
Reported-by: Mikko Perttunen <cyndis@kapsi.fi>
Fixes: 7dc6a446da ("drm/nouveau: improve selection of GPU page size")
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Tested-by: Thierry Reding <treding@nvidia.com>
On my GP107 when I load nouveau after unloading it, for some reason the
GPU stopped sending or the CPU stopped receiving interrupts if MSI was
enabled.
Doing a rearm once before getting any interrupts fixes this.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
When the fbcon object is initialized, but nouveau_fbcon_create is not
called, we run into a NULL pointer access within nouveau_fbcon_create when
unloading nouveau.
The call to drm_fb_helper_funcs.fb_probe is deferred until there is a
display for real since 4.14, that's why fbcon->helper.fb is still not set.
Signed-off-by: Karol Herbst <kherbst@redhat.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
In case we have multiple modesets for different connectors
happening in parallel we could have a race on the RMW on these
shared registers.
This possibility was initially raised by Paulo when reviewing
commit '555e38d27317 ("drm/i915/cnl: DDI - PLL mapping")'
but the original possibility comes from commit '5416d871136d
("drm/i915/skl: Set the eDP link rate on DPLL0")'. Or maybe
later when atomic commits entered into picture.
Apparently the discussion around this topic showed that the
right solution would be on serializing the atomic commits in
a way that we don't have the possibility of races here since
if that parallel modeset happenings apparently many other
things will be on fire.
Code is there since SKL and there was no report of issue,
but since we never looked back to that serialization possibility,
and also we don't have an igt case for that it is better to at
least protect this corner.
Suggested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Fixes: 555e38d273 ("drm/i915/cnl: DDI - PLL mapping")
Fixes: 5416d87113 ("drm/i915/skl: Set the eDP link rate on DPLL0")
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst maarten.lankhorst@linux.intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com
Link: https://patchwork.freedesktop.org/patch/msgid/20171215224310.19103-1-rodrigo.vivi@intel.com
The function tilcdc_mode_hvtotal is local to the source and does not need
to be in global scope, so make it static.
drivers/gpu/drm/tilcdc/tilcdc_crtc.c:297:6: warning: no previous prototype for 'tilcdc_mode_hvtotal' [-Wmissing-prototypes]
uint tilcdc_mode_hvtotal(const struct drm_display_mode *mode)
Signed-off-by: Xiongwei Song <sxwjean@gmail.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Instead of falling back to 2 level and very limited address space use
2+1 PD support and 128TB + 512GB of virtual address space.
v2: cleanup defines, rebase on top of level enum
v3: fix inverted check in hardware setup
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-and-Tested-by: Chunming Zhou <david1.zhou@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
We only need to wait for the contended lock when the reservation object is
shared or when we want to remove everything. A trylock should be sufficient
in all other cases.
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Roger He <Hongbo.He@amd.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
otherwise, uvd block will be never powered up in ring begin_use()
callback. uvd ring test will be fail in resume in rumtime pm.
Signed-off-by: Jim Qu <Jim.Qu@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
When monitoring the GPU with i915 perf, reports are tagged with a hw
id. Gem context creation tracepoints already have a hw_id field,
unfortunately you only get this correlation between a process id and a
hw context id once when the context is created. It doesn't help if you
started monitoring after the process was initialized or if the drm fd
was transfered from one process to another.
This change adds the hw_id field to gem requests, so that correlation
can also be done on submission.
v2: Place hw_id at the end of the tracepoint to not disrupt too much
existing tools (Chris)
v3: Reorder hw_id field again (Chris)
v4: Add missing hw_id to i915_gem_request_wait_begin tracepoint (Chris)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20171218151959.14073-3-lionel.g.landwerlin@intel.com
Prefix the functions with device or device_ip for functions which
deal with ip blocks for consistency.
Acked-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
The drm_framebuffer_get() and drm_framebuffer_put() calls in the
tilcdc driver are obsolete. The drm atomic modesetting core should
take care of holding the references while the atomic state object is
in use. The old state is deleted when a commit of a new one is
completed after drm_atomic_helper_wait_for_vblanks().
This also fixes an occasional framebuffer leak the old
drm_framebuffer_get() and drm_framebuffer_put() code had.
Signed-off-by: Jyri Sarha <jsarha@ti.com>
