On Tuesday, 2019-04-09 11:35:14 +, Ayan Halder wrote:
> Generated using make headers_install from the drm-next
> tree - git://anongit.freedesktop.org/drm/drm
> branch - drm-next
> commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f
>
> The changes were as follows :-
>
> core: (drm.h, drm_fourcc
The __io_virt() macro is not available on all architectures, so cirrus
can't simply pass a pointer to io memory down to the format conversion
helpers. The format conversion helpers must use memcpy_toio() instead.
Add a convert_lines_toio() variant which does just that. Switch the
drm_fb_*_dstcli
On Tue, Apr 09, 2019 at 11:33:04AM +0200, Ondřej Jirman wrote:
> On Tue, Apr 09, 2019 at 10:12:30AM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Tue, Apr 09, 2019 at 02:24:41AM +0200, meg...@megous.com wrote:
> > > +&mmc0 {
> > > + pinctrl-names = "default";
> > > + pinctrl-0 = <&mmc0_pins>;
> >
On Tue, Apr 9, 2019 at 12:20 PM Hans de Goede wrote:
>
> Hi,
>
> On 09-04-19 11:47, Patrik Jakobsson wrote:
> > On Tue, Apr 9, 2019 at 8:51 AM Hans de Goede wrote:
> >>
> >> Some CedarView VBT-s claim that there is a LVDS panel, while there is none.
> >> Specifically this happens on the Thecus N2
On Tuesday, 2019-04-09 12:59:13 +0100, Eric Engestrom wrote:
> On Tuesday, 2019-04-09 11:35:14 +, Ayan Halder wrote:
> > Generated using make headers_install from the drm-next
> > tree - git://anongit.freedesktop.org/drm/drm
> > branch - drm-next
> > commit - 14d2bd53a47a7e1cb3e03d00a6b952734cf
https://bugs.freedesktop.org/show_bug.cgi?id=110370
Bug ID: 110370
Summary: Rendering artifacts in Enter The Gungeon on Both RX
590 and Radeon 7
Product: Mesa
Version: git
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=110137
--- Comment #3 from Nicholas Kazlauskas ---
I suppose that the issue with using realpath is while it's good at stripping
args from chromium based browsers it'll have issues with programs run under
script interpreters.
Maybe the drirc needs a mo
Hi Ondřej Jirman,
On Tue, Apr 9, 2019 at 5:01 PM Ondřej Jirman wrote:
>
> Hi Jagan,
>
> On Tue, Apr 09, 2019 at 02:08:18PM +0530, Jagan Teki wrote:
> > Based on the conversation about using common dtsi from this thread[1],
> > I'm commenting here to make show the diff directly on the nodes,
> > g
https://bugs.freedesktop.org/show_bug.cgi?id=110370
--- Comment #1 from Ryan Houdek ---
Some additional information.
If you change their lighting model from High to Low in the video settings then
the corruption goes away, but this is obviously less than ideal.
Definitely something to do with that
Am 08.04.19 um 13:59 schrieb Thomas Zimmermann:
[SNIP]
> If not for TTM, what would be the alternative? One VMA manager per
> memory region per device?
Since everybody vital seems to be on this mail thread anyway, let's use
it a bit for brain storming what a possible replacement for TTM should
l
On Tue, Apr 09, 2019 at 01:29:41PM +, Jim Zhang wrote:
> Villie:
>
> What is Intel's plan for the colorkey patch? Does Intel have any plan to
> review and release?
There is no real plan at this time. But if you have a use case
for it I can try to harass people until someone reviews it :)
On Tue, Apr 09, 2019 at 04:46:24PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 09, 2019 at 01:29:41PM +, Jim Zhang wrote:
> > Villie:
> >
> > What is Intel's plan for the colorkey patch? Does Intel have any plan to
> > review and release?
>
> There is no real plan at this time. But if you ha
https://bugs.freedesktop.org/show_bug.cgi?id=110360
Alex Deucher changed:
What|Removed |Added
Attachment #143905|text/x-log |text/plain
mime type|
On Tue, Apr 09, 2019 at 01:59:21PM +, Jim Zhang wrote:
> Nice, do you have any sample code for it?
https://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/sna/sna_video_sprite.c
is the only userspace code we have that uses the colorkey.
>
> Thanks,
>
> Jim
>
>
> Caterpillar: Co
On Tue, Apr 09, 2019 at 02:14:49PM +, Jim Zhang wrote:
> Once I pre-configure the colorkey, am I able to enable and disable it? If
> colorkey can be enabled/disabled after that might meet my requirement
Not atomically with other updates.
>
> Thanks,
>
> Jim
>
>
> Caterpillar: Confidentia
Andrew anything blocking this for 5.2 ? Should i ask people (ie the end
user of this) to re-ack v6 (it is the same as previous version just rebase
and dropped kvm bits).
On Tue, Mar 26, 2019 at 12:47:39PM -0400, jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> (Andrew this apply on top of m
https://bugs.freedesktop.org/show_bug.cgi?id=110360
--- Comment #2 from Alex Deucher ---
Does booting with amdgpu.runpm=0 on the kernel command line in grub help?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel m
Am 08.04.19 um 18:08 schrieb Andrey Grodzovsky:
For later driver's reference to see if the fence is signaled.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/
Hi,
On 09-04-19 14:05, Patrik Jakobsson wrote:
On Tue, Apr 9, 2019 at 12:20 PM Hans de Goede wrote:
Hi,
On 09-04-19 11:47, Patrik Jakobsson wrote:
On Tue, Apr 9, 2019 at 8:51 AM Hans de Goede wrote:
Some CedarView VBT-s claim that there is a LVDS panel, while there is none.
Specifically
Am 08.04.19 um 18:08 schrieb Andrey Grodzovsky:
Also reject TDRs if another one already running.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 94 +-
1 file changed, 67 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/dr
On Tue, Apr 09, 2019 at 02:24:03PM +, Jim Zhang wrote:
> What about if I disable interrupt when changing the colorkey? This will
> solve the atomic issue. I think we only change colorkey or enable/disable
> colorkey once a while. If disabling interrupt work, I will disable interrupt
> and
https://bugzilla.kernel.org/show_bug.cgi?id=203201
Bug ID: 203201
Summary: [mgag200] Unable to do mmap call on mgadrmfb device -
Returns -EINVAL
Product: Drivers
Version: 2.5
Kernel Version: 4.4 LTS
Hardware: Intel
On Mon, 8 Apr 2019 at 23:04, Rob Herring wrote:
>
> On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
> >
> > On 01/04/2019 08:47, Rob Herring wrote:
> > > This adds the initial driver for panfrost which supports Arm Mali
> > > Midgard and Bifrost family of GPUs. Currently, only the T860 and
> >
https://bugs.freedesktop.org/show_bug.cgi?id=108879
--- Comment #10 from Jan Vesely ---
(In reply to Steffen Klee from comment #9)
> AMD R9 390 (Linux 4.14, LLVM 8.0.0, AMDGPU kernel driver, Mesa 19.0.1)
>
> Also experiencing hangs when running clinfo and other OpenCL software.
> Applying mentio
On Tue, Apr 9, 2019 at 10:56 AM Tomeu Vizoso wrote:
>
> On Mon, 8 Apr 2019 at 23:04, Rob Herring wrote:
> >
> > On Fri, Apr 5, 2019 at 7:30 AM Steven Price wrote:
> > >
> > > On 01/04/2019 08:47, Rob Herring wrote:
> > > > This adds the initial driver for panfrost which supports Arm Mali
> > > >
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Jonas
>Karlman
>Sent: Monday, April 8, 2019 3:51 PM
>To: Shankar, Uma ; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org
>Cc: seanp...@chromium.org; emil.l.veli...@gmail.
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 retu
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 calculation
HDR metadata requires a infoframe to be set. Due to fastset,
full modeset is not performed hence adding it to update_pipe
to handle that.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_ddi.c | 13 +
drivers/gpu/drm/i915/intel_hdmi.c | 7
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 rev
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 fo
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.
Added
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 --git
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.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sh
This patch enables modeset whenever HDR metadata
needs to be updated to sink.
v2: Addressed Shashank's review comments.
v3: Added Shashank's RB.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_atomic.c | 14 +-
d
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 a/drivers/gpu
Hoegeun Kwon writes:
> On 4/2/19 2:48 AM, Eric Anholt wrote:
>> Hoegeun Kwon writes:
>>
>>> There is a problem when often dpms goes from off to on. pm idle is not
>>> in sync and the problem occurs. Modify pm_runtime_put from
>>> asynchronous to synchronous.
>> Why would we need the power domain
https://bugs.freedesktop.org/show_bug.cgi?id=109692
--- Comment #29 from Andrey Grodzovsky ---
(In reply to mikhail.v.gavrilov from comment #28)
> And again deadlock occurred.
Yea, looks like another annoying regression. Try first of all to revert all the
3 patches i uploaded here and see if you
On 4/9/19 10:50 AM, Christian König wrote:
> Am 08.04.19 um 18:08 schrieb Andrey Grodzovsky:
>> Also reject TDRs if another one already running.
>>
>> Signed-off-by: Andrey Grodzovsky
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 94
>> +-
>> 1 file change
Rob Herring writes:
> On Mon, Apr 1, 2019 at 10:43 AM Eric Anholt wrote:
>>
>> Chris Wilson writes:
>>
>> > Quoting Daniel Vetter (2019-04-01 14:06:48)
>> >> On Mon, Apr 1, 2019 at 9:47 AM Rob Herring wrote:
>> >> > +{
>> >> > + int i, ret = 0;
>> >> > + struct drm_gem_object *obj;
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #34 from Talha Khan ---
(In reply to Alex Deucher from comment #33)
> (In reply to Talha Khan from comment #31)
> > I moved the raven_dcmu.bin file to another directory, but unfortunately I am
> > still unable to boot any kernel newe
https://bugs.freedesktop.org/show_bug.cgi?id=110347
--- Comment #4 from bednarczyk.pa...@outlook.com ---
For whatever reason the below configuration works fine:
OD_SCLK:
0:852Mhz800mV
1:979Mhz825mV
2: 1106Mhz850mV
3: 1233Mhz875mV
4:
Den 09.04.2019 13.59, skrev Gerd Hoffmann:
> Also add two conversion functions for the swab / not swab cases.
> That way we have to check the swab flag only once.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/drm_format_helper.c | 117 +++-
> 1 file changed,
On Tue, Apr 09, 2019 at 07:15:20PM +, Jim Zhang wrote:
> Ville:
>
> Yes, if this patch is needed by kernel 3.10.61, please get somebody to
> review it. What do I need do to speed up the review process?
> Please generate a patch against kernel 3.10.61 if possible.
3.10 is so ancient I don't
Hi Daniel/Dave,
The vmwgfx-next changes for 5.2:
Resource dirtying improvement by Thomas,
user-space error logging improvement and
some other minor fixes.
The following changes since commit 14d2bd53a47a7e1cb3e03d00a6b952734cf90f3f:
Merge tag 'drm-misc-next-2019-04-04' of
git://anongit.freedes
For a while, we've had the problem of i2c bus access not grabbing
a runtime PM ref when it's being used in userspace by i2c-dev, resulting
in nouveau spamming the kernel log with errors if anything attempts to
access the i2c bus while the GPU is in runtime suspend. An example:
[ 130.078386] nouve
Here's v3 of the panfrost driver. Lot's of changes from review comments
and further testing. Details are in each patch. Of note, a problem with
MMU page faults has been addressed improving the stability. In the
process, the TLB invalidate has been optimized which Tomeu says has
improved the perform
Similar to the single handle drm_gem_object_lookup(),
drm_gem_objects_lookup() takes an array of handles and returns an array
of GEM objects.
v2:
- Take the userspace pointer directly and allocate the array.
- Expand the function documentation.
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean P
ARM Mali midgard GPU is similar to standard 64-bit stage 1 page tables, but
have a few differences. Add a new format type to represent the format. The
input address size is 48-bits and the output address size is 40-bits (and
possibly less?). Note that the later bifrost GPUs follow the standard
64-b
Rob Herring writes:
> This adds the initial driver for panfrost which supports Arm Mali
> Midgard and Bifrost family of GPUs. Currently, only the T860 and
> T760 Midgard GPUs have been tested.
> +static int panfrost_ioctl_get_bo_offset(struct drm_device *dev, void *data,
> +
Eric Anholt writes:
> [ Unknown signature status ]
> Rob Herring writes:
>
>> This adds the initial driver for panfrost which supports Arm Mali
>> Midgard and Bifrost family of GPUs. Currently, only the T860 and
>> T760 Midgard GPUs have been tested.
>
>> +static int panfrost_ioctl_get_bo_offset
On Tue, 26 Mar 2019 12:47:39 -0400 jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> (Andrew this apply on top of my HMM patchset as otherwise you will have
> conflict with changes to mm/hmm.c)
>
> Changes since v5:
> - drop KVM bits waiting for KVM people to express interest if they
>
https://bugs.freedesktop.org/show_bug.cgi?id=108879
--- Comment #11 from Steffen Klee ---
cl-api-enqueue-copy-buffer passes when using the workaround.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
Hi Dave, Daniel:
This include stable MT2701 HDMI, framebuffer device and some fixes for
mediatek drm driver.
Regards,
CK
The following changes since commit
9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:
Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)
are available in the Git repository at:
https://g
https://bugs.freedesktop.org/show_bug.cgi?id=109181
babblebo...@gmail.com changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=110371
Bug ID: 110371
Summary: HP Dreamcolor display *Error* No EDID read
Product: DRI
Version: unspecified
Hardware: All
OS: Linux (All)
Status: NEW
Severity:
https://bugs.freedesktop.org/show_bug.cgi?id=109692
--- Comment #30 from mikhail.v.gavri...@gmail.com ---
Created attachment 143908
--> https://bugs.freedesktop.org/attachment.cgi?id=143908&action=edit
dmesg without patches
Without patches backtrace are looks like initial deadlock backtrace.
-
Not all archs have the __io_virt() macro, so cirrus can't simply convert
pointers that way. The drm format helpers have to use memcpy_toio()
instead.
This patch makes drm_fb_xrgb_to_rgb888_dstclip() accept a __iomem
dst pointer and use memcpy_toio() instead of memcpy(). The helper
function (
Not all archs have the __io_virt() macro, so cirrus can't simply convert
pointers that way. The drm format helpers have to use memcpy_toio()
instead.
This patch makes drm_fb_memcpy_dstclip() accept a __iomem dst pointer
and use memcpy_toio() instead of memcpy(). With that separating out the
memc
Not all archs have the __io_virt() macro, so cirrus can't simply convert
pointers that way. The drm format helpers have to use memcpy_toio()
instead.
This patch makes drm_fb_xrgb_to_rgb565_dstclip() accept a __iomem
dst pointer and use memcpy_toio() instead of memcpy(). The helper
function (
Turned out to be a bit more difficuilt than just adding the "asm/io.h"
header files. Not all architectures actually have a __io_virt() macro,
so cirrus can't depend on that. The drm format helpers have to call
memcpy_toio instead. So this little series add support for that.
v2: drop the drm_for
On Wed, Apr 10, 2019 at 01:17:19PM +1000, Alastair D'Silva wrote:
> @@ -107,7 +108,7 @@ EXPORT_SYMBOL(bin2hex);
> * string if enough space had been available.
> */
> int hex_dump_to_buffer(const void *buf, size_t len, int rowsize, int
> groupsize,
> -char *linebuf, size_t
101 - 163 of 163 matches
Mail list logo
