On 01.02.2017 08:44, Inki Dae wrote:
>
> 2017년 02월 01일 16:34에 Andrzej Hajda 이(가) 쓴 글:
>> On 01.02.2017 08:31, Inki Dae wrote:
>>> 2017년 01월 20일 15:52에 Andrzej Hajda 이(가) 쓴 글:
In some platforms there is attached another device to the end of HDMI.
The patch adds support for it.
>>> Andrzej,
2017년 02월 01일 17:12에 Andrzej Hajda 이(가) 쓴 글:
> On 01.02.2017 08:44, Inki Dae wrote:
>>
>> 2017년 02월 01일 16:34에 Andrzej Hajda 이(가) 쓴 글:
>>> On 01.02.2017 08:31, Inki Dae wrote:
2017년 01월 20일 15:52에 Andrzej Hajda 이(가) 쓴 글:
> In some platforms there is attached another device to the end of
On TM2/TM2e platforms HDMI output is connected to MHL bridge
SiI8620. To allow configure UltraHD modes on the bridge
and to eliminate unsupported modes this bridge should be
attached to drm_encoder implemented in exynos_hdmi.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c
On Tue, Jan 31, 2017 at 04:27:14PM -0800, Dave Hansen wrote:
> I added some printk()s all over and gathered a bit more information
> about what's going on. It looks like the display doesn't work until the
> drm connector code cleans up the *old* connector. For some reason, it
> isn't motivated to
Hi Liviu,
Am Dienstag, den 31.01.2017, 18:58 + schrieb Liviu Dudau:
> Commit 25d3db7600b8 ("mm, fs: reduce fault, page_mkwrite, and pfn_mkwrite
> to take only vmf") updated the etnaviv_gem_fault() function signature
> without updating the header file with the declaration.
>
There is already a
Am Dienstag, den 31.01.2017, 18:56 + schrieb Liviu Dudau:
> etnaviv_gem.h header gets included twice. Remove duplicate.
>
> Signed-off-by: Liviu Dudau
Thanks, applied to my tree.
> ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/
On Wed, Feb 01, 2017 at 10:26:08AM +0100, Lucas Stach wrote:
> Hi Liviu,
>
> Am Dienstag, den 31.01.2017, 18:58 + schrieb Liviu Dudau:
> > Commit 25d3db7600b8 ("mm, fs: reduce fault, page_mkwrite, and pfn_mkwrite
> > to take only vmf") updated the etnaviv_gem_fault() function signature
> > wit
On Tue, 31 Jan 2017, Eric Anholt wrote:
> Martin Peres writes:
>
>> Despite all the careful planing of the kernel, a link may become
>> insufficient to handle the currently-set mode. At this point, the
>> kernel should mark this particular configuration as being broken
>> and potentially prune th
Hi Andrey,
(by the way there's a typo in the subject)
On Monday 30 Jan 2017 19:42:23 Grodzovsky, Andrey wrote:
> On Monday, January 30, 2017 6:05 AM Laurent Pinchart wrote:
> > On Saturday 28 Jan 2017 21:26:49 Andrey Grodzovsky wrote:
> >> Allows using atomic flip helpers for drivers using ASYNC
On Tue, 31 Jan 2017, Manasi Navare wrote:
> On Thu, Jan 26, 2017 at 06:21:20PM +0100, Daniel Vetter wrote:
>> On Thu, Jan 26, 2017 at 02:37:28PM +0200, Martin Peres wrote:
>> > Despite all the careful planing of the kernel, a link may become
>> > insufficient to handle the currently-set mode. At t
Hi Andrey,
On 29.01.2017 03:26, Andrey Grodzovsky wrote:
> Swicth to use atomic helper.
> Start using actual user's given target_vblank value for flip
> instead of current value.
>
> v3:
> Update for movig pflip flags to crtc_state
>
> Change-Id: I25dae6d8c29de5d022a42aa99a18a32674b56cda
>
Gerri
All DPs have a COLORADJ matrix which is applied prior to output gamma.
Attach that to the CTM property. Also, ensure the input CTM's coefficients
can fit in the DP registers' Q3.12 format.
Signed-off-by: Mihail Atanassov
---
This patch depends on "[PATCH 2/2] drm: mali-dp: enable gamma support",
https://bugs.freedesktop.org/show_bug.cgi?id=99285
James Legg changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--
You are receiving this mail be
Hi Harry,
On Monday 30 Jan 2017 10:38:47 Harry Wentland wrote:
> On 2017-01-28 09:26 PM, Andrey Grodzovsky wrote:
> > Swicth to use atomic helper.
> > Start using actual user's given target_vblank value for flip
> > instead of current value.
> >
> > v3:
> > Update for movig pflip flags to crtc_st
HDMI 2.0 spec defines a method to reduce the RF footprint while
operating at higher pixel clocks, which is called Scrambling.
Scrambling can be controlled over a new set of I2C registers
which are accessible over existing DDC I2C lines, called SCDC
register set.
This patch series contains 6 patche
From: Thierry Reding
This patch implements a small function that finds if a
given CEA db is hdmi-forum vendor specific data block
or not.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/drm_edid.c | 15 +++
include/linux/hdmi.h | 1 +
2 files changed, 16 insertions(+)
dif
From: Thierry Reding
SCDC is a mechanism defined in the HDMI 2.0 specification that allows
the source and sink devices to communicate.
This commit introduces helpers to access the SCDC and provides the
symbolic names for the various registers defined in the specification.
Signed-off-by: Thierry
Geminilake has a native HDMI 2.0 controller, which is capable of
driving clocks upto 594Mhz. This patch updates the max tmds clock
limit for the same.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i
Geminilake platform has a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.
Sign
HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
than 340Mhz. This patch adds few new functions in drm layer for
core drivers to enable/disable scrambling.
This patch adds:
- A function to detect scrambling support parsing HF-VSDB
- A function to check scrambling status runtime
This patch does following:
- Adds a new structure (drm_hdmi_info) in drm_display_info.
This structure will be used to save and indicate if sink
supports advance HDMI 2.0 features
- Checks the HF-VSDB block for presence of SCDC, and marks it
in hdmi_info structure.
- If SCDC is present, checks
On 30 January 2017 at 10:29, Thierry Reding wrote:
> From: Thierry Reding
>
> The util_open() helper is used in a couple of test programs to open an
> appropriate device. It takes a device path and a module name, both are
> optional, as parameters. If a device path is specified, it will try to
>
Add a custom CRTC state struct to enable storing driver-private per-CRTC
state. This patch only adds the base drm_crtc_state struct.
Signed-off-by: Mihail Atanassov
---
drivers/gpu/drm/arm/malidp_crtc.c | 39 +--
drivers/gpu/drm/arm/malidp_drv.h | 6 ++
On 28 January 2017 at 19:49, Grazvydas Ignotas wrote:
> I've taken several patches from amdgpu-pro libdrm that look useful
> to me and I think can be applied already. The only things I did was
> rebasing, fixing some typos and dropping Change-Id.
>
> Alex Xie (3):
> amdgpu: Free/uninit vamgr_32
Add gamma via the DRM GAMMA_LUT/GAMMA_LUT_SIZE CRTC
properties. The expected LUT size is 4096 in order
to produce as accurate a set of segments as possible.
This version uses only the green channel's gamma curve
to set the hardware curve on DP550/650. For the sake of
simplicity, it uses the same t
+Daniel to weigh in on the coefficient conversion.
On Wed, Feb 01, 2017 at 12:05:03PM +, Mihail Atanassov wrote:
All DPs have a COLORADJ matrix which is applied prior to output gamma.
Attach that to the CTM property. Also, ensure the input CTM's coefficients
can fit in the DP registers' Q3.1
I'd be fine with you squashing these two together, but either way both
are:
Reviewed-by: Brian Starkey
(two nitpicks below, but take them or leave them.)
On Wed, Feb 01, 2017 at 10:16:57AM +, Mihail Atanassov wrote:
Add a custom CRTC state struct to enable storing driver-private per-CRTC
2017-01-30 12:52 GMT+01:00 Christian Gmeiner :
> Hi Lucas,
>
> 2017-01-30 12:48 GMT+01:00 Lucas Stach :
>> Am Mittwoch, den 18.01.2017, 12:25 +0100 schrieb Lucas Stach:
>>> Hi all,
>>>
>>> the following patches introduce a cmduf suballocator in the Etnaviv
>>> kernel driver, which has the following
Acked-by: Vincent Abriou
On 01/12/2017 05:27 PM, Fabien Dessenne wrote:
> Since nonblocking atomic commits are now supported, the driver can
> now use drm_atomic_helper_commit().
>
> Signed-off-by: Fabien Dessenne
> ---
> drivers/gpu/drm/sti/sti_drv.c | 83
> +--
Add gamma via the DRM GAMMA_LUT/GAMMA_LUT_SIZE CRTC
properties. The expected LUT size is 4096 in order
to produce as accurate a set of segments as possible.
This version uses only the green channel's gamma curve
to set the hardware curve on DP550/650. For the sake of
simplicity, it uses the same t
Acked-by: Vincent Abriou
On 01/12/2017 05:27 PM, Fabien Dessenne wrote:
> Use drm-core to handle event.
> This is required to be able to use the nonblocking helpers.
>
> Signed-off-by: Fabien Dessenne
> ---
> drivers/gpu/drm/sti/sti_crtc.c | 46
> +
> d
On Wed, Feb 01, 2017 at 08:48:30AM +0900, Inki Dae wrote:
>
>
> 2017년 02월 01일 06:31에 Thierry Reding 이(가) 쓴 글:
> > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
> >> Thierry Reding writes:
> >>
> >>> [ Unknown signature status ]
> >>> On Tue, Jan 31, 2017 at 09:38:53AM -0500, Sean
Acked-by: Vincent Abriou
On 01/12/2017 05:27 PM, Fabien Dessenne wrote:
> Fix a division by 0 case : in some cases, when the HQVDP plane is being
> disabled atomic_check() is called with "mode->clock = 0".
> In that case, do not check for scaling capabilities.
>
> Signed-off-by: Fabien Dessenne
Add a custom CRTC state struct to enable storing driver-private per-CRTC
state. This patch only adds the base drm_crtc_state struct.
Signed-off-by: Mihail Atanassov
Reviewed-by: Brian Starkey
---
Link to v1: https://lkml.org/lkml/2017/2/1/203
Changes since v1:
- Moved unused variable to patch 2
On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote:
> Thierry Reding writes:
>
> > [ Unknown signature status ]
> > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
> >> Thierry Reding writes:
> >>
> >> > [ Unknown signature status ]
> >> > On Tue, Jan 31, 2017 at 09:38:53A
https://bugs.freedesktop.org/show_bug.cgi?id=97556
--- Comment #4 from Sergey Kochneff ---
On ASUS Strix RX 470, “fan stop” works fine on firmware boot and in GRUB, but
after loading amdgpu module fan starts to spin and never stops. Although it’s
possible to emulate proper behavior with custom sc
https://bugs.freedesktop.org/show_bug.cgi?id=97556
--- Comment #5 from Sergey Kochneff ---
In addition to my previous comment. pwm1_enable always reads “1” which usually
means “manual control”, and writing “2” (hardware control) or higher values
doesn’t change file contents neither it changes fan
On 1 February 2017 at 14:52, Thierry Reding wrote:
> On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote:
>> Thierry Reding writes:
>>
>> > [ Unknown signature status ]
>> > On Tue, Jan 31, 2017 at 10:15:10AM -0800, Eric Anholt wrote:
>> >> Thierry Reding writes:
>> >>
>> >> > [ Unknown
From: Emil Velikov
Earlier commit removed all the legacy 'tests' but a file was left
danglig.
Cc: Andreas Boll
Reported-by: Andreas Boll
Fixes: 0c80fddd1d0 "tests: remove useless legacy tests"
Signed-off-by: Emil Velikov
---
tests/drmstat.c | 419 -
https://bugs.freedesktop.org/show_bug.cgi?id=99628
Bug ID: 99628
Summary: AMD Radeon HD 8600M graphics doesn't work with amdgpu
Product: Mesa
Version: 13.0
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=99628
mohsen2120habibik...@gmail.com changed:
What|Removed |Added
Priority|medium |highest
--
You are rece
https://bugs.freedesktop.org/show_bug.cgi?id=99628
mohsen2120habibik...@gmail.com changed:
What|Removed |Added
Summary|AMD Radeon HD 8600M |AMD Radeon HD 8600M
Reviewed-by: Andreas Boll
2017-02-01 16:32 GMT+01:00 Emil Velikov :
> From: Emil Velikov
>
> Earlier commit removed all the legacy 'tests' but a file was left
> danglig.
>
> Cc: Andreas Boll
> Reported-by: Andreas Boll
> Fixes: 0c80fddd1d0 "tests: remove useless legacy tests"
> Signed-off-by:
2017-01-30 21:41 GMT+01:00 Bjorn Helgaas :
> The PCI Power Management Spec, r1.2, sec 5.6.1, requires a 10 millisecond
> delay when powering on a device, i.e., transitioning from state D3hot to
> D0.
>
> Apparently some devices require more time, and d1f9809ed131 ("drm/radeon:
> add quirk for d3 de
https://bugs.freedesktop.org/show_bug.cgi?id=99628
Alex Deucher changed:
What|Removed |Added
Priority|highest |medium
--- Comment #1 from Alex Deucher
On Wed, Feb 01, 2017 at 12:47:21PM +, Emil Velikov wrote:
> On 30 January 2017 at 10:29, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > The util_open() helper is used in a couple of test programs to open an
> > appropriate device. It takes a device path and a module name, both are
> >
My randconfig tests on linux-next showed a newly introduced warning:
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c: In function
'amdgpu_bo_create_restricted':
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c:377:2: error: #warning Please enable
CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks
https://bugs.freedesktop.org/show_bug.cgi?id=99628
--- Comment #2 from mohsen2120habibik...@gmail.com ---
Created attachment 129273
--> https://bugs.freedesktop.org/attachment.cgi?id=129273&action=edit
dmesg result
No, it didn't help. dmesg result
--
You are receiving this mail because:
You a
https://bugs.freedesktop.org/show_bug.cgi?id=99628
--- Comment #3 from Alex Deucher ---
The driver appears to be loaded fine. What exactly are you trying to do? The
dGPU has no displays attached so you have to use the integrated GPU for
display. You can select the dGPU to offscreen rendering u
On Wed, Feb 01, 2017 at 06:14:38PM +0530, Shashank Sharma wrote:
> This patch does following:
> - Adds a new structure (drm_hdmi_info) in drm_display_info.
> This structure will be used to save and indicate if sink
> supports advance HDMI 2.0 features
"advanced"
> - Checks the HF-VSDB block f
Remove unnecessary save/restore of pdev->d3_delay.
The only assignments to pdev->d3_delay are in radeon_switcheroo_set_state()
and some quirks, none of which should be relevant in the
amdgpu_switcheroo_set_state() path.
Signed-off-by: Bjorn Helgaas
Acked-by: Alex Deucher
---
drivers/gpu/drm/am
The PCI Power Management Spec, r1.2, sec 5.6.1, requires a 10 millisecond
delay when powering on a device, i.e., transitioning from state D3hot to
D0.
Apparently some devices require more time, and d1f9809ed131 ("drm/radeon:
add quirk for d3 delay during switcheroo poweron for apple macbooks") add
amdgpu doesn't need to touch pdev->d3_delay at all.
radeon has a d3_delay quirk for MacBook Pro, but it only affects
radeon_switcheroo_set_state(). I think it should affect wakeups done by
the PCI core as well.
Changes from v1 to v2:
- Fix accidental removal of "{ 0, 0, 0, 0, 0 }" quirk list t
https://bugs.freedesktop.org/show_bug.cgi?id=99628
--- Comment #4 from mohsen2120habibik...@gmail.com ---
Created attachment 129274
--> https://bugs.freedesktop.org/attachment.cgi?id=129274&action=edit
The result of cat ~/.local/share/xorg/Xorg.0.log
--
You are receiving this mail because:
You
For the series:
Reviewed-by: Andreas Boll
2017-02-01 17:22 GMT+01:00 Bjorn Helgaas :
> amdgpu doesn't need to touch pdev->d3_delay at all.
>
> radeon has a d3_delay quirk for MacBook Pro, but it only affects
> radeon_switcheroo_set_state(). I think it should affect wakeups done by
> the PCI core
On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> than 340Mhz. This patch adds few new functions in drm layer for
> core drivers to enable/disable scrambling.
>
> This patch adds:
> - A function to detect scramb
https://bugs.freedesktop.org/show_bug.cgi?id=95306
--- Comment #55 from Jaime Rodrigo ---
I kind of have the same laptop, manufactured for a different region. I can
confirm it doesn't work well with 4.10 RC6 (for me it blanks before the login
screen). 4.10 RC5 works great, although it gets really
https://bugs.freedesktop.org/show_bug.cgi?id=99628
Alex Deucher changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |ch...@chris-wilson.co.uk
On Wed, Feb 01, 2017 at 06:14:39PM +0530, Shashank Sharma wrote:
> HDMI 2.0 spec mandates scrambling for modes with pixel clock higher
> than 340Mhz. This patch adds few new functions in drm layer for
> core drivers to enable/disable scrambling.
>
> This patch adds:
> - A function to detect scramb
On Wed, Feb 01, 2017 at 06:14:38PM +0530, Shashank Sharma wrote:
> This patch does following:
> - Adds a new structure (drm_hdmi_info) in drm_display_info.
> This structure will be used to save and indicate if sink
> supports advance HDMI 2.0 features
> - Checks the HF-VSDB block for presence o
On Wed, Feb 01, 2017 at 06:14:40PM +0530, Shashank Sharma wrote:
> Geminilake platform has a native HDMI 2.0 controller, and is
> capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
> mendates scrambling for these higher clocks, for reduced RF footprint.
>
> This patch checks if the monitor
https://bugs.freedesktop.org/show_bug.cgi?id=69897
--- Comment #7 from Vedran Miletić ---
Grigori, can you repost the kernel?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedeskt
https://bugs.freedesktop.org/show_bug.cgi?id=69897
Jan Vesely changed:
What|Removed |Added
Attachment #86758|text/plain |application/tar+gzip
mime type|
On Wed, Feb 1, 2017 at 2:04 PM, Breno Matheus Lima
wrote:
> Hi,
>
> I'm trying to use the Seiko 43WVF1G panel (Datasheet link:
> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf) and the DRM_MXS driver
> on
> the i.MX6SX SabreSD. Applying the patch below removes the old
> timing configuration
On Wed, Feb 01, 2017 at 02:04:29PM -0200, Breno Matheus Lima wrote:
> Hi,
>
> I'm trying to use the Seiko 43WVF1G panel (Datasheet link:
> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf) and the DRM_MXS
> driver on
> the i.MX6SX SabreSD. Applying the patch below removes the old
> timing conf
On Wed, Feb 01, 2017 at 02:48:55PM -0200, Fabio Estevam wrote:
> On Wed, Feb 1, 2017 at 2:04 PM, Breno Matheus Lima
> wrote:
> > Hi,
> >
> > I'm trying to use the Seiko 43WVF1G panel (Datasheet link:
> > http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf) and the DRM_MXS driver
> > on
> > the i.
On Mon, Jan 30, 2017 at 11:49:18AM -0500, Rob Clark wrote:
> The plan is to use the OPP bindings. For now, remove the documentation
> for qcom,gpu-pwrlevels, and make the driver fall back to a safe low
> clock if the node is not present.
>
> Note that no upstream dtb use this node. For now we ke
This series is a folow-up on
https://patchwork.kernel.org/patch/9501787/
The first patch makes changes to atomic helpers to allow for drives with ASYNC
flip support to use them.
Patch 2 is to use this in AMDGPU/DC.
Patch 3 is possible cleanup in nouveau/kms who seems to have to duplicate the
hel
v2:
Update code after flip_flags moved from plane_state
to crtc_state
Change-Id: I5a3189c03e389af2ff6c13d870a7d28282b7b0ee
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/nouveau/nv50_display.c | 84 --
1 file changed, 10 insertions(+), 74 deletions(-)
diff
Allows using atomic flip helpers for drivers
using ASYNC flip.
Remove ASYNC_FLIP restriction in helpers and
caches the page flip flags in drm_crtc_state
to be used in the low level drivers.
v2:
Resending the patch since the original was broken.
v3:
Save flag in crtc_state instead of plane_state
On Mon, Jan 30, 2017 at 11:49:19AM -0500, Rob Clark wrote:
> The original way we determined the gpu version was based on downstream
> bindings from android kernel. A cleaner way is to get the version from
> the compatible string.
>
> Note that no upstream dtb uses these bindings. But the code st
On Mon, Jan 30, 2017 at 11:49:21AM -0500, Rob Clark wrote:
> Suggested by Rob Herring. We still support the old names for
> compatibility with downstream android dt files.
>
> Cc: Rob Herring
> Signed-off-by: Rob Clark
> ---
> Documentation/devicetree/bindings/display/msm/gpu.txt | 12 ++--
On Fri, Jan 20, 2017 at 09:46:17PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 17, 2017 at 05:43:29PM +0100, Takashi Iwai wrote:
> > This is just a cleanup, no functional change.
> >
> > The fixup code for 1366x768 in drm_mode_create_from_cmdline_mode() is
> > basically a copy of the existing code i
v2:
Modify for movig pflip flags to crtc_state
v4:
Fix identation.
Change-Id: I25dae6d8c29de5d022a42aa99a18a32674b56cda
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 1 -
.../drm/amd/display/amdgpu_dm/amdgpu_dm_types.c| 113 +
On Wed, Feb 01, 2017 at 03:19:47PM -0200, Fabio Estevam wrote:
> Currently when the 'power-supply' regulator is passed via device tree
> it does not actually work since drm_panel_prepare()/drm_panel_enable()
> are never called.
>
> Quoting Thierry Reding: "It should really call drm_panel_prepare()
On Mon, 30 Jan 2017 15:25:10 -0500, Sean Paul wrote:
> On Sun, Jan 29, 2017 at 01:24:33PM +, John Keeping wrote:
> > This clock rate is derived from the PHY PLL, so it should be calculated
> > dynamically. Use the same calculation as the vendor kernel to derive
> > the escape clock speed.
> >
On Wed, Feb 01, 2017 at 12:03:34PM -0500, Andrey Grodzovsky wrote:
> Allows using atomic flip helpers for drivers
> using ASYNC flip.
> Remove ASYNC_FLIP restriction in helpers and
> caches the page flip flags in drm_crtc_state
> to be used in the low level drivers.
>
> v2:
> Resending the patch s
On Wed, Feb 1, 2017 at 12:09 PM, Rob Herring wrote:
> On Mon, Jan 30, 2017 at 11:49:19AM -0500, Rob Clark wrote:
>> The original way we determined the gpu version was based on downstream
>> bindings from android kernel. A cleaner way is to get the version from
>> the compatible string.
>>
>> Note
On Tue, Jan 31, 2017 at 05:03:17PM +0100, Noralf Trønnes wrote:
> Display panels can be oriented many ways, especially in the embedded
> world. The rotation property is a way to describe this orientation.
> The counter clockwise direction is chosen because that's what fbdev
> and drm use.
The h/w
On Tue, Jan 31, 2017 at 05:03:18PM +0100, Noralf Trønnes wrote:
> Add device-tree binding documentation for the MI0283QT display panel.
>
> Signed-off-by: Noralf Trønnes
> ---
>
> Datasheet: https://cdn-shop.adafruit.com/datasheets/MI0283QT-11+V1.1.PDF
>
> .../bindings/display/multi-inno,mi028
On Tue, Jan 24, 2017 at 10:27:27AM +0800, Chris Zhong wrote:
> Hi Sean
>
> On 01/24/2017 01:48 AM, Sean Paul wrote:
> >On Fri, Jan 20, 2017 at 06:10:49PM +0800, Chris Zhong wrote:
> >>The MIPI DSI do not need check the validity of resolution, the max
> >>resolution should depend VOP. Hence, remove
Scheduling the output_poll_work before calling bind_all to create the
crtcs can race the fbdev initialization with the components
initialization (i.e. crtc initialization). One side effect is that we
may call drm_fbdev_cma_init with a zeroed num_crtc value, crashing the
fbdev allocation.
I found
Instead of receiving the num_crts as a parameter, we can read it
directly from the mode_config structure. I audited the drivers that
invoke this helper and I believe all of them (but one, see below)
initialize the mode_config struct accordingly, prior to calling the
fb_helper.
The auditing was do
On Tue, Jan 24, 2017 at 10:38:02AM +0800, Chris Zhong wrote:
> The vopb/vopl switch register of RK3399 mipi is different from RK3288,
> the default setting for mipi dsi mode is different too, so add a
> of_device_id structure to distinguish them, and make sure set the
> correct mode before mipi phy
On Tue, Jan 24, 2017 at 10:38:03AM +0800, Chris Zhong wrote:
> correct the coding style, according the checkpatch scripts
>
Reviewed-by: Sean Paul
> Signed-off-by: Chris Zhong
> ---
>
> Changes in v4: None
> Changes in v3: None
>
> drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 33 +++
On Wed, Feb 01, 2017 at 03:29:40PM +, Emil Velikov wrote:
> On 1 February 2017 at 14:52, Thierry Reding wrote:
> > On Tue, Jan 31, 2017 at 02:54:53PM -0800, Eric Anholt wrote:
> >> Thierry Reding writes:
> >>
> >> > [ Unknown signature status ]
> >> > On Tue, Jan 31, 2017 at 10:15:10AM -0800,
On Thu, Jan 26, 2017 at 02:37:28PM +0200, Martin Peres wrote:
> Despite all the careful planing of the kernel, a link may become
> insufficient to handle the currently-set mode. At this point, the
> kernel should mark this particular configuration as being broken
> and potentially prune the mode be
Jani Nikula writes:
> On Tue, 31 Jan 2017, Eric Anholt wrote:
>> Martin Peres writes:
>>
>>> Despite all the careful planing of the kernel, a link may become
>>> insufficient to handle the currently-set mode. At this point, the
>>> kernel should mark this particular configuration as being broke
On Wed, Feb 01, 2017 at 11:58:16AM -0800, Eric Anholt wrote:
> Jani Nikula writes:
>
> > On Tue, 31 Jan 2017, Eric Anholt wrote:
> >> Martin Peres writes:
> >>
> >>> Despite all the careful planing of the kernel, a link may become
> >>> insufficient to handle the currently-set mode. At this poi
https://bugs.freedesktop.org/show_bug.cgi?id=99524
wwa <10dma...@gmail.com> changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Gabriel Krisman Bertazi writes:
> Instead of receiving the num_crts as a parameter, we can read it
> directly from the mode_config structure. I audited the drivers that
> invoke this helper and I believe all of them (but one, see below)
> initialize the mode_config struct accordingly, prior to c
https://bugs.freedesktop.org/show_bug.cgi?id=99275
--- Comment #16 from Reimar Imhof ---
I had an other look at 4.8.
4.8 is ok.
Next try was 4.9-rc1.
That one is buggy.
Trying to bisect ended up in lots of unbootable kernels.
git bisect start
# good: [c8d2bc9bc39ebea8437fd974fdbc21847bb897a3]
https://bugs.freedesktop.org/show_bug.cgi?id=99275
--- Comment #17 from Alex Deucher ---
Does using the new ucode here help?
https://people.freedesktop.org/~agd5f/radeon_ucode/polaris/
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=193651
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #7 from
https://bugs.freedesktop.org/show_bug.cgi?id=99418
--- Comment #29 from lei.p...@gmail.com ---
Just want to add few things, did reported bug to gnome project, but, problem
does not happen when "vblank_mode" value in .drirc configuration file is set to
1 (instead of 0 I've used before).
Thought it
On Mon, Jan 30, 2017 at 01:35:47PM -0500, Rob Clark wrote:
> On Mon, Jan 30, 2017 at 1:21 PM, Eric Anholt wrote:
> > Rob Clark writes:
> >
> >> The plan is to use the OPP bindings. For now, remove the documentation
> >> for qcom,gpu-pwrlevels, and make the driver fall back to a safe low
> >> clo
This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
Reviewed-by: Andrzej Hajda
---
On 01/30/2017 10:35 PM, Jani Nikula wrote:
On Sat, 28 Jan 2017, Peter Senna Tschudin wrote:
On Thu, Jan 05, 2017 at 01:18:47PM +0530, Archit Taneja wrote:
Hi Archit,
Thank you for the comments!
[...]
+ total_size = (block[EDID_EXT_BLOCK_CNT] + 1) * EDID_LENGTH;
+ if (total_size
On Wed, Feb 01, 2017 at 10:58:43AM +, Peter Senna Tschudin wrote:
> Hi Archit,
>
> On 01 February, 2017 10:44 CET, Archit Taneja wrote:
>
> >
> >
> > On 01/30/2017 10:35 PM, Jani Nikula wrote:
> > > On Sat, 28 Jan 2017, Peter Senna Tschudin
> > > wrote:
> > >> On Thu, Jan 05, 2017 at 01:18
On 02/01/2017 05:52 PM, Thierry Reding wrote:
> On Wed, Feb 01, 2017 at 02:04:29PM -0200, Breno Matheus Lima wrote:
>> Hi,
>>
>> I'm trying to use the Seiko 43WVF1G panel (Datasheet link:
>> http://www.glyn.de/data/glyn/media/doc/43wvf1g-0.pdf) and the DRM_MXS
>> driver on
>> the i.MX6SX SabreSD. A
1 - 100 of 134 matches
Mail list logo
