https://bugs.freedesktop.org/show_bug.cgi?id=110257
67b02...@casix.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110257
--- Comment #2 from Andrew Randrianasulu ---
wasn't this fixed by
https://cgit.freedesktop.org/mesa/mesa/commit/?id=d507bcdcf26b417dea201090165af651253b6b11
--
st/va: reverse qt matrix back to its original order
The quantiser matrix
https://bugzilla.kernel.org/show_bug.cgi?id=203627
Aleksandr Mezin (mezin.alexan...@gmail.com) changed:
What|Removed |Added
Regression|No |Yes
--
https://bugzilla.kernel.org/show_bug.cgi?id=203627
Bug ID: 203627
Summary: [Regression] Boot fails with linux-firmware 20190514
Product: Drivers
Version: 2.5
Kernel Version: 4.19.44
Hardware: All
OS: Linux
On Tue, Apr 23, 2019 at 7:26 AM Thierry Reding wrote:
>
> On Tue, Apr 16, 2019 at 12:06:43PM +0200, Marco Felsch wrote:
> > Evervision Electronics is a panel manufacturer from Taipei.
> > http://www.evervisionlcd.com/index.php?lang=en
> >
> > Signed-off-by: Marco Felsch
> > Reviewed-by: Rob
Quoting Brendan Higgins (2019-05-14 15:16:55)
> diff --git a/kunit/test.c b/kunit/test.c
> index 86f65ba2bcf92..a15e6f8c41582 100644
> --- a/kunit/test.c
> +++ b/kunit/test.c
[..]
> +
> +void *kunit_kmalloc(struct kunit *test, size_t size, gfp_t gfp)
> +{
> + struct kunit_kmalloc_params
Quoting Brendan Higgins (2019-05-14 15:16:54)
> diff --git a/include/kunit/test.h b/include/kunit/test.h
> new file mode 100644
> index 0..e682ea0e1f9a5
> --- /dev/null
> +++ b/include/kunit/test.h
> @@ -0,0 +1,162 @@
[..]
> +/**
> + * struct kunit - represents a running instance of a
Hi,
On Thu, May 16, 2019 at 2:40 PM Douglas Anderson wrote:
>
> On Rockchip rk3288-based Chromebooks when you do a suspend/resume
> cycle:
>
> 1. You lose the ability to detect an HDMI device being plugged in.
>
> 2. If you're using the i2c bus built in to dw_hdmi then it stops
> working.
>
>
On Tue, May 14, 2019 at 3:40 AM Xiaqing (A) wrote:
>
>
>
> On 2019/5/14 2:37, John Stultz wrote:
> > This adds a CMA heap, which allows userspace to allocate
> > a dma-buf of contiguous memory out of a CMA region.
> >
> > This code is an evolution of the Android ION implementation, so
> > thanks
On Rockchip rk3288-based Chromebooks when you do a suspend/resume
cycle:
1. You lose the ability to detect an HDMI device being plugged in.
2. If you're using the i2c bus built in to dw_hdmi then it stops
working.
Let's call the core dw-hdmi's suspend/resume functions to restore
things.
NOTE:
So a couple of things:
On Thu, 2019-05-16 at 11:17 -0400, sunpeng...@amd.com wrote:
> From: Ville Syrjälä
>
> All available downstream ports - physical and logical - are exposed for
> each MST device. They are listed in /dev/, following the same naming
> scheme as SST devices by appending an
On Rockchip rk3288-based Chromebooks when you do a suspend/resume
cycle:
1. You lose the ability to detect an HDMI device being plugged in.
2. If you're using the i2c bus built in to dw_hdmi then it stops
working.
Let's add a hook to the core dw-hdmi driver so that we can call it in
Reviewed-by: Lyude Paul
On Thu, 2019-05-16 at 11:18 -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> Set the connector's kernel device as the parent for the aux kernel
> device. This allows udev rules to access connector attributes when
> creating symlinks to aux devices.
>
> Cc: Ben
aghsorry, but I need to take back my Reviewed-by. Noticed an issue when
reloading drm and i915. I'll explain it when I respond to patch 2/7 in a
moment
On Thu, 2019-05-16 at 11:17 -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> Placing the MST aux device as a child of the connector
On Thu, 2019-05-16 at 11:17 -0400, sunpeng...@amd.com wrote:
> From: Leo Li
>
> Placing the MST aux device as a child of the connector gives udev the
> ability to access the connector device's attributes. This will come in
> handy when writing udev rules to create more descriptive symlinks to
On Thu, May 16, 2019 at 03:14:46PM +0100, Steven Price wrote:
> Provide a wrapper for drm_gem_map_offset() for clients of shmem. This
> wrapper provides the correct semantics for the drm_gem_shmem_mmap()
> callback.
>
> Signed-off-by: Steven Price
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c
On Thu, May 16, 2019 at 03:14:45PM +0100, Steven Price wrote:
> drm_gem_dumb_map_offset() is a useful helper for non-dumb clients, so
> rename it to remove the _dumb.
>
> Signed-off-by: Steven Price
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_dumb_buffers.c | 4 ++--
>
On 2019-05-16 3:54 p.m., Lyude Paul wrote:
> [CAUTION: External Email]
>
> Hi, could we (and for future versions of this series and others) get a respin
> of this that's actually rebased against drm-tip? That is the defacto standard
> branch to do development on, and otherwise anyone trying to
Whoops-one more thing I forgot to mention. This is just personal preference
for me, but if you're ccing me on any of the patches in the series feel free
to just do it for all of them. Makes my inbox a little less confusing to look
at
On Thu, 2019-05-16 at 15:54 -0400, Lyude Paul wrote:
> Hi,
Hi, could we (and for future versions of this series and others) get a respin
of this that's actually rebased against drm-tip? That is the defacto standard
branch to do development on, and otherwise anyone trying to test these patches
has to resolve merge conflicts (along with maintainers). The
Am Mittwoch, 8. Mai 2019, 18:09:05 CEST schrieb Sean Paul:
> From: Sean Paul
>
> Another version of the SR helpers for your consumption.
>
> Pretty minor differences between v4 and v3:
> - lots of documentation changes
> - Use connector to get at crtc state in encoders
> - Use the damage
On Thu, May 16, 2019 at 9:49 AM Torsten Duwe wrote:
>
> On Thu, May 16, 2019 at 09:06:41AM -0700, Vasily Khoruzhick wrote:
> >
> > Driver can talk to the panel over AUX channel only after t1+t3, t1 is
> > up to 10ms, t3 is up to 200ms.
>
> This is after power-on. The boot loader needs to deal
Hi,
On Thu, May 16, 2019 at 10:25 AM Matthias Kaehlcke wrote:
> The GPU can be used as a thermal cooling device, add an optional
> '#cooling-cells' property.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> Changes in v2:
> - patch added to the series
> ---
>
Hi,
On Thu, May 16, 2019 at 10:25 AM Matthias Kaehlcke wrote:
> Currently the CPUs are used as cooling devices of the rk3288 GPU
> thermal zone. The CPUs are also configured as cooling devices in the
> CPU thermal zone, which indirectly helps with cooling the GPU thermal
> zone, since the CPU
Currently the CPUs are used as cooling devices of the rk3288 GPU
thermal zone. The CPUs are also configured as cooling devices in the
CPU thermal zone, which indirectly helps with cooling the GPU thermal
zone, since the CPU and GPU temperatures are correlated on the rk3288.
Configure the ARM Mali
On 5/16/19 11:18 AM, sunpeng...@amd.com wrote:
>
> From: Leo Li
>
> Set the connector's kernel device as the parent for the aux kernel
> device. This allows udev rules to access connector attributes when
> creating symlinks to aux devices.
>
> For example, the following udev rule:
>
>
The GPU can be used as a thermal cooling device, add an optional
'#cooling-cells' property.
Signed-off-by: Matthias Kaehlcke
---
Changes in v2:
- patch added to the series
---
Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 3 +++
1 file changed, 3 insertions(+)
diff --git
The Mali GPU of the rk3288 can be used as cooling device, add
a #cooling-cells entry for it.
Signed-off-by: Matthias Kaehlcke
Reviewed-by: Douglas Anderson
---
Changes in v2:
- added Doug's 'Reviewed-by' tag
---
arch/arm/boot/dts/rk3288.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git
On Thursday, 2019-05-16 09:37:40 -0700, Eric Anholt wrote:
> Eric Anholt writes:
>
> > [ Unknown signature status ]
> > James Clarke writes:
> >
> >> Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t
> >> types, which differs from the BSDs' headers. Thus we should include
>
On Thu, May 16, 2019 at 6:33 PM Michel Dänzer wrote:
> On 2019-05-16 2:47 p.m., Daniel Vetter wrote:
> > On Thu, May 16, 2019 at 2:46 PM Michel Dänzer wrote:
> >> On 2019-05-16 12:09 p.m., Christian König wrote:
> >>> Am 16.05.19 um 10:16 schrieb zhoucm1:
> I was able to push changes to
Daniel Vetter writes:
> On Wed, Apr 24, 2019 at 03:06:38PM -0700, Eric Anholt wrote:
>> I was trying to figure out if it was permissible to merge the Mesa
>> side of V3D's CSD support yet while it's in drm-misc-next but not
>> drm-next, and developers on #dri-devel IRC had differing opinions of
Eric Anholt writes:
> [ Unknown signature status ]
> James Clarke writes:
>
>> Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t
>> types, which differs from the BSDs' headers. Thus we should include
>> stdint.h to ensure we have all the required integer types.
>>
>>
https://bugs.freedesktop.org/show_bug.cgi?id=108824
--- Comment #7 from Baldur Karlsson ---
I applied the patchset on top of latest mesa
(aa040d3b3c7d068e1ece61c71770c16a54745f89) and I seem to get some rendered
corruption that I don't get with the parent commit before applying the patches.
It
On 2019-05-16 2:47 p.m., Daniel Vetter wrote:
> On Thu, May 16, 2019 at 2:46 PM Michel Dänzer wrote:
>> On 2019-05-16 12:09 p.m., Christian König wrote:
>>> Am 16.05.19 um 10:16 schrieb zhoucm1:
I was able to push changes to libdrm, but now seems after libdrm is
migrated to gitlab, I
The new interfaces drm_gem_vram_{pin/unpin}_reserved() are variants of the
GEM VRAM pin/unpin functions that do not reserve the BO during validation.
The mgag200 driver requires this behavior for its cursor handling. The
patch also converts the driver to use the new interfaces.
Signed-off-by:
A kernel test bot reported a problem with the locktorture testcase that
was triggered by the GEM VRAM helpers.
...
[ 10.004734] RIP: 0010:ttm_bo_validate+0x41/0x141 [ttm]
...
[ 10.015669] ? kvm_sched_clock_read+0x5/0xd
[ 10.016157] ? get_lock_stats+0x11/0x3f
[ 10.016607]
The original bochs and vbox implementations of pin and unpin functions
automatically reserved BOs during validation. This functionality got lost
while converting the code to a generic implementation. This may result
in validating unlocked TTM BOs.
Adding the reserve and unreserve operations to
Hello Sabyasachi,
Thank you for the patch.
On Thu, May 16, 2019 at 08:55:56PM +0530, Sabyasachi Gupta wrote:
> Remove duplicate header which is included twice
>
> Signed-off-by: Sabyasachi Gupta
Reviewed-by: Laurent Pinchart
> ---
> v2: rebased the code against drm -next and arranged the
Paul Kocialkowski writes:
> Changes sinve v8:
> * Added collected Reviewed-by;
> * Fixed up another problematic case as discussed on v8.
I think this is ready to go. Thanks!
signature.asc
Description: PGP signature
On Thu, May 16, 2019 at 8:48 AM Torsten Duwe wrote:
>
> On Wed, May 15, 2019 at 08:08:57AM -0700, Vasily Khoruzhick wrote:
> > On Wed, May 15, 2019 at 12:32 AM Torsten Duwe wrote:
> > >
> > > It does comply with the bindings. The ports are all optional.
> > > As far as DT is concerned, the
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #5 from tempel.jul...@gmail.com ---
Yes, it also happens with Linux 5.1.
It btw. runs fine on xwayland inside a Plasma Wayland session.
--
You are receiving this mail because:
You are the assignee for the
From: Harald Geyer
The TERES-I has internal speakers (left, right), internal microphone
and a headset combo jack (headphones + mic), "CTIA" (android) pinout.
The headphone and mic detect lines of the A64 are connected properly,
but AFAIK currently unsupported by the driver.
Signed-off-by:
From: Icenowy Zheng
Allwinner A64's TCON0 can output RGB666 LCD signal.
Add its pinmux.
Signed-off-by: Icenowy Zheng
Signed-off-by: Vasily Khoruzhick
Signed-off-by: Torsten Duwe
---
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git
From: Icenowy Zheng
TERES-I has an ANX6345 bridge connected to the RGB666 LCD output, and
the I2C controlling signals are connected to I2C0 bus.
Enable it in the device tree.
Signed-off-by: Icenowy Zheng
Signed-off-by: Torsten Duwe
---
originally: patchwork.kernel.org/patch/10646867
From: Icenowy Zheng
The ANX6345 is an ultra-low power DisplayPort/eDP transmitter designed
for portable devices.
Add a binding document for it.
Signed-off-by: Icenowy Zheng
Signed-off-by: Vasily Khoruzhick
Reviewed-by: Rob Herring
Signed-off-by: Torsten Duwe
---
Hi all,
based on Maxime's sunxi-dt64-for-5.2, here is what I found so far
still missing in the device tree. Those bits and pieces have already
been submitted but were not yet applied.
Changes since v1:
* lcd-rgb666-pins
-
* dvdd12-supply, dvdd25-supply now are required by the
On Wed, May 15, 2019 at 08:08:57AM -0700, Vasily Khoruzhick wrote:
> On Wed, May 15, 2019 at 12:32 AM Torsten Duwe wrote:
> >
> > It does comply with the bindings. The ports are all optional.
> > As far as DT is concerned, the signal path ends here. This is also the
> > final component _required_
Providing maintainers more aware of the substance review it and ok it,
patches 1-2 are:
Acked-by: Alyssa Rosenzweig
Patch 3 should be:
Reviewed-by: Alyssa Rosenzweig
Hi Noralf.
> > drm/fb-helper: Remove drm_fb_helper_crtc
> > drm/fb-helper: Prepare to move out commit code
> > drm/fb-helper: Move out commit code
> > drm/fb-helper: Remove drm_fb_helper_connector
>
> Patches 5-8 are still in need of review...
With the improved changelogs the remaining
Hi Noralf.
After clarifying patch 8 this looks good (moved code touched n patch 8).
So I consider this:
Reviewed-by: Sam Ravnborg
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Noralf.
On Thu, May 16, 2019 at 03:53:07PM +0200, Noralf Trønnes wrote:
>
>
> Den 16.05.2019 15.07, skrev Sam Ravnborg:
> > Hi Noralf.
> >
> > See few comments in the following.
> >
> > Sam
> >
> > On Mon, May 06, 2019 at 08:01:36PM +0200, Noralf Trønnes wrote:
> >> All drivers add
From: Ville Syrjälä
All available downstream ports - physical and logical - are exposed for
each MST device. They are listed in /dev/, following the same naming
scheme as SST devices by appending an incremental ID.
Although all downstream ports are exposed, only some will work as
expected.
From: Leo Li
In preparation for adding aux devices for DP MST, make the IDR
non-cyclic. That way, hotplug cycling MST devices won't needlessly
increment the minor version index.
Signed-off-by: Leo Li
Reviewed-by: Lyude Paul
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/drm_dp_aux_dev.c | 3
From: Leo Li
Set the connector's kernel device as the parent for the aux kernel
device. This allows udev rules to access connector attributes when
creating symlinks to aux devices.
To do so, the connector needs to be registered beforehand. Therefore,
shift aux registration to be after connector
From: Leo Li
Placing the MST aux device as a child of the connector gives udev the
ability to access the connector device's attributes. This will come in
handy when writing udev rules to create more descriptive symlinks to the
MST aux devices.
Cc: Ville Syrjälä
Cc: Lyude Paul
Signed-off-by:
From: Leo Li
This can be used to create more descriptive symlinks for MST aux
devices. Consider the following udev rule:
SUBSYSTEM=="drm_dp_aux_dev", SUBSYSTEMS=="drm", ATTRS{mstpath}=="?*",
SYMLINK+="drm_dp_aux/by-path/$attr{mstpath}"
The following symlinks will be created (depending
From: Leo Li
Set the connector's kernel device as the parent for the aux kernel
device. This allows udev rules to access connector attributes when
creating symlinks to aux devices.
For example, the following udev rule:
SUBSYSTEM=="drm_dp_aux_dev", SUBSYSTEMS=="drm", ATTRS{edid}=="*",
From: Leo Li
Set the connector's kernel device as the parent for the aux kernel
device. This allows udev rules to access connector attributes when
creating symlinks to aux devices.
Cc: Ben Skeggs
Cc: Lyude Paul
Signed-off-by: Leo Li
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
1
From: Leo Li
This series adds support for MST AUX devices.
A more descriptive 'mstpath' attribute is also added to MST connector
devices. In addition, the DP aux device is made to be a child of the
corresponding connector's device where possible (*). This allows udev
rules to provide
Remove duplicate header which is included twice
Signed-off-by: Sabyasachi Gupta
---
v2: rebased the code against drm -next and arranged the headers alphabetically
drivers/gpu/drm/bridge/panel.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/panel.c
The pull request you sent on Thu, 16 May 2019 12:27:54 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2019-05-16
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/cc7ce90153e74f8266eefee9fba466faa1a2d5df
Thank you!
--
Deet-doot-dot, I am a bot.
On Thu, May 16, 2019 at 10:10 AM Tejun Heo wrote:
> I haven't gone through the patchset yet but some quick comments.
>
> On Wed, May 15, 2019 at 10:29:21PM -0400, Kenny Ho wrote:
> > Given this controller is specific to the drm kernel subsystem which
> > uses minor to identify drm device, I don't
Changes sinve v8:
* Added collected Reviewed-by;
* Fixed up another problematic case as discussed on v8.
Changes since v7:
* Moved the used bool to vc4_v3d_bin_bo_get in order to check it locked and
avoid a possible race condition;
Changes since v6:
* Removed vc4_v3d_bin_bo_put from error
Check that we have a V3D device registered before attempting to
allocate a binner buffer object.
Signed-off-by: Paul Kocialkowski
Reviewed-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_v3d.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c
In preparation for wrapping the binner bo allocation helper with
put/get helpers, pass the vc4 dev directly and drop the vc4 prefix.
Signed-off-by: Paul Kocialkowski
Reviewed-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_v3d.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
Since the OOM interrupt directly deals with the binner bo, it doesn't
make sense to try and handle it without a binner buffer registered.
Signed-off-by: Paul Kocialkowski
Reviewed-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_irq.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
The binner BO is not required until the V3D is in use, so avoid
allocating it at probe and do it on the first non-dumb BO allocation.
Keep track of which clients are using the V3D and liberate the buffer
when there is none left, using a kref. Protect the logic with a
mutex to avoid race
Hi all,
While picking up the IGT tests for timeline syncobj,
I noticed that although we deal with multi wait across both timeline
(with point value > 0) and binary (point value = 0) syncobjs,
we don't seem to have a similar behavior with signaling.
Do you have any thought on this?
I'm
On Thu, May 16, 2019 at 10:12 AM Christian König
wrote:
> Am 16.05.19 um 16:03 schrieb Kenny Ho:
> > On Thu, May 16, 2019 at 3:25 AM Christian König
> > wrote:
> >> Am 16.05.19 um 09:16 schrieb Koenig, Christian:
> >> We need something like the Linux sysfs location or similar to have a
> >>
On Thu, May 16, 2019 at 03:00:01PM +0300, Laurent Pinchart wrote:
> Hi Sean,
>
> On Mon, May 13, 2019 at 10:38:58AM -0400, Sean Paul wrote:
> > On Sat, May 11, 2019 at 3:12 PM Laurent Pinchart wrote:
> > > On Thu, May 02, 2019 at 03:49:46PM -0400, Sean Paul wrote:
> > >> From: Sean Paul
> > >>
>
drm_gem_dumb_map_offset() is a useful helper for non-dumb clients, so
rename it to remove the _dumb.
Signed-off-by: Steven Price
---
drivers/gpu/drm/drm_dumb_buffers.c | 4 ++--
drivers/gpu/drm/drm_gem.c | 6 +++---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 3 +--
Panfrost has a re-implementation of drm_gem_dumb_map_offset() with an
extra bug regarding the handling of imported buffers. However we don't
really want Panfrost calling _dumb functions because it's not a KMS
driver.
This series renames drm_gem_dumb_map_offset() to drop the '_dumb' and
introduces
https://bugs.freedesktop.org/show_bug.cgi?id=108487
Daniel Stone changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Am 16.05.19 um 16:03 schrieb Kenny Ho:
On Thu, May 16, 2019 at 3:25 AM Christian König
wrote:
Am 16.05.19 um 09:16 schrieb Koenig, Christian:
Am 16.05.19 um 04:29 schrieb Kenny Ho:
On Wed, May 15, 2019 at 5:26 PM Welty, Brian wrote:
On 5/9/2019 2:04 PM, Kenny Ho wrote:
Each file is
Hello,
I haven't gone through the patchset yet but some quick comments.
On Wed, May 15, 2019 at 10:29:21PM -0400, Kenny Ho wrote:
> Given this controller is specific to the drm kernel subsystem which
> uses minor to identify drm device, I don't see a need to complicate
> the interfaces more by
On Thu, May 16, 2019 at 3:25 AM Christian König
wrote:
> Am 16.05.19 um 09:16 schrieb Koenig, Christian:
> > Am 16.05.19 um 04:29 schrieb Kenny Ho:
> >> On Wed, May 15, 2019 at 5:26 PM Welty, Brian wrote:
> >>> On 5/9/2019 2:04 PM, Kenny Ho wrote:
> Each file is multi-lined with one
Am 16.05.19 um 14:28 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Thu, May 16, 2019 at 09:25:31AM +0200, Christian König wrote:
>> Am 16.05.19 um 09:16 schrieb Koenig, Christian:
>>> Am 16.05.19 um 04:29 schrieb Kenny Ho:
[CAUTION: External Email]
On Wed, May 15, 2019
Oh, please not that problem again :(
Please just try "ssh gitlab.freedesktop.org" if that also times out like
this you need to contact AMD network IT and ask why ssh once more
doesn't work.
Christian.
Am 16.05.19 um 13:43 schrieb Zhou, David(ChunMing):
It mentioned me I cannot push to
Am 16.05.19 um 13:23 schrieb Thomas Hellstrom:
On Thu, 2019-05-16 at 12:05 +0200, Christian König wrote:
Am 16.05.19 um 11:23 schrieb Thomas Hellstrom:
Drivers like vmwgfx may want to test whether the dma page pool is
present
or not. Since it's activated by default by TTM if compiled-in,
On Thu, Apr 04, 2019 at 12:06:14PM +0100, james qian wang (Arm Technology
China) wrote:
> For supporting AFBC:
> 1. Check if the user requested modifier can be supported by display HW.
> 2. Check the obj->size with AFBC's requirement.
> 3. Configure HW according to the modifier (afbc features)
Den 16.05.2019 15.07, skrev Sam Ravnborg:
> Hi Noralf.
>
> See few comments in the following.
>
> Sam
>
> On Mon, May 06, 2019 at 08:01:36PM +0200, Noralf Trønnes wrote:
>> All drivers add all their connectors so there's no need to keep around an
>> array of available connectors.
I
This patch enables modeset whenever HDR metadata
needs to be updated to sink.
v2: Addressed Shashank's review comments.
v3: Added Shashank's RB.
v4: Addressed Ville's review comments.
v5: Addressed Ville's review comments.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by:
Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comments
v5: Rebase. Added infoframe
From: Ville Syrjälä
This patch enables infoframes on GLK+ to be
used to send HDR metadata to HDMI sink.
v2: Addressed Shashank's review comment.
v3: Addressed Shashank's review comment.
v4: Added Shashank's RB.
v5: Dropped hdr_metadata_change check while modeset, as per
Ville's suggestion.
Hi Sabyasachi,
On Thu, May 16, 2019 at 06:45:04PM +0530, Sabyasachi Gupta wrote:
> On Tue, May 14, 2019 at 1:05 PM Laurent Pinchart wrote:
> > On Tue, May 14, 2019 at 01:01:41PM +0530, Sabyasachi Gupta wrote:
> > > Remove drm/drm_panel.h which is included more than once
> > >
> > > Signed-off-by:
From: Jonas Karlman
This adds reference count for HDR metadata blob,
handled as part of duplicate and destroy connector
state functions.
v2: Removed the hdr_metadata_changed initialization as
the variable is dropped and not required.
Signed-off-by: Jonas Karlman
Signed-off-by: Uma Shankar
Added state readout for DRM infoframe and enabled
state validation for DRM infoframe.
v2: Addressed Ville's review comments and dropped the
unused drm infoframe read at intel_hdmi_init.
v3: Removed a redundant platform check as per Ville's
comment.
Signed-off-by: Uma Shankar
---
Attach HDR metadata property to connector object.
v2: Rebase
v3: Updated the property name as per updated name
while creating hdr metadata property
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff
BYT/CHT doesn't support DRM Infoframe. This caused
a WARN_ON due to a missing CASE while executing
intel_hdmi_infoframes_enabled function. This patch
fixes the same.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Added unpack function for DRM infoframe for dynamic
range and mastering infoframe readout.
v2: Addressed Ville's review comments.
Suggested-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/video/hdmi.c | 67
1 file changed, 67
From: Ville Syrjälä
ADD HLG EOTF to the list of EOTF transfer functions supported.
Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
HLG defines a nonlinear transfer function in which the lower
half of the signal values use a gamma curve and the upper half
of the signal values use a
Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.
The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.
This patch series enables HDR support in drm. It basically defines
HDR metadata structures, property to pass content (after blending)
metadata from user space compositors to driver.
Dynamic Range and Mastering infoframe creation and sending.
ToDo:
1. We need to get the color framework in place
HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.
v2: Rebase and added Ville's POC changes to the patch.
v3: No Change
v4: Addressed Shashank's review comments
v5: Addressed Shashank's comment and added his RB.
v6: Addressed Jonas Karlman
This patch adds a blob property to get HDR metadata
information from userspace. This will be send as part
of AVI Infoframe to panel.
It also implements get() and set() functions for HDR output
metadata property.The blob data is received from userspace and
saved in connector state, the same is
On Thu, May 16, 2019 at 02:07:34PM +0200, Daniel Vetter wrote:
> On Thu, May 16, 2019 at 2:02 PM Laurent Pinchart
> wrote:
> >
> > Hi Daniel,
> >
> > On Mon, May 13, 2019 at 04:47:47PM +0200, Daniel Vetter wrote:
> > > On Sat, May 11, 2019 at 10:12:02PM +0300, Laurent Pinchart wrote:
> > > > On
On 16/05/2019 12:19, Robin Murphy wrote:
[...]
> I was expecting to see a similar behaviour to my T620 (which I now
> assume was down to 64-bit job descriptors sort-of-but-not-quite working)
> but this does look a bit more fundamental - the fact that it's a level 1
> fault with VA == head == tail
On Tue, May 14, 2019 at 1:05 PM Laurent Pinchart
wrote:
>
> Hi Sabyasachi,
>
> Thank you for the patch.
>
> On Tue, May 14, 2019 at 01:01:41PM +0530, Sabyasachi Gupta wrote:
> > Remove drm/drm_panel.h which is included more than once
> >
> > Signed-off-by: Sabyasachi Gupta
> > ---
> >
On Thu, May 16, 2019 at 10:54:14AM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> >Of Ville
> >Syrjälä
> >Sent: Thursday, May 16, 2019 12:57 AM
> >To: Shankar, Uma
> >Cc: dcasta...@chromium.org;
Hi Noralf.
See few comments in the following.
Sam
On Mon, May 06, 2019 at 08:01:36PM +0200, Noralf Trønnes wrote:
> All drivers add all their connectors so there's no need to keep around an
> array of available connectors.
>
> Rename functions which signature is changed since they will
1 - 100 of 165 matches
Mail list logo
