On 18.04.2018 14:19, Sandeep Panda wrote:
> Changelog:
>
> v3 -> v4:
> Current patchset separates out eDP panel specific resources from sn65dsi86
> bridge driver and creates a separate driver for the innloux edp panel.
>
> Now bridge driver check if any panel is attached or not to get the supported
On 17.12.2017 03:17, Laurent Pinchart wrote:
> Color keying is the action of replacing pixels matching a given color
> (or range of colors) with transparent pixels in an overlay when
> performing blitting. Depending on the hardware capabilities, the
> matching pixel can either become fully transpar
Quoting Sandeep Panda (2018-04-19 10:56:06)
> Document the bindings used for the sn65dsi86 DSI to eDP bridge.
>
> Changes in v1:
> - Rephrase the dt-binding descriptions to be more inline with existing
>bindings (Andrzej Hajda).
> - Add missing dt-binding that are parsed by corresponding dri
Hi Anusha,
Can I ask if this is on anyone's radar as I'm concerned this patch will
stall otherwise?
I see that the significance of testing with the 4.14 kernel enabled the
firmware to be included in the latest Chrome OS kernel (
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-os-r
On Wed, Apr 25, 2018 at 08:33:12AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote:
> > - dma api hides the cache flushing requirements from us. GPUs love
> > non-snooped access, and worse give userspace control over that. We want
> > a strict sep
Andrey Grodzovsky writes:
> On 04/25/2018 11:29 AM, Eric W. Biederman wrote:
>
>> Another issue is changing wait_event_killable to wait_event_timeout where I
>> need
>> to understand
>> what TO value is acceptable for all the drivers using the scheduler, or
>> maybe it
>> should come as a prop
Hello Laurent,
On 17.12.2017 03:17, Laurent Pinchart wrote:
> Hello,
>
> This patch series is an attempt at implementing standard properties for color
> keying support in the KMS API.
I was looking at implementing colorkey support for NVIDIA Tegra (older Tegra's
in particular) and Daniel Vetter
On 4/17/2018 5:13 PM, Sinan Kaya wrote:
> Tested-by: Sinan Kaya
>
> using QDF2400 and XFX Vega64 GPU for the first two patches.
>
> ./builddir/tests/amdgpu/amdgpu_test -s 1
>
> Suite: Basic Tests
> Test: Userptr Test ...passed
>
> Userptr Test fails without this patch.
I'm taking this back
On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote:
> On arm that doesn't work. The iommu api seems like a good fit, except
> the dma-api tends to get in the way a bit (drm/msm apparently has
> similar problems like tegra), and if you need contiguous memory
> dma_alloc_coherent is the on
On Tue, Apr 24, 2018 at 04:40:03PM +0100, Kieran Bingham wrote:
> Replace the initialisation of the vsps table with a NULL specifier.
>
> Fixes the following warning:
> linux/drivers/gpu/drm/rcar-du/rcar_du_kms.c:483:40:
> warning: Using plain integer as NULL pointer
> CC drivers/g
On Mon, Apr 23, 2018 at 2:04 PM, Robin Murphy wrote:
> I've given this a go on the nearest VExpress (with CA15_A7 tile) and sadly
> it doesn't quite work for me :( With the HDLCD driver configure out, the
> PL111 driver seems to repeatedly defer somewhere past
> pl111_versatile_init():
>
> root@j
I guess the first patch should be mergable. With the second, maybe it
is better to wait until we have a full solution including the bridges
too. What should I do to get the first patch merged?
The third version of these patches can be found here:
https://lists.freedesktop.org/archives/dri-devel/20
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 sure the drm device is unbound before
the panel driver becomes
Remove all drm_panel_detach() calls from all panel drives update the
kernel doc for drm_panel_detach().
Setting the connector and drm to NULL when the drm panel device is
going away hardly serves any purpose. Usually the the whole memory
structure is freed right after the remove call. However, cal
https://bugs.freedesktop.org/show_bug.cgi?id=105597
Marta Löfstedt changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=105597
Marta Löfstedt changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=105610
Marta Löfstedt changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=105610
Marta Löfstedt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=105618
Marta Löfstedt changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=105618
Marta Löfstedt changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=105617
Marta Löfstedt changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=105617
Marta Löfstedt changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=105589
Marta Löfstedt changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=105589
Marta Löfstedt changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=103769
--- Comment #16 from letha...@gmail.com ---
I've done some more tests, the games all start more or less correctly on
fedora 28. Still several "display bugs" like flickering screen or so, but they
do start. Even it segfaults at the end, it's bett
A buffer object leak was introduced when fixing a premature buffer
object release. Fix this.
Cc:
Fixes: 73a88250b709 ("Fix a destoy-while-held mutex problem.")
Signed-off-by: Thomas Hellstrom
Reviewed-by: Deepak Rawat
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 1 +
1
At least since the atomic port, the vmwgfx fbdev code is taking
a number of unnecessary modeset locks. In particular the
kms_set_config() function will grab its own locks, leading to
locking retries. So avoid drm_modeset_lock_all() and instead
provide a local acquire context for kms_set_config(). A
With the previous patch drm_atomic_helper_check_plane_state correctly
calculates clipping and the xf86-video-intel ddx is fixed to fall back
to GPU correctly when SetPlane fails, we can remove the hack where
we try to pan/zoom when out of min/max scaling range. This was already
poor behavior where
No matter how you perform the clip adjustments, a small
error may push the scaling factor to the other side of
0x1. Solve this with a macro that will fixup the
scale to 0x1 if we accidentally wrap to the other side.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_rect.c | 65 +++
When calculating limits we want to be as pessimistic as possible,
so we have to explicitly say whether we want to round up or down
to accurately calculate whether we are below min_scale or above
max_scale.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_rect.c | 17 -
1
https://bugs.freedesktop.org/show_bug.cgi?id=104082
--- Comment #45 from Michel Dänzer ---
(In reply to ojab from comment #43)
> I'm not sure if it's another issue [...]
It is, please file your own report.
--
You are receiving this mail because:
You are the assignee for the bug.___
Hi Greg,
On 19/04/2018 10:27, Greg KH wrote:
> On Thu, Apr 19, 2018 at 10:18:35AM +0200, Neil Armstrong wrote:
>> Hi Greg,
>>
>> On 23/02/2018 12:44, Neil Armstrong wrote:
>>> The Amlogic Meson GX SoCs, embedded the v2.01a controller, has been also
>>> identified needing this workaround.
>>> This
https://bugs.freedesktop.org/show_bug.cgi?id=106245
Bug ID: 106245
Summary: Raven ridge (2400g) fails to start (swiotlb buffer is
full) with IOMMU disabled
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=104082
--- Comment #46 from ojab ---
Done, https://bugs.freedesktop.org/show_bug.cgi?id=106245
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@l
https://bugs.freedesktop.org/show_bug.cgi?id=106225
Michel Dänzer changed:
What|Removed |Added
CC||harry.wentl...@amd.com
--- Comment #3 f
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #4 from Michel Dänzer ---
Maybe you can try enabling KASAN and see if that catches anything earlier.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
On Thu, Apr 26, 2018 at 10:38:08AM +0200, Neil Armstrong wrote:
> Hi Greg,
>
> On 19/04/2018 10:27, Greg KH wrote:
> > On Thu, Apr 19, 2018 at 10:18:35AM +0200, Neil Armstrong wrote:
> >> Hi Greg,
> >>
> >> On 23/02/2018 12:44, Neil Armstrong wrote:
> >>> The Amlogic Meson GX SoCs, embedded the v2
On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote:
> > get_required_mask() is supposed to tell you if you are safe. However
> > we are missing lots of implementations of it for iommus so you might get
> > some false negatives, improvements welcome. It's been on my list of
> > things t
On Wed, Apr 25, 2018 at 11:54:43PM +0100, Russell King - ARM Linux wrote:
>
> if the memory was previously dirty (iow, CPU has written), you need to
> flush the dirty cache lines _before_ the GPU writes happen, but you
> don't know whether the CPU has speculatively prefetched, so you need
> to flu
On Thu, Apr 26, 2018 at 1:26 AM, Russell King - ARM Linux
wrote:
> On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote:
>> On arm that doesn't work. The iommu api seems like a good fit, except
>> the dma-api tends to get in the way a bit (drm/msm apparently has
>> similar problems like t
On Thu, Apr 26, 2018 at 12:54 AM, Russell King - ARM Linux
wrote:
> On Wed, Apr 25, 2018 at 08:33:12AM -0700, Christoph Hellwig wrote:
>> On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote:
>> > - dma api hides the cache flushing requirements from us. GPUs love
>> > non-snooped access
On Thu, Apr 26, 2018 at 11:20:44AM +0200, Daniel Vetter wrote:
> The above is already what we're implementing in i915, at least
> conceptually (it all boils down to clflush instructions because those
> both invalidate and flush).
The clwb instruction that just writes back dirty cache lines might
b
Hi Dave,
And welcome back! Hope you had a good one.
We got a few -rc2 induced 3rd party bugs to CI (but that's nowadays
more the rule than an exception), but other than that the results look
solid.
Main thing are the fixes for the user reported black screen (DP MST)
and HDA codec interop issues
On Thu, Apr 26, 2018 at 11:24 AM, Christoph Hellwig wrote:
> On Thu, Apr 26, 2018 at 11:20:44AM +0200, Daniel Vetter wrote:
>> The above is already what we're implementing in i915, at least
>> conceptually (it all boils down to clflush instructions because those
>> both invalidate and flush).
>
>
On Thu, Apr 26, 2018 at 11:09 AM, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote:
>> > get_required_mask() is supposed to tell you if you are safe. However
>> > we are missing lots of implementations of it for iommus so you might get
>> > some false negat
On Thu, Apr 26, 2018 at 12:56 AM, Stéphane Marchesin
wrote:
> On Tue, Apr 24, 2018 at 6:04 AM, Daniel Vetter wrote:
>> On Fri, Apr 20, 2018 at 09:55:32AM -0400, Sean Paul wrote:
>>> On Fri, Apr 20, 2018 at 01:50:01PM +0200, Emil Lundmark wrote:
>>> > This fixes a NULL pointer dereference that can
On Sunday, November 26, 2017 02:00:16 PM SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 26 Nov 2017 13:48:55 +0100
>
> Omit an extra message for a memory allocation failure in these functions.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus
On Sunday, November 26, 2017 01:19:17 PM SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 26 Nov 2017 13:08:43 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus El
On Monday, November 27, 2017 06:01:41 PM SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Mon, 27 Nov 2017 17:53:05 +0100
>
> Omit an extra message for a memory allocation failure in this function.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus El
On Sunday, November 26, 2017 09:42:49 PM SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 26 Nov 2017 21:16:30 +0100
>
> Omit an extra message for a memory allocation failure in these functions.
>
> This issue was detected by using the Coccinelle software.
>
> Signed-off-by: Markus
On Sunday, November 26, 2017 09:43:52 PM SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 26 Nov 2017 21:21:33 +0100
>
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a
On Sunday, November 26, 2017 11:18:26 AM SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 26 Nov 2017 10:22:37 +0100
>
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a
On Sunday, November 26, 2017 06:42:23 PM SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Sun, 26 Nov 2017 18:16:20 +0100
>
> Replace the specification of a data structure by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a
It's been a while since we introduced drm_dev{get/put} functions
to replace reference/unreference in drm subsystem for the
consistency purpose. So, with this patch, let's just replace
all current use cases of drm_dev_unref() with drm_dev_put and remove
the function itself.
Coccinelle was used for
Hi Vaishali,
Thank you for the patch.
On Thursday, 26 April 2018 13:28:19 EEST Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> al
Hi Kieran,
Thank you for the patch.
On Tuesday, 24 April 2018 18:39:42 EEST Kieran Bingham wrote:
> The symbol 'rcar_du_of_init' is defined by the rcar_du_of module header,
> but it is not included by the C implementation.
>
> Include the header to correctly define the function prototypes.
>
>
Hi Kieran,
Thank you for the patch.
On Tuesday, 24 April 2018 18:40:03 EEST Kieran Bingham wrote:
> Replace the initialisation of the vsps table with a NULL specifier.
>
> Fixes the following warning:
> linux/drivers/gpu/drm/rcar-du/rcar_du_kms.c:483:40:
> warning: Using plain integer as NU
On Mon, Feb 26, 2018 at 10:23:00AM -0800, Doug Anderson wrote:
> Hi,
>
> On Thu, Feb 8, 2018 at 9:48 AM, Sean Paul wrote:
> > This patch adds an override mode for kevin devices. The mode increases
> > both back porches to allow a pixel clock of 2kHz as opposed to the
> > 'typical' value of 25
On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> all current use cases of drm_dev_unref()
On Wed, Apr 25, 2018 at 08:18:15AM -0700, Christoph Hellwig wrote:
> The series seems to miss a cover letter.
>
> Also I really think this patch original patch shouldn't be in the proper
> series.
I added a note explaining why I included this. Not everyone in this
discussion had seen the patch an
On Wed, Apr 25, 2018 at 08:19:34AM -0700, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 12:10:48PM +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > The dma_iommu_detach_device() API can be used by drivers to forcibly
> > detach a device from an IOMMU that architecture code might
On Wed, Apr 25, 2018 at 08:20:49AM -0700, Christoph Hellwig wrote:
> > +void arch_iommu_detach_device(struct device *dev)
> > +{
> > +#ifdef CONFIG_ARM_DMA_USE_IOMMU
> > + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
> > + const struct dma_map_ops *dma_ops;
> > +
> > + if (!
On Thu, 26 Apr 2018 15:58:19 +0530
Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> all current use cases of drm_dev_unref() with
On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> It's been a while since we introduced drm_dev{get/put} functions
> to replace reference/unreference in drm subsystem for the
> consistency purpose. So, with this patch, let's just replace
> all current use cases of drm_dev_unref()
On Wed, Apr 25, 2018 at 09:28:49AM -0600, Jordan Crouse wrote:
> On Wed, Apr 25, 2018 at 12:10:47PM +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Depending on the kernel configuration, early ARM architecture setup code
> > may have attached the GPU to a DMA/IOMMU mapping that tran
Reviewed-by: Stanislav Lisovskiy
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
From: Intel-gfx [intel-gfx-boun...@lists.freedesktop.org] on behalf of
Lisovskiy, Stanislav [stanislav.liso
Hi Daniel,
On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
> On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
> > It's been a while since we introduced drm_dev{get/put} functions
> > to replace reference/unreference in drm subsystem for the
> > consistency purpose. S
On Thu, Apr 26, 2018 at 11:06:58AM +0300, Jyri Sarha wrote:
> I guess the first patch should be mergable. With the second, maybe it
> is better to wait until we have a full solution including the bridges
> too. What should I do to get the first patch merged?
I don't see a reason why patch 2 can't
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-4.15
head: 9556f93f18f7923978fb90f860c107fed9ca7f57
commit: 265083076187e619aa9176aeb05ad630013429b4 [1231/1759] drm/amd/display:
Hookup color management functions
smatch warnings:
drivers/gpu/drm/amd/amdgpu/../display/amdg
On Thu, Apr 26, 2018 at 6:15 PM, Laurent Pinchart
wrote:
> Hi Daniel,
>
> On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
>> On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
>> > It's been a while since we introduced drm_dev{get/put} functions
>> > to replace referen
On 26.04.2018 15:41, Thierry Reding wrote:
On Wed, Apr 25, 2018 at 09:28:49AM -0600, Jordan Crouse wrote:
On Wed, Apr 25, 2018 at 12:10:47PM +0200, Thierry Reding wrote:
From: Thierry Reding
Depending on the kernel configuration, early ARM architecture setup code
may have attached the GPU to
On Thu, Apr 26, 2018 at 03:59:04PM +0300, Mikko Perttunen wrote:
> On 26.04.2018 15:41, Thierry Reding wrote:
> > On Wed, Apr 25, 2018 at 09:28:49AM -0600, Jordan Crouse wrote:
> > > On Wed, Apr 25, 2018 at 12:10:47PM +0200, Thierry Reding wrote:
> > > > From: Thierry Reding
> > > >
> > > > Depen
On Sun, Dec 17, 2017 at 02:17:21AM +0200, Laurent Pinchart wrote:
> Color keying is the action of replacing pixels matching a given color
> (or range of colors) with transparent pixels in an overlay when
> performing blitting. Depending on the hardware capabilities, the
> matching pixel can either
On Thu, Apr 26, 2018 at 10:28:20AM +0200, Maarten Lankhorst wrote:
> No matter how you perform the clip adjustments, a small
> error may push the scaling factor to the other side of
> 0x1. Solve this with a macro that will fixup the
> scale to 0x1 if we accidentally wrap to the other side.
On Tue, Apr 24, 2018 at 3:32 AM, Türk, Jan wrote:
>> -Ursprüngliche Nachricht-
>> Von: Shawn Guo Gesendet: Montag, 23. April 2018 10:45
>> Re: [PATCH v3 5/6] ARM: dts: Add support for emtrion emCON-MX6 series
>>
>> On Fri, Apr 20, 2018 at 02:50:52PM +0200, jan.tu...@emtrion.com wrote:
>> >
On Thu, Apr 26, 2018 at 3:14 PM, Alexandre Belloni
wrote:
> Hi,
>
> On 26/04/2018 15:45:44+0300, Laurent Pinchart wrote:
>> Hi Daniel,
>>
>> On Thursday, 26 April 2018 15:36:15 EEST Daniel Vetter wrote:
>> > On Thu, Apr 26, 2018 at 03:58:19PM +0530, Vaishali Thakkar wrote:
>> > > It's been a while
https://bugs.freedesktop.org/show_bug.cgi?id=105284
--- Comment #8 from Harry Wentland ---
(In reply to Jon from comment #7)
> (In reply to Harry Wentland from comment #6)
> > Marking resolved as no longer an issue on recent mainline.
>
> Which commit fixes this? I merged in agd5f/drm-fixes-4.17
https://bugs.freedesktop.org/show_bug.cgi?id=106006
--- Comment #15 from Joel Sass ---
This bug has been fixed in this branch: h
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-4.17
brightness appears as normal after building the kernel from git.
Good job, and thanks.
--
You are r
https://bugs.freedesktop.org/show_bug.cgi?id=106006
Joel Sass changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=106159
--- Comment #14 from Joel Sass ---
Alex, I just rebooted to this kernel after building. This problem still exists,
but it's not a hard freeze!
I'll attach the dmesg showing the error.
--
You are receiving this mail because:
You are the assign
From: Thierry Reding
Building the driver in a configuration with !PM currently causes a
warning about these operations being unused. Mark them as such to shut
up the compiler.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/bridge/cdns-dsi.c | 4 ++--
1 file changed, 2 insertions(+), 2 delet
On Thu, Apr 26, 2018 at 10:28:20AM +0200, Maarten Lankhorst wrote:
> No matter how you perform the clip adjustments, a small
> error may push the scaling factor to the other side of
> 0x1. Solve this with a macro that will fixup the
> scale to 0x1 if we accidentally wrap to the other side.
https://bugs.freedesktop.org/show_bug.cgi?id=106159
--- Comment #15 from Joel Sass ---
Created attachment 139132
--> https://bugs.freedesktop.org/attachment.cgi?id=139132&action=edit
This is the dmesg from an ssh session after attaching a monitor to my MST hub
root@nope:~/errors# uname -a
Linu
https://bugs.freedesktop.org/show_bug.cgi?id=106159
--- Comment #16 from Joel Sass ---
Created attachment 139134
--> https://bugs.freedesktop.org/attachment.cgi?id=139134&action=edit
Here's the kernel .config I used for making the kernel
Key changes:
I added AMDGPU module, checked all 4 boxes
On Wed, Mar 14, 2018 at 05:12:14PM +0800, Lin Huang wrote:
> From: huang lin
>
> Refactor Innolux P079ZCA panel driver, let it support
> multi panel.
>
> Change-Id: If89be5e56dba8cb498e2d50c1bbeb0e8016123a2
When you send out a revised set of these patches, please drop the
Change-Id: line from t
On Mon, Mar 12, 2018 at 11:33:45PM +0200, Jyri Sarha wrote:
> 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,
On Mon, Mar 12, 2018 at 11:33:45PM +0200, Jyri Sarha wrote:
> 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,
From: Ville Syrjälä
An overeager sed has corrupted the drm_rect_rotation_inv()
documentation. Fix it up.
Looks like it wasn't entirely correct before the sed fail
either. We were missing _rect_ from the function names, which
also explains why the sed hit these by accident.
Signed-off-by: Ville
On Thu, Apr 26, 2018 at 03:58:53PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Building the driver in a configuration with !PM currently causes a
> warning about these operations being unused. Mark them as such to shut
> up the compiler.
>
> Signed-off-by: Thierry Reding
I'd so lov
On Mon, Apr 23, 2018 at 01:11:25PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 23, 2018 at 10:43:47AM +0530, Nautiyal, Ankit K wrote:
> >
> >
> > On 4/20/2018 7:37 PM, Ville Syrjälä wrote:
> > > On Fri, Apr 20, 2018 at 07:01:46PM +0530, Nautiyal, Ankit K wrote:
> > >> From: Ankit Nautiyal
> > >>
>
This is the exact same text as proposed&merged for igt:
https://patchwork.kernel.org/patch/10339739/
With one minor change: Both regular contributions to the kernel
overall and to userspace graphics counts. We've gained a few
committers in the past who are coming from arm-soc platform work and
si
On Thu, Apr 26, 2018 at 4:25 PM, Daniel Vetter wrote:
> This is the exact same text as proposed&merged for igt:
>
> https://patchwork.kernel.org/patch/10339739/
>
> With one minor change: Both regular contributions to the kernel
> overall and to userspace graphics counts. We've gained a few
> comm
From: "Leo (Sunpeng) Li"
The lines were removed as part of the original change. They may have
been missed during merge.
This is a fixup to:
committ 265083076187e619aa9176aeb05ad630013429b4
Author: Leo (Sunpeng) Li
Date: Fri Feb 2 10:18:56 2018 -0500
drm/amd/display: Hook
On Tue, Apr 03, 2018 at 01:30:00PM +0300, Robert Chiras wrote:
> Add support for the OLED display based on MIPI-DSI protocol from Raydium:
> RM67191.
>
> Signed-off-by: Robert Chiras
> ---
> .../bindings/display/panel/raydium,rm67191.txt | 55 ++
> drivers/gpu/drm/panel/Kconfig
On Thu, Apr 26, 2018 at 04:25:57PM +0200, Daniel Vetter wrote:
> This is the exact same text as proposed&merged for igt:
>
> https://patchwork.kernel.org/patch/10339739/
>
> With one minor change: Both regular contributions to the kernel
> overall and to userspace graphics counts. We've gained a
On Tue, Apr 03, 2018 at 01:30:01PM +0300, Robert Chiras wrote:
> From: Mirela Rabulea
>
> Do not hardcode pixel_format to 0x77 but calculate it from dsi->format.
> Report all the supported bus formats in get_modes:
> MEDIA_BUS_FMT_RGB888_1X24
> MEDIA_BUS_FMT_RGB666_1X18
>
From: Michel Dänzer
GFP_TRANSHUGE tries very hard to allocate huge pages, which can result
in long delays with high memory pressure. I have observed firefox
freezing for up to around a minute due to this while restic was taking
a full system backup.
Since we don't really need huge pages, use GFP
From: Michel Dänzer
When it's set, TTM tries to allocate huge pages if possible. Drivers
which can take advantage of huge pages should set it.
Drivers not setting this flag no longer incur any overhead related to
allocating or freeing huge pages.
Cc: sta...@vger.kernel.org
Signed-off-by: Michel
On Wed, Apr 04, 2018 at 11:57:14AM +0200, Maxime Ripard wrote:
> The LHR050H41 panel is the panel shipped with the BananaPi M2-Magic, and is
> based on the Ilitek ILI9881c Controller. Add a driver for it, modelled
> after the other Ilitek controller drivers.
>
> Signed-off-by: Maxime Ripard
> ---
On Thu, Apr 26, 2018 at 04:21:04PM +0200, Daniel Vetter wrote:
> On Thu, Apr 26, 2018 at 03:58:53PM +0200, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > Building the driver in a configuration with !PM currently causes a
> > warning about these operations being unused. Mark them as such t
1 - 100 of 184 matches
Mail list logo
