This commit was reverted later. I guess the revert was probably not picked up
properly.
Regards,
Yong
From: syzbot
Sent: Tuesday, May 21, 2019 11:16 PM
To: Zhao, Yong; airl...@linux.ie; Deucher, Alexander;
amd-...@lists.freedesktop.org; a...@kernel.org;
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #1 from rro...@gmail.com ---
I get similar corruption in Chromium and Visual Studio Code with Mesa
19.1.0-rc3. There was no problem with 19.1.0-rc2.
This is on Archlinux, kernel 5.1.3, the card is an RX480. I tried compiling
Mesa
https://bugs.freedesktop.org/show_bug.cgi?id=107731
--- Comment #13 from Fermulator ---
Sorry I no longer have access to the system originally reported this issue
from.
--
You are receiving this mail because:
You are the assignee for the bug.___
Add support for encodings to or from limited range quantization.
Signed-off-by: Steve Longerbeam
---
Changes in v7:
- hard-code the coefficients instead of deriving the limited range
coefficients from the full2full coefficients on the fly with
fixed-point math.
- add support for RGB
The saturation bit was being set at bit 9 in the second 32-bit word
of the TPMEM CSC. This isn't correct, the saturation bit is bit 42,
which is bit 10 of the second word.
Fixes: 1aa8ea0d2bd5d ("gpu: ipu-v3: Add Image Converter unit")
Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
Only providing the input and output RGB/YUV space to the IC task init
functions is not sufficient. To fully characterize a colorspace
conversion, the Y'CbCr encoding standard, and quantization also
need to be specified.
Define a 'struct ipu_ic_colorspace' that includes all the above.
This allows
Add support for Rec.709 encoding and inverse encoding.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v7:
- moved CSC tables to new module ipu-ic-csc.c.
- express negative coefficients as true signed int's, for better
readability.
Changes in v5:
- moved API changes to
https://bugs.freedesktop.org/show_bug.cgi?id=107731
--- Comment #12 from L.S.S. ---
Sorry, but should have commented on this much sooner.
After my last comment I eventually replaced the ATEN CS1924 KVM with a new
generic 4-port KVM that is 4K@60Hz-capable. This one does not exhibit the
issue,
On 5/20/19 8:30 AM, Daniel Thompson wrote:
> On Mon, May 20, 2019 at 08:14:03AM -0500, Rob Herring wrote:
>> On Mon, May 20, 2019 at 3:59 AM Brian Masney wrote:
>>>
>>> The '#address-cells' and '#size-cells' properties were not defined in
>>> the lm3630a bindings and would cause the following
https://bugs.freedesktop.org/show_bug.cgi?id=110701
--- Comment #24 from Yury Zhuravlev ---
(In reply to Marek Olšák from comment #23)
> Fixed by d6053bf2a170a0fec6d232fda097d2f35f0e9eae. Closing.
The original issue was about Vega and on Vega we saw a different problem. I
suppose before close
On Tue, May 21, 2019 at 07:29:33PM +0100, Catalin Marinas wrote:
> On Mon, May 20, 2019 at 04:53:07PM -0700, Evgenii Stepanov wrote:
> > On Fri, May 17, 2019 at 7:49 AM Catalin Marinas
> > wrote:
> > > IMO (RFC for now), I see two ways forward:
> > > [...]
> > > 2. Similar shim to the above libc
https://bugs.freedesktop.org/show_bug.cgi?id=110701
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110721
Bug ID: 110721
Summary: graphics corruption on steam client with mesa 19.1.0
rc3 on polaris
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
Hi Joonas,
On Tue, 21 May 2019 16:04:16 +0300 Joonas Lahtinen
wrote:
>
> We also have an incoming patch where the Fixes: line has a comment in
> it. Does your tooling account for this when checking the Fixes: line?
I will make sure mine does.
--
Cheers,
Stephen Rothwell
pgpRzgG4OaQLx.pgp
https://bugs.freedesktop.org/show_bug.cgi?id=110701
--- Comment #22 from Christian Widmer ---
(In reply to Marek Olšák from comment #21)
> Created attachment 144313 [details] [review]
> likely fix
>
> This patch should fix it. Thanks to Pierre-Eric for inspiring it.
I can confirm that this
https://bugs.freedesktop.org/show_bug.cgi?id=108824
--- Comment #13 from LoneVVolf ---
Applying the "likely fix" patch in
https://bugs.freedesktop.org/show_bug.cgi?id=108824#c12 solves the issue with
plasma shell/knetwalk on my rx 580.
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=110719
Bug ID: 110719
Summary: Crash in radeon_drv_video.so when attempting to
convert rgb video data
Product: Mesa
Version: git
Hardware: All
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=110701
--- Comment #21 from Marek Olšák ---
Created attachment 144313
--> https://bugs.freedesktop.org/attachment.cgi?id=144313=edit
likely fix
This patch should fix it. Thanks to Pierre-Eric for inspiring it.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=108824
--- Comment #12 from Marek Olšák ---
Created attachment 144312
--> https://bugs.freedesktop.org/attachment.cgi?id=144312=edit
likely fix
This patch should fix it. Thanks to Pierre-Eric for inspiring it.
--
You are receiving this mail
Quoting Rob Herring (2019-05-21 16:24:27)
> On Mon, May 20, 2019 at 4:23 AM Steven Price wrote:
> >
>
> You forgot to update the subject. I can fixup when applying, but I'd
> like an ack from Chris on patch 1.
I still think it is incorrect as the limitation is purely an issue with
the shmem
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #93 from Diego Viola ---
I just tried to reproduce this issue (xterm bug) with sway today and noticed
that I can't reproduce it under sway.
The bug can still be reproduced with weston and i3.
- sway 1.0-8
- xorg-server-xwayland
From: Sean Paul
The driver checks for gmu->mmio as a sign that the device has been
initialized, however there are failures in probe below the mmio init.
If one of those is hit, mmio will be non-null but freed.
In that case, a6xx_gmu_probe will return an error to a6xx_gpu_init which
will in turn
On 21/05/2019 12:52:17+0200, Bartlomiej Zolnierkiewicz wrote:
> Add COMPILE_TEST support to atmel_lcdfb driver for better compile
> testing coverage.
>
> Signed-off-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Alexandre Belloni
> ---
> v2: add missing HAVE_CLK && HAS IOMEM dependencies
>
>
On Tue, May 21, 2019 at 06:00:36PM +0200, Daniel Vetter wrote:
> On Tue, May 21, 2019 at 5:41 PM Jerome Glisse wrote:
> >
> > On Mon, May 20, 2019 at 11:39:45PM +0200, Daniel Vetter wrote:
> > > This is a similar idea to the fs_reclaim fake lockdep lock. It's
> > > fairly easy to provoke a
https://bugs.freedesktop.org/show_bug.cgi?id=108824
--- Comment #11 from Pierre-Eric Pelloux-Prayer ---
Created attachment 144311
--> https://bugs.freedesktop.org/attachment.cgi?id=144311=edit
wip patch
The following patch (applied on top of the problematic commit 78e35df52a) seems
to fix the
Add support for per-instance pagetables for a6xx targets. Add support
to handle split pagetables and create a new instance if the needed
IOMMU support exists and insert the necessary PM4 commands to trigger
a pagetable switch at the beginning of a user command.
Signed-off-by: Jordan Crouse
---
Add support for creating a auxiliary domain from the IOMMU device to
implement per-instance pagetables. Also add a helper function to
return the pagetable base address (ttbr) and asid to the caller so
that the GPU target code can set up the pagetable switch.
Signed-off-by: Jordan Crouse
---
Move the address space setup code out of the generic msm GPU code to
to the individual GPU targets. This allows us to do target specific
setup such as gpummu for a2xx or split pagetables and per-instance
pagetables for newer a5xx and a6xx targets. All this is at the
expense of duplicated code in
Targets that support per-instance pagetable switching will have to keep
track of which pagetable belongs to each instance to be able to recover
for preemption.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_ringbuffer.h | 1 +
1 file changed, 1 insertion(+)
diff --git
Add support to create a GPU target specific address space for
a context. For those targets that support per-instance
pagetables they will return a new address space set up for
the instance if possible otherwise just use the global
device pagetable.
Signed-off-by: Jordan Crouse
---
Pass the index of the MMU domain in struct msm_file_private instead
of assuming gpu->id throughout the submit path. This clears the way
to change ctx->aspace to a per-instance pagetable.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.c| 2 ++
Add support for per-instance pagetables for 5XX targets. Create a support
buffer for preemption to hold the SMMU pagetable information for a
preempted ring, enable TTBR1 to support split pagetables and add the
necessary PM4 commands to trigger a pagetable switch at the beginning
of a user command.
Add a helper function to create a GEM address space attached to
an iommu auxiliary domain for a per-instance pagetable.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.h | 4 +++
drivers/gpu/drm/msm/msm_gem_vma.c | 53 +++
2 files changed,
A5XX and newer GPUs can be run in either 32 or 64 bit mode. The GPU
registers and the microcode use 64 bit virtual addressing in either
case but the upper 32 bits are ignored if the GPU is in 32 bit mode.
There is no performance disadvantage to remaining in 64 bit mode even
if we are only
When we move to 64 bit addressing for a5xx and a6xx targets we will start
seeing pagefaults at larger addresses so format them appropriately in the
log message for easier debugging.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1
This is a refresh of the per-instance pagetable support for arm-smmu-v2 and the
MSM GPU driver. I think this is pretty mature at this point, so I've dropped the
RFC designation and ask for consideration for 5.3.
Per-instance pagetables allow the target GPU driver to create and manage
an
Add the mali gpu node to the H6 device-tree.
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index
Enable and add supply to the Mali GPU node on all the
H6 boards.
Regarding the datasheet the maximum time for supply to reach
its voltage is 32ms.
Signed-off-by: Clément Péron
---
arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 6 ++
Allwinner H6 SoC has a Mali T720MP2 with a 33-bit iommu which
trig the sanity check during the alloc of the pgtable.
Change the sanity check to allow non 48-bit configuration.
Suggested-by: Robin Murphy
Signed-off-by: Clément Péron
---
drivers/iommu/io-pgtable-arm.c | 2 +-
1 file changed, 1
On Tue, May 21, 2019 at 5:41 PM Jerome Glisse wrote:
>
> On Mon, May 20, 2019 at 11:39:45PM +0200, Daniel Vetter wrote:
> > This is a similar idea to the fs_reclaim fake lockdep lock. It's
> > fairly easy to provoke a specific notifier to be run on a specific
> > range: Just prep it, and then
On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing
On Mon, May 20, 2019 at 11:39:45PM +0200, Daniel Vetter wrote:
> This is a similar idea to the fs_reclaim fake lockdep lock. It's
> fairly easy to provoke a specific notifier to be run on a specific
> range: Just prep it, and then munmap() it.
>
> A bit harder, but still doable, is to provoke the
On Mon, May 20, 2019 at 11:39:44PM +0200, Daniel Vetter wrote:
> We need to make sure implementations don't cheat and don't have a
> possible schedule/blocking point deeply burried where review can't
> catch it.
>
> I'm not sure whether this is the best way to make sure all the
> might_sleep()
On Mon, May 20, 2019 at 4:23 AM Steven Price wrote:
>
You forgot to update the subject. I can fixup when applying, but I'd
like an ack from Chris on patch 1.
> panfrost_ioctl_mmap_bo() contains a reimplementation of
> drm_gem_map_offset() but with a bug - it allows mapping imported objects
>
On Mon, May 20, 2019 at 10:37:53AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 20.05.19 um 10:33 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 20.05.19 um 10:21 schrieb Daniel Vetter:
> > ...
> >> diff --git a/drivers/video/fbdev/core/fbmem.c
> >> b/drivers/video/fbdev/core/fbmem.c
> >> index
GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).
Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_pocket2 data struct may very well need to be updated
with
On Tue, May 21, 2019 at 02:41:30PM +0200, Daniel Vetter wrote:
> On Tue, May 21, 2019 at 01:09:06PM +0200, Maxime Ripard wrote:
> > We introduced new functions in the commit bf39607c1614 ("drm/fourcc: Pass
> > the format_info pointer to drm_format_plane_width/height") based on
> > previous ones
Reviewed-by: Deepak Rawat
On Tue, 2019-05-21 at 00:35 +0200, Daniel Vetter wrote:
> That's purely for the uapi layer to implement the ALLOW_MODESET flag.
>
> Drivers should instead look at the state, e.g. through
> drm_atomic_crtc_needs_modeset(), which vmwgfx already does. Also
> remove
> the
On Tue, May 21, 2019 at 12:46:38PM +0200, Michal Hocko wrote:
> On Tue 21-05-19 12:06:11, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debug checks. Add a
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not
On Tue 21-05-19 14:43:38, Cristopher Lameter wrote:
> On Tue, 21 May 2019, Daniel Vetter wrote:
>
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debug checks. Add a
On Tue, 21 May 2019, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
Just putting preempt
On Tue, May 21, 2019 at 08:24:53PM +0900, Tetsuo Handa wrote:
> On 2019/05/21 20:11, Michal Hocko wrote:
> > On Tue 21-05-19 20:04:34, Tetsuo Handa wrote:
> >> On 2019/05/21 19:51, Michal Hocko wrote:
> >>> On Tue 21-05-19 19:44:01, Tetsuo Handa wrote:
> On 2019/05/21 19:06, Daniel Vetter
On Tue, May 21, 2019 at 10:58:06AM +0200, Andrzej Hajda wrote:
> On 08.05.2019 18:09, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch adds atomic variants for all of
> > pre_enable/enable/disable/post_disable bridge functions. These will be
> > called from the appropriate atomic helper
On Tue, May 21, 2019 at 4:26 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 21.05.19 um 14:40 schrieb Daniel Vetter:
> > On Tue, May 21, 2019 at 01:08:28PM +0200, Thomas Zimmermann wrote:
> >> Replacing drm_gem_vram_push_to_system() moves policy from drivers back
> >> to the memory manager. Now,
Hi
Am 21.05.19 um 14:40 schrieb Daniel Vetter:
> On Tue, May 21, 2019 at 01:08:28PM +0200, Thomas Zimmermann wrote:
>> Replacing drm_gem_vram_push_to_system() moves policy from drivers back
>> to the memory manager. Now, unused BOs are only evicted when the space
>> is required.
>>
>> The
This is unused code since
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
when fbcon was made a compile-time static dependency of fbdev. We
can't exit fbcon anymore without exiting
On 21.05.2019 13:34, Tomi Valkeinen wrote:
> On 21/05/2019 10:07, Andrzej Hajda wrote:
>
>>> @@ -1214,19 +1234,43 @@ static int tc_connector_get_modes(struct
>>> drm_connector *connector)
>>> return count;
>>> }
>>>
>>> -static void tc_connector_set_polling(struct tc_data *tc,
>>> -
Am 21.05.19 um 16:13 schrieb Alex Deucher:
> [CAUTION: External Email]
>
> On Tue, May 21, 2019 at 2:48 AM Koenig, Christian
> wrote:
>> Am 21.05.19 um 01:16 schrieb Erico Nunes:
>>> [CAUTION: External Email]
>>>
>>> After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
>>> only
On Tue, May 21, 2019 at 2:48 AM Koenig, Christian
wrote:
>
> Am 21.05.19 um 01:16 schrieb Erico Nunes:
> > [CAUTION: External Email]
> >
> > After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
> > only deleted when the timeout handler is able to be cancelled
> > successfully.
> >
On Tue, May 21, 2019 at 4:02 PM Bartlomiej Zolnierkiewicz
wrote:
> No need for them.
>
> Cc: Geert Uytterhoeven
> Signed-off-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #68 from udo ---
I started getting these after/around commit
076159b40b96096ba01413abc011a26c9acf7176
--
You are receiving this mail because:
You are the assignee for the bug.___
No need for them.
Cc: Geert Uytterhoeven
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/atafb.c | 21 -
1 file changed, 21 deletions(-)
Index: b/drivers/video/fbdev/atafb.c
===
---
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #67 from udo ---
I get multiple of these:
392.377183] amdgpu :09:00.0: [gfxhub] VMC page fault (src_id:0 ring:24
vmid:5 pasid:32772, for process firefox pid 4467 thread firefox:cs0 pid 4565
)
[ 392.377194]
This is a PCI driver and FB_CYBER2000 depends on PCI in Kconfig so
there is no need to check for PCI inside the driver code.
Cc: Russell King
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/cyber2000fb.c |5 -
1 file changed, 5 deletions(-)
Index:
On 5/21/19 3:59 AM, Christian König wrote:
> BTW: Is there actually good documentation how to correctly do the variable
> length array at end of structure thing in the kernel?
>
> I do know that I've seen a lot of different variants like array[] array[0] or
> array[1] and I have also seen a
Thanks David,
Initially I thought we could run into wait issues with a dma_fence_chain
with a value = 0, but you're right, it works fine.
We could just avoid to create a dma_fence_chain object, but maybe we
don't care.
-Lionel
On 21/05/2019 09:51, zhoucm1 wrote:
Sorry for late response.
We also have an incoming patch where the Fixes: line has a comment in
it. Does your tooling account for this when checking the Fixes: line?
Regards, Joonas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
On Tue, May 21, 2019 at 8:17 PM Erico Nunes wrote:
>
> On Tue, May 21, 2019 at 8:47 AM Koenig, Christian
> wrote:
> >
> > Am 21.05.19 um 01:16 schrieb Erico Nunes:
> > > [CAUTION: External Email]
> > >
> > > After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
> > > only deleted
Quoting Stephen Rothwell (2019-05-20 15:15:38)
> Hi all,
>
> In commit
>
> 0d90ccb70211 ("drm/i915: Delay semaphore submission until the start of the
> signaler")
>
> Fixes tag
>
> Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchroni
>
> has these problem(s):
>
>
Am 21.05.19 um 14:16 schrieb Erico Nunes:
> [CAUTION: External Email]
>
> On Tue, May 21, 2019 at 8:47 AM Koenig, Christian
> wrote:
>> Am 21.05.19 um 01:16 schrieb Erico Nunes:
>>> [CAUTION: External Email]
>>>
>>> After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
>>> only
On Tue, May 21, 2019 at 12:56:30PM +0200, Maarten Lankhorst wrote:
> Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> > Create a new wrapper function for this, feels like there's some
> > refactoring room here between the two modes.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Lee Jones
> > Cc:
On Tue, May 21, 2019 at 01:09:06PM +0200, Maxime Ripard wrote:
> We introduced new functions in the commit bf39607c1614 ("drm/fourcc: Pass
> the format_info pointer to drm_format_plane_width/height") based on
> previous ones but with a slightly different prototype. However, the
> documentation
On Tue, May 21, 2019 at 01:08:28PM +0200, Thomas Zimmermann wrote:
> Replacing drm_gem_vram_push_to_system() moves policy from drivers back
> to the memory manager. Now, unused BOs are only evicted when the space
> is required.
>
> The lock/unlock-renaming patch aligns the interface with other
Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to
HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and
HDMI ports.
v2: Minor style fix.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1
Data M/N calculations were assumed a bpp as RGB format. But when we are
using YCbCr 4:2:0 output format on DP, we should change bpp calculations
as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format,
therefore, it was multiplied with 3. But YCbCr 4:2:0 requires a multiplier
value to
This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr
Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.
Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP
On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
And Link M/N values are calculated and applied based on the Full Clock
When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for
VSC SDP Payload for PSR is one of data block type of SDP (Secondaray Data
Packet). In order to generalize SDP packet structure name, it renames
struct edp_vsc_psr to struct dp_sdp. And each SDP data blocks have
different usages, each SDP type has different reserved data blocks and
On Tue, May 21, 2019 at 8:47 AM Koenig, Christian
wrote:
>
> Am 21.05.19 um 01:16 schrieb Erico Nunes:
> > [CAUTION: External Email]
> >
> > After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
> > only deleted when the timeout handler is able to be cancelled
> > successfully.
> >
Hi Maxime,
On Tue, May 21, 2019 at 01:46:11PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Tue, May 21, 2019 at 01:50:08AM +0200, meg...@megous.com wrote:
> > From: Ondrej Jirman
> >
> > Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
> > for the DDC bus to be usable.
> >
>
On Tue, 2019-05-21 at 13:14 +0300, Laurent Pinchart wrote:
> Hello Jani,
>
> On Tue, May 21, 2019 at 09:44:04AM +0300, Jani Nikula wrote:
> > On Mon, 20 May 2019, Gwan-gyeong Mun
> > wrote:
> > > VSC SDP Payload for PSR is one of data block type of SDP
> > > (Secondaray Data
> > > Packet). In
Add COMPILE_TEST support to gbefb driver for better compile
testing coverage.
While at it convert bogus udelay() calls to mdelay() (needed to
build driver on ARM) and remove dead x86 specific code.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2:
- add missing HAS_IOMEM dependency
- fix build
Hi,
On Tue, May 21, 2019 at 01:50:08AM +0200, meg...@megous.com wrote:
> From: Ondrej Jirman
>
> Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
> for the DDC bus to be usable.
>
> Add support for hdmi-connector node's optional ddc-en-gpios property to
> support this use
Hi
Am 21.05.19 um 12:35 schrieb Gerd Hoffmann:
> Hi,
>
>> I think would be good to have a lockdep_assert_held here for the ww_mutex.
>>
>> Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations
>> we call the structure tracking the fences+lock the "reservation", but the
>>
On 21/05/2019 10:07, Andrzej Hajda wrote:
@@ -1214,19 +1234,43 @@ static int tc_connector_get_modes(struct drm_connector
*connector)
return count;
}
-static void tc_connector_set_polling(struct tc_data *tc,
-struct drm_connector *connector)
-{
On Tuesday, May 21, 2019 11:48 AM, Daniel Vetter wrote:
> With Eric's patch
>
> commit ba6e798ecf320716780bb6a6088a8d17dcba1d49
> Author: Eric Anholt
> Date: Wed Apr 24 11:56:17 2019 -0700
>
> drm/doc: Document expectation that userspace review looks at kernel uAPI.
>
> there's been
Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> It's not pretty.
>
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Hans de Goede
> Cc: Yisheng Xie
> ---
> drivers/video/fbdev/core/fbcon.c | 19 +++
> 1 file changed, 19 insertions(+)
>
We introduced new functions in the commit bf39607c1614 ("drm/fourcc: Pass
the format_info pointer to drm_format_plane_width/height") based on
previous ones but with a slightly different prototype. However, the
documentation wasn't changed to reflect that change.
Fixes: bf39607c1614 ("drm/fourcc:
To align with the rest of DRM terminology, the GEM VRAM helpers now use
lock and unlock in places where reserve and unreserve where used before.
All callers have been adapted.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_fb.c | 11 +++
Replacing drm_gem_vram_push_to_system() moves policy from drivers back
to the memory manager. Now, unused BOs are only evicted when the space
is required.
The lock/unlock-renaming patch aligns the interface with other names
in DRM. No functional changes are done.
Finally, there's now a lockdep
We may not call drm_gem_vram_{pin,unpin}_locked() with an unlocked
BO. Now test for this.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
The push-to-system function forces a buffer out of video RAM. This decision
should rather be made by the memory manager. By replacing the function with
calls to the kunmap and unpin functions, the buffer's memory becomes available,
but the buffer remains in VRAM until it's evicted by a pin
Hi
Am 21.05.19 um 12:35 schrieb Gerd Hoffmann:
> Hi,
>
>> I think would be good to have a lockdep_assert_held here for the ww_mutex.
>>
>> Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations
>> we call the structure tracking the fences+lock the "reservation", but the
>>
Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> Create a new wrapper function for this, feels like there's some
> refactoring room here between the two modes.
>
> Signed-off-by: Daniel Vetter
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Daniel
Add COMPILE_TEST support to da8xx-fb driver for better compile
testing coverage.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2: add missing HAVE_CLK && HAS IOMEM dependencies
drivers/video/fbdev/Kconfig |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index:
^Typo in subject.
Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> For some reasons the pm_vt_switch_unregister call was missing from the
> direct unregister_framebuffer path. Fix this.
>
> v2: fbinfo->dev is used to decided whether unlink_framebuffer has been
> called already. I botched that in
Add COMPILE_TEST support to atmel_lcdfb driver for better compile
testing coverage.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2: add missing HAVE_CLK && HAS IOMEM dependencies
drivers/video/fbdev/Kconfig |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index:
1 - 100 of 149 matches
Mail list logo
