Hi Jordan,
Thanks for the review. Will incorporate the suggested changes in v2.
On 03/12/2018 08:43 PM, Jordan Crouse wrote:
On Mon, Mar 12, 2018 at 06:53:11PM +0530, Sibi S wrote:
Add dsi host helper function implementation for DSI v2
and DSI 6G 1.x controllers
Signed-off-by: Sibi S
---
dr
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #184 from Chris Heald ---
Created attachment 138059
--> https://bugs.freedesktop.org/attachment.cgi?id=138059&action=edit
dmesg output
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=91880
Chris Heald changed:
What|Removed |Added
CC||che...@gmail.com
--- Comment #183 from Chr
https://bugs.freedesktop.org/show_bug.cgi?id=91880
--- Comment #182 from Chris Heald ---
Just adding a data point here, I've got an MSI R9 390 running on Ubuntu 18.04
on 4.15.0-10-generic - I haven't had any stability issues, but I have had
maddening screen flickering/corruption.
I'm running dua
Hi all,
After merging the drm tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c: In function
'smu7_notify_link_speed_change_after_state_change':
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:3830:7: err
On Monday 12 March 2018 06:53 PM, Sibi S wrote:
From: Archit Taneja
I'm a bit uncertain about using this patch in its current state.
Some reasons below.
Add command broadcast support for DSI 6G v2.0+ controller
on SDM845
Signed-off-by: Sibi S
---
drivers/gpu/drm/msm/dsi/dsi.h
On Monday 12 March 2018 06:53 PM, Sibi S wrote:
Replace version checks with the helper functions bound to
cfg_handler for DSI v2 and DSI 6G 1.x controllers
With the ops set up for DSI6G 2.x too:
Reviewed-by: Archit Taneja
Thanks,
Archit
Signed-off-by: Sibi S
---
drivers/gpu/drm/msm/d
On Monday 12 March 2018 06:53 PM, Sibi S wrote:
Add dsi host helper function implementation for DSI v2
and DSI 6G 1.x controllers
Signed-off-by: Sibi S
---
drivers/gpu/drm/msm/dsi/dsi.h | 15 +++
drivers/gpu/drm/msm/dsi/dsi_cfg.c | 44 +--
drivers/gpu/drm/msm/dsi/dsi_host.c |
https://bugzilla.kernel.org/show_bug.cgi?id=199101
Kevin McCormack (wittyma...@yahoo.com) changed:
What|Removed |Added
Regression|No |Yes
--
You are
https://bugzilla.kernel.org/show_bug.cgi?id=199101
Bug ID: 199101
Summary: AMDGPU Fury X random screen flicker on Linux kernel
4.16rc5
Product: Drivers
Version: 2.5
Kernel Version: 4.16rc5
Hardware: All
https://bugs.freedesktop.org/show_bug.cgi?id=102905
--- Comment #3 from Roland Scheidegger ---
(In reply to iive from comment #2)
> The problem that causes this bug is when the first half of the above code,
> changes the condition check in the second. Something that will not happen,
> if "cndge"
On 2018.03.12 12:43:58 +0100, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in gvt_err error message text.
>
> Signed-off-by: Colin Ian King
> ---
Thanks Colin, will pick up.
> drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(
On 2018-03-12 13:32, Sean Paul wrote:
On Thu, Mar 08, 2018 at 07:28:08PM -0800, abhin...@codeaurora.org
wrote:
On 2018-02-28 11:19, Sean Paul wrote:
> Now that all of the msm-specific goo is tucked safely away we can switch
> over to using the atomic helper commit directly. \o/
>
[Abhinav] Can w
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
between commit:
a0aaa03062be ("drm/amd/powerplay: fix power over limit on Fiji")
from the Linus' and commit:
a5278e511dce ("drm/amd/pp: Revert gfx/compute profile switch
Hey John,
Feel free to add my ACK.
Rob.
On 03/08/2018 11:08 PM, John Stultz wrote:
On Thu, Mar 8, 2018 at 3:16 AM, Robert Foss wrote:
Hey John,
This patch looks good to me.
I have yet to build it, and I haven't brought my HiKey960 up for testing
quite yet.
On 03/07/2018 12:19 AM, John S
The check before alone is not enough for a case where there is another
bug introduced so that
context->stream_count is not in sync with actual number of streams
across entire resource_context.
At least assert indeed should be there.
Andrey
On 03/12/2018 07:06 PM, Li, Roman wrote:
There is
There is a check just before for-loop that should ensure pipe_ctx is not null:
/* Only supports single display */
if (context->stream_count != 1)
return false;
To remove the subject warning - we can rather add an assert:
assert(pipe_ctx);
Thanks,
Roman
-Orig
https://bugs.freedesktop.org/show_bug.cgi?id=105426
Józef Kucia changed:
What|Removed |Added
Keywords||bisected
--
You are receiving this mail
Jason Ekstrand writes:
> On Fri, Feb 23, 2018 at 3:43 PM, Keith Packard wrote:
>
> Once we're sure that's what we want, create an MR against the spec that
> just adds enough to the XML to reserve your extension number. That will
> get merged almost immediately. Then make a second one with the
https://bugs.freedesktop.org/show_bug.cgi?id=105426
--- Comment #6 from i...@yahoo.com ---
> It looks like the same problem as bug 104668 and bug 104777.
> 4195eed961ccfe404ae81b9112189fc93a254ded fixes the problem.
Well, this is kind of expected, because the current git master does not have
that
On 03/12/2018 06:22 AM, David Binderman wrote:
hello there,
Source code is
for (i = 0; i < dc->res_pool->pipe_count; i++) {
if (res_ctx->pipe_ctx[i].stream) {
pipe_ctx = &res_ctx->pipe_ctx[i];
*pipe_idx = i;
break;
}
}
Inde
On Mon, 2018-03-12 at 15:05 -0700, Manasi Navare wrote:
> On Fri, Mar 09, 2018 at 04:32:31PM -0500, Lyude Paul wrote:
> > For a while we actually haven't had any way of retraining MST links with
> > fallback link parameters like we do with SST. While uncommon, certain
> > setups such as my Caldigit
On Fri, Mar 09, 2018 at 04:32:31PM -0500, Lyude Paul wrote:
> For a while we actually haven't had any way of retraining MST links with
> fallback link parameters like we do with SST. While uncommon, certain
> setups such as my Caldigit TS3 + EVGA MST hub require this since
> otherwise, they end up
https://bugs.freedesktop.org/show_bug.cgi?id=105423
--- Comment #3 from Andrey Grodzovsky ---
(In reply to Max from comment #2)
> Thanks to Nick Sarnie on Discord, he found that disable completely DC fix
> the issue.
>
> I fix it with "amdgpu.dc=0" in my grub.conf
Did you try latest kernel (4.
Add support for Three Five displays TFC S9700RTWV43TR-01B 800x480
panel with resistive touch found on TI's AM335X-EVM.
Signed-off-by: Jyri Sarha
Reviewed-by: Tomi Valkeinen
cc: Thierry Reding
---
.../display/panel/tfc,s9700rtwv43tr-01b.txt| 10 +
drivers/gpu/drm/panel/panel-sim
On Mon, 12 Mar 2018 21:55:50 +0100,
Lukas Wunner wrote:
>
> On Mon, Mar 12, 2018 at 05:54:47PM +0100, Daniel Vetter wrote:
> > On Sun, Mar 11, 2018 at 04:55:49PM +0100, Lukas Wunner wrote:
> > > > On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote:
> > > > > Modernize vga_switcheroo by u
On Fri, Mar 09, 2018 at 04:32:29PM -0500, Lyude Paul wrote:
> Unlike SST, MST can have far more then a single display hooked up on a
> single port. What this also means however, is that if the DisplayPort
> link to the top-level MST branch device becomes unstable then every
> single branch device a
https://bugs.freedesktop.org/show_bug.cgi?id=102553
--- Comment #11 from mercuriete ---
Created attachment 138045
--> https://bugs.freedesktop.org/attachment.cgi?id=138045&action=edit
fix null dereference
--
You are receiving this mail because:
You are the assignee for the bug.___
On Fri, Mar 09, 2018 at 04:32:31PM -0500, Lyude Paul wrote:
> @@ -6266,25 +6368,98 @@ static bool intel_edp_init_connector(struct intel_dp
> *intel_dp,
> return false;
> }
>
> +static void intel_dp_mst_retrain_link_work(struct work_struct *work)
> +{
Why do we need another work for this?
On Fri, Mar 09, 2018 at 04:32:28PM -0500, Lyude Paul wrote:
> When a DP MST link needs retraining, sometimes the hub will detect that
> the current link bw config is impossible and will update it's RX caps in
> the DPCD to reflect the new maximum link rate. Currently, we make the
> assumption that
On Fri, Mar 09, 2018 at 04:32:27PM -0500, Lyude Paul wrote:
> While having the modeset_retry_work in intel_connector makes sense with
> SST, this paradigm doesn't make a whole ton of sense when it comes to
> MST since we have to deal with multiple connectors. In most cases, it's
> more useful to ju
On Mon, Mar 12, 2018 at 05:54:47PM +0100, Daniel Vetter wrote:
> On Sun, Mar 11, 2018 at 04:55:49PM +0100, Lukas Wunner wrote:
> > > On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote:
> > > > Modernize vga_switcheroo by using a device link to enforce a runtime PM
> > > > dependency from
https://bugs.freedesktop.org/show_bug.cgi?id=105463
erhar...@mailbox.org changed:
What|Removed |Added
Summary|[r600] 4210 piglit |[r600g] 4210 piglit
https://bugs.freedesktop.org/show_bug.cgi?id=105463
--- Comment #3 from erhar...@mailbox.org ---
Created attachment 138043
--> https://bugs.freedesktop.org/attachment.cgi?id=138043&action=edit
coredumps collected from 'pigllit run all' crashes
--
You are receiving this mail because:
You are th
On Fri, Mar 09, 2018 at 04:32:28PM -0500, Lyude Paul wrote:
> When a DP MST link needs retraining, sometimes the hub will detect that
> the current link bw config is impossible and will update it's RX caps in
> the DPCD to reflect the new maximum link rate. Currently, we make the
> assumption that
On Tue, Mar 13, 2018 at 03:48:38AM +0800, kbuild test robot wrote:
> tree: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
> head: ab30b9c117f37f9f33bec6b92818e2b402791f54
> commit: ab30b9c117f37f9f33bec6b92818e2b402791f54 [4/4] drm/i915: Wrap
> engine->schedule in RCU locks for s
From: Ville Syrjälä
Now that the core makes sure that the pixel format is supported
by at least one plane, we can eliminate the hand rolled code for the
same thing in i915. The way we were doing was extremely inconvenient
because not only did you have to add the format to the plane's format
list,
From: Ville Syrjälä
To make life easier for drivers, let's have the core check that the
requested pixel format is supported by at least one plane when creating
a new framebuffer.
This eases the burden on drivers by making sure they'll never get
requests to create fbs with unsupported pixel forma
From: Ville Syrjälä
To make it possible for the core to check the fb pixel format and
modifier, we need to first ask the driver to deduce the modifier
when the request does not explicitly specify one.
Add a new .fb_modifier() hook for that purpose and convert i915
and vc4 to make use if it. All
On Thu, Mar 08, 2018 at 07:28:08PM -0800, abhin...@codeaurora.org wrote:
> On 2018-02-28 11:19, Sean Paul wrote:
> > Now that all of the msm-specific goo is tucked safely away we can switch
> > over to using the atomic helper commit directly. \o/
> >
> [Abhinav] Can we say something like "Move rem
On Fri, Mar 02, 2018 at 04:44:55PM -0800, Jeykumar Sankaran wrote:
> On 2018-02-28 11:19, Sean Paul wrote:
> > Remove release/output/retire fences from the dpu driver. These are
> > already available via drm core's OUT_FENCE property.
> >
> > Change-Id: Id4238d0b5457f2c8ee2e87bb7814e1850a573623
>
On Thu, Mar 08, 2018 at 05:59:11PM -0800, Jeykumar Sankaran wrote:
> On 2018-02-28 11:19, Sean Paul wrote:
> > Instead of subclassing atomic state, store driver private data in
> > private_obj/state. This allows us to remove the swap_state driver hook
> > for mdp5 and get closer to using the atomic
On Thu, Mar 08, 2018 at 05:08:03PM -0800, Jeykumar Sankaran wrote:
> On 2018-03-02 06:56, Sean Paul wrote:
> > On Thu, Mar 01, 2018 at 07:37:10PM -0500, Rob Clark wrote:
> > > On Thu, Mar 1, 2018 at 3:37 PM, wrote:
> > > > On 2018-03-01 07:27, Sean Paul wrote:
> > > >>
> > > >> On Wed, Feb 28, 20
On Thu, Mar 08, 2018 at 04:56:01PM -0800, Jeykumar Sankaran wrote:
> On 2018-02-28 11:18, Sean Paul wrote:
> > Instead, shuffle things around so we kickoff crtc after enabling encoder
> > during modesets. Also moves the vblank wait to after the frame.
> >
> > Change-Id: I16c7b7f9390d04f6050aa20e17
Den 12.03.2018 17.51, skrev Daniel Vetter:
On Thu, Mar 08, 2018 at 06:12:11PM +0100, Noralf Tr??nnes wrote:
Den 06.03.2018 09.56, skrev Daniel Vetter:
On Thu, Feb 22, 2018 at 09:06:50PM +0100, Noralf Tr??nnes wrote:
This adds an API for writing in-kernel clients.
TODO:
- Flesh out and comple
On 2018-03-12 03:37 PM, Daniel Vetter wrote:
> On Mon, Mar 12, 2018 at 7:17 PM, Felix Kuehling
> wrote:
>> On 2018-03-07 03:34 PM, Felix Kuehling wrote:
Again stop worrying about ioctl overhead, this isn't Windows. If you
can show the overhead as being a problem then address it, but I
>
https://bugs.freedesktop.org/show_bug.cgi?id=105426
--- Comment #5 from Józef Kucia ---
error: declarations for shader output `gl_BackSecondaryColor` are in
gl_PerVertex and gl_PerVertex
It looks like the same problem as bug 104668 and bug 104777.
4195eed961ccfe404ae81b9112189fc93a254ded fixes
On Fri, Mar 02, 2018 at 04:04:24PM -0800, jsa...@codeaurora.org wrote:
> On 2018-02-28 11:18, Sean Paul wrote:
> > Instead of duplicating whole swaths of atomic helper functions (which
> > are already out-of-date), just skip the encoder/crtc disables in the
> > .disable hooks.
> >
> > Change-Id: I
tree: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
head: ab30b9c117f37f9f33bec6b92818e2b402791f54
commit: ab30b9c117f37f9f33bec6b92818e2b402791f54 [4/4] drm/i915: Wrap
engine->schedule in RCU locks for set-wedge protection
config: i386-randconfig-x010-201810 (attached as .confi
On Mon, Mar 12, 2018 at 8:15 PM, Christian König
wrote:
> Am 12.03.2018 um 18:24 schrieb Daniel Vetter:
>>
>> On Fri, Mar 09, 2018 at 08:11:40PM +0100, Christian K??nig wrote:
>>>
>>> This set of patches adds an option invalidate_mappings callback to each
>>> DMA-buf attachment which can be filled
On Fri, Mar 09, 2018 at 11:49:44PM +, Atwood, Matthew S wrote:
> On Thu, 2018-03-08 at 09:22 +0200, Jani Nikula wrote:
> > On Wed, 07 Mar 2018, matthew.s.atw...@intel.com wrote:
> > >
> > > From: Matt Atwood
> > >
> > > DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme
> > > f
On Mon, Mar 12, 2018 at 7:17 PM, Felix Kuehling wrote:
> On 2018-03-07 03:34 PM, Felix Kuehling wrote:
>>> Again stop worrying about ioctl overhead, this isn't Windows. If you
>>> can show the overhead as being a problem then address it, but I
>>> think it's premature worrying about it at this sta
https://bugzilla.kernel.org/show_bug.cgi?id=197925
kwka...@gmx.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Am 12.03.2018 um 18:24 schrieb Daniel Vetter:
On Fri, Mar 09, 2018 at 08:11:40PM +0100, Christian K??nig wrote:
This set of patches adds an option invalidate_mappings callback to each
DMA-buf attachment which can be filled in by the importer.
This callback allows the exporter to provided the DM
Am 12.03.2018 um 18:07 schrieb Daniel Vetter:
On Fri, Mar 09, 2018 at 08:11:41PM +0100, Christian K??nig wrote:
[SNIP]
+/**
+ * dma_buf_invalidate_mappings - invalidate all mappings of this dma_buf
+ *
+ * @dmabuf:[in]buffer which mappings should be invalidated
+ *
+ * Informs all at
Thanks!
Reviewed-by: Sinclair Yeh
On Wed, Mar 07, 2018 at 11:33:22PM +0530, Himanshu Jha wrote:
> Use kasprintf instead of combination of kmalloc and sprintf. Also,
> remove the local variables used for storing the string length as they
> are not required now.
>
> Signed-off-by: Himanshu Jha
>
https://bugs.freedesktop.org/show_bug.cgi?id=105463
--- Comment #2 from erhar...@mailbox.org ---
Created attachment 138036
--> https://bugs.freedesktop.org/attachment.cgi?id=138036&action=edit
Xorg.0.log
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=105463
--- Comment #1 from erhar...@mailbox.org ---
Created attachment 138035
--> https://bugs.freedesktop.org/attachment.cgi?id=138035&action=edit
html summary from 'pigllit run all'
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=105463
Bug ID: 105463
Summary: [r600] 4210 piglit failures, 55 crashes, 14 warnings
on ppc (PCIe, ppc64, mesa-18.0.0_rc4)
Product: Mesa
Version: git
Hardware: PowerPC
On 2018-03-10 10:01 AM, Christian König wrote:
>> To accomodate those we need to
>> create a "hole" inside the process address space. This patchset have
>> a hack for that (patch 13 HACK FOR HMM AREA), it reserves a range of
>> device file offset so that process can mmap this range with PROT_NONE
>
Meson's compiler.has_header is completely useless, it only checks that a
header exists, not whether it's usable. This creates problems if a
header contains a conditional #error declaration, like so:
> #if __x86_64__
> # error "Doesn't work with x86_64!"
> #endif
Compiler.has_header will return tr
On 2018-03-07 03:34 PM, Felix Kuehling wrote:
>> Again stop worrying about ioctl overhead, this isn't Windows. If you
>> can show the overhead as being a problem then address it, but I
>> think it's premature worrying about it at this stage.
> I'd like syscall overhead to be small. But with recent
https://bugs.freedesktop.org/show_bug.cgi?id=104064
--- Comment #39 from taij...@posteo.de ---
(In reply to Harry Wentland from comment #38)
> Thanks, taijian. I'll queue the patch up for merge.
Hey, thank YOU for fixing this!
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=104064
--- Comment #38 from Harry Wentland ---
Thanks, taijian. I'll queue the patch up for merge.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-dev
https://bugs.freedesktop.org/show_bug.cgi?id=104064
--- Comment #37 from taij...@posteo.de ---
Ans suspend-to-ram and wake-up-again also works! That also was kinda buggy for
me ever since 4.15...
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=104064
--- Comment #36 from taij...@posteo.de ---
Also, here are my backlight devices:
[gunnar@alien-arch ~]$ ls /sys/class/backlight
insgesamt 0
drwxr-xr-x 2 root root 0 12. Mär 18:05 .
drwxr-xr-x 62 root root 0 12. Mär 18:05 ..
lrwxrwxrwx 1 root ro
https://bugs.freedesktop.org/show_bug.cgi?id=104064
--- Comment #35 from taij...@posteo.de ---
Created attachment 138032
--> https://bugs.freedesktop.org/attachment.cgi?id=138032&action=edit
dmesg output with the patch from comment #34
OK, I've recompiled the kernel with v2 of your patch (comme
On Mon, Mar 12, 2018 at 06:30:09PM +0100, Daniel Vetter wrote:
> On Sat, Mar 10, 2018 at 04:01:58PM +0100, Christian K??nig wrote:
[...]
> > > They are work underway to revamp nouveau channel creation with a new
> > > userspace API. So we might want to delay upstreaming until this lands.
> > > We
Hi Daniel,
On Mon, Mar 12, 2018 at 06:34:43PM +0100, Daniel Vetter wrote:
> On Sun, Mar 11, 2018 at 05:33:13PM -0600, Haneen Mohammed wrote:
> > This patch replace instances of drm_framebuffer_unreference with _put()
> > suffix, because it is shorter and consistent with the kernel use of
> > *_ge
On Sun, Mar 11, 2018 at 02:53:03PM +0100, Linus Walleij wrote:
> This adds the actual VGA DAC bridge that is used in the
> Versatile AB, and sets the mode to 640x480 VGA.
>
> The "clcd" clock was incorrectly named, the proper name
> (from bindings) is "clcdclk". So far drivers survived
> by just g
On Sun, Mar 11, 2018 at 05:33:13PM -0600, Haneen Mohammed wrote:
> This patch replace instances of drm_framebuffer_unreference with _put()
> suffix, because it is shorter and consistent with the kernel use of
> *_get/put() suffixes.
> This was done with the following Coccinelle script:
>
> @r@
> e
On Sun, Mar 11, 2018 at 02:53:02PM +0100, Linus Walleij wrote:
> The Versatile board can be equipped with a interface board
> just named "IB2". This was created in the early 2000s for
> prototyping GSM candybar phone form factor products.
>
> The IB2 board contains:
> - Cascaded interrupt controll
On Sun, Mar 11, 2018 at 02:53:01PM +0100, Linus Walleij wrote:
> The PL111 in the ARM reference platforms are connected to
> "panels" that are actually dumb VGA DAC connector bridges.
> Now that we can support the proper bridges in the DRM driver,
> fix this up.
>
> Cc: Liviu Dudau
> Cc: Mali DP
On Sun, Mar 11, 2018 at 02:52:57PM +0100, Linus Walleij wrote:
> The ARM Versatile and RealView platforms have enough support
> merged for v4.17/next that we can fully switch them all over to
> using the DRM PL111 driver instead of the old fbdev driver.
>
> Integrator and Versatile Express will fo
On Sat, Mar 10, 2018 at 04:01:58PM +0100, Christian K??nig wrote:
> Good to have an example how to use HMM with an upstream driver.
>
> Am 10.03.2018 um 04:21 schrieb jgli...@redhat.com:
> > This patchset adds SVM (Share Virtual Memory) using HMM (Heterogeneous
> > Memory Management) to the nouvea
On Sun, Mar 11, 2018 at 02:52:58PM +0100, Linus Walleij wrote:
> The PL111 in the ARM reference platforms are connected to
> "panels" that are actually dumb VGA DAC connector bridges.
> Now that we can support the proper bridges in the DRM driver,
> fix this up.
>
> Cc: Liviu Dudau
> Cc: Mali DP
Am Freitag, 9. März 2018, 23:22:51 CET schrieb Enric Balletbo i Serra:
> Hi,
>
> This patchset includes cleanups, improvements, and bug fixes for
> Rockchip DRM driver and PSR support.
>
> This new version is the same as before removing some of the patches
> already applied and fixing the Exynos
https://bugzilla.kernel.org/show_bug.cgi?id=199089
--- Comment #1 from naisa...@gmail.com ---
The two log lines related to `disp` are shown below:
```
nouveau :65:00.0: disp: outp 0x6541[0]: INIT_GENERIC_CONDITION:
unknown 0x07
nouveau :65:00.0: disp: outp 01:0006;0f84: link rate un
On Fri, Mar 09, 2018 at 08:11:40PM +0100, Christian K??nig wrote:
> This set of patches adds an option invalidate_mappings callback to each
> DMA-buf attachment which can be filled in by the importer.
>
> This callback allows the exporter to provided the DMA-buf content
> without pinning it. The r
https://bugzilla.kernel.org/show_bug.cgi?id=199089
Bug ID: 199089
Summary: nouveau :65:00.0: disp: outp 01:0006;0f84: link
rate unsupported by sink (displayport monitor
flickering)
Product: Drivers
Version: 2
On Fri, Mar 09, 2018 at 08:11:41PM +0100, Christian K??nig wrote:
> Each importer can now provide an invalidate_mappings callback.
>
> This allows the exporter to provide the mappings without the need to pin
> the backing store.
>
> Signed-off-by: Christian K??nig
> ---
> drivers/dma-buf/dma-bu
Am Freitag, 9. März 2018, 23:23:10 CET schrieb Enric Balletbo i Serra:
> From: zain wang
>
> If we failed disable psr, it would hang the display until next psr
> cycle coming. So we should restore psr->state when it failed.
>
> Cc: Tomasz Figa
> Signed-off-by: zain wang
> Signed-off-by: Dougla
https://bugs.freedesktop.org/show_bug.cgi?id=105426
--- Comment #4 from Emil Velikov ---
Bisecting the issue to the offending commit would be a good move.
A small shader test [1] for piglit will also be a nice move. Thus one can
easily reproduce and + ensure it doesn't happen in the future ;-)
On Mon, Mar 12, 2018 at 01:18:44PM +0200, Joonas Lahtinen wrote:
> Hi Fengguang,
>
> I think the original patch To+Cc (I added them) should receive these
> e-mails too even though they're for drm-next.
+1
What I don't understand is why this is happening there while
it is fixed on drm-intel-next
Am Freitag, 9. März 2018, 23:22:54 CET schrieb Enric Balletbo i Serra:
> From: zain wang
>
> There is a race between AUX CH bring-up and enabling bridge which will
> cause link training to fail. To avoid hitting it, don't change psr state
> while enabling the bridge.
>
> Cc: Tomeu Vizoso
> Cc:
Am Freitag, 9. März 2018, 23:22:52 CET schrieb Enric Balletbo i Serra:
> From: Yakir Yang
>
> Make sure the request PSR state takes effect in analogix_dp_send_psr_spd()
> function, or print the sink PSR error state if we failed to apply the
> requested PSR setting.
>
> Cc: 征增 王
> Cc: Stéphane M
Hi,
the subject is misleading I think, as this is touching only the generic
bridge code and not anything Rockchip-related, so should probably
be "drm/bridge"?
Am Freitag, 9. März 2018, 23:22:57 CET schrieb Enric Balletbo i Serra:
> From: zain wang
>
> We currently wait for the panel to mirror o
On Fri, Mar 09, 2018 at 12:54:43PM -0800, Eric Anholt wrote:
> Ville Syrjala writes:
>
> > From: Ville Syrj??l??
> >
> > Only create framebuffers with supported format/modifier combinations by
> > checking that at least one plane supports the requested combination.
> >
> > Using drm_any_plane_ha
On Sun, Mar 11, 2018 at 04:55:49PM +0100, Lukas Wunner wrote:
> On Tue, Mar 06, 2018 at 11:29:40AM +0100, Daniel Vetter wrote:
> > On Sat, Mar 03, 2018 at 10:53:24AM +0100, Lukas Wunner wrote:
> > > Modernize vga_switcheroo by using a device link to enforce a runtime PM
> > > dependency from an HDA
On Thu, Mar 08, 2018 at 06:12:11PM +0100, Noralf Tr??nnes wrote:
>
> Den 06.03.2018 09.56, skrev Daniel Vetter:
> > On Thu, Feb 22, 2018 at 09:06:50PM +0100, Noralf Tr??nnes wrote:
> > > This adds an API for writing in-kernel clients.
> > >
> > > TODO:
> > > - Flesh out and complete documentation
Am Freitag, 9. März 2018, 23:22:55 CET schrieb Enric Balletbo i Serra:
> From: zain wang
>
> Add a lock to vop to avoid disabling the crtc while waiting for a line
> flag while enabling psr. If we disable in the middle of waiting for the
> line flag, we'll end up timing out or worse.
>
> Signed-
Am Freitag, 9. März 2018, 23:22:53 CET schrieb Enric Balletbo i Serra:
> From: Sean Paul
>
> Now that the spinlocks and timers are gone, we can remove the psr
> worker located in rockchip's analogix driver and do the enable/disable
> directly. This should simplify the code and remove races on dis
On Friday, March 09, 2018 11:02:24 AM Emil Velikov wrote:
> On 9 March 2018 at 10:59, Eric Engestrom wrote:
> > On Thursday, 2018-03-08 11:39:49 -0600, Gustavo A. R. Silva wrote:
> >> In preparation to enabling -Wvla, remove VLA usage.
> >>
> >> Also, fixed as part of the directive to remove all V
https://bugs.freedesktop.org/show_bug.cgi?id=100759
--- Comment #6 from Nicola Mori ---
Wow, thanks! I finally can update from kernel 4.9.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@li
https://bugs.freedesktop.org/show_bug.cgi?id=102905
--- Comment #2 from i...@yahoo.com ---
Back when I discovered the bug, glennk suggested that this commit might be
involved:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=acef65503e79ce61a16bdba92462f0ed8a7b52c2
"r600g: fix abs() support on A
Hi Andrzej,
thanks for the detailed reply, much appreciated :)
On Mon, Mar 12, 2018 at 02:47:20PM +0100, Andrzej Hajda wrote:
> On 12.03.2018 13:30, jacopo mondi wrote:
> > Hi Andrzej,
> >
> > On Mon, Mar 12, 2018 at 10:07:27AM +0100, Andrzej Hajda wrote:
> >>
[snip]
> > I understand. The "t
Hi Thierry,
On 03/12/2018 09:04 AM, Thierry Reding wrote:
> On Fri, Mar 02, 2018 at 04:32:20PM +0100, Philippe Cornu wrote:
>> The Raydium Semiconductor Corporation RM68200 is a 5.5" 720x1280
>> TFT LCD panel connected using a MIPI-DSI video interface.
>>
>> Version 2:
>> - Add Rob Herring Reviewe
On Tuesday, February 06, 2018 06:04:24 PM Gustavo A. R. Silva wrote:
> Cast _pitch_ to u64 in order to give the compiler complete information
> about the proper arithmetic to use. Notice that this variable is
> being used in a context that expects an expression of type u64
> (64 bits, unsigned).
>
https://bugs.freedesktop.org/show_bug.cgi?id=104064
Harry Wentland changed:
What|Removed |Added
Attachment #138027|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=104064
--- Comment #33 from Harry Wentland ---
Created attachment 138027
--> https://bugs.freedesktop.org/attachment.cgi?id=138027&action=edit
[PATCH] Only register backlight device if embedded panel connected
Can you see if this help with the backl
1 - 100 of 187 matches
Mail list logo