https://bugs.freedesktop.org/show_bug.cgi?id=97909
Timothy Arceri changed:
What|Removed |Added
Status|NEEDINFO|RESOLVED
Resolution|---
Implement routines to estimate GPU busy time and fetching the
current frequency for the polling interval. This is required by
the devfreq framework which recommends a frequency change if needed.
The driver code then tries to set this new frequency on the GPU by
sending an Out Of Band(OOB) request
This patch series starts off with a bug fixes in devfreq code, followed by
refactoring the devfreq code needed for supporting different chipsets, and
ends with adding devfreq support for A6xx.
v2, v3: Addressed review comments from Jordan Crouse.
Sharat Masetty (4):
drm/msm: suspend devfreq on
Devfreq turns on and starts recommending power level as soon as it is
initialized. The GPU is still not powered on by the time the devfreq
init happens and this leads to problems on GPU's where register access
is needed to get/set power levels. So we start suspended and only restart
devfreq when
The devfreq framework requires the drivers to provide busy time estimations.
The GPU driver relies on the hardware performance counteres for the busy time
estimations, but different hardware revisions have counters which can be
sourced from different clocks. So the busy time estimation will be
Add a simple function to read 64 registers in the GMU domain
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index
https://bugs.freedesktop.org/show_bug.cgi?id=107744
--- Comment #2 from Christopher Snowhill ---
I guess I can report it to the Wine developers, if you think this compiler
error is occurring due to Wine translating the demo’s shaders incorrectly. I
don’t know that it would be the demo’s fault,
https://bugs.freedesktop.org/show_bug.cgi?id=107693
--- Comment #2 from Timothy Arceri ---
This is an odd one. The games rendering thread creates and uses a compat
profile but when it checks extensions it actually creates a core profile in
another thread.
It ends up failing to find
https://bugs.freedesktop.org/show_bug.cgi?id=107652
--- Comment #13 from mikhail.v.gavri...@gmail.com ---
Created attachment 141391
--> https://bugs.freedesktop.org/attachment.cgi?id=141391=edit
amdgpu_gem_info after
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107652
--- Comment #12 from mikhail.v.gavri...@gmail.com ---
Created attachment 141390
--> https://bugs.freedesktop.org/attachment.cgi?id=141390=edit
amdgpu_gem_info before
--
You are receiving this mail because:
You are the assignee for the
Hi Linus,
Regular fixes pull,
Mediatek is a bunch of fixes to their RDMA and Overlay engines.
i915 has some Cannonlake/Geminilake watermark workarounds, LSPCON fix,
HDCP free fix, audio fix and a ppgtt reference counting fix.
amdgpu has some SRIOV, Kasan, memory leaks and other misc fixes.
https://bugs.freedesktop.org/show_bug.cgi?id=107744
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=99857
--- Comment #10 from copperly ---
I downloaded kernel 4.18 and it seems to be working. (I must have looked crazy
opening and closing my laptop lid over and over again :) )
Thank you so much for your help
--
You are receiving this mail because:
Hello
During one of our internal tests, we ran into an issue where the
calculated refresh rate for the mode using the drm_mode_vrefresh() API
doesnt
match the theoretical value due to rounding.
552{ DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 31500, 640, 664,
553 704, 832, 0,
在 2018/8/31 5:12, Heiko Stuebner 写道:
To be able to have both internal subdrivers and external bridge
drivers as output endpoints of vops, add a function to be able
to distinguish these.
changes in v8:
- improved function documentation
- better error handling
- put calls for node and pdev
https://bugs.freedesktop.org/show_bug.cgi?id=107694
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
This patches add support rockchip RGB output, Some Rockchip CRTCs, like
rv1108 and px30 can directly output parallel and serial RGB data to panel
or to conversion chip.
So add a feature-bit for vops to mark the ability for these direct outputs
and add an internal encoder in that case, that can
From: Sandy Huang
Some Rockchip CRTCs, like rv1108 and px30, can directly output parallel
and serial RGB data to panel or conversion chip.
So add a feature-bit for vops to mark the ability for these direct
outputs and add an internal encoder in that case, that can attach to
bridge chipsor
To be able to have both internal subdrivers and external bridge
drivers as output endpoints of vops, add a function to be able
to distinguish these.
changes in v8:
- improved function documentation
- better error handling
- put calls for node and pdev references
changes in v6:
- added function to
From: Sandy Huang
Add this feature bit indicate px30 vop can directly output
parallel or serial rgb data.
Signed-off-by: Sandy Huang
Signed-off-by: Heiko Stuebner
---
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
From 1d6e6e327162c6965c6007f9a46ce51086a7a458 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B8ren=20Andersen?=
Date: Thu, 30 Aug 2018 20:48:57 +0200
Subject: [PATCH 1/1] panel-simple: add LOGIC Technologies panels
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Hi Philip
Thanks for the review comments.
I will fix them all in v7.
Thanks
Abhinav
On 2018-08-27 05:41, Philipp Zabel wrote:
Hi Abhinav,
I have a few comments below.
On Fri, 2018-08-17 at 19:06 -0700, Abhinav Kumar wrote:
From: "abhin...@codeaurora.org"
Add support for Truly NT35597
https://bugs.freedesktop.org/show_bug.cgi?id=107652
--- Comment #11 from Andrey Grodzovsky ---
I see from the log that your failure was on 0 order allocation (1 page) in zone
NORMAL but this ZONE still had enough 1 page blocks and even larger blocks to
fulfill your request so that strange.
The
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #34 from markusr...@gmail.com ---
I have exactly same in here. Youtube videos make the system crash randomly,
also it is happening without video playback. This bug is making whole system
worthless. I have run system ram memtests.
[
From 870ce6ea622ff6dc8c3119b36507f0df577c754b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=B8ren=20Andersen?=
Date: Thu, 30 Aug 2018 20:48:57 +0200
Subject: [PATCH 1/1] panel-simple: add LOGIC Technologies panels
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
NV_PRINTK is a macro that adds the "%s: ", nouveau_cli.name to
logging output.
Save a few KB by creating a specific function to add that name
and change the users of theh NV_PRINTK macros to use the new
logging function.
(size -t drivers/gpu/drm/nouveau/built-in.a x86/64 defconfig with nouveau)
Use a more common logging style and reduce object size by calling
the nouveau_cli_printk function.
(size -t drivers/gpu/drm/nouveau/built-in.a x86/64 defconfig with nouveau)
textdata bss dec hex filename
1736437 1084841048 1845969 1c2ad1 (TOTALS) (new)
1737254 108484
Reduces object size ~4kb
Joe Perches (2):
drm/nouveau: Add new logging function nv_cli_printk
drm/nouveau: Convert NV_PRINTK macros and uses to new nv_cli_ macros
drivers/gpu/drm/nouveau/nouveau_abi16.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_chan.c | 12 +++
On Thu, 2018-08-30 at 13:57 +0100, Lisovskiy, Stanislav wrote:
> On Wed, 2018-08-29 at 12:16 -0700, Dhinakaran Pandiyan wrote:
> >
> > On Wed, 2018-08-29 at 21:10 +0300, Ville Syrjälä wrote:
> > > On Wed, Aug 29, 2018 at 02:28:47PM +0300, Stanislav Lisovskiy
> > > wrote:
> > > >
On Thu, 2018-08-30 at 20:36 +0300, Ville Syrjälä wrote:
> On Thu, Aug 30, 2018 at 01:16:28PM -0400, Lyude Paul wrote:
> > It looks like that when we moved over to using
> > drm_connector_for_each_possible_encoder() in nouveau, that one rather
> > important part of this function got dropped by
On Thu, Aug 30, 2018 at 01:16:28PM -0400, Lyude Paul wrote:
> It looks like that when we moved over to using
> drm_connector_for_each_possible_encoder() in nouveau, that one rather
> important part of this function got dropped by accident:
>
> /* Right v here */
> for (i
It looks like that when we moved over to using
drm_connector_for_each_possible_encoder() in nouveau, that one rather
important part of this function got dropped by accident:
/* Right v here */
for (i = 0; nv_encoder = NULL, i < DRM_CONNECTOR_MAX_ENCODER; i++) {
https://bugs.freedesktop.org/show_bug.cgi?id=99857
--- Comment #9 from Andrey Grodzovsky ---
What i meant is i looked at the dmesg which was already attached to the ticket.
Anyway, as I said, even 4.15 is a bit old, so I would advise to give a try to
latest kernel. And if the problem is still
https://bugs.freedesktop.org/show_bug.cgi?id=99857
--- Comment #8 from copperly ---
How did you get my dmesg? I never posted it (I signed up for bugzilla just so I
could add to this thread, I have never used this before) and I was wondeering
if upgrading the kernel before it has been tested by
On Thu, Aug 30, 2018 at 10:45:11AM +0200, Linus Walleij wrote:
> On Thu, Aug 30, 2018 at 10:40 AM Russell King - ARM Linux
> wrote:
>
> > Well, as I've no idea what the issue is here, I can't do anything or
> > make any suggestions. I wasn't copied on the initial part of the
> > thread.
>
>
On Tue, Aug 28, 2018 at 05:39:57PM -0700, Jeykumar Sankaran wrote:
> Resource manager assigns hw_intf blocks for the encoder only on
> modeset. If queried for hw_intf objects during init, it will be
> NULL. Since hw_intf objects are needed only during encoder enable,
s/during/after/ it looks like
On Tue, Aug 28, 2018 at 05:39:56PM -0700, Jeykumar Sankaran wrote:
> Instead of iterating for hw ctrl per physical encoder, this
> patch moves the iterations and assignment to the virtual encoder.
>
Missing "Changes in" section as well as _why_ you're doing this in your
description.
>
On Tue, Aug 28, 2018 at 05:39:54PM -0700, Jeykumar Sankaran wrote:
> Identify slave-master encoders during initialization and enable
> the encoders explicitly as the current logic has redundant and
> ambiguous loops.
Please include a "Changes in vX" section so I don't need to figure it out
https://bugs.freedesktop.org/show_bug.cgi?id=107762
Bug ID: 107762
Summary: [Intel GFX CI] *ERROR* ring sdma0 timeout, signaled
seq=137, emitted seq=137
Product: DRI
Version: XOrg git
Hardware: Other
OS:
On Tue, Aug 28, 2018 at 05:39:50PM -0700, Jeykumar Sankaran wrote:
> Strip down debugfs support for misr data read on layer mixers
> and interfaces.
Could you please start explaining not only the what, but also the why? I'm
certain there's a very good reason for this change, however you don't
Hi Jacopo,
On 30/08/18 17:00, Kieran Bingham wrote:
> Hi Jacopo,
>
> On 22/08/18 08:21, Jacopo Mondi wrote:
>> The ESCR registers offset definition is confusing, as each channel is
>> equipped with an ESCR register instance, but the names suggest only ESCR and
>> ESCR2 are taken into account.
>>
https://bugs.freedesktop.org/show_bug.cgi?id=107689
--- Comment #6 from Andrey Grodzovsky ---
I noticed amdgpu :01:00.0: GPU pci config reset print, long before the
suspend. Did you manually trigger device reset before the suspend ?
--
You are receiving this mail because:
You are the
Hi Jacopo,
On 22/08/18 08:21, Jacopo Mondi wrote:
> The ESCR registers offset definition is confusing, as each channel is
> equipped with an ESCR register instance, but the names suggest only ESCR and
> ESCR2 are taken into account.
>
> Rename the offsets to a name that includes the channels
On Tue, Aug 28, 2018 at 04:02:15PM -0700, Jeykumar Sankaran wrote:
> DPU is broken with patch [1]. This patch cleans up few stale codes
> and fixes the DPU bug by using encoder type to identify displays.
>
> [1] https://patchwork.kernel.org/patch/10568269/
>
> Thanks.
>
> Jeykumar Sankaran (3):
Hi Dave,
Here's the first PR for 4.20 (Seth Rogan edition). It's super light compared to
most PRs after feature freeze. Perhaps we were all enjoying summer a bit too
much! Anyways, nothing controversial, tag description says it all.
drm-misc-next-2018-08-30:
drm-misc-next for 4.20:
UAPI
On Thu, Aug 30, 2018 at 08:06:48AM -0700, Radhakrishna Sripada wrote:
> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> level shifters etc. To workaround them we may need to drive the output
> at a lower bpc. Currently the user space does not have a way to limit
> the bpc. The
On 07/04/2018 10:00 AM, Gerd Hoffmann wrote:
On Wed, Jul 04, 2018 at 09:26:39AM +0200, Tomeu Vizoso wrote:
On 07/04/2018 07:53 AM, Gerd Hoffmann wrote:
On Tue, Jul 03, 2018 at 10:37:57AM +0200, Daniel Vetter wrote:
On Tue, Jul 03, 2018 at 09:53:58AM +0200, Gerd Hoffmann wrote:
A driver to
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Kishore Kadiyala
Cc: Manasi Navare
Cc: Stanislav Lisovskiy
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against
On 30.08.2018 14:32, Linus Walleij wrote:
> On Thu, Apr 26, 2018 at 10:07 AM Jyri Sarha wrote:
>
>> Add device_link from panel device (supplier) to drm device (consumer)
>> when drm_panel_attach() is called. This patch should protect the
>> master drm driver if an attached panel driver unbinds
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #46 from CheatCodesOfLife ---
Created attachment 141377
--> https://bugs.freedesktop.org/attachment.cgi?id=141377=edit
amd6.tar.gz and amd7.tar.gz with usual logs, 2 attempts
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=54133
--- Comment #13 from korbin.freed...@guilderlandschools.net ---
Created attachment 141376
--> https://bugs.freedesktop.org/attachment.cgi?id=141376=edit
Possible error messages relating to the bug
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=54133
--- Comment #12 from korbin.freed...@guilderlandschools.net ---
I dont understand why "attachment 2" was highlighted. sorry
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=54133
--- Comment #11 from korbin.freed...@guilderlandschools.net ---
Hello all, my RV610 gpu has issues when resuming. I usually get the screen i
posted. When that screen appears, the only solution ive found is to Ctrl+alt+f3
and reboot the system.
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #45 from CheatCodesOfLife ---
I've just tried it again a couple of times, and this time I'm sitting there
tailing (-f) the ddebug file and nothing is being added to it after GFX_
tail -f ~/ddebug_dumps/Cemu.13f.exe_1990_
v5: This is YUV444 packed format same as AYUV, but without alpha,
as supported by i915.
v6: Removed unneeded initializer for new XYUV format.
v7: Added is_yuv field initialization according to latest
drm_fourcc format structure initialization changes.
v8: Edited commit message to be
Introduced new XYUV scan-in format for framebuffer and
added support for it to i915(SkyLake+).
Stanislav Lisovskiy (2):
drm: Introduce new DRM_FORMAT_XYUV
drm/i915: Adding YUV444 packed format support for skl+
drivers/gpu/drm/drm_fourcc.c | 1 +
drivers/gpu/drm/i915/i915_reg.h
PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
specification.
v2: Edited commit message, removed redundant whitespaces.
v3: Fixed fallthrough logic for the format switch cases.
v4: Yet again fixed fallthrough logic, to reuse code from other case
labels.
v5: Started to
https://bugs.freedesktop.org/show_bug.cgi?id=54133
--- Comment #10 from korbin.freed...@guilderlandschools.net ---
Created attachment 141375
--> https://bugs.freedesktop.org/attachment.cgi?id=141375=edit
Screen when resuming on RV610 gpu
--
You are receiving this mail because:
You are the
On Thu, Aug 30, 2018 at 03:41:13PM +0300, Juha-Pekka Heikkila wrote:
> Preparations for enabling P010, P012 and P016 formats. These
> formats will extend NV12 for larger bit depths.
>
> (Sharma, Swati2): removed unnecessary checks, changed debug error message
> to be more generic.
>
>
On Thu, Aug 30, 2018 at 04:40:27PM +0300, Stanislav Lisovskiy wrote:
> PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
> specification.
>
> v2: Edited commit message, removed redundant whitespaces.
>
> v3: Fixed fallthrough logic for the format switch cases.
>
> v4: Yet again
PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
specification.
v2: Edited commit message, removed redundant whitespaces.
v3: Fixed fallthrough logic for the format switch cases.
v4: Yet again fixed fallthrough logic, to reuse code from other case
labels.
v5: Started to
v5: This is YUV444 packed format same as AYUV, but without alpha,
as supported by i915.
v6: Removed unneeded initializer for new XYUV format.
v7: Added is_yuv field initialization according to latest
drm_fourcc format structure initialization changes.
v8: Edited commit message to be
Introduced new XYUV scan-in format for framebuffer and
added support for it to i915(SkyLake+).
Stanislav Lisovskiy (2):
drm: Introduce new DRM_FORMAT_XYUV
drm/i915: Adding YUV444 packed format support for skl+
drivers/gpu/drm/drm_fourcc.c | 1 +
drivers/gpu/drm/i915/i915_reg.h
On Wed, 2018-08-29 at 12:16 -0700, Dhinakaran Pandiyan wrote:
>
> On Wed, 2018-08-29 at 21:10 +0300, Ville Syrjälä wrote:
> > On Wed, Aug 29, 2018 at 02:28:47PM +0300, Stanislav Lisovskiy
> > wrote:
> > > PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
> > > specification.
> > >
Add P010 definition, semi-planar yuv format where each component
is 16 bits 10 msb containing color value. First come Y plane [10:6]
followed by 2x2 subsampled Cr:Cb plane [10:6:10:6]
Add P012 definition, semi-planar yuv format where each component
is 16 bits 12 msb containing color value. First
Enabling of P010, P012 and P016 formats. These formats will
extend NV12 for larger bit depths.
(Sharma, Swati2) Rename glk format table to follow similar style as on skl.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_display.c | 24 +++-
Preparations for enabling P010, P012 and P016 formats. These
formats will extend NV12 for larger bit depths.
(Sharma, Swati2): removed unnecessary checks, changed debug error message
to be more generic.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_atomic.c | 3 +--
Add needed plane control flag definitions for P010, P012 and
P016 formats.
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f232178..2c959c8
https://bugs.freedesktop.org/show_bug.cgi?id=107377
--- Comment #4 from Martin Peres ---
I will also add the following (old issues) here, since the signature matches
and it stopped right after the actual fix was committed.
On Thu, Apr 26, 2018 at 10:07 AM Jyri Sarha wrote:
> Add device_link from panel device (supplier) to drm device (consumer)
> when drm_panel_attach() is called. This patch should protect the
> master drm driver if an attached panel driver unbinds while it is in
> use. The device_link should make
在 2018/8/30 19:09, Heiko Stuebner 写道:
The rk3188 has 2 vops not using iommus which only output directly
to a rgb interface per vop. So all other output modes like hdmi
are provided by external brige chips.
Signed-off-by: Heiko Stuebner
---
This depends on Sandy's + mine recent series enabling
https://bugs.freedesktop.org/show_bug.cgi?id=107748
Bug ID: 107748
Summary: [Intel GFX CI] couldn't schedule ib on ring
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
[SNIP]
+
+struct drm_syncobj_wait_pt {
+ struct drm_syncobj_stub_fence base;
+ u64 value;
+ struct rb_node node;
+};
+struct drm_syncobj_signal_pt {
+ struct drm_syncobj_stub_fence base;
+ struct dma_fence *signal_fence;
+ struct dma_fence *pre_pt_base;
+ struct
The rk3188 has 2 vops not using iommus which only output directly
to a rgb interface per vop. So all other output modes like hdmi
are provided by external brige chips.
Signed-off-by: Heiko Stuebner
---
This depends on Sandy's + mine recent series enabling direct
rgb outputs of specific vops.
Checks the pixel blending mode and plane alpha value when
do the plane_check. Mali DP supports blending the current plane
with the background either based on the pixel alpha blending
mode or by using the layer's alpha value, but not both at the
same time. If both case, plane_check will return
On 2018年08月30日 15:25, Christian König wrote:
Am 30.08.2018 um 05:50 schrieb zhoucm1:
On 2018年08月29日 19:42, Christian König wrote:
Am 29.08.2018 um 12:44 schrieb Chunming Zhou:
VK_KHR_timeline_semaphore:
This extension introduces a new type of semaphore that has an
integer payload
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.20-wip
head: d9997b64c52b70bd98c48f443f068253621d1ffc
commit: d617d4d73043bc4cbc316a7a1b4370fa5bc26a31 [99/248] drm/amd/powerplay:
new interfaces for overdrive vega20 sclk and mclk
config: parisc-allmodconfig (attached as .config)
Am 30.08.2018 um 08:45 schrieb Christian König:
[...]
>> or create their private instance.
>
> That doesn't sounds good. Drivers should not be allowed to create their
> own private instance of that.
OK, will be changed in the patchset.
Best regards
Thomas
>
> Thanks for doing this,
>
https://bugs.freedesktop.org/show_bug.cgi?id=103320
Lakshmi changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=103320
Lakshmi changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #64 from Peter Wu ---
(In reply to Thomas Martitz from comment #62)
> To recap, the original bug (panic with that particular backtrace) is also
> fixed for me.
In that case, it is probably better to open a new bug report (and refer
Op 28-08-18 om 12:42 schreef Mika Kahola:
> On Wed, 2018-08-15 at 12:08 +0200, Maarten Lankhorst wrote:
>> We now have infrastructure for generic enum handling. This will make
>> it easier
>> to write new tests without defining all enum constants beforehand.
>>
>> Changes since v1:
>> - Fix
https://bugs.freedesktop.org/show_bug.cgi?id=106639
--- Comment #10 from Daniel Drake ---
Thanks - that looks great! I don't see any glitch now.
There is still a flash during boot, presumably when it hands off from efifb to
amdgpu it's doing a modeset. But it's ultra quick and it doesn't feel
Hi!
There's neat series of patches on
https://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git/log/?h=droid4-pending-v4.19
They enable display support for my hardware. As you can imagine,
display is rather important for a cellphone.
Tomi, can you take the patches? I can resubmit
On Thu, Aug 30, 2018 at 10:40 AM Russell King - ARM Linux
wrote:
> Well, as I've no idea what the issue is here, I can't do anything or
> make any suggestions. I wasn't copied on the initial part of the
> thread.
Sorry about that, it was because the original patch only hit in
drivers/of/*.
I
On Wed, Aug 29, 2018 at 8:28 PM, Andrey Grodzovsky
wrote:
> Actually, I've just spotted this drm_dev_unplug, does it make sense to use
> it in our pci_driver.remove hook
>
> instead of explicitly doing drm_dev_unregister and drm_dev_put(dev) ?
>
> This way at least any following IOCTL will fail
On Wed, Aug 29, 2018 at 07:55:21AM +0200, Christoph Hellwig wrote:
> On Tue, Aug 28, 2018 at 03:14:14PM +0100, Russell King - ARM Linux wrote:
> > But yes, the fundamental fact is that AMBA devices don't have any
> > care about the differences between coherent and streaming DMA. The
> >
Am Mittwoch, 29. August 2018, 05:12:41 CEST schrieb Sandy Huang:
> This patches add support rockchip RGB output, Some Rockchip CRTCs, like
> rv1108 and px30 can directly output parallel and serial RGB data to panel
> or to conversion chip.
> So add a feature-bit for vops to mark the ability for
On Mon, Aug 27, 2018 at 04:39:50PM +0800, Chen-Yu Tsai wrote:
> Two patches from the R40 display pipeline support series weren't applied
> with the rest of the series. When they did get applied, the -rc6
> deadline for drm-misc-next had past, so they didn't get into 4.19-rc1
> with the rest of the
Host1x is getting attached to an implicit IOMMU DMA domain if
CONFIG_ARM_DMA_USE_IOMMU=y. Since Host1x driver manages IOMMU by
itself, Host1x device must be detached from the implicit domain using
arch-specific IOMMU-API.
Signed-off-by: Dmitry Osipenko
---
Changelog:
v2: Correctly placed the
The fault handler code is commented since v4.2.
If there is no plan to enable the fault handler
code in future, we can remove this dead code.
Signed-off-by: Souptick Joarder
Signed-off-by: Gerd Hoffmann
---
v2: corrected subject line
drivers/gpu/drm/virtio/virtgpu_ttm.c | 36
On 29-Aug-2018 3:36 AM, "Matthew Wilcox" wrote:
>
> On Tue, Aug 28, 2018 at 10:44:43PM +0530, Souptick Joarder wrote:
> > We have introduce a new return type vm_fault_t for
> > fault handler. Update the document for the same.
>
> Have you built the documentation and checked the html looks better
Use new return type vm_fault_t for fault handler.
Signed-off-by: Souptick Joarder
Signed-off-by: Gustavo Padovan
---
v2: Updated patch title
drivers/gpu/drm/vkms/vkms_drv.h | 2 +-
drivers/gpu/drm/vkms/vkms_gem.c | 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git
On Tue 2018-08-21 00:14:35, Dmitry Safonov wrote:
> Hi Petr, thanks for review,
>
> On Wed, 2018-08-15 at 17:10 +0200, Petr Mladek wrote:
> > On Tue 2018-07-03 23:56:28, Dmitry Safonov wrote:
> > > Currently ratelimit_state is protected with spin_lock. If the .lock
> > > is
> > > taken at the
Am 30.08.2018 um 08:48 schrieb Chunming Zhou:
That is certainly totally nonsense. dma_fence_enable_sw_signaling()
is the function who is calling this callback.
Signed-off-by: Chunming Zhou
Cc: Jason Ekstrand
Reviewed-by: Christian König
Acked-by: Daniel Vetter
If there are no objections
Am 30.08.2018 um 05:50 schrieb zhoucm1:
On 2018年08月29日 19:42, Christian König wrote:
Am 29.08.2018 um 12:44 schrieb Chunming Zhou:
VK_KHR_timeline_semaphore:
This extension introduces a new type of semaphore that has an
integer payload
identifying a point in a timeline. Such timeline
On Wednesday 01 August 2018 04:32 PM, Shankar, Uma wrote:
-Original Message-
From: C, Ramalingam
Sent: Saturday, July 14, 2018 8:45 AM
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
dan...@ffwll.ch; seanp...@chromium.org; Winkler, Tomas
; Usyskin, Alexander ;
On Thu, Aug 30, 2018 at 08:14:02AM +0200, Thomas Zimmermann wrote:
> Hi Gerd
>
> Am 09.08.2018 um 17:27 schrieb Gerd Hoffmann:
> >> diff --git a/drivers/gpu/drm/bochs/bochs_mm.c
> >> b/drivers/gpu/drm/bochs/bochs_mm.c
> >> index 39cd08416773..c9c7097030ca 100644
> >> ---
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #63 from Thomas Martitz ---
Maybe https://bugzilla.kernel.org/show_bug.cgi?id=156341 is related? I found a
related thread on the nouveau ML ("Rewriting Intel PCI bridge prefetch base
address bits solves nvidia graphics issues") that
1 - 100 of 114 matches
Mail list logo
