In function ‘radeon_process_i2c_ch’ a comparison of a u8 value against
255 is done. Since it is always false, change the signature of this
function to use an `int` instead, which match the type used in caller:
`radeon_atom_hw_i2c_xfer`.
Fix the following warning triggered with W=1:
CC [M] driv
This commit adds support for KOE's 5.7" display.
Signed-off-by: Lukasz Majewski
---
.../bindings/display/panel/koe,tx14d24vm1bpa.txt | 42 ++
drivers/gpu/drm/panel/panel-simple.c | 26 ++
2 files changed, 68 insertions(+)
create mode 100644
Docum
On Thu, Apr 12, 2018 at 03:42:32PM +0100, Ayan Kumar Halder wrote:
> In a situation when the reference count of the drm connector is greater than
> 1,
> the unbind function should not invoke drm_connector_cleanup as this will lead
> to an inconsistent state where the drm_crtc_state->connector_mask
Document the bindings used for the sn65dsi86 DSI to eDP bridge.
Signed-off-by: Sandeep Panda
---
.../bindings/display/bridge/ti,sn65dsi86.txt | 75 ++
1 file changed, 75 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
This patchset replaces the obsolete gpio config APIs
with gpiod APIs.
This patchset captures the bindings for bridge driver
in more detailed manner.
This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c
On 2018-04-12 06:33, Christian König wrote:
Am 12.04.2018 um 11:49 schrieb Lucas Stach:
Am Donnerstag, den 12.04.2018, 11:35 +0200 schrieb Christian König:
Am 12.04.2018 um 11:11 schrieb Lucas Stach:
Am Mittwoch, den 11.04.2018, 20:26 +0200 schrieb Christian König:
Am 11.04.2018 um 19:11 schr
Add support for TI's sn65dsi86 dsi2edp bridge chip.
The chip converts DSI transmitted signal to eDP signal,
which is fed to the connected eDP panel.
This chip can be controlled via either i2c interface or
dsi interface. Currently in driver all the control registers
are being accessed through i2c i
This driver is for the ASPEED BMC SoC's GFX display hardware. This
driver runs on the ARM based BMC systems, unlike the ast driver which
runs on a host CPU and is is for a PCIe graphics device that happens to
live in the BMC's silicon, but is otherwise available for use by the BMC.
The AST2500 sup
On Thu, Apr 12, 2018 at 09:33:33PM +0200, Mathieu Malaterre wrote:
> In function ‘radeon_process_i2c_ch’ a comparison of a u8 value against
> 255 is done. Since it is always false, change the signature of this
> function to use an `int` instead, which match the type used in caller:
> `radeon_atom_h
Hi Daniel,
2018년 03월 30일 23:11에 Daniel Stone 이(가) 쓴 글:
> Since drm_framebuffer can now store GEM objects directly, place them
> there rather than in our own subclass. As this makes the framebuffer
> create_handle and destroy functions the same as the GEM framebuffer
> helper, we can reuse those.
https://bugzilla.kernel.org/show_bug.cgi?id=199385
Bug ID: 199385
Summary: Lockup radeon :01:00.0: Packet0 not allowed!
Product: Drivers
Version: 2.5
Kernel Version: 4.15.15
Hardware: All
OS: Linux
Tree: M
Selecting CONFIG_HDMI for S390 is inappropriate - there is no real
graphic hardware on this architecture. The drm subsystem is only
enabled here for using the virtual graphics card "virtio-gpu". So
it should be possible to compile the drm subsystem also without
CONFIG_I2C. Tweak the Makefile to onl
Selecting CONFIG_HDMI for S390 is inappropriate - there is no real
graphic hardware on this architecture. The drm subsystem is only
enabled here for using the virtual graphics card "virtio-gpu". So
it should be possible to compile the drm subsystem also without
CONFIG_DRM. Let's move the related co
By enabling the DRM code for virtio-gpu on S390, you currently also get
all the code that is enabled by CONFIG_HDMI and CONFIG_I2C automatically.
This is quite ugly, since on S390, there is no HDMI and no I2C. Thus it
would be great if the DRM code could also be compiled without CONFIG_HDMI
and CON
Hi John,
On Thu, Apr 12, 2018 at 04:18:54PM -0700, John Stultz wrote:
> On Wed, Apr 11, 2018 at 8:22 AM, Alexandru Gheorghe
> wrote:
> > Flattening a scene in order to reduce memory consumption it's an idea
> > which had been floating around on irc and mailing list several times,
> > this patchse
This tries to align with the X.org communities's long-standing
tradition of trying to be an inclusive community and handing out
commit rights fairly freely.
We also tend to not revoke commit rights for people no longer
regularly active in a given project, as long as they're still part of
the large
Hi Inki,
On 13 April 2018 at 10:55, Inki Dae wrote:
> 2018년 03월 30일 23:11에 Daniel Stone 이(가) 쓴 글:
>> Since drm_framebuffer can now store GEM objects directly, place them
>> there rather than in our own subclass. As this makes the framebuffer
>> create_handle and destroy functions the same as the
https://bugzilla.kernel.org/show_bug.cgi?id=199357
Mathias Tillman (master.ho...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=96519
Timothy Arceri changed:
What|Removed |Added
Component|Mesa core |Drivers/Gallium/r300
Assignee
https://bugs.freedesktop.org/show_bug.cgi?id=64091
Timothy Arceri changed:
What|Removed |Added
Component|Mesa core |Drivers/Gallium/r600
Assignee
https://bugs.freedesktop.org/show_bug.cgi?id=70402
Timothy Arceri changed:
What|Removed |Added
Assignee|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
https://bugs.freedesktop.org/show_bug.cgi?id=42128
Timothy Arceri changed:
What|Removed |Added
Component|Mesa core |Drivers/DRI/i915
Assignee|mes
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #11 from Chí-Thanh Christopher Nguyễn ---
Created attachment 138824
--> https://bugs.freedesktop.org/attachment.cgi?id=138824&action=edit
dmesg from kernel 4.15 with cik_support=1 dc=1 dc_log=1
Going back to kernel 4.15 makes no d
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #12 from Chí-Thanh Christopher Nguyễn ---
So, with the additional dmesg output from kernel 4.15, the following appeared
interesting:
[ 43.356569] [drm] DC: create_links: connectors_num: physical:3, virtual:0
[ 43.356583] [drm] U
On Fri, Apr 13, 2018 at 05:30:04PM +0530, Jagan Teki wrote:
> On Wed, Apr 11, 2018 at 6:13 PM, Maxime Ripard
> wrote:
> > On Wed, Apr 04, 2018 at 11:57:08AM +0200, Maxime Ripard wrote:
> >> Hi,
> >>
> >> Here is an preliminary version of the MIPI-DSI support for the Allwinner
> >> SoCs.
> >>
> >>
https://bugs.freedesktop.org/show_bug.cgi?id=105880
Chí-Thanh Christopher Nguyễn changed:
What|Removed |Added
Summary|[dc][kabini] Cannot find|[dc] No support for LVDS
On second thought, I pushed this patchset here:
https://github.com/ARM-software/drm-hwcomposer/tree/scene_flattening_support
On Fri, Apr 13, 2018 at 10:52:55AM +0100, Alexandru-Cosmin Gheorghe wrote:
> Hi John,
>
> On Thu, Apr 12, 2018 at 04:18:54PM -0700, John Stultz wrote:
> > On Wed, Apr 11, 2
On Fri, 13 Apr 2018, Thomas Huth wrote:
> Selecting CONFIG_HDMI for S390 is inappropriate - there is no real
> graphic hardware on this architecture. The drm subsystem is only
> enabled here for using the virtual graphics card "virtio-gpu". So
> it should be possible to compile the drm subsystem a
https://bugs.freedesktop.org/show_bug.cgi?id=105945
--- Comment #1 from Timothy Arceri ---
I tried this game yesterday but it crashed entering the tutorial. Today I tried
again and it applied an update (no more crashing). The trees etc are displayed
fine for me using radeonsi git. But there are s
On Tue, Apr 10, 2018 at 03:00:01PM +0200, Boris Brezillon wrote:
> From: Boris Brezillon
>
> Document the bindings used for the Cadence DSI bridge.
>
> Signed-off-by: Boris Brezillon
> ---
> Hello Rob,
>
> I dropped your Acked-by because this version now documents the DPHY
> bindings.
>
> Reg
On Fri, Apr 13, 2018 at 11:40 AM, Thomas Huth wrote:
> By enabling the DRM code for virtio-gpu on S390, you currently also get
> all the code that is enabled by CONFIG_HDMI and CONFIG_I2C automatically.
> This is quite ugly, since on S390, there is no HDMI and no I2C. Thus it
> would be great if t
On 13.04.2018 16:32, Daniel Vetter wrote:
> On Fri, Apr 13, 2018 at 11:40 AM, Thomas Huth wrote:
>> By enabling the DRM code for virtio-gpu on S390, you currently also get
>> all the code that is enabled by CONFIG_HDMI and CONFIG_I2C automatically.
>> This is quite ugly, since on S390, there is no
On Fri, Apr 13, 2018 at 4:46 PM, Thomas Huth wrote:
> On 13.04.2018 16:32, Daniel Vetter wrote:
>> On Fri, Apr 13, 2018 at 11:40 AM, Thomas Huth wrote:
>>> By enabling the DRM code for virtio-gpu on S390, you currently also get
>>> all the code that is enabled by CONFIG_HDMI and CONFIG_I2C automa
dma_unmap_sg() should be called with the same number of entries
originally passed to dma_map_sg(), not the number it returned, which may
be fewer. Admittedly this driver probably never runs on non-coherent
architectures where getting that wrong could lead to data loss, but it's
always good to be co
https://bugs.freedesktop.org/show_bug.cgi?id=104391
--- Comment #6 from Andy Furniss ---
It seems that
HDMI has no sound after Panel power off/on
is the cause of the warnings.
I tested 4.18-wip, no sound of course but nothing in dmesg.
I then applied "HDMI has no sound after Panel power off/o
One needs to ensure that the crtcs are shutdown so that the
drm_crtc_state->connector_mask reflects that no connectors
are currently active. Further, it reduces the reference
count for each connector. This ensures that the connectors
and encoders can be cleanly removed either when _unbind
is called
On Wed, Apr 11, 2018 at 08:59:32AM +0300, Oleksandr Andrushchenko wrote:
> On 04/10/2018 08:26 PM, Dongwon Kim wrote:
> > On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko wrote:
> > > On 04/06/2018 09:57 PM, Dongwon Kim wrote:
> > > > On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleks
On Mon, Apr 09, 2018 at 05:15:08PM +0100, Brian Starkey wrote:
> Hi Daniel,
>
> On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote:
> > On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote:
> > > On Tue, Mar 27, 2018 at 01:09:36PM +0200, Daniel Vetter wrote:
> > > > On Tue, Mar 2
On Mon, Apr 09, 2018 at 12:25:57PM +0100, Emil Velikov wrote:
> On 9 April 2018 at 11:24, Emil Velikov wrote:
> > On 9 April 2018 at 09:26, Daniel Vetter wrote:
> >
> >>> - point drm_device::dev to the parent of the virtio_device
> >>> The biggest hack imaginable, if even possible.
> >>
> >> Wha
On Wed, Apr 11, 2018 at 01:57:15PM +0530, Ramalingam C wrote:
>
>
> On Monday 09 April 2018 01:58 PM, Daniel Vetter wrote:
> > On Fri, Apr 06, 2018 at 07:02:02PM +0300, Ville Syrjälä wrote:
> > > On Mon, Apr 02, 2018 at 02:35:42PM +0530, Ramalingam C wrote:
> > > >
> > > > On Thursday 29 March 2
On Mon, Apr 09, 2018 at 09:45:51AM +, Alexey Brodkin wrote:
> Hi Daniel,
>
> On Mon, 2018-04-09 at 11:17 +0200, Daniel Vetter wrote:
> > On Mon, Apr 09, 2018 at 08:55:36AM +, Alexey Brodkin wrote:
> > > Hi Daniel,
> > >
> > > On Mon, 2018-04-09 at 10:31 +0200, Daniel Vetter wrote:
> > > >
On Mon, Apr 09, 2018 at 12:43:07PM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> On Monday, 9 April 2018 12:18:28 EEST Daniel Vetter wrote:
> > On Mon, Apr 09, 2018 at 11:56:55AM +0300, Laurent Pinchart wrote:
> > > On Monday, 9 April 2018 11:53:07 EEST Daniel Vetter wrote:
> > >> On Fri, Apr 06
Hi Daniel,
On Fri, Apr 13, 2018 at 05:44:09PM +0200, Daniel Vetter wrote:
On Mon, Apr 09, 2018 at 05:15:08PM +0100, Brian Starkey wrote:
Hi Daniel,
On Mon, Apr 09, 2018 at 10:23:37AM +0200, Daniel Vetter wrote:
> On Fri, Apr 06, 2018 at 08:02:16PM +0100, Ayan Halder wrote:
> > On Tue, Mar 27,
On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
> Adding dri-devel, which I should've included from the start.
Top posting, because I'm lazy and was out sick ...
Few observations:
- Stéphane has a great point which seems to have been ignored thus far.
- Where's the VK extension fo
On Wed, Apr 11, 2018 at 09:32:16AM +0200, Simon Horman wrote:
> On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote:
> > The documentation was wrong, gpiod_get_direction() returns 0/1 instead
> > of the GPIOF_* flags. The docs were fixed with commit 94fc73094abe47
> > ("gpio: correct docs
Commit 51f7415039d4 ("drm/amd/amdgpu: creating two I2S instances for
stoney/cz") added support for the "BT_I2S" ACP i2s channel. As part of
this change, one additional acp resource was added, but the "num_resource"
count was accidentally incremented by 2.
This incorrect count eventually causes mf
On Fri, Apr 13, 2018 at 06:08:24PM +0200, Daniel Vetter wrote:
> On Wed, Apr 11, 2018 at 09:32:16AM +0200, Simon Horman wrote:
> > On Tue, Apr 10, 2018 at 02:32:40PM +0200, Wolfram Sang wrote:
> > > The documentation was wrong, gpiod_get_direction() returns 0/1 instead
> > > of the GPIOF_* flags. T
Hello,
small self review, as I've just noticed a trivial error.
On Tue, Apr 10, 2018 at 12:53:10PM +0200, Jacopo Mondi wrote:
> Add DRM bridge driver for Thine THC63LVD1024 LVDS to digital parallel
> output converter.
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Andrzej Hajda
> Reviewed-by:
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #14 from Alex Deucher ---
Please try attachment 138813 on bug 105996.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.f
https://bugzilla.kernel.org/show_bug.cgi?id=199385
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
From: David Herrmann
Rather than doing drm_file allocation/destruction right in the fops, lets
provide separate helpers. This decouples drm_file management from the
still-mandatory drm-fops. It prepares for use of drm_file without the
fops, both by possible separate fops implementations and APIs
This patchset explores the possibility of having generic fbdev emulation
in DRM for drivers that supports dumb buffers which they can export. An
API is added to support in-kernel clients in general.
In this version I was able to reuse the modesetting code from
drm_fb_helper in the client API. This
It only makes sense for userspace clients.
Signed-off-by: Noralf Trønnes
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_file.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index d4588d33f91c..5
For each enabled crtc the functions sets dpms on all registered connectors.
Limit this to only doing it once and on the connectors actually in use.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/dr
This the beginning of an API for in-kernel clients.
First out is a display representation that will be used by drm_fb_helper
in order to move out its mode setting code.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/drm_client.c | 119 +++
Getting rotation info is cheap so we can do it on demand.
This is done in preparation for the removal of struct drm_fb_helper_crtc.
Cc: Hans de Goede
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 131
include/drm/drm_fb_helper.h
Prepare to move the modeset committing code to drm_client.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 161
include/drm/drm_fb_helper.h | 8 ++
2 files changed, 89 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/
Atomic drivers can't use them so finish what was started in
commit 9c79e0b1d096 ("drm/fb-helper: Give up on kgdb for atomic drivers").
This prepares the ground for creating modesets on demand.
TODO:
- Actually remove the functions, not just the contents.
- Nuke drm_crtc_helper_funcs->mode_set_bas
Prepare for moving drm_fb_helper modesetting code to drm_client.
drm_client will be linked to drm.ko, so move
__drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config()
out of drm_kms_helper.ko.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_atomic.c| 168 +++
This moves the committing part of the modesetting code to drm_client.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c| 242
drivers/gpu/drm/drm_fb_helper.c | 216 +--
include/drm/drm_client.h| 8
Add functions to deal with the registred connectors as an array:
- drm_connector_get_all()
- drm_connector_put_all()
And to get the enabled status of those connectors:
drm_connector_get_enabled_status()
This is prep work to remove struct drm_fb_helper_connector.
Signed-off-by: Noralf Trønnes
--
Move them over from drm_fb_helper since they are connector functions.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_connector.c| 94 ++
drivers/gpu/drm/drm_fb_helper.c| 75 ++
drivers/gpu/drm/i915/intel_fbdev.c | 7
As part of moving the modesetting code out of drm_fb_helper and into
drm_client, the drm_fb_helper_funcs->initial_config callback needs to go.
Replace it with a drm_driver->initial_client_display callback that can
work for all in-kernel clients.
TODO:
- Add a patch that moves the function out of i
The modesetting code is already present, this adds the rest of the API.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c | 573 +
drivers/gpu/drm/drm_debugfs.c | 7 +
drivers/gpu/drm/drm_drv.c | 11 +
drivers/gpu/drm/drm_fi
Give clients easy access to the display modes.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c | 159 +--
include/drm/drm_client.h | 25 +++
2 files changed, 148 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/drm_clien
Avoid pinning the module when exporting a GEM object as a dmabuf. This
makes it possible to unload drivers that has in-kernel clients using it.
The client is removed on drm_dev_unregister() so no need to pin the driver.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_prime.c | 24 +
Make ioctl wrappers for functions that will be used by the in-kernel API.
The following functions are touched:
- drm_mode_create_dumb_ioctl()
- drm_mode_destroy_dumb_ioctl()
- drm_mode_addfb2()
- drm_mode_rmfb()
- drm_prime_handle_to_fd_ioctl()
drm_mode_addfb2() also gets the ability to override t
Call the function drm_client_find_display().
No functional change apart from making width/height arguments optional.
Some function name/signature changes and whitespace adjustments.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_client.c| 399
If there's a DRM master, return -EBUSY.
Block userspace from becoming master by taking the master lock while
the client is setting the mode.
Suggested-by: Daniel Vetter
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_auth.c | 33 +
drivers/gpu/drm/drm_
No need to maintain a list of registered connectors. Just use the
connector iterator.
TODO: Remove:
- drm_fb_helper_add_one_connector()
- drm_fb_helper_single_add_all_connectors()
- drm_fb_helper_remove_one_connector()
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 359
The stage is now set for a clean removal of drm_fb_helper_crtc.
struct drm_client_display is doing its job now.
Also remove the drm_fb_helper_funcs->initial_config which has been
superseded by drm_driver->initial_client_display.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c
These helpers keep track of fbdev users and drm_driver.last_close will
only restore fbdev when actually in use. Additionally the display is
turned off when the last user is closing. fbcon is a user in this context.
If struct fb_ops is defined in a library, fb_open() takes a ref on the
library (fb_
Argh, it didn't go through this time either.
I'll just have to strip off recipients and just send to the lists when
the cool off period is over.
Sorry about the noise, I'll have to investigate this further.
Noralf.
Den 13.04.2018 18.53, skrev Noralf Trønnes:
This patchset explores the possi
Hi Noralf,
1 comment inline.
On 13-04-18 18:53, Noralf Trønnes wrote:
Getting rotation info is cheap so we can do it on demand.
This is done in preparation for the removal of struct drm_fb_helper_crtc.
Cc: Hans de Goede
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/drm_fb_helper.c | 1
Hi Thomas,
On Wed, Apr 11, 2018 at 10:27:06AM +0200, Thomas Hellstrom wrote:
> Hi!
>
> Thinking of adding ww-mutexes for reservation also of vmwgfx resources,
> (like surfaces), I became a bit worried that doubling the locks taken during
> command submission wouldn't be a good thing. Particularly
On Mon, Apr 09, 2018 at 12:59:14PM +0200, Peter Rosin wrote:
> Start list of actual chips compatible with "lvds-encoder".
>
> Reviewed-by: Laurent Pinchart
> Signed-off-by: Peter Rosin
> ---
> .../devicetree/bindings/display/bridge/lvds-transmitter.txt | 8
> +++-
> 1 file changed, 7
On Mon, Apr 09, 2018 at 12:59:15PM +0200, Peter Rosin wrote:
> Useful for beating cases where an output mode selection heuristic
> fails.
>
> Signed-off-by: Peter Rosin
> ---
> Documentation/devicetree/bindings/display/atmel/hlcdc-dc.txt | 4
> 1 file changed, 4 insertions(+)
>
> diff --gi
On Mon, Apr 09, 2018 at 04:00:38PM -0700, Eric Anholt wrote:
> The GPU subsystem node was a workaround to have a central device to
> bind V3D and display to. Following the lead of 246774d17fc0
> ("drm/etnaviv: remove the need for a gpu-subsystem DT node"), remove
> the subsystem node usage and jus
On Tue, Apr 10, 2018 at 07:19:26AM +0200, Philippe Cornu wrote:
> Add the 3 optional power supplies using the exact description
> found in the document named
> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet (August 2016)".
>
> Signed-off-by: Philippe Cornu
> ---
> Documentation/devicetree/bindin
https://bugzilla.kernel.org/show_bug.cgi?id=199101
--- Comment #18 from Martin Babutzka (martin.babut...@web.de) ---
Okay the AMD devs reverted the corresponding commit in amd-staging-drm-next
(https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=fc0644eddd2d5f77aac44ad2ab5a
On Fri, Apr 13, 2018 at 1:23 AM Sandeep Panda wrote:
> Document the bindings used for the sn65dsi86 DSI to eDP bridge.
> Signed-off-by: Sandeep Panda
> ---
> .../bindings/display/bridge/ti,sn65dsi86.txt | 75
++
> 1 file changed, 75 insertions(+)
> create mode 100
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #15 from David Henningsson ---
(In reply to Michel Dänzer from comment #10)
> (In reply to David Henningsson from comment #8)
> > The regression is between 4.15rc2 and 4.15rc3
>
> Any chance you can bisect between these two?
I can,
On 2018-04-13 12:04 PM, Daniel Vetter wrote:
> On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
>> Adding dri-devel, which I should've included from the start.
>
> Top posting, because I'm lazy and was out sick ...
>
> Few observations:
> - Stéphane has a great point which seems to
On 2018-04-12 05:38 PM, Stéphane Marchesin wrote:
> On Tue, Apr 10, 2018 at 12:37 AM, Michel Dänzer wrote:
>> On 2018-04-10 08:45 AM, Christian König wrote:
>>> Am 09.04.2018 um 23:45 schrieb Manasi Navare:
Thanks for initiating the discussion. Find my comments below:
On Mon, Apr 09, 201
On Fri, Apr 13, 2018 at 10:53:00AM +0530, Sandeep Panda wrote:
> Add support for TI's sn65dsi86 dsi2edp bridge chip.
> The chip converts DSI transmitted signal to eDP signal,
> which is fed to the connected eDP panel.
>
> This chip can be controlled via either i2c interface or
> dsi interface. Cur
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #29 from MirceaKitsune ---
For the first time ever, I might finally have some very good news on this
issue! It will take several more days to confirm, then possibly another month
to pinpoint the exact option responsible. However it's
On 2018-04-13 06:00 AM, Daniel Vetter wrote:
> This tries to align with the X.org communities's long-standing
> tradition of trying to be an inclusive community and handing out
> commit rights fairly freely.
>
> We also tend to not revoke commit rights for people no longer
> regularly active in a
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #16 from Chí-Thanh Christopher Nguyễn ---
I tried with 4.16, made no difference. But as dc_log=1 on 4.16 gives no helpful
additional output, I will try on Monday with 4.15 again. It may also be
possible that I am affected both by the
On Tue, Apr 10, 2018 at 06:16:07PM -0700, Chandan Uddaraju wrote:
> For dual dsi mode, the horizontal timing needs
> to be divided by half since both the dsi controllers
> will be driving this panel. Adjust the pixel clock and
> DSI timing accordingly.
>
> Change-Id: Iee1226b2eef9eea23d9653e3d738e
On Tue, Apr 10, 2018 at 06:16:08PM -0700, Chandan Uddaraju wrote:
> Current DSI driver uses two connectors for dual DSI case even
> though we only have one panel. Fix this by implementing one
> connector/bridge for dual DSI use case. Use master DSI
> controllers to register one connector/bridge.
>
Hi, Daniel,
On 04/13/2018 07:13 PM, Daniel Vetter wrote:
Hi Thomas,
On Wed, Apr 11, 2018 at 10:27:06AM +0200, Thomas Hellstrom wrote:
Hi!
Thinking of adding ww-mutexes for reservation also of vmwgfx resources,
(like surfaces), I became a bit worried that doubling the locks taken during
comman
On Tue, Apr 10, 2018 at 06:54:06PM -0700, Abhinav Kumar wrote:
> Make sure the video mode engine is on before waiting
> for the video done interrupt.
>
> Otherwise it leads to silent timeouts increasing display
> turn ON time.
>
> Changes in v2:
> - Replace pr_err with dev_err
> - Changed error m
On Tue, Apr 10, 2018 at 06:54:07PM -0700, Abhinav Kumar wrote:
> Currently the DSI PHY timings are hard-coded for a specific panel
> for the 10nm PHY.
>
> Replace this with the auto PHY timing calculator which can calculate
> the PHY timings for any panel.
Any chance you could document what you'r
On Sat, Apr 07, 2018 at 12:06:53AM -0700, Abhinav Kumar wrote:
> Register truly panel as a backlight led device and
> provide methods to control its backlight operation.
>
> Signed-off-by: Abhinav Kumar
> ---
> drivers/gpu/drm/panel/panel-truly-dual-dsi.c | 96
> +++-
>
On 2018-04-13 13:29, Sean Paul wrote:
On Tue, Apr 10, 2018 at 06:54:07PM -0700, Abhinav Kumar wrote:
Currently the DSI PHY timings are hard-coded for a specific panel
for the 10nm PHY.
Replace this with the auto PHY timing calculator which can calculate
the PHY timings for any panel.
Any chan
Hi Sean
Thanks for the comments.
Some replies inline.
On 2018-04-13 13:46, Sean Paul wrote:
On Sat, Apr 07, 2018 at 12:06:53AM -0700, Abhinav Kumar wrote:
Register truly panel as a backlight led device and
provide methods to control its backlight operation.
Signed-off-by: Abhinav Kumar
---
Hi Sean
Thanks for the review.
Reply inline.
On 2018-04-13 13:26, Sean Paul wrote:
On Tue, Apr 10, 2018 at 06:54:06PM -0700, Abhinav Kumar wrote:
Make sure the video mode engine is on before waiting
for the video done interrupt.
Otherwise it leads to silent timeouts increasing display
turn O
On Tue, Apr 10, 2018 at 12:53:09PM +0200, Jacopo Mondi wrote:
> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Andrzej Hajda
> Reviewed-by: Niklas Söderlund
> Reviewed-by: Laurent Pinchart
> ---
> .../bindings/display/bridge/thine
https://bugs.freedesktop.org/show_bug.cgi?id=106038
Bug ID: 106038
Summary: visual corruption and stuttery playback of VC-1
interlaced video with VAAPI and Polaris
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. Switch to a constant value that covers all hardware.
[1] https://lkml.org/lkml/2018/3/7/621
Reviewed-by: Felix Kuehling
Acked-by: Christian König
Signed-off-by: Laura Abbott
---
v3: Introduced a #define f
1 - 100 of 112 matches
Mail list logo
