On Tue, Jul 02, 2019 at 04:17:48PM -0700, Dan Williams wrote:
> On Tue, Jul 2, 2019 at 11:42 AM Jason Gunthorpe wrote:
> >
> > On Mon, Jul 01, 2019 at 10:25:17AM +0200, Christoph Hellwig wrote:
> > > And I've demonstrated that I can't send patch series.. While this
> > > has all the right patches
Daniel,
On 02/07/2019 11:58, Daniel Thompson wrote:
On Mon, Jul 01, 2019 at 05:14:23PM +0200, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
Add DT binding for led-backlight.
I think the patchset is in the wrong order; the DT bindings
documentation should appear *before* the binding is
impl
On Fri, Jun 07, 2019 at 05:14:52PM -0700, Ralph Campbell wrote:
> HMM defines its own struct hmm_update which is passed to the
> sync_cpu_device_pagetables() callback function. This is
> sufficient when the only action is to invalidate. However,
> a device may want to know the reason for the invali
On 7/2/19 5:26 AM, Daniel Thompson wrote:
[PATCH 1/2] dt-bindings: backlight: fix vendor prefix for
ArcticSand arcxcnn driver bindings
The "v2" is normally applied to the whole patchset (if you
prepare the patchset using git format-patch then you can use
the --subject-prefix argument for that).
On 7/2/19 12:53 PM, Jason Gunthorpe wrote:
On Fri, Jun 07, 2019 at 05:14:52PM -0700, Ralph Campbell wrote:
HMM defines its own struct hmm_update which is passed to the
sync_cpu_device_pagetables() callback function. This is
sufficient when the only action is to invalidate. However,
a device may
Hi David,
The following changes since commit e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd:
Linux 5.1 (2019-05-05 17:42:58 -0700)
are available in the git repository at:
git://git.armlinux.org.uk/~rmk/linux-arm.git for-airlie-armada
for you to fetch changes up to 837567c1e9d587c0b438263c9cfd32d
On Tue, 2019-07-02 at 10:09 +0200, Michel Dänzer wrote:
> On 2019-07-01 6:01 p.m., Timur Kristóf wrote:
> > On Mon, 2019-07-01 at 16:54 +0200, Michel Dänzer wrote:
> > > On 2019-06-28 2:21 p.m., Timur Kristóf wrote:
> > > > I haven't found a good way to measure the maximum PCIe
> > > > throughput
>
This inits the panel orientation property for the mediatek dsi driver
if the panel orientation (connector.display_info.panel_orientation) is
not DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 8
1 file changed, 8 insertions(+)
On Mon, Jul 01, 2019 at 10:25:17AM +0200, Christoph Hellwig wrote:
> And I've demonstrated that I can't send patch series.. While this
> has all the right patches, it also has the extra patches already
> in the hmm tree, and four extra patches I wanted to send once
> this series is merged. I'll g
On Wed, Jul 03, 2019 at 12:49:12AM +0200, Christoph Hellwig wrote:
> On Tue, Jul 02, 2019 at 07:53:23PM +, Jason Gunthorpe wrote:
> > > I'm sending this out now since we are updating many of the HMM APIs
> > > and I think it will be useful.
> >
> > This make so much sense, I'd like to apply th
On Tue, Jul 2, 2019 at 9:45 AM Rob Clark wrote:
>
> From: Rob Clark
>
> The bridge has pretty good docs, lets add a link to make them easier to
> find.
>
> Signed-off-by: Rob Clark
This is in the DT binding, but having it in the driver as well is a nice touch.
Reviewed-by: Jeffrey Hugo
__
https://bugs.freedesktop.org/show_bug.cgi?id=109524
--- Comment #3 from BabylonAS ---
Connected to this bug report on WineHQ:
https://bugs.winehq.org/show_bug.cgi?id=47389
Confirmed for Mesa 18.3.6. R100-class GPU too (ATI Mobility Radeon 7000 IGP).
R100 class Radeon GPUs only support OpenGL up
Adds a new drm property "vrr" and "vrr_enable" and implemented
the set/get functions, through which userspace could set vfp
data to komeda.
Signed-off-by: Lowry Li (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/d71/d71_component.c | 6 +++
drivers/gpu/drm/arm/display/komeda/komeda_cr
https://bugs.freedesktop.org/show_bug.cgi?id=111042
Michel Dänzer changed:
What|Removed |Added
Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
Implement get_dai_id callback of audio HDMI codec
to support ASoC audio graph card.
HDMI audio output has to be connected to sii902x port 3.
get_dai_id callback maps this port to ASoC DAI index 0.
Signed-off-by: Olivier Moysan
---
drivers/gpu/drm/bridge/sii902x.c | 23 +++
1
On 2019-07-02 11:49 a.m., Timur Kristóf wrote:
> On Tue, 2019-07-02 at 10:09 +0200, Michel Dänzer wrote:
>> On 2019-07-01 6:01 p.m., Timur Kristóf wrote:
>>> On Mon, 2019-07-01 at 16:54 +0200, Michel Dänzer wrote:
On 2019-06-28 2:21 p.m., Timur Kristóf wrote:
> I haven't found a good way t
On Tue, 2019-07-02 at 14:38 +0100, Emil Velikov wrote:
> Hi Oleg,
>
> On Mon, 1 Jul 2019 at 09:00, Oleg Vasilev
> wrote:
> > Currently, downstream port type is only reported in debugfs. This
> > information should be considered important since it reflects the
> > actual
> > physical connector typ
Hi all,
On Wed, 3 Jul 2019 14:54:43 +1000 Stephen Rothwell
wrote:
>
> On Wed, 3 Jul 2019 01:55:08 + "Kuehling, Felix"
> wrote:
> >
> > From: Philip Yang
> >
> > In order to pass mirror instead of mm to hmm_range_register, we need
> > pass bo instead of ttm to amdgpu_ttm_tt_get_user_pages
This patch replaces mgag200's framebuffer console with DRM's generic
implememtation. All respective code is being removed from the driver.
The console is set up with a shadow buffer. The actual buffer object is
not permanently pinned in video ram, but just another buffer object that
the driver mov
DRM clients, such as the fbdev emulation, have their buffer objects
mapped by default. Mapping a buffer implicitly prevents its relocation.
Hence, the buffer may permanently consume video memory while it's
allocated. This is a problem for drivers of low-memory devices, such as
ast, mgag200 or older
This patch replaces ast's framebuffer console with DRM's generic
implememtation. All respective code is being removed from the driver.
The console is set up with a shadow buffer. The actual buffer object is
not permanently pinned in video ram, but just another buffer object that
the driver moves i
DRM client buffers are permanently mapped throughout their lifetime. This
prevents us from using generic framebuffer emulation for devices with
small dedicated video memory, such as ast or mgag200. With fb buffers
permanently mapped, such devices often won't have enougth space left to
display other
The bochs driver (and virtual hardware) requires buffer objects to
reside in video ram to display them to the screen. So it can not
display the framebuffer console because the respective buffer object
is permanently pinned in system memory.
Using a shadow buffer for the console solves this problem
The shadow-buffered framebuffer console only needs the buffer object
to be mapped during updates. While not being updated from the shadow
buffer, the buffer object can remain unmapped.
An unmapped buffer object can be evicted to system memory and does
not consume video ram until displayed. This al
On Wed, Jul 03, 2019 at 01:48:41PM +0530, Nishka Dasgupta wrote:
> Remove file ion_carveout_heap.c as its functions and definitions are not
> used anywhere.
> Issue found with Coccinelle.
>
> Signed-off-by: Nishka Dasgupta
> ---
> drivers/staging/android/ion/Kconfig | 9 --
> drivers
On Wed, Jul 03, 2019 at 02:14:21PM +0530, Nishka Dasgupta wrote:
> On 03/07/19 2:07 PM, Greg KH wrote:
> > On Wed, Jul 03, 2019 at 01:48:41PM +0530, Nishka Dasgupta wrote:
> > > Remove file ion_carveout_heap.c as its functions and definitions are not
> > > used anywhere.
> > > Issue found with Cocc
On Tue, Jul 02, 2019 at 05:17:21PM +0200, Jean-Jacques Hiblot wrote:
> Daniel,
>
> On 02/07/2019 15:04, Daniel Thompson wrote:
> > On Tue, Jul 02, 2019 at 12:59:53PM +0200, Jean-Jacques Hiblot wrote:
> > > Hi Daniel,
> > >
> > > On 02/07/2019 11:54, Daniel Thompson wrote:
> > > > On Mon, Jul 01,
On Wed, Jul 3, 2019 at 10:37 AM Greg KH wrote:
>
> On Wed, Jul 03, 2019 at 01:48:41PM +0530, Nishka Dasgupta wrote:
> > Remove file ion_carveout_heap.c as its functions and definitions are not
> > used anywhere.
> > Issue found with Coccinelle.
> >
> > Signed-off-by: Nishka Dasgupta
> > ---
> >
On Tue, Jul 02, 2019 at 08:57:05PM -0500, Alex Deucher wrote:
> Hi Dave, Daniel,
>
> 3 fixes all cc'ed to stable. Note that dim complains about the Fixes tag
> in one of the patches. The patch has:
> Fixes: 921935dc6404 ("drm/amd/powerplay: enforce display related settings
> only on needed")
>
On Wed, Jul 03, 2019 at 07:26:16AM +, Lowry Li (Arm Technology China) wrote:
> Adds a new drm property "vrr" and "vrr_enable" and implemented
> the set/get functions, through which userspace could set vfp
> data to komeda.
>
> Signed-off-by: Lowry Li (Arm Technology China)
> ---
> .../gpu/dr
Daniel,
On 03/07/2019 11:44, Daniel Thompson wrote:
On Tue, Jul 02, 2019 at 05:17:21PM +0200, Jean-Jacques Hiblot wrote:
Daniel,
On 02/07/2019 15:04, Daniel Thompson wrote:
On Tue, Jul 02, 2019 at 12:59:53PM +0200, Jean-Jacques Hiblot wrote:
Hi Daniel,
On 02/07/2019 11:54, Daniel Thompson w
Commit 9a61c54b9bff ("drm/rockchip: vop: group vop registers") seems to
have unintentionally changed the defintion of this macro. Since it is
unused, this was not spotted but any attempt to use it results in
compilation errors.
Revert to the previous definition.
Fixes: 9a61c54b9bff ("drm/rockchi
drm_sched_entity_kill_jobs_cb() is called right from the last scheduled
job finished fence signaling. As this might happen from IRQ context we
now end up calling the GPU driver free_job callback in IRQ context, while
all other paths call it from normal process context.
Etnaviv in particular calls
Hi Daniel,
discussion on this somehow died quite a while ago. As the bug is still
present in etnaviv, I would like to get it going again.
Am Montag, den 18.06.2018, 10:06 +0200 schrieb Daniel Vetter:
> On Thu, May 31, 2018 at 10:41:25AM +0200, Lucas Stach wrote:
> > Am Dienstag, den 29.05.2018, 1
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #69 from Hleb Valoshka <375...@gmail.com> ---
I have this fault with 2400G and mesa 18.3 & 19.1.1 with Linux 4.19 (other
versions haven't been tested).
It seems that Vega is unable to handle tiny VBO correctly. I have an old
applicat
On 7/3/19 5:50 AM, Daniel Vetter wrote:
On Wed, Jul 3, 2019 at 10:37 AM Greg KH wrote:
On Wed, Jul 03, 2019 at 01:48:41PM +0530, Nishka Dasgupta wrote:
Remove file ion_carveout_heap.c as its functions and definitions are not
used anywhere.
Issue found with Coccinelle.
Signed-off-by: Nishka D
On 7/3/19 4:18 AM, Nishka Dasgupta wrote:
Remove file ion_chunk_heap.c as its functions and definitions are not
used anywhere else.
Issue found with Coccinelle.
Acked-by: Laura Abbott
Signed-off-by: Nishka Dasgupta
---
drivers/staging/android/ion/Kconfig | 9 --
drivers/stagi
On Monday, 2019-05-13 02:52:04 +1000, Jonathan Gray wrote:
> drm render nodes have the same major as drm primary devices but offset
> the minor by a base of 128.
>
> I expected the name of the device to have numbering starting at 0 when
> these non-linux codepaths were added (before OpenBSD had re
On Monday, 2019-05-13 02:50:49 +1000, Jonathan Gray wrote:
> Unlike Linux the OpenBSD primary "drm" device name is substring of the
> "drmR" render node device name and strncmp() tests resulted in render
> nodes being flagged as primary nodes.
>
> Signed-off-by: Jonathan Gray
Reviewed-by: Eric E
On Tue, Jun 25, 2019 at 09:00:36PM +0530, Jagan Teki wrote:
> On Tue, Jun 25, 2019 at 8:19 PM Maxime Ripard
> wrote:
> >
> > On Thu, Jun 20, 2019 at 11:57:44PM +0530, Jagan Teki wrote:
> > > On Fri, Jun 14, 2019 at 7:54 PM Maxime Ripard
> > > wrote:
> > > >
> > > > On Wed, Jun 05, 2019 at 01:03
On Tue, Jul 02, 2019 at 09:10:26PM +0530, Jagan Teki wrote:
> On Tue, Jul 2, 2019 at 8:59 PM Maxime Ripard
> wrote:
> > On Tue, Jul 02, 2019 at 12:30:14AM +0530, Jagan Teki wrote:
> > > On Tue, Jun 25, 2019 at 8:07 PM Maxime Ripard
> > > wrote:
> > > > > > > > > > > BSP has tcon_div and dsi_div
On Tue, Jul 2, 2019 at 9:08 PM Bjorn Andersson
wrote:
>
> On Mon 01 Jul 10:39 PDT 2019, Jeffrey Hugo wrote:
>
> > Creating the msm gem address space requires a reference to the dev where
> > the iommu is located. The driver currently assumes this is the same as
> > the platform device, which brea
On 02/07/2019 21:26, Rob Clark wrote:
From: Rob Clark
Avoid attaching any non-driver managed domain if the driver indicates
that it manages the iommu directly.
This solves a couple problems that drm/msm + arm-smmu has with the iommu
framework:
1) In some cases the bootloader takes the iommu o
https://bugs.freedesktop.org/show_bug.cgi?id=110635
--- Comment #10 from tempel.jul...@gmail.com ---
Bug still present with
mesa-git 19.2.0_devel.112439.11a3679e3ab
llvm-git 9.0.0_r320439.9e8e8c60fa
Is GFX8 not receiving any fixes anymore?
--
You are receiving this mail because:
You are the a
On Wed, Jul 3, 2019 at 5:54 AM Daniel Vetter wrote:
>
> On Tue, Jul 02, 2019 at 08:57:05PM -0500, Alex Deucher wrote:
> > Hi Dave, Daniel,
> >
> > 3 fixes all cc'ed to stable. Note that dim complains about the Fixes tag
> > in one of the patches. The patch has:
> > Fixes: 921935dc6404 ("drm/amd/
kmemdup is introduced to duplicate a region of memory in a neat way.
Rather than kmalloc/kzalloc + memset, which the programmer needs to
write the size twice (sometimes lead to mistakes), kmemdup improves
readability, leads to smaller code and also reduce the chances of mistakes.
Suggestion to use
On Wed, Jul 3, 2019 at 12:47 PM Lucas Stach wrote:
>
> Hi Daniel,
>
> discussion on this somehow died quite a while ago. As the bug is still
> present in etnaviv, I would like to get it going again.
>
> Am Montag, den 18.06.2018, 10:06 +0200 schrieb Daniel Vetter:
> > On Thu, May 31, 2018 at 10:41
On Wed, Jul 3, 2019 at 3:10 PM Alex Deucher wrote:
>
> On Wed, Jul 3, 2019 at 5:54 AM Daniel Vetter wrote:
> >
> > On Tue, Jul 02, 2019 at 08:57:05PM -0500, Alex Deucher wrote:
> > > Hi Dave, Daniel,
> > >
> > > 3 fixes all cc'ed to stable. Note that dim complains about the Fixes tag
> > > in on
On Wed, Jul 03, 2019 at 12:39:10PM +0100, Eric Engestrom wrote:
> On Monday, 2019-05-13 02:52:04 +1000, Jonathan Gray wrote:
> > drm render nodes have the same major as drm primary devices but offset
> > the minor by a base of 128.
> >
> > I expected the name of the device to have numbering starti
From: Emil Velikov
With later commit we'll rework DRM core authentication handling.
Namely unauthenticated master will be allowed with, DRM_AUTH ioctls.
Since vmwgfx does additional master locking and DRM_AUTH handling, this
will not matter almost all cases.
The only exception being using the l
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.
The former was a case for Mesa where it did
From: Emil Velikov
With earlier commits we've removed DRM_AUTH for driver ioctls annotated
with DRM_AUTH | DRM_RENDER_ALLOW, as the protection it introduces is
effectively not existent.
With next commit, we'll effectively do the same for DRM core.
Yet the AMD developers have voiced concerns tha
Exported BOs might be imported back, then mmap()-ed to be written
too. Most drivers handle that by mmap()-ing the GEM handle after it's
been imported, but, according to [1], this is illegal. The panfrost
driver has recently switched to this generic helper (which was renamed
into drm_gem_map_offset(
On Wed, 3 Jul 2019 at 09:19, Vasilev, Oleg wrote:
>
> On Tue, 2019-07-02 at 14:38 +0100, Emil Velikov wrote:
> > Hi Oleg,
> >
> > On Mon, 1 Jul 2019 at 09:00, Oleg Vasilev
> > wrote:
> > > Currently, downstream port type is only reported in debugfs. This
> > > information should be considered imp
On Wed, Jul 3, 2019 at 7:34 AM Boris Brezillon
wrote:
>
> Exported BOs might be imported back, then mmap()-ed to be written
> too. Most drivers handle that by mmap()-ing the GEM handle after it's
> been imported, but, according to [1], this is illegal.
It's not illegal, but is supposed to go thru
Well this is still a NAK.
As stated previously please just don't remove DRM_AUTH and keep the
functionality as it is.
I absolutely don't see the point to add a new flag to remove the same
functionality a different flag provides.
Christian.
Am 03.07.2019 15:30 schrieb Emil Velikov :
From: Emil
On Wed, 3 Jul 2019 07:45:32 -0600
Rob Herring wrote:
> On Wed, Jul 3, 2019 at 7:34 AM Boris Brezillon
> wrote:
> >
> > Exported BOs might be imported back, then mmap()-ed to be written
> > too. Most drivers handle that by mmap()-ing the GEM handle after it's
> > been imported, but, according to
On Wed, 3 Jul 2019 at 14:48, Koenig, Christian wrote:
>
> Well this is still a NAK.
>
> As stated previously please just don't remove DRM_AUTH and keep the
> functionality as it is.
>
AFAICT nobody was in favour of your suggestion to remove DRM_AUTH from
the handle to/from fd ioclts.
Thus this se
From: Rob Clark
For platforms that require the "zap shader" to take the GPU out of
secure mode at boot, we also need the zap fw to end up in the initrd.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/d
Den 03.07.2019 10.32, skrev Thomas Zimmermann:
> DRM clients, such as the fbdev emulation, have their buffer objects
> mapped by default. Mapping a buffer implicitly prevents its relocation.
> Hence, the buffer may permanently consume video memory while it's
> allocated. This is a problem for dri
On Wed, Jul 3, 2019 at 5:42 AM Robin Murphy wrote:
>
> On 02/07/2019 21:26, Rob Clark wrote:
> > From: Rob Clark
> >
> > Avoid attaching any non-driver managed domain if the driver indicates
> > that it manages the iommu directly.
> >
> > This solves a couple problems that drm/msm + arm-smmu has
Den 03.07.2019 10.33, skrev Thomas Zimmermann:
> This patch replaces ast's framebuffer console with DRM's generic
> implememtation. All respective code is being removed from the driver.
>
> The console is set up with a shadow buffer. The actual buffer object is
> not permanently pinned in video
Den 03.07.2019 10.33, skrev Thomas Zimmermann:
> The bochs driver (and virtual hardware) requires buffer objects to
> reside in video ram to display them to the screen. So it can not
> display the framebuffer console because the respective buffer object
> is permanently pinned in system memory.
>
On 7/3/19 6:28 AM, Lucas Stach wrote:
> drm_sched_entity_kill_jobs_cb() is called right from the last scheduled
> job finished fence signaling. As this might happen from IRQ context we
> now end up calling the GPU driver free_job callback in IRQ context, while
> all other paths call it from normal
Den 03.07.2019 10.33, skrev Thomas Zimmermann:
> This patch replaces mgag200's framebuffer console with DRM's generic
> implememtation. All respective code is being removed from the driver.
>
> The console is set up with a shadow buffer. The actual buffer object is
> not permanently pinned in vi
Am Mittwoch, den 03.07.2019, 14:23 + schrieb Grodzovsky, Andrey:
> On 7/3/19 6:28 AM, Lucas Stach wrote:
> > drm_sched_entity_kill_jobs_cb() is called right from the last scheduled
> > job finished fence signaling. As this might happen from IRQ context we
> > now end up calling the GPU driver f
Am 03.07.2019 16:00 schrieb Emil Velikov :
On Wed, 3 Jul 2019 at 14:48, Koenig, Christian wrote:
>
> Well this is still a NAK.
>
> As stated previously please just don't remove DRM_AUTH and keep the
> functionality as it is.
>
AFAICT nobody was in favour of your suggestion to remove DRM_AUTH fr
On Wed, 3 Jul 2019 15:13:25 +0100
Steven Price wrote:
> On 03/07/2019 14:56, Boris Brezillon wrote:
> > On Wed, 3 Jul 2019 07:45:32 -0600
> > Rob Herring wrote:
> >
> >> On Wed, Jul 3, 2019 at 7:34 AM Boris Brezillon
> >> wrote:
> >>>
> >>> Exported BOs might be imported back, then mmap()-
On 7/3/19 10:32 AM, Lucas Stach wrote:
> Am Mittwoch, den 03.07.2019, 14:23 + schrieb Grodzovsky, Andrey:
>> On 7/3/19 6:28 AM, Lucas Stach wrote:
>>> drm_sched_entity_kill_jobs_cb() is called right from the last scheduled
>>> job finished fence signaling. As this might happen from IRQ context
On Wed, 3 Jul 2019 at 15:33, Koenig, Christian wrote:
> Am 03.07.2019 16:00 schrieb Emil Velikov :
>
> On Wed, 3 Jul 2019 at 14:48, Koenig, Christian
> wrote:
> >
> > Well this is still a NAK.
> >
> > As stated previously please just don't remove DRM_AUTH and keep the
> > functionality as it is
Am Mittwoch, den 03.07.2019, 14:41 + schrieb Grodzovsky, Andrey:
> On 7/3/19 10:32 AM, Lucas Stach wrote:
> > Am Mittwoch, den 03.07.2019, 14:23 + schrieb Grodzovsky, Andrey:
> > > On 7/3/19 6:28 AM, Lucas Stach wrote:
> > > > drm_sched_entity_kill_jobs_cb() is called right from the last sc
Am 03.07.2019 16:51 schrieb Emil Velikov :
On Wed, 3 Jul 2019 at 15:33, Koenig, Christian wrote:
> Am 03.07.2019 16:00 schrieb Emil Velikov :
>
> On Wed, 3 Jul 2019 at 14:48, Koenig, Christian
> wrote:
> >
> > Well this is still a NAK.
> >
> > As stated previously please just don't remove DRM_
On 7/3/19 10:53 AM, Lucas Stach wrote:
> Am Mittwoch, den 03.07.2019, 14:41 + schrieb Grodzovsky, Andrey:
>> On 7/3/19 10:32 AM, Lucas Stach wrote:
>>> Am Mittwoch, den 03.07.2019, 14:23 + schrieb Grodzovsky, Andrey:
On 7/3/19 6:28 AM, Lucas Stach wrote:
> drm_sched_entity_kill_jo
drm_debugfs_crtc_crc_add() function checks that both .set_crc_source and
.verify_crc_source hooks are provided before enabling debugfs support for
reading per-frame CRC data. Make that explicit in the documentation.
Cc: Daniel Vetter
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/drm_debugfs_cr
On Wed, 3 Jul 2019 15:50:08 +0100
Steven Price wrote:
> On 03/07/2019 15:33, Boris Brezillon wrote:
> > On Wed, 3 Jul 2019 15:13:25 +0100
> > Steven Price wrote:
> >
> >> On 03/07/2019 14:56, Boris Brezillon wrote:
> >>> On Wed, 3 Jul 2019 07:45:32 -0600
> >>> Rob Herring wrote:
> >>>
On Wed, 3 Jul 2019 at 15:58, Koenig, Christian wrote:
> Am 03.07.2019 16:51 schrieb Emil Velikov :
>
> On Wed, 3 Jul 2019 at 15:33, Koenig, Christian
> wrote:
> > Am 03.07.2019 16:00 schrieb Emil Velikov :
> >
> > On Wed, 3 Jul 2019 at 14:48, Koenig, Christian
> > wrote:
> > >
> > > Well this
On Wed, 3 Jul 2019 at 14:15, Fuqian Huang wrote:
>
> kmemdup is introduced to duplicate a region of memory in a neat way.
> Rather than kmalloc/kzalloc + memset, which the programmer needs to
> write the size twice (sometimes lead to mistakes), kmemdup improves
> readability, leads to smaller code
On Wed, Jul 03, 2019 at 04:03:30PM +0100, Liviu Dudau wrote:
> drm_debugfs_crtc_crc_add() function checks that both .set_crc_source and
> .verify_crc_source hooks are provided before enabling debugfs support for
> reading per-frame CRC data. Make that explicit in the documentation.
>
> Cc: Daniel
/commits/Derek-Basehore/Panel-rotation-patches/20190703-172146
config: i386-defconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-6) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
If you fix the issue, kindly add following tag
Reported-by
/commits/Derek-Basehore/Panel-rotation-patches/20190703-172146
config: s390-debug_defconfig (attached as .config)
compiler: s390-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
On Wed, Jul 03, 2019 at 07:45:32AM -0600, Rob Herring wrote:
> On Wed, Jul 3, 2019 at 7:34 AM Boris Brezillon
> wrote:
> >
> > Exported BOs might be imported back, then mmap()-ed to be written
> > too. Most drivers handle that by mmap()-ing the GEM handle after it's
> > been imported, but, accordi
On Wed, Jul 03, 2019 at 05:47:24PM +0200, Daniel Vetter wrote:
> On Wed, Jul 03, 2019 at 07:45:32AM -0600, Rob Herring wrote:
> > On Wed, Jul 3, 2019 at 7:34 AM Boris Brezillon
> > wrote:
> > >
> > > Exported BOs might be imported back, then mmap()-ed to be written
> > > too. Most drivers handle t
On Wed, Jul 03, 2019 at 05:21:20PM +0200, Daniel Vetter wrote:
> On Wed, Jul 03, 2019 at 04:03:30PM +0100, Liviu Dudau wrote:
> > drm_debugfs_crtc_crc_add() function checks that both .set_crc_source and
> > .verify_crc_source hooks are provided before enabling debugfs support for
> > reading per-fr
On Wed, Jul 3, 2019 at 8:13 AM Steven Price wrote:
>
> On 03/07/2019 14:56, Boris Brezillon wrote:
> > On Wed, 3 Jul 2019 07:45:32 -0600
> > Rob Herring wrote:
> >
> >> On Wed, Jul 3, 2019 at 7:34 AM Boris Brezillon
> >> wrote:
> >>>
> >>> Exported BOs might be imported back, then mmap()-ed to b
On Wed, Jul 3, 2019 at 5:59 PM Liviu Dudau wrote:
>
> On Wed, Jul 03, 2019 at 05:21:20PM +0200, Daniel Vetter wrote:
> > On Wed, Jul 03, 2019 at 04:03:30PM +0100, Liviu Dudau wrote:
> > > drm_debugfs_crtc_crc_add() function checks that both .set_crc_source and
> > > .verify_crc_source hooks are pr
On Wed, Jul 3, 2019 at 6:11 PM Steven Price wrote:
>
> On 03/07/2019 15:33, Boris Brezillon wrote:
> > On Wed, 3 Jul 2019 15:13:25 +0100
> > Steven Price wrote:
> >
> >> On 03/07/2019 14:56, Boris Brezillon wrote:
> >>> On Wed, 3 Jul 2019 07:45:32 -0600
> >>> Rob Herring wrote:
> >>>
> On W
On Wed, Jul 03, 2019 at 07:32:27AM -0400, Laura Abbott wrote:
> On 7/3/19 5:50 AM, Daniel Vetter wrote:
> > On Wed, Jul 3, 2019 at 10:37 AM Greg KH wrote:
> > >
> > > On Wed, Jul 03, 2019 at 01:48:41PM +0530, Nishka Dasgupta wrote:
> > > > Remove file ion_carveout_heap.c as its functions and defi
Am 03.07.2019 18:27 schrieb Fuqian Huang :
kmemdup is introduced to duplicate a region of memory in a neat way.
Rather than kmalloc/kzalloc + memcpy, which the programmer needs to
write the size twice (sometimes lead to mistakes), kmemdup improves
readability, leads to smaller code and also reduc
https://bugs.freedesktop.org/show_bug.cgi?id=109524
--- Comment #4 from laszlo.erd...@freenet.de ---
Other applications using OpenGL (and so mesa, I guess?) still seem to work
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=109524
--- Comment #5 from Ilia Mirkin ---
NV05 and NV11 don't support GLSL at all. Some entry point must not be
preventing it properly... perhaps something internal.
Is there like a wine test or something of the sort that can be used to
reproduce thi
On Tue, Jul 02, 2019 at 03:48:48PM -0700, Rob Clark wrote:
> > > There is one kernel, and there
> > > are N distro's, so debugging a users "I don't get a screen at boot"
> > > problem because their distro missed some shim patch really just
> > > doesn't seem like a headache I want to have.
> >
> >
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.
The former was a case for Mesa where it did
https://bugs.freedesktop.org/show_bug.cgi?id=109524
--- Comment #6 from laszlo.erd...@freenet.de ---
(In reply to Ilia Mirkin from comment #5)
> Is there like a wine test or something of the sort that can be used to
> reproduce this? I have such a GPU plugged in I can test with, but I need a
> re
https://bugs.freedesktop.org/show_bug.cgi?id=110113
--- Comment #1 from ludo.sur...@gmail.com ---
Hello,
Juste to say i have the same bug and we both have gigabyte Gaming OC Vega.
--
You are receiving this mail because:
You are the assignee for the bug.___
On Wed, Jul 3, 2019 at 9:33 AM Leif Lindholm wrote:
>
> On Tue, Jul 02, 2019 at 03:48:48PM -0700, Rob Clark wrote:
> > > > There is one kernel, and there
> > > > are N distro's, so debugging a users "I don't get a screen at boot"
> > > > problem because their distro missed some shim patch really j
On Wed, Jul 3, 2019 at 1:49 PM Ralph Campbell wrote:
> On 6/30/19 11:20 PM, Christoph Hellwig wrote:
> > hmm_vma_fault is marked as a legacy API to get rid of, but quite suites
> > the current nouvea flow. Move it to the only user in preparation for
>
> I didn't quite parse the phrase "quite suit
https://bugs.freedesktop.org/show_bug.cgi?id=106224
LunarG changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
On Wed, 3 Jul 2019 at 19:41, Rob Clark wrote:
>
> On Wed, Jul 3, 2019 at 9:33 AM Leif Lindholm wrote:
> >
> > On Tue, Jul 02, 2019 at 03:48:48PM -0700, Rob Clark wrote:
> > > > > There is one kernel, and there
> > > > > are N distro's, so debugging a users "I don't get a screen at boot"
> > > > >
On Tue, Jul 2, 2019 at 7:19 AM Gerd Hoffmann wrote:
>
> Call reservation_object_* directly instead
> of using ttm_bo_{reserve,unreserve}.
>
> v4: check for EINTR only.
> v3: check for EINTR too.
>
> Signed-off-by: Gerd Hoffmann
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/virtio/virtgpu
On Tue, Jul 2, 2019 at 7:19 AM Gerd Hoffmann wrote:
>
> Some helper functions to manage an array of gem objects.
>
> v6:
> - add ticket to struct virtio_gpu_object_array.
> - add virtio_gpu_array_{lock,unlock}_resv helpers.
> - add virtio_gpu_array_add_fence helper.
> v5: some small optimizatio
1 - 100 of 168 matches
Mail list logo
