The IT6505 is a high-performance DisplayPort 1.1a transmitter, fully compliant
with DisplayPort 1.1a, HDCP 1.3 specifications. The IT6505 supports color depth
of up to 36 bits (12 bits/color) and ensures robust transmission of
high-quality uncompressed video content, along with uncompressed and
Adding support for visionox rm69299 panel driver and adding bindings for the
same panel.
Harigovindan P (2):
dt-bindings: display: add visionox rm69299 panel variant
drm/panel: add support for rm69299 visionox panel driver
.../display/panel/visionox,rm69299.yaml | 82 +
Add bindings for visionox rm69299 panel.
Signed-off-by: Harigovindan P
---
Changes in v2:
- Removed unwanted properties from description.
- Creating source files without execute permissions(Rob Herring).
Changes in v3:
- Changing txt file into yaml
Changes in v4:
- Updating
Hi Jassi,
On Thu, 2020-03-19 at 20:05 -0500, Jassi Brar wrote:
> On Sun, Mar 8, 2020 at 5:53 AM Dennis YC Hsieh
> wrote:
> >
> > Some gce hardware shift pc and end address in register to support
> > large dram addressing.
> > Implement gce address shift when write or read pc and end register.
>
Hi Ilia Mirkin,
Thanks for the comments.
I have sent new patch for review, can you please check ?
Thanks,
Rohit
> -Original Message-
> From: Ilia Mirkin [mailto:imir...@alum.mit.edu]
> Sent: Friday, March 13, 2020 8:17 PM
> To: Rohit Visavalia
> Cc: Devarsh Thakkar ; dri-devel
Add a DT binding documentation for IT6505.
Acked-by: Sam Ravnborg
Signed-off-by: Allen Chen
Signed-off-by: Pi-Hsun Shih
---
cros-ec does not have an associated driver that uses the standard Linux USB-C
driver class.
extcon is used to model the Type-C connector.(crbug.com/982932)
---
On Fri, Mar 20, 2020 at 03:21:13AM +0100, Emmanuel Vadot wrote:
> Source file was dual licenced but the header was omitted, fix that.
> Contributors for this file are:
> Daniel Vetter
> Matt Roper
> Maxime Ripard
> Noralf Trønnes
> Thomas Zimmermann
>
> Signed-off-by: Emmanuel Vadot
There's another OLED panel needs to use DPCD aux interface to control
backlight.
BugLink: https://bugs.launchpad.net/bugs/1860303
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/drm_dp_helper.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_dp_helper.c
"The PM core always increments the runtime usage counter
before calling the ->suspend() callback and decrements it
after calling the ->resume() callback"
DPU and DSI are managed as runtime devices. When
suspend is triggered, PM core adds a refcount on all the
devices and calls device suspend,
From: Allen Chen
This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.
Signed-off-by: Jitao Shi
Signed-off-by: Yilun Lin
Signed-off-by: Allen Chen
Signed-off-by: Pi-Hsun Shih
---
drivers/gpu/drm/bridge/Kconfig |7 +
drivers/gpu/drm/bridge/Makefile
Hi all,
Just a small fly-by idea.
On Thu, 19 Mar 2020 at 20:25, wrote:
>
> From: Deepak Rawat
>
> Surface define v4 added new member buffer_byte_stride. With this patch
> add buffer_byte_stride in surface metadata and create surface using new
> command if support is available.
>
> Also with
https://bugzilla.kernel.org/show_bug.cgi?id=206895
bigbeesh...@gmail.com changed:
What|Removed |Added
Kernel Version|5.5.10 |5.5.10 & 5.6.0-rc6
On Wed, Feb 26, 2020 at 11:09:59AM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 01:59:04PM +0100, Christian König wrote:
> > On the exporter side we add optional explicit pinning callbacks. Which are
> > called when the importer doesn't implement dynamic handling, move
> > notification
>
On Fri, Mar 06, 2020 at 09:37:10PM +0100, Sam Ravnborg wrote:
> On Mon, Mar 02, 2020 at 11:26:00PM +0100, Daniel Vetter wrote:
> > We need to add a drmm_kstrdup for this, but let's start somewhere.
> >
> > This is not exactly perfect onion unwinding, but it's jsut a kfree so
> > doesn't really
Hi Dan,
On Fri, 20 Mar 2020 at 13:23, Dan Carpenter wrote:
>
> If the "handles" allocation or the copy_from_user() fails then we leak
> "objs". It's supposed to be freed in panfrost_job_cleanup().
>
> Fixes: c117aa4d8701 ("drm: Add a drm_gem_objects_lookup helper")
> Signed-off-by: Dan
On 20.3.2020 2.38, Swathi Dhanavanthri wrote:
> Changes:
> 91b79fb35d67 ("drm/i915/tgl: Add new PCI IDs to TGL")
>
> Signed-off-by: Swathi Dhanavanthri
> ---
> intel/i915_pciids.h | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/intel/i915_pciids.h
On Sat, Mar 07, 2020 at 09:06:08AM +0100, Sam Ravnborg wrote:
> On Mon, Mar 02, 2020 at 11:25:44PM +0100, Daniel Vetter wrote:
> > I also did a full review of all callers, and only the xen driver
> > forgot to call drm_dev_put in the failure path. Fix that up too.
>
> So ~40 callers - phew..
>
>
On Mon, Mar 23, 2020 at 02:28:02PM +0300, Wambui Karuga wrote:
> Remove unneeded #if/#endif guards for checking whether the
> CONFIG_DEBUG_FS option is set or not. If the option is not set, the
> compiler optimizes the functions making the guards
> unnecessary.
>
> Signed-off-by: Wambui Karuga
>
https://bugzilla.kernel.org/show_bug.cgi?id=206895
--- Comment #9 from bigbeesh...@gmail.com ---
Also validated last night that the following patch to disable the merging of sg
sections within dma-iommu fixes the issue I am seeing
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
On Mon, Mar 23, 2020 at 11:13:22AM +, Emil Velikov wrote:
> Hi Dan,
>
> On Fri, 20 Mar 2020 at 13:23, Dan Carpenter wrote:
> >
> > If the "handles" allocation or the copy_from_user() fails then we leak
> > "objs". It's supposed to be freed in panfrost_job_cleanup().
> >
> > Fixes:
On Thu, Mar 19, 2020 at 03:51:01PM +0530, Pankaj Bharadiya wrote:
> Introduce scaler registers and bit fields needed to configure the
> scaling filter in prgrammed mode and configure scaling filter
> coefficients.
>
> changes since v1:
> * None
> changes since RFC:
> * Parametrize scaler
On Thu, Mar 19, 2020 at 03:51:03PM +0530, Pankaj Bharadiya wrote:
> GEN >= 10 hardware supports the programmable scaler filter.
>
> Attach scaling filter property for CRTC and plane for GEN >= 10
> hardwares and program scaler filter based on the selected filter
> type.
>
> changes since v1:
> *
Add David, Christian, Alex and Felix
-Original Message-
From: Yintian Tao
Sent: 2020年3月23日 22:40
To: dri-devel@lists.freedesktop.org
Cc: Tao, Yintian
Subject: [PATCH] drm/scheduler: fix rare NULL ptr race
There is one one corner case at dma_fence_signal_locked which will raise the
On Thu, Mar 19, 2020 at 03:50:59PM +0530, Pankaj Bharadiya wrote:
> Introduce new plane and CRTC scaling filter properties to allow
> userspace to select the driver's default scaling filter or
> Nearest-neighbor(NN) filter for upscaling operations on CRTC and
> plane.
>
> Drivers can set up this
There is one one corner case at dma_fence_signal_locked
which will raise the NULL pointer problem just like below.
->dma_fence_signal
->dma_fence_signal_locked
->test_and_set_bit
here trigger dma_fence_release happen due to the zero of fence refcount.
->dma_fence_put
We have lots of these. And the cleanup code tends to be of dubious
quality. The biggest wrong pattern is that developers use devm_, which
ties the release action to the underlying struct device, whereas
all the userspace visible stuff attached to a drm_device can long
outlive that one (e.g. after
For two reasons:
- The driver core clears this already for us after we're unloaded in
__device_release_driver().
- It's way too late, the drm_device ->release callback might massively
outlive the underlying physical device, since a drm_device can't be
kept alive by open drm_file or well
With this we can drop the final kfree from the release function.
v2: We need drm_dev_put to unroll the driver creation (once
drm_dev_init and drmm_add_final_kfree suceeded), otherwise
the drmm_ magic doesn't happen.
v3: Actually squash in the fixup (Laurent).
Acked-by: Thomas Zimmermann
I also did a full review of all callers, and only the xen driver
forgot to call drm_dev_put in the failure path. Fix that up too.
v2: I noticed that xen has a drm_driver.release hook, and uses
drm_dev_alloc(). We need to remove the kfree from
xen_drm_drv_release().
bochs also has a release hook,
With this we can drop the final kfree from the release function.
The mock device in the selftests needed it's pci_device split
up from the drm_device. In the future we could simplify this again
by allocating the pci_device as a managed allocation too.
v2: I overlooked that i915_driver_destroy is
With this we can drop the final kfree from the release function.
Acked-by: Sam Ravnborg
Reviewed-by: Noralf Trønnes
Signed-off-by: Daniel Vetter
Cc: "Noralf Trønnes"
---
drivers/gpu/drm/tiny/repaper.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
Hi all,
Another round, another set of polish all over. intel-gfx-ci was happy last
time around (after I fixed a fumble), so really just review and comments
needed now. There's still a few patches at the beginning holding the
entire thing up and preventing merging of the driver patches which have
slab does this already, and I want to use this in a memory allocation
tracker in drm for stuff that's tied to the lifetime of a drm_device,
not the underlying struct device. Kinda like devres, but for drm.
Acked-by: Andrew Morton
Signed-off-by: Daniel Vetter
Cc: Christoph Lameter
Cc: Pekka
These are the leftover drivers that didn't have a ->release hook that
needed to be updated.
Acked-by: Sam Ravnborg
Acked-by: Liviu Dudau
Signed-off-by: Daniel Vetter
Cc: "James (Qian) Wang"
Cc: Liviu Dudau
Cc: Mihail Atanassov
Cc: Russell King
Cc: Hans de Goede
---
With this we can drop the final kfree from the release function.
I also noticed that cirrus forgot to call drm_dev_fini().
v2: Don't call kfree(cirrus) after we've handed overship of that to
drm_device and the drmm_ stuff.
Acked-by: Gerd Hoffmann
Acked-by: Sam Ravnborg
Signed-off-by: Daniel
With this we can drop the final kfree from the release function.
Acked-by: Sam Ravnborg
Reviewed-by: Paul Cercueil
Signed-off-by: Daniel Vetter
Cc: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git
On Thu, Mar 19, 2020 at 03:51:02PM +0530, Pankaj Bharadiya wrote:
> Integer scaling (IS) is a nearest-neighbor upscaling technique that
> simply scales up the existing pixels by an integer
> (i.e., whole number) multiplier.Nearest-neighbor (NN) interpolation
> works by filling in the missing color
In contrast to other display controllers on imx like DCSS and ipuv3
lcdif/mxsfb does not support detiling e.g. vivante tiled layouts.
Since mesa might assume otherwise make it explicit that only
DRM_FORMAT_MOD_LINEAR is supported.
Signed-off-by: Guido Günther
---
Instead of having a work item that never stops (which really should be
a kthread), with a dedicated workqueue to not upset anyone else, use a
delayed work. A bunch of changes:
- We can throw out all the custom wakeup and requeue logic and state
tracking. If we schedule the work with a 0 delay
All collected together to provide a consistent story in one patch,
instead of the somewhat bumpy refactor-evolution leading to this.
Also some thoughts on what the next steps could be:
- Create a macro called devm_drm_dev_alloc() which essentially wraps
the kzalloc(); devm_drm_dev_init();
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside: This
It has become empty. Given the few users I figured not much point
splitting this up.
v2: Rebase over i915 changes.
v3: Rebase over patch split fix.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/cirrus/cirrus.c | 1 -
drivers/gpu/drm/drm_drv.c
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside:
7/7 drivers agree that's the right choice, let's do this.
This avoids duplicating the same old error checking code over all 7
drivers, which is the motivation here.
Acked-by: Sam Ravnborg
Reviewed-by: Noralf Trønnes
Tested-by: Noralf Trønnes
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
There's only two functions called from that:
drm_kms_helper_poll_fini() and udl_free_urb_list(). Both of these are
also called from the ubs_driver->disconnect hook, so entirely
pointless to do the same again in the ->release hook.
Furthermore by the time we clean up the drm_driver we really
Only drops the drm_dev_put, but hey a few lines!
Reviewed-by: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
Cc: "Noralf Trønnes"
---
drivers/gpu/drm/tiny/gm12u320.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git
Auto-unwind ftw, now possible with the fixed drm_device related
management.
Aside, clk/regulator seem to be missing devm versions for a bunch of
functions, preventing a pile of these simpler drivers from outright
losing their ->remove hook.
Reviewed-by: Linus Walleij
Signed-off-by: Daniel
It's right above the drm_dev_put().
This allows us to delete a bit of onion unwinding in
udl_modeset_init().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final
Also there's a race in the disconnect implemenation. First shut
down, then unplug, leaves a window where userspace could sneak
in and restart the entire machinery.
With this we can also delete the very un-atomic global pipe_enabled
tracking.
Reviewed-by: Hans de Goede
Signed-off-by: Daniel
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside:
The drm_mode_config_cleanup call we can drop, and all the allocations
we can switch over to drmm_kzalloc. Unfortunately the work queue is
still present, so can't get rid of the drm_driver->release function
outright.
v2: Use drmm_mode_config_init() for more clarity (Sam, Thomas)
Cc: Sam Ravnborg
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside:
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside:
Allows us to drop the drm_driver.release callback from all
drivers, and remove the mipi_dbi_release() function.
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on
Daniel Vetter 於 2020年3月23日 週一 下午10:51寫道：
>
> It's right above the drm_dev_put().
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is run on final drm_device
> cleanup
On Mon, Mar 23, 2020 at 12:37:26PM +0100, Greg KH wrote:
> On Mon, Mar 23, 2020 at 02:28:02PM +0300, Wambui Karuga wrote:
> > Remove unneeded #if/#endif guards for checking whether the
> > CONFIG_DEBUG_FS option is set or not. If the option is not set, the
> > compiler optimizes the functions
https://bugzilla.kernel.org/show_bug.cgi?id=206895
--- Comment #10 from bigbeesh...@gmail.com ---
Created attachment 288017
--> https://bugzilla.kernel.org/attachment.cgi?id=288017=edit
amdgpu_possible_patch
drm_prime_sg_to_page_addr_arrays does not support cases when the number of
segments
With this we can drop the final kfree from the release function.
v2: After drm_dev_init/drmm_add_final_kfree we need to clean up
everything through a drm_dev_put. Rework the unwind code to match
that.
Reviewed-by: Rodrigo Siqueira
Tested-by: Rodrigo Siqueira
Signed-off-by: Daniel Vetter
Cc:
drm_mode_config_cleanup is idempotent, so no harm in calling this
twice. This allows us to gradually switch drivers over by removing
explicit drm_mode_config_cleanup calls.
With this step it's now also possible that (at least for simple
drivers) automatic resource cleanup can be done correctly
Well for the simple stuff at least, vblank, gem and minor cleanup I
want to further split up as a demonstration.
v2: We need to clear drm_device->dev otherwise the debug drm printing
after our cleanup hook (e.g. in drm_manged_release) will chase
released memory and result in a use-after-free. Not
With this we can drop the final kfree from the release function.
Acked-by: Sam Ravnborg
Reviewed-by: Hans de Goede
Signed-off-by: Daniel Vetter
Cc: Hans de Goede
---
drivers/gpu/drm/tiny/gm12u320.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
A few things:
- Update the example driver in the documentation.
- We can drop the old kfree in drm_dev_release.
- Add a WARN_ON check in drm_dev_register to make sure everyone calls
drmm_add_final_kfree and there's no leaks.
v2: Restore the full cleanup, I accidentally left some moved code
With this we can drop the final kfree from the release function.
Acked-by: Jyri Sarha
Signed-off-by: Daniel Vetter
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tidss/tidss_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_drv.c
With this we can drop the final kfree from the release function.
Reviewed-by: Linus Walleij
Signed-off-by: Daniel Vetter
Cc: Linus Walleij
---
drivers/gpu/drm/mcde/mcde_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mcde/mcde_drv.c
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside:
The cleanup here is somewhat tricky, since we can't tell apart the
allocated minor index from 0. So register a cleanup action first, and
if the index allocation fails, unregister that cleanup action again to
avoid bad mistakes.
The kdev for the minor already handles NULL, so no problem there.
We might want to look into pushing this down into drm_mm_init, but
that would mean rolling out return codes to a pile of functions
unfortunately. So let's leave that for now.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 8 +---
Instead rely on the automatic clean, for which we just need to check
that drm_mode_config_init succeeded. To avoid an inversion in the
cleanup we also have to move the dev_private allocation over to
drmm_kzalloc.
This is made possible by a preceeding patch which added a drmm_
cleanup action to
With the drm_device lifetime fun cleaned up there's nothing in the way
anymore to use devm_ for everything hw releated. Do it, and in the
process, throw out the entire onion unwinding.
Acked-by: Gerd Hoffmann
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: Daniel Vetter
We need to add a drmm_kstrdup for this, but let's start somewhere.
This is not exactly perfect onion unwinding, but it's jsut a kfree so
doesn't really matter at all.
Reviewed-by: Sam Ravnborg
Acked-by: Thomas Zimmermann
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_drv.c | 5
It's right above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Aside: This
With this we can drop the final kfree from the release function.
I also noticed that the unwind code is wrong, after drm_dev_init the
drm_device owns the v3d allocation, so the kfree(v3d) is a double-free.
Reorder the setup to fix this issue.
After a bit more prep in drivers and drm core v3d
Nothing special here, except that this is the first time that we
automatically clean up something that's initialized with an explicit
driver call. But the cleanup was done at the very end of the release
sequence for all drivers, and that's still the case. At least without
more uses of drmm_
It's (almost, there's some iommu stuff without significance) right
above the drm_dev_put().
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup
Small mistake that crept into
commit 81da8c3b8d3df6f05b11300b7d17ccd1f3017fab
Author: Gerd Hoffmann
Date: Tue Feb 11 14:52:18 2020 +0100
drm/bochs: add drm_driver.release callback
where drm_atomic_helper_shutdown was left in both places. The
->release callback really shouldn't touch
Allows us to drop the drm_driver.release callback.
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
Allows us to drop the drm_driver.release callback.
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
We can even delete the drm_driver.release hook now!
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for
Allows us to drop the drm_driver.release callback.
This is made possible by a preceeding patch which added a drmm_
cleanup action to drm_mode_config_init(), hence all we need to do to
ensure that drm_mode_config_cleanup() is run on final drm_device
cleanup is check the new error code for _init().
They all share mipi_dbi_release so we need to switch them all
together. With this we can drop the final kfree from the release
function.
Aside, I think we could perhaps have a tiny additional helper for
these mipi_dbi drivers, the first few lines around devm_drm_dev_init
are all the same (except
With this we can drop the final kfree from the release function.
v2: After drm_dev_init/drmm_add_final_kfree we need to clean up
everything through a drm_dev_put. Rework the unwind code to match
that.
Acked-by: Sam Ravnborg
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Emil Velikov
Cc:
With this we can drop the final kfree from the release function.
Acked-by: Gerd Hoffmann
Signed-off-by: Daniel Vetter
Cc: Dave Airlie
Cc: Gerd Hoffmann
Cc: virtualizat...@lists.linux-foundation.org
Cc: spice-de...@lists.freedesktop.org
---
drivers/gpu/drm/qxl/qxl_drv.c | 2 --
Am Montag, den 23.03.2020, 15:52 +0100 schrieb Guido Günther:
> In contrast to other display controllers on imx like DCSS and ipuv3
> lcdif/mxsfb does not support detiling e.g. vivante tiled layouts.
> Since mesa might assume otherwise make it explicit that only
> DRM_FORMAT_MOD_LINEAR is
https://bugzilla.kernel.org/show_bug.cgi?id=206895
--- Comment #13 from bigbeesh...@gmail.com ---
Indeed, however they may not have pushed the SG lists via dma map in the same
way as amdgpu.
In that case getting lengths from dma_map_sg would probably cause other issues
--
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=206895
--- Comment #15 from Alex Deucher (alexdeuc...@gmail.com) ---
General comment about the patch, you can make amdgpu_ttm_dma_sg_to_arrays
static since it's only used within amdgpu_ttm.c,
--
You are receiving this mail because:
You are watching
https://bugzilla.kernel.org/show_bug.cgi?id=206895
--- Comment #11 from Alex Deucher (alexdeuc...@gmail.com) ---
Thanks for the patch. Please fix drm_prime_sg_to_page_addr_arrays() directly
and send the patch to dri-devel@lists.freedesktop.org . Also please add your
Signed-off_by.
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=206895
--- Comment #12 from Alex Deucher (alexdeuc...@gmail.com) ---
It's likely other drivers that rely on these helpers would be similarly broken.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=206895
--- Comment #16 from bigbeesh...@gmail.com ---
I'll update drm_prime_sg_to_page_addr_arrays to support both the current logic
and dma mapped logic and get a patch up this evening.
That way at least nothing else get broke
--
You are receiving
Am 23.03.20 um 13:02 schrieb Emil Velikov:
> Hi all,
>
> Just a small fly-by idea.
>
> On Thu, 19 Mar 2020 at 20:25, wrote:
>>
>> From: Deepak Rawat
>>
>> Surface define v4 added new member buffer_byte_stride. With this patch
>> add buffer_byte_stride in surface metadata and create surface
https://bugzilla.kernel.org/show_bug.cgi?id=206895
--- Comment #14 from Alex Deucher (alexdeuc...@gmail.com) ---
True. For now just send out the patch and we can discuss further on the list.
Thanks!
--
You are receiving this mail because:
You are watching the assignee of the bug.
Sometimes the drm_mm is searched from within an atomic context (yikes!)
so we must be cautious and not insert a schedule() unless the caller
indicates it is safe to do so.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1509
Fixes: 7be1b9b8e9d1 ("drm/mm: Break long searches in fragmented
Hi Daniel.
On Mon, Mar 23, 2020 at 03:49:02PM +0100, Daniel Vetter wrote:
> We have lots of these. And the cleanup code tends to be of dubious
> quality. The biggest wrong pattern is that developers use devm_, which
> ties the release action to the underlying struct device, whereas
> all the
Am 23.03.20 um 01:36 schrieb Dave Airlie:
> On Sat, 21 Mar 2020 at 08:57, Roland Scheidegger (VMware)
> wrote:
>>
>> Dave, Daniel,
>>
>> vmwgfx pull for for 5.7. Needed for GL4 functionality.
>> Sync up device headers, add support for new commands, code
>> refactoring around surface definition.
>
On Mon, Mar 09, 2020 at 07:55:22AM +0100, Johan Jonker wrote:
> Hi,
>
> Question for robh:
>
> In the old txt situation we add/describe only properties that are used
> by the driver/hardware itself. With yaml it also filters things in a
> node that are used by other drivers like:
>
>
On 2020-03-09 20:51, Laurent Pinchart wrote:
> Commit 8e93f1028d74 ("drm/mxsfb: Use drm_fbdev_generic_setup()")
> replaced fbdev handling with drm_fbdev_generic_setup() but left
> inclusion of the drm/drm_fb_cma_helper.h header. Remove it.
>
> Fixes: 8e93f1028d74 ("drm/mxsfb: Use
Previously drm_prime_sg_to_page_addr_arrays did not allow for
scatter-gather tables where the length had been reduced in a
dma_map.
This commit enables this via drm_prime_dma_sg_to_page_addr_arrays
while still keeping the original logic in place for tables that
that have not been through dma
On Fri, Mar 06, 2020 at 06:03:53PM +0100, Johan Jonker wrote:
> Current dts files with 'vop' nodes are manually verified.
> In order to automate this process rockchip-vop.txt
> has to be converted to yaml. Also included are new
> properties needed for the latest Rockchip Socs.
>
> Added
On Mon, Mar 09, 2020 at 03:52:46PM +0530, Krishna Manikandan wrote:
> MSM Mobile Display Subsytem(MDSS) encapsulates sub-blocks
> like DPU display controller, DSI etc. Add YAML schema
> for the device tree bindings for the same.
>
> Signed-off-by: Krishna Manikandan
>
> Changes in v2:
> -
This patch set is to fix a bug in amdgpu that results in
a crash when dma_map_sg combines segments. There are 2
shortfalls in the current kernel.
1) AMDGPU assumes that the requested and created segments
from dma_map_sg are equal
2) drm_prime does not allow for setting the segment length
Calls to dma_map_sg may return segments / entries than requested
if they fall on page bounderies. The old implementation did not
support this use case.
Signed-off-by: Shane Francis
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff
1 - 100 of 170 matches
Mail list logo
