Quoting Alex Deucher (2020-02-20 02:52:32)
> On Wed, Feb 19, 2020 at 7:42 PM Paul E. McKenney wrote:
> >
> > Hello!
> >
> > A box with GCC 4.8.3 compiler didn't like drm_dp_mst_topology.c. The
> > following (lightly tested) patch makes it happy and seems OK for newer
> > compilers as well.
> >
>
On Wed, 19 Feb 2020, Tony Lindgren wrote:
> * Pavel Machek [200219 19:15]:
> > From: Tomi Valkeinen
> >
> > This patch adds a led-backlight driver (led_bl), which is similar to
> > pwm_bl except the driver uses a LED class driver to adjust the
> > brightness in the HW. Multiple LEDs can be
On Wed, Feb 19, 2020 at 1:33 PM Jordan Crouse wrote:
>
> When CONFIG_INIT_ON_ALLOC_DEFAULT_ON the GMU memory allocator runs afoul of
> cache coherency issues because it is mapped as write-combine without clearing
> the cache after it was zeroed.
>
> Rather than duplicate the hacky workaround we
On Wed, Feb 19, 2020 at 7:42 PM Paul E. McKenney wrote:
>
> Hello!
>
> A box with GCC 4.8.3 compiler didn't like drm_dp_mst_topology.c. The
> following (lightly tested) patch makes it happy and seems OK for newer
> compilers as well.
>
> Is this of interest?
How about a memset instead? That
> From: Tian, Kevin
> Sent: Thursday, February 20, 2020 10:05 AM
>
> > From: Chia-I Wu
> > Sent: Thursday, February 20, 2020 3:37 AM
> >
> > On Wed, Feb 19, 2020 at 1:52 AM Tian, Kevin wrote:
> > >
> > > > From: Paolo Bonzini
> > > > Sent: Wednesday, February 19, 2020 12:29 AM
> > > >
> > > >
> From: Chia-I Wu
> Sent: Thursday, February 20, 2020 3:18 AM
>
> On Wed, Feb 19, 2020 at 2:00 AM Tian, Kevin wrote:
> >
> > > From: Chia-I Wu
> > > Sent: Saturday, February 15, 2020 5:15 AM
> > >
> > > On Fri, Feb 14, 2020 at 2:26 AM Paolo Bonzini
> wrote:
> > > >
> > > > On 13/02/20 23:18,
> From: Chia-I Wu
> Sent: Thursday, February 20, 2020 3:37 AM
>
> On Wed, Feb 19, 2020 at 1:52 AM Tian, Kevin wrote:
> >
> > > From: Paolo Bonzini
> > > Sent: Wednesday, February 19, 2020 12:29 AM
> > >
> > > On 14/02/20 23:03, Sean Christopherson wrote:
> > > >> On Fri, Feb 14, 2020 at 1:47 PM
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: 2a97892fdbae277a104d6ba0b90f8a47cbe53681
commit: 0db409f2a5a4ec41dba541c21d6fa294c8a4dfd4 [18/21] Revert "drm/i915:
Don't select BROKEN"
config: powerpc-ksi8560_defconfig
compiler: powerpc-linux-gcc (GCC) 7.5.0
reproduce:
Hi, Phong:
On Wed, 2020-02-19 at 15:13 +0100, Phong LE wrote:
> The larb device remains NULL if the type is MTK_DISP_OVL_2L.
> A kernel panic is raised when a crtc uses mtk_smi_larb_get or
> mtk_smi_larb_put.
>
Reviewed-by: CK Hu
> Signed-off-by: Phong LE
> ---
>
Intel ID: PSIRT-TA-201910-001
CVEID: CVE-2019-14615
Summary of Vulnerability
Insufficient control flow in certain data structures for some Intel(R)
Processors with Intel Processor Graphics may allow an unauthenticated
user to potentially enable information disclosure via
From: Prathap Kumar Valsan
On gen7 and gen7.5 devices, there could be leftover data residuals in
EU/L3 from the retiring context. This patch introduces workaround to clear
that residual contexts, by submitting a batch buffer with dedicated HW
context to the GPU with ring allocation for each
From: Mika Kuoppala
This patch adds framework to submit an arbitrary batchbuffer on each
context switch to clear residual state for render engine on Gen7/7.5
devices.
The idea of always emitting the context and vm setup around each request
is primary to make reset recovery easy, and not require
Hello!
A box with GCC 4.8.3 compiler didn't like drm_dp_mst_topology.c. The
following (lightly tested) patch makes it happy and seems OK for newer
compilers as well.
Is this of interest?
Thanx, Paul
On Wed, Feb 19, 2020 at 4:20 PM John Bates wrote:
>
>
>
> On Wed, Feb 19, 2020 at 12:40 PM John Bates wrote:
>>
>> The previous code was not thread safe and caused
>> undefined behavior from spurious duplicate resource IDs.
>> In this patch, an atomic_t is used instead. We no longer
>> see any
Hi!
> > > If you guys instead want me to pick these both into my fixes
> > > branch, just let me know and I'll do the explaining why these
> > > are needed as fixes. Basically we no longer have a way to enable
> > > the LCD backlight for droid4 manually starting with v5.6-rc1
> > > unlike
On Wed, Feb 19, 2020 at 11:45:40AM -0800, Tony Lindgren wrote:
> * Pavel Machek [200219 19:15]:
> > From: Tomi Valkeinen
> >
> > This patch adds a led-backlight driver (led_bl), which is similar to
> > pwm_bl except the driver uses a LED class driver to adjust the
> > brightness in the HW.
On Fri, Feb 14, 2020 at 01:24:39PM +0100, Maxime Ripard wrote:
> Some LVDS encoders can support multiple polarities on the data and
> clock lanes, and similarly some panels require a given polarity on
> their inputs. Add a property on the panel to configure the encoder
> properly.
If the panel
On Mon, Feb 17, 2020 at 7:41 AM James Hughes
wrote:
>
> The wait_for macro's for Broadcom VC4 and V3D drivers used msleep
> which is inappropriate due to its inaccuracy at low values (minimum
> wait time is about 30ms on the Raspberry Pi).
>
> This patch replaces the macro with the one from the
Use an boolean variable to track whether a context has been
initiated.
v5: Fix possible race and sleep via mutex (olv)
Reviewed-by: Chia-I Wu
Reviewed-by: Emil Velikov
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 8
Minor cleanup, change:
- file_priv--> file,
- drm_file --> file.
Reviewed-by: Chia-I Wu
Reviewed-by: Emil Velikov
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git
For old userspace, initialization will still be implicit.
For backwards compatibility, enqueue virtio_gpu_cmd_context_create after
the first 3D ioctl.
v3: staticify virtio_gpu_create_context
remove notify to batch vm-exit
v6: Remove nested 3D checks (emil.velikov):
- unify 3D check in
We currently create an OpenGL context when opening the DRM fd
if 3D is available.
We may need other context types (VK,..) in the future, and the plan
is to have explicit initialization for that.
For explicit initialization to work, we need to factor out
virtio_gpu_create_context from driver
The GMU has very few memory allocations and uses a flat memory space so
there is no good reason to go out of our way to bypass the DMA APIs which
were basically designed for this exact secnario.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 107
Convert display/msm/gmu.txt to display/msm/gmu.yaml and remove the old
text bindings.
Signed-off-by: Jordan Crouse
---
.../devicetree/bindings/display/msm/gmu.txt| 116 --
.../devicetree/bindings/display/msm/gmu.yaml | 130 +
2 files changed,
The GMU node now requires a specific dma-range property so that the driver
can use the DMA API to do the few memory allocations required by the GMU.
This sets the IOMMU iova allocadtor to match the 'uncached' part of the
GMU virtual address space.
Signed-off-by: Jordan Crouse
---
When CONFIG_INIT_ON_ALLOC_DEFAULT_ON the GMU memory allocator runs afoul of
cache coherency issues because it is mapped as write-combine without clearing
the cache after it was zeroed.
Rather than duplicate the hacky workaround we use in the GEM allocator for the
same reason it turns out that we
On Wed, Feb 19, 2020 at 10:35:32PM +0200, Ville Syrjala wrote:
> - Eliminate the second list head somehow?
I think we could just convert that to a boolean, or even just
borrow eg. the one totally free mode->type bit for our internal
use to tag the exposed modes. That would in fact get us down
to
Hi!
> > This patch adds a led-backlight driver (led_bl), which is similar to
> > pwm_bl except the driver uses a LED class driver to adjust the
> > brightness in the HW. Multiple LEDs can be used for a single backlight.
> >
> > Signed-off-by: Tomi Valkeinen
> > Signed-off-by: Jean-Jacques
From: Ville Syrjälä
gma500 needs 4 bits (to store a pixel multiplier) in the
mode->private_flags, i915 currently has three bits defined.
No one else uses this. Reduce the size to u8.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Ville Syrjälä
Remove the pointless whole-function indentation. Also don't
need to worry about negative values anymore since we switched
everything to u16.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 26 --
1 file changed, 12 insertions(+), 14
From: Ville Syrjälä
Instead of supporting ~2000km wide displayes let's limit ourselves
to ~65m. That seems plenty big enough to me.
Even with EDID_QUIRK_DETAILED_IN_CM EDIDs seem to be limited to
10*0xfff which fits into the 16 bits.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h |
From: Ville Syrjälä
The mode flags are direclty exposed in the uapi as u32. Use the
same size type to store them internally.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_modes.h
From: Ville Syrjälä
Reorganize drm_display_mode to eliminate all the holes.
We'll put all the actual timings to the start of the
struct and all the extra junk to the end.
Gets the size down to 136 bytes on 64bit and 120 bytes on
32bit. With a bit more work we should be able to get this
below
From: Ville Syrjälä
We only have 7 bits defined for mode->type. Shrink the storage to u8.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_modes.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index
From: Ville Syrjälä
The driver never sets mode->private_flags so copying
it back and forth is entirely pointless. Stop doing it.
Also drop private_flags from the tracepoint.
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville
From: Ville Syrjälä
Store the timings (apart from the clock) as u16. The uapi mode
struct already uses u16 for everything so using something bigger
internally doesn't really help us.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 7 --
include/drm/drm_modes.h | 46
From: Ville Syrjälä
htotal*vtotal*vrefresh ~= clock. So just use say "clock" when we mean it.
Cc: Inki Dae
Cc: Joonyoung Shim
Cc: Seung-Woo Kim
Cc: Kyungmin Park
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
1 file changed, 1 insertion(+), 1
From: Ville Syrjälä
Let's just calculate the hsync rate on demand. No point in wasting
space storing it and risking the cached value getting out of sync
with reality.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 14 ++
From: Ville Syrjälä
The drrs code dereferences mode->vrefresh via some really long chain
of structures/pointers. Couldn't get coccinelle to see through all
that so let's add some local variables to help it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 18
From: Ville Syrjälä
struct drm_display_mode is extremely fat. Put it on diet.
Some stats for the whole series:
64bit sizeof(struct drm_display_mode):
200 -> 136 bytes (-32%)
64bit bloat-o-meter -c drm.ko:
add/remove: 1/0 grow/shrink: 29/47 up/down: 893/-1544 (-651)
Function
On Wed, Feb 19, 2020 at 7:19 PM Greg Kroah-Hartman
wrote:
>
> On Wed, Feb 19, 2020 at 07:36:52PM +0200, Laurent Pinchart wrote:
> > Hi Greg,
> >
> > On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote:
> > > On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote:
> > > > On
https://bugzilla.kernel.org/show_bug.cgi?id=206575
--- Comment #10 from Noel Maersk (veox+ker...@veox.pw) ---
That came in negative. Looks like it's 1ea8751bd28d1ec2b36a56ec6bc1ac28903d09b4
indeed.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Wed, 19 Feb 2020 11:20:31 +0100 Daniel Vetter wrote:
> 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.
>
> ...
>
> Ack for merging through drm trees very much appreciated.
Acked-by: Andrew Morton
On Wed, Feb 19, 2020 at 1:52 AM Tian, Kevin wrote:
>
> > From: Paolo Bonzini
> > Sent: Wednesday, February 19, 2020 12:29 AM
> >
> > On 14/02/20 23:03, Sean Christopherson wrote:
> > >> On Fri, Feb 14, 2020 at 1:47 PM Chia-I Wu wrote:
> > >>> AFAICT, it is currently allowed on ARM (verified) and
On Wed, Feb 19, 2020 at 2:00 AM Tian, Kevin wrote:
>
> > From: Chia-I Wu
> > Sent: Saturday, February 15, 2020 5:15 AM
> >
> > On Fri, Feb 14, 2020 at 2:26 AM Paolo Bonzini wrote:
> > >
> > > On 13/02/20 23:18, Chia-I Wu wrote:
> > > >
> > > > The bug you mentioned was probably this one
> > > >
From: Tomi Valkeinen
This patch adds a led-backlight driver (led_bl), which is similar to
pwm_bl except the driver uses a LED class driver to adjust the
brightness in the HW. Multiple LEDs can be used for a single backlight.
Signed-off-by: Tomi Valkeinen
Signed-off-by: Jean-Jacques Hiblot
Hello,
Finn Thain wrote:
> A few minor patches are needed to more easily boot a MIPS Magnum build
> under QEMU. This series fixes a build failure in the g364fb driver and
> modifies jazz_defconfig for use with 'qemu-system-mips64el -M magnum'.
>
> Note that QEMU's dp8393x implementation has
On Tue, Feb 18, 2020 at 9:28 AM Wambui Karuga wrote:
>
> As drm_debugfs_create_files should return void, remove its use as the
> return value of v3d_debugfs_init and have the function return 0
> directly.
If we're going this route, then this function should be returning void, too.
>
>
On Wed, Feb 19, 2020 at 2:21 AM Daniel Vetter wrote:
>
> 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
Patch 1-4 are
Reviewed-by: Chia-I Wu
I think we can drop patch 5 for now.
On Wed, Feb 19, 2020 at 9:56 AM Gurchetan Singh
wrote:
>
> Use an atomic variable to track whether a context has been
> initiated.
>
> v5: Fix possible race and sleep via mutex (@olv)
>
> Signed-off-by: Gurchetan Singh
On Wed, 19 Feb 2020 at 17:57, Gurchetan Singh
wrote:
>
> We'll have to do something like this eventually, and this
> conveys we want a Virgl context by default.
>
> Signed-off-by: Gurchetan Singh
Reviewed-by: Emil Velikov
HTH
Emil
___
dri-devel
On Wed, 19 Feb 2020 at 17:57, Gurchetan Singh
wrote:
>
> For old userspace, initialization will still be implicit.
>
> For backwards compatibility, enqueue virtio_gpu_cmd_context_create after
> the first 3D ioctl.
>
> v3: staticify virtio_gpu_create_context
> remove notify to batch vm-exit
>
On Wed, Feb 19, 2020 at 07:36:52PM +0200, Laurent Pinchart wrote:
> Hi Greg,
>
> On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote:
> > On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote:
> > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote:
> > > > On Wed,
On Wed, 19 Feb 2020 at 17:56, Gurchetan Singh
wrote:
>
> Use an atomic variable to track whether a context has been
> initiated.
>
> v5: Fix possible race and sleep via mutex (@olv)
>
> Signed-off-by: Gurchetan Singh
Reviewed-by: Emil Velikov
-Emil
On Wed, Feb 19, 2020 at 6:30 PM Noralf Trønnes wrote:
>
>
>
> Den 19.02.2020 17.23, skrev Daniel Vetter:
> > On Wed, Feb 19, 2020 at 5:08 PM Laurent Pinchart
> > wrote:
> >>
> >> Hi Daniel,
> >>
> >> On Wed, Feb 19, 2020 at 04:47:55PM +0100, Daniel Vetter wrote:
> >>> On Wed, Feb 19, 2020 at
Hi Gurchetan,
s/hyercall/hypercall/ in the commit message
On Wed, 19 Feb 2020 at 17:56, Gurchetan Singh
wrote:
> +void virtio_gpu_create_context(struct drm_device *dev,
> + struct drm_file *file)
> +{
> + struct virtio_gpu_device *vgdev = dev->dev_private;
>
On Wed, 19 Feb 2020 at 17:56, Gurchetan Singh
wrote:
>
> Minor cleanup, change:
>
> - file_priv--> file,
> - drm_file --> file.
>
> Signed-off-by: Gurchetan Singh
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
We'll have to do something like this eventually, and this
conveys we want a Virgl context by default.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git
We currently create an OpenGL context when opening the DRM fd
if 3D is available.
We may need other context types (VK,..) in the future, and the plan
is to have explicit initialization for that.
For explicit initialization to work, we need to factor out
virtio_gpu_create_context from driver
Minor cleanup, change:
- file_priv--> file,
- drm_file --> file.
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c
Use an atomic variable to track whether a context has been
initiated.
v5: Fix possible race and sleep via mutex (@olv)
Signed-off-by: Gurchetan Singh
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 8
drivers/gpu/drm/virtio/virtgpu_kms.c |
For old userspace, initialization will still be implicit.
For backwards compatibility, enqueue virtio_gpu_cmd_context_create after
the first 3D ioctl.
v3: staticify virtio_gpu_create_context
remove notify to batch vm-exit
Signed-off-by: Gurchetan Singh
---
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
consistency among
The ioreadX() helpers have inconsistent interface. On some architectures
void *__iomem address argument is a pointer to const, on some not.
Implementations of ioreadX() do not modify the memory under the
address so they can be converted to a "const" version for const-safety
and consistency among
The ioreadX() and ioreadX_rep() helpers have inconsistent interface. On
some architectures void *__iomem address argument is a pointer to const,
on some not.
Implementations of ioreadX() do not modify the memory under the address
so they can be converted to a "const" version for const-safety and
Hi,
Changes since v1
https://lore.kernel.org/lkml/1578415992-24054-1-git-send-email-k...@kernel.org/
1. Constify also ioreadX_rep() and mmio_insX(),
2. Squash lib+alpha+powerpc+parisc+sh into one patch for bisectability,
3. Add acks and reviews,
4. Re-order patches so all
Make iterator implementation private, and add function to
query resources assigned to an encoder.
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 59 ---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 10
Track hardware resource objects in arrays rather than
a list and remove the resource manager's iterator idiom. Separate
the mapping of hardware resources to an encoder ID into a different
array.
Use an implicit mapping between the hardware blocks' ids, which
are 1-based, and array indices in
Move mapping of resources to encoder ids from the resource manager to a
new dpu_global_state struct. Store this struct in global atomic state.
Before this patch, atomic test would be performed by modifying global
state (resource manager), and backing out any changes if the test fails.
By using
Several functions arguments in the resource manager are unused, so
remove them.
Signed-off-by: Drew Davenport
---
drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 37 ++
1 file changed, 14 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c
Hi Dave, Daniel,
Fixes for 5.6.
The following changes since commit 6f4134b30b6ee33e2fd4d602099e6c5e60d0351a:
Merge tag 'drm-intel-next-fixes-2020-02-13' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2020-02-14 13:04:46
+1000)
are available in the Git repository at:
Hi Greg,
On Wed, Feb 19, 2020 at 06:00:46PM +0100, Greg Kroah-Hartman wrote:
> On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote:
> > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote:
> > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote:
> > > > On Wed, Feb
Den 19.02.2020 17.23, skrev Daniel Vetter:
> On Wed, Feb 19, 2020 at 5:08 PM Laurent Pinchart
> wrote:
>>
>> Hi Daniel,
>>
>> On Wed, Feb 19, 2020 at 04:47:55PM +0100, Daniel Vetter wrote:
>>> On Wed, Feb 19, 2020 at 2:50 PM Laurent Pinchart wrote:
On Wed, Feb 19, 2020 at 11:20:57AM +0100,
On Wed, Feb 19, 2020 at 6:02 PM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> On Wed, Feb 19, 2020 at 05:53:59PM +0100, Daniel Vetter wrote:
> > On Wed, Feb 19, 2020 at 5:46 PM Laurent Pinchart wrote:
> > > On Wed, Feb 19, 2020 at 05:22:38PM +0100, Daniel Vetter wrote:
> > >> On Wed, Feb 19, 2020 at
Hi Daniel,
On Wed, Feb 19, 2020 at 05:53:59PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 5:46 PM Laurent Pinchart wrote:
> > On Wed, Feb 19, 2020 at 05:22:38PM +0100, Daniel Vetter wrote:
> >> On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote:
> >>> On Wed, 19 Feb 2020 at 14:23,
On Wed, Feb 19, 2020 at 03:22:49PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman
> wrote:
> >
> > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote:
> > > Hi Daniel,
> > >
> > > Thank you for the patch.
> > >
> > > On Wed, Feb 19, 2020 at
On Wed, Feb 19, 2020 at 5:46 PM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> On Wed, Feb 19, 2020 at 05:22:38PM +0100, Daniel Vetter wrote:
> > On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote:
> > > On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote:
> > >> On Wed, Feb 19, 2020 at 2:33 PM Greg
Hi Geert,
On Wed, Feb 19, 2020 at 05:36:57PM +0100, Geert Uytterhoeven wrote:
> On Wed, Feb 19, 2020 at 5:04 PM Laurent Pinchart wrote:
> > On Fri, Feb 14, 2020 at 09:26:23AM +0100, Geert Uytterhoeven wrote:
> > > Document the optional properties for describing module resets, to
> > > support
Hi Daniel,
On Wed, Feb 19, 2020 at 05:22:38PM +0100, Daniel Vetter wrote:
> On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote:
> > On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote:
> >> On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman wrote:
> >>> On Wed, Feb 19, 2020 at 03:28:47PM +0200,
On Wed, 19 Feb 2020 at 16:22, Daniel Vetter wrote:
>
> On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote:
> >
> > On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote:
> > >
> > > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > On Wed, Feb 19, 2020 at 03:28:47PM
Hi Laurent,
On Wed, Feb 19, 2020 at 5:04 PM Laurent Pinchart
wrote:
> On Fri, Feb 14, 2020 at 09:26:23AM +0100, Geert Uytterhoeven wrote:
> > Document the optional properties for describing module resets, to
> > support resetting display channels on R-Car Gen2 and Gen3.
> >
> > Signed-off-by:
On 2/19/20 12:20 PM, 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.
>
> v2: I noticed that xen has a drm_driver.release hook, and uses
> drm_dev_alloc(). We need to remove the kfree from
>
On Wed, Feb 19, 2020 at 11:18 AM Johannes Weiner wrote:
>
> Yes, I'd go with absolute units when it comes to memory, because it's
> not a renewable resource like CPU and IO, and so we do have cliff
> behavior around the edge where you transition from ok to not-enough.
>
> memory.low is a bit in
On Wed, Feb 19, 2020 at 5:08 PM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> On Wed, Feb 19, 2020 at 04:47:55PM +0100, Daniel Vetter wrote:
> > On Wed, Feb 19, 2020 at 2:50 PM Laurent Pinchart wrote:
> > > On Wed, Feb 19, 2020 at 11:20:57AM +0100, Daniel Vetter wrote:
> > > >
On Wed, Feb 19, 2020 at 5:09 PM Emil Velikov wrote:
>
> On Wed, 19 Feb 2020 at 14:23, Daniel Vetter wrote:
> >
> > On Wed, Feb 19, 2020 at 2:33 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > On Wed, Feb 19, 2020 at 03:28:47PM +0200, Laurent Pinchart wrote:
> > > > Hi Daniel,
> > > >
> > > > Thank
Calculate GEM VRAM bo's offset within vram-helper without depending on
bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/drm_gem_vram_helper.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
Calculate GPU offset within vmwgfx driver itself without depending on
bo->offset
Signed-off-by: Nirmoy Das
Acked-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 2 +-
This patch removes slot->gpu_offset which is not required as
VRAM and PRIV slot are in separate PCI bar
This patch also removes unused qxl_bo_gpu_offset()
Signed-off-by: Nirmoy Das
Acked-by: Christian König
Acked-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 6 ++
Calculate GPU offset in radeon_bo_gpu_offset without depending on
bo->offset
Signed-off-by: Nirmoy Das
Reviewed-and-tested-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 1 +
drivers/gpu/drm/radeon/radeon_object.h | 16 +++-
drivers/gpu/drm/radeon/radeon_ttm.c
Store ttm bo->offset in struct nouveau_bo instead.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv04/overlay.c | 6 +++---
drivers/gpu/drm/nouveau/dispnv50/base507c.c |
Switch over to GEM VRAM's implementation to retrieve bo->offset
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/bochs/bochs_kms.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index
The larb device remains NULL if the type is MTK_DISP_OVL_2L.
A kernel panic is raised when a crtc uses mtk_smi_larb_get or
mtk_smi_larb_put.
Signed-off-by: Phong LE
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 1 +
1 file changed, 1 insertion(+)
diff --git
On Tue, Feb 18, 2020 at 07:50:33PM +0200, Andrey Lebedev wrote:
> On Mon, Feb 17, 2020 at 06:51:35PM +0100, Maxime Ripard wrote:
> > > diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> > > b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> > > index cfbf4e6c1679..bc87d28ee341 100644
> > > ---
GPU address should belong to driver not in memory management.
This patch moves ttm bo.offset and gpu_offset calculation to amdgpu driver.
Signed-off-by: Nirmoy Das
Acked-by: Huang Rui
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 ++--
1 - 100 of 253 matches
Mail list logo
