Hi,
> > > That would also make the verify_access callback completely superfluous
> > > and looks like a good step into the right direction of de-midlayering.
> >
> > Hmm, right, noticed that too while working on another patch series.
> > Guess I'll try to merge those two and see where I end up
No, I just see your comment "The next vkQueueSubmit()
waiting on a the syncobj will read the sideband payload and wait for a
fence chain element with a seqno superior or equal to the sideband
payload value to be added into the fence chain and use that fence to
trigger the submission on the kernel d
This allows to drop qxl_mode_dumb_mmap() and qxl_bo_mmap_offset(),
the default gem function works just fine.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 4 +---
drivers/gpu/drm/qxl/qxl_object.h | 5 -
drivers/gpu/drm/qxl/qxl_drv.c| 1 -
drivers/gpu/drm/qxl/qxl_
Now with ttm_buffer_object being a subclass of drm_gem_object we can
easily lookup ttm_buffer_object for a given drm_gem_object, which in
turm allows to create common helper functions.
This patch starts off with a gem_ttm_bo_device_init() helper function
which initializes ttm with the vma offset m
Gerd Hoffmann (17):
drm/ttm: turn ttm_bo_device.vma_manager into a pointer
drm/ttm: add gem_ttm_bo_device_init()
drm/vram: switch vram helpers to the new gem_ttm_bo_device_init()
drm/qxl: switch qxl to the new gem_ttm_bo_device_init()
drm: add mmap() to drm_gem_object_funcs
drm/shmem:
... using the use drm_gem_ttm_mmap() helper function.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.h| 1 -
drivers/gpu/drm/qxl/qxl_drv.c| 2 +-
drivers/gpu/drm/qxl/qxl_object.c | 1 +
drivers/gpu/drm/qxl/qxl_ttm.c| 16
4 files changed, 2 insertions
Add helper function to mmap ttm bo's via drm_gem_object_funcs->mmap().
Note that with this code path access verification is done by
drm_gem_mmap() and ttm_bo_driver.verify_access() is not used.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_ttm_helper.h | 2 ++
drivers/gpu/drm/drm_ge
This allows to drop drm_gem_vram_mmap_offset() and
drm_gem_vram_driver_dumb_mmap_offset(), the default
gem function works just fine.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_vram_helper.h | 6 +--
drivers/gpu/drm/drm_gem_vram_helper.c | 48 ---
dr
Not sure what this hook is supposed to do. vmf->vma->vm_private_data
should never be NULL, so the extra check in qxl_ttm_fault should have no
effect.
Drop it.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_ttm.c | 27 +--
1 file changed, 1 insertion(+), 26 del
Not needed any more.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_ttm.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_ttm.c b/drivers/gpu/drm/qxl/qxl_ttm.c
index dbaed0e67c21..d1d8fe6e1e93 100644
--- a/drivers/gpu/drm/qxl/qxl_ttm.c
+++ b/drivers/
Factor out ttm vma setup to a new function.
Signed-off-by: Gerd Hoffmann
---
include/drm/ttm/ttm_bo_api.h| 8 ++
drivers/gpu/drm/ttm/ttm_bo_vm.c | 47 ++---
2 files changed, 33 insertions(+), 22 deletions(-)
diff --git a/include/drm/ttm/ttm_bo_api.h b/includ
Switch gem shmem helper from gem_driver->fops->mmap to
drm_gem_object_funcs->mmap.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_shmem_helper.h | 4 ++--
drivers/gpu/drm/drm_gem_shmem_helper.c | 18 +++---
drivers/gpu/drm/panfrost/panfrost_gem.c | 1 +
drivers/gpu/drm/
drm_gem_object_funcs->vm_ops alone can't handle
everything mmap() needs. Add a new callback for it.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem.h | 9 +
drivers/gpu/drm/drm_gem.c | 6 ++
2 files changed, 15 insertions(+)
diff --git a/include/drm/drm_gem.h b/include/drm
We have no qxl-specific fops any more.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 2fb1641c817e..4853082ba924 100644
--- a/drivers/
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_drv.c| 8
drivers/gpu/drm/qxl/qxl_object.c | 12
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
index 12cf85a06bed..38467478c7b2 10064
Rename the embedded struct vma_offset_manager, it is named _vma_manager
now. ttm_bo_device.vma_manager is a pointer now, pointing to the
embedded ttm_bo_device._vma_manager by default.
Add ttm_bo_device_init_with_vma_manager() function which allows to
initialize ttm with a different vma manager.
Not needed any more.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_vram_helper.h | 3 ---
include/drm/drm_vram_mm_helper.h | 3 ---
drivers/gpu/drm/drm_gem_vram_helper.c | 1 -
drivers/gpu/drm/drm_vram_mm_helper.c | 11 ---
4 files changed, 18 deletions(-)
diff --git
Not needed any more because we don't have vram specific functions any
more. DEFINE_DRM_GEM_FOPS() can be used instead.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_vram_mm_helper.h| 17 -
drivers/gpu/drm/ast/ast_drv.c | 5 +
drivers/gpu
DEFINE_DRM_GEM_SHMEM_FOPS is identical to DEFINE_DRM_GEM_FOPS now,
drop it.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_shmem_helper.h | 26 -
drivers/gpu/drm/cirrus/cirrus.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +-
drivers/gpu/drm/v
... using the new drm_gem_ttm_mmap() helper function.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_vram_mm_helper.h | 9 +
drivers/gpu/drm/drm_gem_vram_helper.c | 4 +++-
drivers/gpu/drm/drm_vram_mm_helper.c | 27 ---
3 files changed, 4 insertions(+),
https://bugs.freedesktop.org/show_bug.cgi?id=22
--- Comment #9 from Pierre-Eric Pelloux-Prayer
---
(In reply to Brian Schott from comment #3)
> I think that I'm seeing something related with my 2700u Inspiron 7375.
>
> If I have compositing enabled in XFWM4, the system will immediately stop
https://bugs.freedesktop.org/show_bug.cgi?id=110214
Pierre-Eric Pelloux-Prayer changed:
What|Removed |Added
Resolution|--- |FIXED
Status|N
https://bugs.freedesktop.org/show_bug.cgi?id=111231
Pierre-Eric Pelloux-Prayer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolutio
On 08/08/2019 16:42, Chunming Zhou wrote:
No, I just see your comment "The next vkQueueSubmit()
waiting on a the syncobj will read the sideband payload and wait for a
fence chain element with a seqno superior or equal to the sideband
payload value to be added into the fence chain and use that fen
On 08/08/2019 17:01, Lionel Landwerlin wrote:
On 08/08/2019 16:42, Chunming Zhou wrote:
No, I just see your comment "The next vkQueueSubmit()
waiting on a the syncobj will read the sideband payload and wait for a
fence chain element with a seqno superior or equal to the sideband
payload value to
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #9 from Alex Deucher ---
Created attachment 144983
--> https://bugs.freedesktop.org/attachment.cgi?id=144983&action=edit
fix DC code
Can you try applying both of these patches? Assuming both of your monitors
have the same timing
On 25/06/2019 01:15, Kevin Hilman wrote:
> Julien Masson writes:
>
>> This patch add new macros which are used to set the following
>> registers:
>> - VPP_OSD_SCALE_COEF_IDX
>> - VPP_DOLBY_CTRL
>> - VPP_OFIFO_SIZE
>> - VPP_HOLD_LINES
>> - VPP_SC_MISC
>> - VPP_VADJ_CTRL
>>
>> Signed-off-by: Julien
On 25/06/2019 01:20, Kevin Hilman wrote:
> Julien Masson writes:
>
>> This patch add new macro HHI_HDMI_PLL_CNTL_EN which is used to enable
>> HDMI PLL.
>>
>> Signed-off-by: Julien Masson
>> ---
>> drivers/gpu/drm/meson/meson_vclk.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
On 25/06/2019 01:24, Kevin Hilman wrote:
> Julien Masson writes:
>
>> This patch series aims to clean-up differents parts of the drm meson
>> code source.
>>
>> Couple macros have been defined and used to set several registers
>> instead of using magic constants.
>>
>> I also took the opportunity
在 2019/8/8 22:01, Lionel Landwerlin 写道:
> On 08/08/2019 16:42, Chunming Zhou wrote:
>> No, I just see your comment "The next vkQueueSubmit()
>> waiting on a the syncobj will read the sideband payload and wait for a
>> fence chain element with a seqno superior or equal to the sideband
>> payload va
On Thu, Aug 8, 2019 at 2:55 AM Neil Armstrong wrote:
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for the Amlogic Display Controller over to YAML schemas.
>
> The original example has a leftover "dmc" memory cell, that has been
> removed in the yaml rew
Hi Andrzej,
On Wed, Jul 17, 2019 at 08:39:47AM +0200, Andrzej Hajda wrote:
> On 07.07.2019 20:18, Laurent Pinchart wrote:
> > Most bridge drivers create a DRM connector to model the connector at the
> > output of the bridge. This model is historical and has worked pretty
> > well so far, but cause
Hi Sebastian,
On Thu, Jul 11, 2019 at 01:59:23PM +0200, Sebastian Reichel wrote:
> On Thu, Jul 11, 2019 at 09:37:26AM +0200, Daniel Vetter wrote:
> > > [1] The only notable exception is the omapdrm-specific DSI panel driver
> > > that implements a large number of custom operations. This should be
On Thu, Aug 8, 2019 at 4:13 AM Michel Dänzer wrote:
>
> On 2019-08-08 7:31 a.m., Alex Deucher wrote:
> > On Wed, Aug 7, 2019 at 11:49 PM Mikhail Gavrilov
> > wrote:
> >>
> >> Unfortunately error "gnome-shell: page allocation failure: order:4,
> >> mode:0x40cc0(GFP_KERNEL|__GFP_COMP),
> >> nodemas
Hi Daniel,
On Thu, Jul 11, 2019 at 09:37:26AM +0200, Daniel Vetter wrote:
> On Sun, Jul 07, 2019 at 09:07:52PM +0300, Laurent Pinchart wrote:
> > Hello,
> >
> > This patch series (nearly, see [1]) completes the rework of the omapdrm
> > driver to move to drm_bridge and drm_panel.
> >
> > What a
On 08/08/2019 17:16, Chunming Zhou wrote:
在 2019/8/8 22:01, Lionel Landwerlin 写道:
On 08/08/2019 16:42, Chunming Zhou wrote:
No, I just see your comment "The next vkQueueSubmit()
waiting on a the syncobj will read the sideband payload and wait for a
fence chain element with a seqno superior or e
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #61 from ReddestDream ---
This issue is still not fixed with 5.3-rc3, at least not with two DisplayPort
monitors.
I am not able to test with DP+HDMI configuration.
--
You are receiving this mail because:
You are the assignee for t
On Thu, Aug 8, 2019 at 7:44 AM Gerd Hoffmann wrote:
>
>
>
> Gerd Hoffmann (17):
> drm/ttm: turn ttm_bo_device.vma_manager into a pointer
> drm/ttm: add gem_ttm_bo_device_init()
> drm/vram: switch vram helpers to the new gem_ttm_bo_device_init()
> drm/qxl: switch qxl to the new gem_ttm_bo_d
Daniel any more comments on this one?
If not I'm going to push it.
Christian.
Am 08.08.19 um 15:22 schrieb Christian König:
We clear the callback list on kref_put so that by the time we
release the fence it is unused. No one should be adding to the cb_list
that they don't themselves hold a ref
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #10 from Martin ---
Sorry for the delay, I had to figure out which kernel to use, because only
Kernel 5.3.0-rc3 accepts your second patch. Stable 5.2.6 and .7 generate errors
at :25
In about 2 hours I will have it built.
You don't h
在 2019/8/8 22:34, Lionel Landwerlin 写道:
> On 08/08/2019 17:16, Chunming Zhou wrote:
>> 在 2019/8/8 22:01, Lionel Landwerlin 写道:
>>> On 08/08/2019 16:42, Chunming Zhou wrote:
No, I just see your comment "The next vkQueueSubmit()
waiting on a the syncobj will read the sideband payload and w
https://bugzilla.kernel.org/show_bug.cgi?id=203781
ReddestDream (reddestdr...@gmail.com) changed:
What|Removed |Added
CC||reddestdr...@gmail
On 29.07.2019 04:49, Chanwoo Choi wrote:
> On 19. 7. 23. 오후 9:20, Artur Świgoń wrote:
>> This patch adds interconnect functionality to the exynos-bus devfreq
>> driver.
>>
>> The devfreq target() callback provided by exynos-bus now selects either the
>> frequency calculated by the devfreq governor
On 08/08/2019 17:48, Chunming Zhou wrote:
在 2019/8/8 22:34, Lionel Landwerlin 写道:
On 08/08/2019 17:16, Chunming Zhou wrote:
在 2019/8/8 22:01, Lionel Landwerlin 写道:
On 08/08/2019 16:42, Chunming Zhou wrote:
No, I just see your comment "The next vkQueueSubmit()
waiting on a the syncobj will rea
Maybe we can check if iommu is enabled in the driver and do the appropriate
thing with respect to gfxoff, assuming this is not platform specific.
Alex
From: Huang, Ray
Sent: Thursday, August 8, 2019 4:14 AM
To: Michel Dänzer ; Kai-Heng Feng
; Olsak, Marek
Cc: Z
Now that we have an official way to request custom encoder/bridge
enable/disable sequences we can get rid of the extra ->out_bridge field
and use the encoder one.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 17 +
1 file changed, 5 insertions(+), 1
The VC4 and Exynos DSI encoder drivers need a custom enable/disable
sequence and manually set encoder->bridge to NULL to prevent the core
from calling the bridge hooks.
Let's provide a more official way to support custom bridge/encoder
enable/disable sequences.
Signed-off-by: Boris Brezillon
---
This is part of our attempt to make the bridge chain a double-linked
list based on the generic list helpers. In order to do that, we must
patch all drivers manipulating the encoder->bridge field directly.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/msm/edp/edp.c | 4 +++-
drivers/gpu/dr
Add a new entry for the Toshiba LTA089AC29000 panel.
Signed-off-by: Boris Brezillon
---
.../display/panel/toshiba,lt089ac29000.txt| 5 ++-
drivers/gpu/drm/panel/panel-simple.c | 36 +++
2 files changed, 40 insertions(+), 1 deletion(-)
diff --git
a/Documentation/de
DRM bridges should not be operated independently. Let's rename the
drm_bridge_xxx() helpers that take the first bridge of the chain and
iterate over the whole chain into drm_bridge_chain_xx(). We also pass
it the encoder containing the bridge chain instead of the dereferencing
encoder->bridge.
Sig
Instead of a drm_atomic_state. The only driver implementing those hooks
is patched too.
Signed-off-by: Boris Brezillon
---
.../drm/bridge/analogix/analogix_dp_core.c| 12 ++--
drivers/gpu/drm/drm_bridge.c | 57 +++
include/drm/drm_bridge.h
bridge->next is only points to the new bridge if drm_bridge_attach()
succeeds. No need to reset it manually here.
Note that this change is part of the attempt to make the bridge chain
a double-linked list. In order to do that we must patch all drivers
manipulating the bridge->next field.
Signed-o
The current definition does not represent the exact display pipeline we
have on the board: the LVDS panel is actually connected through a
parallel -> LVDS bridge. Let's fix that so the driver can select the
proper bus format on the CRTC end.
Signed-off-by: Boris Brezillon
---
arch/arm/boot/dts/i
Now that we have an official way to request custom encoder/bridge
enable/disable sequences we can get rid of the extra ->bridge field
and use the encoder one.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/vc4/vc4_dsi.c | 35 ++-
1 file changed, 18 insertions(
And use them in drivers accessing the encoder->bridge or bridge->next
fields directly. This is part of our attempt to make the bridge chain
a double-linked list based on the generic list helpers.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/drm_bridge.c | 52 +
The SN75LVDS83 bridge support several input formats except the input
format is directly related to the expected output format. Let's express
that constraint by setting the bridge_state->output_bus_cfg.fmt field
to the appropriate value.
The previous element in the chain might be able to use this i
Hello,
This patch series aims at adding support for runtime bus-format
negotiation between all elements of the
'encoder -> bridges -> connector/display' section of the pipeline.
In order to support that, we need drm bridges to fully take part in the
atomic state validation process, which requires
We are about to add a drm_bridge_state that inherits from
drm_private_state which is defined in drm_atomic.h. Problem is,
drm_atomic.h includes drm_crtc.h which in turn includes drm_bridge.h,
leading to "drm_private_state has incomplete type" error.
Let's force all users of the drm_bridge API to e
Will be useful for bridge drivers that want to do bus format
negotiation with their neighbours.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/drm_bridge.c | 19 +++
include/drm/drm_bridge.h | 2 ++
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_brid
One of the last remaining object to not have its atomic state.
This is being motivated by our attempt to support runtime bus-format
negotiation between elements of the bridge chain.
This patch just paves the road for such a feature by adding a new
drm_bridge_state object inheriting from drm_privat
This takes the form of various helpers, plus the addition of 2 new
structs:
* drm_bus_caps: describe the bus capabilities of a bridge/encoder. For
bridges we have one for the input port and one for the output port.
Encoders just have one output port.
* drm_bus_cfg: added to the drm_bridge_state
Some LVDS drivers might want to negotiate the bus format with the
previous element in the encoder chain. Let's define a chip-specific ops
structure that contains an ->atomic_check() hook and plug that to the
drm_bridge->atomic_check() infra.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/bri
So each element in the chain can easily access its predecessor. This
will be needed for the work we are doing on bus format negociation
between elements of the bridge chain.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/drm_bridge.c | 278 +-
drivers/gpu/drm
So that bridge drivers have a way to check/reject an atomic operation.
The drm_atomic_bridge_chain_check() (which is just a wrapper around
the ->atomic_check() hook) is called in place of
drm_bridge_chain_mode_fixup() (when ->atomic_check() is not implemented,
the core falls back to ->mode_fixup(),
Now that bridges can expose the bus format/flags they expect, we can
use those instead of the relying on the display_info provided by the
connector (which is only valid if the encoder is directly connected
to bridge element driving the panel/display).
We also explicitly expose the bus formats supp
Hi Sam,
On Mon, Jul 08, 2019 at 09:10:08PM +0200, Sam Ravnborg wrote:
> Hi Laurent.
>
> Thanks for keeping me busy :-)
My pleasure ;-)
> On Sun, Jul 07, 2019 at 09:18:57PM +0300, Laurent Pinchart wrote:
> > This panel is used on the Zoom2/3/3630 SDP boards.
>
> This information may be good to
Thank you, I got your mean.
when you have sideband payload, you will go into timeline path. Clever!
-David
原始邮件
主题：Re: [PATCH v3 1/1] drm/syncobj: add sideband payload
发件人：Lionel Landwerlin
收件人："Zhou, David(ChunMing)" ,dri-de...@freedesktop.org
抄送："Koenig, Christian" ,Jason Ekst
Yeah, the idea is indeed rather clever. I'm just wondering if we don't need to
optimize it even more.
In other words could some IOCTL overhead be saved here if we directly take the
value for binary semaphores waits and signals?
Christian.
Am 08.08.19 um 17:23 schrieb Zhou, David(ChunMing):
Tha
https://bugs.freedesktop.org/show_bug.cgi?id=111332
Bug ID: 111332
Summary: Long running application causes assert in amdgpu_bo.c
'bo->cpu_map_count > 0' failed
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
Hi,
On Wed, Aug 07, 2019 at 02:30:25PM +0200, Daniel Vetter wrote:
> On Wed, Aug 7, 2019 at 2:02 PM Maxime Ripard
> wrote:
> > On Tue, Aug 06, 2019 at 06:11:32PM +0200, Daniel Vetter wrote:
> > > On Tue, Aug 06, 2019 at 06:01:46PM +0200, Maxime Ripard wrote:
> > > > On Tue, Aug 06, 2019 at 10:33
Hi Sam,
On Mon, Jul 08, 2019 at 09:44:52PM +0200, Sam Ravnborg wrote:
> Hi Laurent.
>
> Third panel driver in line for review.
> Review comments that are duplicates from the first two will have only a
> brief remark - if any.
I'll address them the same way. Please consider all unanswered comment
We must make sure our scatterlist segments are not too big, otherwise
we might see swiotlb failures (happens with sev, also reproducable with
swiotlb=force).
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_object.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
https://bugs.freedesktop.org/show_bug.cgi?id=111333
Bug ID: 111333
Summary: [drm:radeon_atom_pick_dig_encoder [radeon]] *ERROR*
chosen encoder in use 0
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #11 from Martin ---
Kernel 5.3.0-rc3 does not boot on my system
It hangs at detecting the discs.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mai
On Thu, Aug 08, 2019 at 08:39:11AM -0600, Rob Herring wrote:
> On Thu, Aug 8, 2019 at 7:44 AM Gerd Hoffmann wrote:
> >
> >
> >
> > Gerd Hoffmann (17):
> > drm/ttm: turn ttm_bo_device.vma_manager into a pointer
> > drm/ttm: add gem_ttm_bo_device_init()
> > drm/vram: switch vram helpers to the
Hi Sam,
On Wed, Jul 10, 2019 at 09:48:55AM +0200, Sam Ravnborg wrote:
> Hi Laurent.
>
> This driver looks very good.
>
> On Sun, Jul 07, 2019 at 09:19:00PM +0300, Laurent Pinchart wrote:
> > This panel is used on the OpenMoko Neo FreeRunner and Neo 1973.
>
> Add info in Kconfig help entry?
>
>
On Thu, 8 Aug 2019, Al Viro wrote:
> On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
> > On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> > > Though personally I'm averse to managing "f"objects through
> > > "m"interfaces, which can get ridiculous (notably, MADV_HU
Hi Sam,
On Wed, Jul 10, 2019 at 03:09:17PM +0200, Sam Ravnborg wrote:
> Hi Laurent.
>
> I had assumed this driver would look like the other Topology driver, but
> they differ a lot. So it makes sense to have different drivers.
>
> This driver implements suspend/resume.
> But the correct way woul
On Tue, Jul 23, 2019 at 04:47:09PM +0100, Kieran Bingham wrote:
> Hi Wolfram,
>
> On 22/07/2019 18:26, Wolfram Sang wrote:
> > In the general move to have i2c_new_*_device functions which return
> > ERR_PTR instead of NULL, this patch converts i2c_new_secondary_device().
> >
> > There are only fe
On Thu, Aug 08, 2019 at 05:57:09PM +0200, Wolfram Sang wrote:
> On Tue, Jul 23, 2019 at 04:47:09PM +0100, Kieran Bingham wrote:
> > On 22/07/2019 18:26, Wolfram Sang wrote:
> > > In the general move to have i2c_new_*_device functions which return
> > > ERR_PTR instead of NULL, this patch converts i
Hi Sam,
On Tue, Jul 16, 2019 at 01:08:27PM +0200, Sam Ravnborg wrote:
> Hi Laurent et all.
>
> > +static int panel_bridge_get_modes(struct drm_bridge *bridge,
> > + struct drm_connector *connector)
> > +{
> > + struct panel_bridge *panel_bridge = drm_bridge_to_panel_
I've got a couple questions that I think go along the lines of what
Christian wrote:
1. Should it really be called sideband? It's a very generic term for what
is currently a very generic thing. However, maybe we don't want it to be
so generic?
2. Do we really want get/set? Or do we want get/in
Quoting Hugh Dickins (2019-08-08 16:54:16)
> On Thu, 8 Aug 2019, Al Viro wrote:
> > On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
> > > On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
> > > > Though personally I'm averse to managing "f"objects through
> > > > "m"i
>
> On 8/7/19 7:36 PM, Ira Weiny wrote:
> > On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> >> On Wed 07-08-19 10:37:26, Jan Kara wrote:
> >>> On Fri 02-08-19 12:14:09, John Hubbard wrote:
> On 8/2/19 7:52 AM, Jan Kara wrote:
> > On Fri 02-08-19 07:24:43, Matthew Wilcox wr
On Thu, Aug 8, 2019 at 3:00 AM Christoph Hellwig wrote:
>
> On Wed, Aug 07, 2019 at 09:09:53AM -0700, Rob Clark wrote:
> > > > (Eventually I'd like to support pages passed in from userspace.. but
> > > > that is down the road.)
> > >
> > > Eww. Please talk to the iommu list before starting on tha
https://bugs.freedesktop.org/show_bug.cgi?id=111333
--- Comment #1 from Alex Deucher ---
Are you actually seeing any problems or is it just the message you are
concerned about?
--
You are receiving this mail because:
You are the assignee for the bug._
Hi Sam,
On Tue, Jul 16, 2019 at 11:28:57AM +0200, Sam Ravnborg wrote:
> On Sun, Jul 07, 2019 at 09:18:47PM +0300, Laurent Pinchart wrote:
> > Display connectors are modelled in DT as a device node, but have so far
> > been handled manually in several bridge drivers. This resulted in
> > duplicate
On Thu, Aug 8, 2019 at 12:59 AM Christoph Hellwig wrote:
>
> On Wed, Aug 07, 2019 at 10:30:04AM -0700, Rob Clark wrote:
> > So, we do end up using GFP_HIGHUSER, which appears to get passed thru
> > when shmem gets to the point of actually allocating pages.. not sure
> > if that just ends up being
Hi Laurent.
As I said in another mail, you have managed to keep me busy...
> > I took a look at this - it seems simple:
> > - Update drm_panel.get_modes() to take drm_connector as argument, and fix
> > all callers. All callers already have connector available.
> > - Drop drm_panel_attach(), drm
https://bugs.freedesktop.org/show_bug.cgi?id=111305
--- Comment #1 from Alex Deucher ---
The contents of vram have to be moved to system memory on suspend since vram is
powered off. Depending on general memory pressure at suspend time it may take
a while to get the contexts of vram into system r
On 08/08/2019 17:23, Chris Wilson wrote:
Quoting Hugh Dickins (2019-08-08 16:54:16)
On Thu, 8 Aug 2019, Al Viro wrote:
On Wed, Aug 07, 2019 at 08:30:02AM +0200, Christoph Hellwig wrote:
On Tue, Aug 06, 2019 at 12:50:10AM -0700, Hugh Dickins wrote:
Though personally I'm averse to managing "f"o
On 08.08.2019 16:25, Laurent Pinchart wrote:
> Hi Andrzej,
>
> On Wed, Jul 17, 2019 at 08:39:47AM +0200, Andrzej Hajda wrote:
>> On 07.07.2019 20:18, Laurent Pinchart wrote:
>>> Most bridge drivers create a DRM connector to model the connector at the
>>> output of the bridge. This model is historic
Hi,
for some unfathomable to me reason, the commit in $Subject breaks
booting of the 32-bit partition of one of my test boxes. The box doesn't
finish booting (normally it boots in text mode, there is no X server
setup on it) but it is still responsible in the sense that I can reboot
it with the Sy
I -thought- I had fixed this entirely, but it looks like that I didn't
test this thoroughly enough as we apparently still make one big mistake
with nv50_msto_atomic_check() - we don't handle the following scenario:
* CRTC #1 has n VCPI allocated to it, is attached to connector DP-4
which is atta
Hi Boris.
Good to see that you kept the alphabetical order in the include files.
One nit below.
With this fixed:
Reviewed-by: Sam Ravnborg
Sam
> diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.h b/drivers/gpu/drm/msm/hdmi/hdmi.h
> index 982865866a29..c681a9e22484 100644
> --- a/drivers/gpu/d
Hello Daniel and Andrzej,
On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote:
> On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> > Hi Laurent,
> >
> > I like the approach, current practice when almost every bridge should
> > optionally implement connector, or alternativ
Hi Mauro,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-19.30
head: 494cd065e68f6ba299e074e269b57773d7524e67
commit: 247814e2121b6f9d3b5f2ed04a7221b991fb441a [1374/2148] gpu: amdgpu: fix
broken amdgpu_dma_buf.c references
reproduce: make htmldo
On Thu, Aug 08, 2019 at 09:19:48PM +0300, Laurent Pinchart wrote:
> On Thu, Jul 11, 2019 at 09:35:48AM +0200, Daniel Vetter wrote:
> > On Wed, Jul 10, 2019 at 02:12:14PM +0200, Andrzej Hajda wrote:
> >> Hi Laurent,
> >>
> >> I like the approach, current practice when almost every bridge should
> >
Hi Sam,
On Thu, Aug 08, 2019 at 06:52:53PM +0200, Sam Ravnborg wrote:
> Hi Laurent.
>
> As I said in another mail, you have managed to keep me busy...
>
> > > I took a look at this - it seems simple:
> > > - Update drm_panel.get_modes() to take drm_connector as argument, and fix
> > > all call
Hi Andrzej,
On Thu, Aug 08, 2019 at 07:36:49PM +0200, Andrzej Hajda wrote:
> On 08.08.2019 16:25, Laurent Pinchart wrote:
> > On Wed, Jul 17, 2019 at 08:39:47AM +0200, Andrzej Hajda wrote:
> >> On 07.07.2019 20:18, Laurent Pinchart wrote:
> >>> Most bridge drivers create a DRM connector to model t
101 - 200 of 265 matches
Mail list logo
