Hey Dave,
The main thing here is the addition of support for Volta GV100 GPUs,
everything else basically restructuring display / graphics init code
to make it possible to fit Volta support in more nicely.
There's a bunch of improvements/fixes scattered in there for earlier
GPUs too, particularly
Hi Linus,
Pretty quiet week again, one vmwgfx regression fix, one core buffer
overflow fix,one vc4 leak fix and three i915 fixes.
Dave.
The following changes since commit 76ef6b28ea4f81c3d511866a9b31392caa833126:
drm: set FMODE_UNSIGNED_OFFSET for drm files (2018-05-15 14:46:04 +1000)
are av
use "{}" instead of "{0}" in empty struct defination to avoid missing-braces
warning:
suggest braces around initialization of subobject [-Wmissing-braces]
Test: compilation on android with this warning free
Signed-off-by: Jenny Cao
---
amdgpu/amdgpu_cs.c | 4 ++--
libsync.h | 2 +-
2
https://bugs.freedesktop.org/show_bug.cgi?id=101976
Pablo Estigarribia changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=96897
--- Comment #14 from Dieter Nützel ---
(In reply to Jan Vesely from comment #13)
> Initial support for cl_khr_fp16 builtins has been added to libclc in r332677.
> It should be enough to run clpeak.
> clpeak still takes few mins to compile the ker
On Thu, May 17, 2018 at 6:41 PM, hl wrote:
> On Thursday, May 17, 2018 09:51 PM, Sean Paul wrote:
>> On Thu, May 17, 2018 at 05:18:00PM +0800, Lin Huang wrote:
>>> DP firmware uses fixed phy config values to do training, but some
>>> boards need to adjust these values to fit for their unique hardw
On Thu, 2018-05-10 at 19:33 -0400, Jan Vesely wrote:
> Close the file descriptors under lock as well.
>
> Signed-off-by: Jan Vesely
> ---
> amdgpu/amdgpu_device.c | 11 +++
> 1 file changed, 7 insertions(+), 4 deletions(-)
>
> diff --git a/amdgpu/amdgpu_device.c b/amdgpu/amdgpu_device.c
https://bugs.freedesktop.org/show_bug.cgi?id=96897
Jan Vesely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 96897, which changed state.
Bug 96897 Summary: clpeak OpenCL benchmark hangs during compilation on Clover
RadeonSI
https://bugs.freedesktop.org/show_bug.cgi?id=96897
What|Removed |Added
From: Gaurav K Singh
This defines all the DSC parameters as per the VESA DSC spec
that will be required for DSC encoder/decoder
v3:
Remove the duplicate define (Harry) (From Manasi)
v2: Define this struct in DRM (From Manasi)
* Changed the data types to u8/u16 instead of unsigned longs (Manasi)
DP 1.4 spec defines DP secondary data packet for DSC
picture parameter set. This patch defines its payload size
according to the DP 1.4 specification.
Signed-off-by: Manasi Navare
Cc: Jani Nikula
Cc: Ville Syrjala
Cc: Anusha Srivatsa
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Harry Wentl
This patch defines a new header file for all the DSC 1.2 structures
and creates a structure for PPS infoframe which will be used to send
picture parameter set secondary data packet for display stream compression.
All the PPS infoframe syntax elements are taken from DSC 1.2 specification
from VESA.
According to Display Stream compression spec 1.2, the picture
parameter set metadata is sent from source to sink device
using the DP Secondary data packet. An infoframe is formed
for the PPS SDP header and PPS SDP payload bytes.
This patch adds helpers to fill the PPS SDP header
and PPS SDP payload
Hey Rob,
On Fri, May 18, 2018 at 12:08 AM, Rob Herring wrote:
> In order to assign planes to layers in ValidateDisplay, testing
> compositing with a DRM atomic modeset test is needed as PresentDisplay
> is too late. This means most of PresentDisplay needs to be run from
> ValidateDisplay, so refa
In order to assign planes to layers in ValidateDisplay, testing
compositing with a DRM atomic modeset test is needed as PresentDisplay
is too late. This means most of PresentDisplay needs to be run from
ValidateDisplay, so refactor PresentDisplay and plumb a test flag down
the stack.
Signed-off-by
On Thu, May 17, 2018 at 11:18 PM, Thomas Hellstrom wrote:
>
> On 05/17/2018 09:20 PM, Daniel Vetter wrote:
>>
>> On Thu, May 17, 2018 at 8:23 PM, Thomas Hellstrom
>> wrote:
>>>
>>> Hi!
>>>
>>> I'm currently working on a remoting KMS backend, and now I thought it
>>> would
>>> be a good time to ge
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 100dd4c0f231fce76fa8115ad28d507e311d32bf
commit: 2a6630b1095609b26a205b7c537594f3cde99c0a [114/431] ASoC: AMD: enable
ACP3x drivers build
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gn
On 05/17/2018 09:20 PM, Daniel Vetter wrote:
On Thu, May 17, 2018 at 8:23 PM, Thomas Hellstrom wrote:
Hi!
I'm currently working on a remoting KMS backend, and now I thought it would
be a good time to get some feedback on a very rough design:
The idea is that we want to be get enough informat
On Thu, Apr 19, 2018 at 04:52:03PM -0700, Jeykumar Sankaran wrote:
> Switch DPU from dsi-staging to upstream dsi driver. To make
> the switch atomic, this change includes:
> - remove dpu connector layers
> - clean up dpu connector dependencies in encoder/crtc
> - compile out writeback and display p
Hi Dave,
On Thursday, 17 May 2018 08:05:03 EEST Dave Airlie wrote:
> On 17 May 2018 at 14:42, Dave Airlie wrote:
> > On 16 May 2018 at 01:37, Laurent Pinchart wrote:
> >> On Tuesday, 15 May 2018 17:24:52 EEST kbuild test robot wrote:
> >>> tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: d19e8ade9c3b04edf71a7ec439ba53ea2b8c76a3
commit: 2a6630b1095609b26a205b7c537594f3cde99c0a [114/432] ASoC: AMD: enable
ACP3x drivers build
config: sh-allyesconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (De
Hi Neil,
I love your patch! Yet something to improve:
[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.17-rc5 next-20180517]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
tree: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next
head: b9136bd01841a63b7706db69e1da8843c8622a9f
commit: c8d8568a8dbb4dc455ceaca7b95108d85b3d4798 [27/35] gpu: host1x: Use not
explicitly sized types
config: arm64-defconfig (attached as .config)
compiler: aarch64-linux-gnu-g
On Thu, May 17, 2018 at 8:23 PM, Thomas Hellstrom wrote:
> Hi!
>
> I'm currently working on a remoting KMS backend, and now I thought it would
> be a good time to get some feedback on a very rough design:
>
> The idea is that we want to be get enough information on the backend side of
> KMS to be
On 05/17/2018 10:48 AM, Michel Dänzer wrote:
On 2018-05-17 01:18 PM, Andrey Grodzovsky wrote:
Hi Michele and others, I am trying to implement the approach bellow to
resolve AMDGPU's hang when commands are stuck in pipe during process exit.
I noticed that once I implemented the file_operation.
On Wed, May 16, 2018 at 9:24 AM, Nayan Deshmukh
wrote:
> That got missed while moving the files outside of amdgpu.
>
> Signed-off-by: Nayan Deshmukh
> Reviewed-by: Christian König
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/scheduler/sched_fence.c | 6 +++---
> 1 file changed, 3 insertion
Hi!
I'm currently working on a remoting KMS backend, and now I thought it
would be a good time to get some feedback on a very rough design:
The idea is that we want to be get enough information on the backend
side of KMS to be able to remote the display system over VNC or
something similar.
https://bugs.freedesktop.org/show_bug.cgi?id=104439
Jani Nikula changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
From: Brian Starkey
Writeback connectors represent writeback engines which can write the
CRTC output to a memory framebuffer. Add a writeback connector type and
related support functions.
Drivers should initialize a writeback connector with
drm_writeback_connector_init() which takes care of sett
From: Brian Starkey
Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to
enable userspace to get a fence which will signal once the writeback is
complete. It is not allowed to request an out-fence without a
framebuffer attached to the connector.
A timeline is added to drm_writeba
Due to the fact that writeback connectors behave in a special way
in DRM (they always report being disconnected) we might confuse some
userspace. Add a client capability for writeback connectors that will
filter them out for clients that don't understand the capability.
Re-requested-by: Sean Paul
Hi,
This is v7 of the writeback connector series. This is just a refresh
of the v6 series in order to get it ready for merging into the kernel,
now that the userspace implementation has been reviewed and ACKed
by Sean Paul here [1].
For anyone that wants a refresh on what changed in v6, the serie
https://bugzilla.kernel.org/show_bug.cgi?id=199693
Len Brown (l...@kernel.org) changed:
What|Removed |Added
CC||l...@kernel.org
A
On Tue, May 15, 2018 at 04:59:26PM +0300, StanLis wrote:
> From: Stanislav Lisovskiy
>
> Added content type setting property to drm_connector(part 1)
> and enabled transmitting it with HDMI AVI infoframes
> for i915(part 2).
>
> Stanislav Lisovskiy (2):
> drm: content-type property for HDMI co
On 2018-05-17 05:33 PM, Andrey Grodzovsky wrote:
>
> BTW, just out of interest, how the FDs are passed to clients ? Using
> sockets ?
Yes, via the socket used for the X11 display connection.
> Can you point me to the code which does it ?
xserver/dri3/dri3_request.c:dri3_send_open_reply() =>
xs
From: Thierry Reding
Document the userspace ABI with kerneldoc to provide some information on
how to use it.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/gem.c | 4 +-
include/uapi/drm/tegra_drm.h | 480 ++-
2 files changed, 468 insertions(+), 16 d
From: Thierry Reding
Set the interface version implemented by the gr3d module. This allows
userspace to pass the correct command stream when programming the gr3d
module.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/gr3d.c | 28 +---
1 file changed, 25 inserti
From: Thierry Reding
Set the interface version implemented by the VIC module. This allows
userspace to pass the correct command stream when programming the VIC
module.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/vic.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers
From: Thierry Reding
Set the owner and name of the exported DMA-BUF in addition to the
already filled-in fields.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 8
From: Thierry Reding
Set the interface version implemented by the gr2d module. This allows
userspace to pass the correct command stream when programming the gr2d
module.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/gr2d.c | 22 --
1 file changed, 20 insertions(+)
From: Thierry Reding
These patches are further preparation work to destage the job submission
ABI. Patch 1 fixes a typo in the argument to the close channel IOCTL and
isn't technically preparation work. Neither are patches 2 and 3 which do
some cleanup and add support for the rotation property. H
On 17 May 2018 at 16:26, Russell King - ARM Linux wrote:
> On Thu, May 17, 2018 at 02:15:40PM +0100, Daniel Stone wrote:
>> On 30 March 2018 at 15:11, Daniel Stone wrote:
>> > Since drm_framebuffer can now store GEM objects directly, place them
>> > there rather than in our own subclass. As this
From: Thierry Reding
Currently only the DRM_MODE_REFLECT_Y rotation is supported. The driver
already supports reflection on the Y axis via a custom flag which is not
very useful because it requires custom userspace. Replace that flag by a
standard rotation property that supports 0 degree rotation
From: Thierry Reding
A separate data structure exists for the DRM_TEGRA_CLOSE_CHANNEL IOCTL,
but it is currently unused. The IOCTL was using the data structure for
the DRM_TEGRA_OPEN_CHANNEL IOCTL.
Signed-off-by: Thierry Reding
---
include/uapi/drm/tegra_drm.h | 2 +-
1 file changed, 1 inserti
Hi,
Applied on drm-misc-next.
Note: patch subject has been renamed "drm/bridge: spelling and coding
style minor fixes" to comply with checkpatch (my bad ;-), hope it is
better, Many thanks,
Philippe :-)
On 05/16/2018 11:43 AM, Daniel Vetter wrote:
> On Tue, May 15, 2018 at 10:37:36PM +0200, Phil
From: Thierry Reding
All other array variables use a plural, and this is the only one using
the *array suffix. This is confusing, so rename it for consistency.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c | 4 ++--
drivers/gpu/host1x/job.c| 8
include/linux/host1x
From: Thierry Reding
Rather than storing some identifier derived from the application
context that can't be used concretely anywhere, store a pointer to the
client directly so that accesses can be made directly through that
client object.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra
From: Thierry Reding
Userspace needs to know the version of the interface implemented by a
client so it can create the proper command streams. Allow individual
drivers to store this version along with the client so that it can be
returned to userspace upon opening a channel.
Signed-off-by: Thier
From: Thierry Reding
The number of words and the offset in a gather don't need to be
explicitly sized, so make them unsigned int instead.
Signed-off-by: Thierry Reding
---
drivers/gpu/host1x/job.c | 13 -
drivers/gpu/host1x/job.h | 4 ++--
include/linux/host1x.h | 4 ++--
3 fil
From: Thierry Reding
The job submission userspace ABI doesn't support this and there are no
plans to implement it, so all of this code is dead and can be removed.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/drm.c| 62 +--
drivers/gpu/host1x/dev.h |
From: Thierry Reding
Functions taking a pointer to a host1x syncpoint as an argument don't
need to specify a pointer to a host1x instance because it can be
obtained from the syncpoint.
Signed-off-by: Thierry Reding
---
drivers/gpu/host1x/hw/channel_hw.c | 2 +-
drivers/gpu/host1x/intr.c
From: Thierry Reding
These couple of patches clean up some things in the host1x driver and
prepares the way for adding a revamped job submission ABI in a future
patch series.
The ultimate goal is to destage the job submission ABI, so that it is
enabled in default builds of the kernel (currently
From: Thierry Reding
Use unsigned int where possible and don't unnecessarily initialize the
loop variable.
Signed-off-by: Thierry Reding
---
drivers/gpu/host1x/debug.c | 2 +-
drivers/gpu/host1x/intr.c | 2 +-
drivers/gpu/host1x/job.c| 4 ++--
drivers/gpu/host1x/syncpt.c | 2 +-
4 files
Thanks Michel, will give it a try.
BTW, just out of interest, how the FDs are passed to clients ? Using
sockets ? Can you point me to the code which does it ?
Andrey
On 05/17/2018 10:48 AM, Michel Dänzer wrote:
On 2018-05-17 01:18 PM, Andrey Grodzovsky wrote:
Hi Michele and others, I am tr
Hi Stephen,
Changes are Signed-off-by: Anthony Koo
Thanks,
Anthony
-Original Message-
From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
Sent: Tuesday, May 15, 2018 7:19 PM
To: Dave Airlie ; DRI
Cc: Linux-Next Mailing List ; Linux Kernel Mailing
List ; Koo, Anthony ;
Wentland, Ha
On Fri, Mar 30, 2018 at 03:11:38PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse th
On Fri, Mar 30, 2018 at 03:11:37PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse th
On Fri, Mar 30, 2018 at 03:11:36PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse th
On Fri, Mar 30, 2018 at 03:11:35PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle function the same as the GEM framebuffer helper, we
> can reuse that.
>
> Sign
On Fri, Mar 30, 2018 at 03:11:34PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse th
On Fri, Mar 30, 2018 at 03:11:33PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse th
On Fri, Mar 30, 2018 at 03:11:24PM +0100, Daniel Stone wrote:
> Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can
> just delete it.
>
> Signed-off-by: Daniel Stone
> Cc: CK Hu
> Cc: Philipp Zabel
> ---
> drivers/gpu/drm/mediatek/mtk_drm_fb.c | 40
> ---
On Fri, Mar 30, 2018 at 03:11:23PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse th
On Thu, May 17, 2018 at 09:22:23AM -0400, Sinan Kaya wrote:
> A host bridge is allowed to remap BAR addresses using _TRA attribute in
> _CRS windows.
>
> pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window]
> (bus address [0x0010-0x1fff])
> pci :02:00.0: reg 0x1
On Thu, May 17, 2018 at 09:58:19AM -0400, Sean Paul wrote:
> On Fri, Mar 30, 2018 at 03:11:22PM +0100, Daniel Stone wrote:
> > A FB with no object is something we should be shouting very loudly
> > about, not quietly logging as debug.
> >
> > Signed-off-by: Daniel Stone
> > Cc: CK Hu
> > Cc: Phi
On Fri, Mar 30, 2018 at 03:11:21PM +0100, Daniel Stone wrote:
> drm_framebuffer already holds per-plane pitch and offsets, which is
> filled out for us when we create the framebuffer. Nuke our local copy in
> the plane struct.
>
> Signed-off-by: Daniel Stone
> Cc: Tomi Valkeinen
> ---
> drivers
On 2018-05-17 01:18 PM, Andrey Grodzovsky wrote:
> Hi Michele and others, I am trying to implement the approach bellow to
> resolve AMDGPU's hang when commands are stuck in pipe during process exit.
>
> I noticed that once I implemented the file_operation.flush callback
> then during run of X, i
On Fri, Mar 30, 2018 at 03:11:20PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse th
On Fri, Mar 30, 2018 at 03:11:18PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse th
On Fri, Mar 30, 2018 at 03:11:19PM +0100, Daniel Stone wrote:
> Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
> can remove it.
>
> Signed-off-by: Daniel Stone
> Cc: Sandy Huang
> Cc: Heiko Stübner
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 54
> ++---
https://bugs.freedesktop.org/show_bug.cgi?id=106548
Joonas Lahtinen changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #4 from Joonas L
From: Dave Stevenson
This is the format generated by VC4's H.264 engine, and preferred by
the ISP as well. By displaying SAND buffers directly, we can avoid
needing to use the ISP to rewrite the SAND H.264 output to linear
before display.
Signed-off-by: Dave Stevenson
Signed-off-by: Eric Anhol
Maxime Ripard writes:
> The vc4 HVS uses an internal RGB888 representation of the frames, and will
> by default expand formats using a lower depth using zeros.
>
> This causes an issue when we try to use other compositing software such as
> pixman that fill the missing bits by repeating the highe
On Fri, Mar 30, 2018 at 03:11:17PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse th
On Fri, Mar 30, 2018 at 03:11:16PM +0100, Daniel Stone wrote:
> Now cirrus_framebuffer is just an empty wrapper around drm_framebuffer,
> we can drop it.
>
> Signed-off-by: Daniel Stone
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux-foundation.org
> ---
> drivers/gpu/dr
Hi Heiko,
On 17 May 2018 at 14:42, Heiko Stübner wrote:
> Am Donnerstag, 17. Mai 2018, 15:08:15 CEST schrieb Daniel Stone:
>> On 30 March 2018 at 15:11, Daniel Stone wrote:
>> > Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
>> > can remove it.
>> >
>> > Signed-off-by: Dan
On Fri, Mar 30, 2018 at 03:11:24PM +0100, Daniel Stone wrote:
> Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can
> just delete it.
>
> Signed-off-by: Daniel Stone
> Cc: CK Hu
> Cc: Philipp Zabel
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/mediatek/mtk_drm_fb.c | 40
On Fri, Mar 30, 2018 at 03:11:23PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse th
On Fri, Mar 30, 2018 at 03:11:22PM +0100, Daniel Stone wrote:
> A FB with no object is something we should be shouting very loudly
> about, not quietly logging as debug.
>
> Signed-off-by: Daniel Stone
> Cc: CK Hu
> Cc: Philipp Zabel
> ---
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 5 +
>
On Fri, Mar 30, 2018 at 03:11:18PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse th
On Fri, Mar 30, 2018 at 03:11:19PM +0100, Daniel Stone wrote:
> Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
> can remove it.
>
> Signed-off-by: Daniel Stone
Reviewed-by: Sean Paul
> Cc: Sandy Huang
> Cc: Heiko Stübner
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_f
On Fri, Mar 30, 2018 at 03:11:15PM +0100, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse th
On Thu, May 17, 2018 at 05:18:00PM +0800, Lin Huang wrote:
> DP firmware uses fixed phy config values to do training, but some
> boards need to adjust these values to fit for their unique hardware
> design. So get phy config values from dts and use software link training
> instead of relying on fir
On Thu, May 17, 2018 at 02:11:16PM +0100, Daniel Stone wrote:
> Hi Thierry,
>
> On 30 March 2018 at 15:11, Daniel Stone wrote:
> > Since tegra_fb is now the same as drm_framebuffer, we can just replace
> > the type completely.
> >
> > Signed-off-by: Daniel Stone
> > Cc: Thierry Reding
> > Cc: l
Hello Rex Zhu,
The patch d389d607e608: "drm/amd/pp: Change voltage/clk range for OD
feature on VI" from Apr 18, 2018, leads to the following static
checker warning:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:872
smu7_setup_voltage_range_from_vbios()
error: uniniti
Hi Daniel,
Am Donnerstag, 17. Mai 2018, 15:08:15 CEST schrieb Daniel Stone:
> On 30 March 2018 at 15:11, Daniel Stone wrote:
> > Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
> > can remove it.
> >
> > Signed-off-by: Daniel Stone
> > Cc: Sandy Huang
> > Cc: Heiko Stübne
On Monday 14 May 2018 03:15 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromiu
The vc4 HVS uses an internal RGB888 representation of the frames, and will
by default expand formats using a lower depth using zeros.
This causes an issue when we try to use other compositing software such as
pixman that fill the missing bits by repeating the higher significant bits.
As such, we c
Hello Andrzej Pietrasiewicz,
The patch 01fb9185dc18: "drm/exynos: Add driver for Exynos Scaler
module" from May 9, 2018, leads to the following static checker
warning:
drivers/gpu/drm/exynos/exynos_drm_scaler.c:402 scaler_task_done()
warn: signedness bug returning '(-22)'
drivers
On Monday 14 May 2018 03:00 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromiu
On Thursday 17 May 2018 06:31 PM, Ramalingam C wrote:
On Monday 14 May 2018 02:53 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedes
This has been useful for debugging the window movement lag in X11, and
I have patches to sysprof that watch these to produce nice
visualizations.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_gem.c | 4 +++
drivers/gpu/drm/vc4/vc4_irq.c | 4 +++
drivers/gpu/drm/vc4/vc4_trace.h | 5
Hi Ville,
On 23 March 2018 at 14:49, Daniel Stone wrote:
> On 23 March 2018 at 14:42, Ville Syrjälä
> wrote:
>> Hmm. I'm thinking we can stick to the single reference per fb.
>> IIRC this counter is there just to prevent changes of the obj
>> tiling mode as long as any fb exists that uses the o
Hi Russell,
On 30 March 2018 at 15:11, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse tho
Hi CK, Philipp,
On 30 March 2018 at 15:11, Daniel Stone wrote:
> Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can
> just delete it.
Did you get a chance to look at these three patches for Mediatek?
Cheers,
Daniel
___
dri-devel ma
On 30 March 2018 at 21:53, Sebastian Reichel
wrote:
> On Fri, Mar 30, 2018 at 03:11:21PM +0100, Daniel Stone wrote:
>> drm_framebuffer already holds per-plane pitch and offsets, which is
>> filled out for us when we create the framebuffer. Nuke our local copy in
>> the plane struct.
>>
>> Signed-o
Hi Rob,
On 30 March 2018 at 15:11, Daniel Stone wrote:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle function the same as the GEM framebuffer helper, we
> can reuse that.
I didn't get
Hi Thierry,
On 30 March 2018 at 15:11, Daniel Stone wrote:
> Since tegra_fb is now the same as drm_framebuffer, we can just replace
> the type completely.
>
> Signed-off-by: Daniel Stone
> Cc: Thierry Reding
> Cc: linux-te...@vger.kernel.org
Did this still need some more testing, or is it OK t
On Monday 14 May 2018 02:53 PM, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ramalingam C
Sent: Tuesday, April 3, 2018 7:28 PM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromiu
On 30 March 2018 at 15:11, Daniel Stone wrote:
> Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we
> can remove it.
>
> Signed-off-by: Daniel Stone
> Cc: Sandy Huang
> Cc: Heiko Stübner
Ping?
Cheers,
Daniel
___
dri-devel mailing
1 - 100 of 184 matches
Mail list logo
