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:47PM +0530, Archit Taneja wrote:
> >> Hi Archit,
> >>
> >> Thank you for the comments!
> >
On Wed, 2017-02-01 at 18:14 +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 scrambling su
Changes for V9:
- Fixed the te-gpio to optional in bindings
Changes for V8:
- Applied below two patches: (drm/exynos)
: drm/exynos: mic: Add mode_set callback function
: drm/exynos: mic: Fix parse_dt function
- The dt-binding patch and driver patch were divided.
- Rebase these patches on samsu
The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
using MIPI-DSI interfaces.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
Reviewed-by: Andrzej Hajda
Acked-by: Rob Herring
---
.../bindings/display/panel/samsung,s6e3ha2.txt | 28
From: Hyungwon Hwang
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Andrzej Hajda
Signed-off-by: Chanwoo Choi
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
---
arch/arm64/boot/dts/exynos/exynos5433-tm2
Hi,
Some minor comments:
On 01/28/2017 07:51 PM, Peter Senna Tschudin wrote:
The video processing pipeline on the second output on the GE B850v3:
Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
Each bridge has a dedicated flash containing firmware for supporting the
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 the dtsi and adds it to the panel-simple.c
I can get the display work
On Wed, Feb 1, 2017 at 9:46 AM, Hoegeun Kwon wrote:
> The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
> using MIPI-DSI interfaces.
>
> Signed-off-by: Donghwa Lee
> Signed-off-by: Hyungwon Hwang
> Signed-off-by: Hoegeun Kwon
> Reviewed-by: Andrzej Hajda
> Acked-by: Rob Herring
>
When drm_crtc_init_with_planes() was orignally added
(in drm_crtc.c, e13161af80c185ecd8dc4641d0f5df58f9e3e0af
drm: Add drm_crtc_init_with_planes() (v2)), it only checked for "primary"
being non-null. If that was the case, it modified primary->possible_crtcs.
Then, when support for cursor planes wa
On Wed, Feb 01, 2017 at 04:45:42PM +0100, Andreas Boll wrote:
> 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 devic
On 01/31/2017 06:22 PM, Krzysztof Kozlowski wrote:
On Tue, Jan 31, 2017 at 2:01 AM, Inki Dae wrote:
2017년 01월 24일 10:50에 Hoegeun Kwon 이(가) 쓴 글:
Dear Thierry,
Could you please review this patch?
Thierry, I think this patch has been reviewed enough but no comment from you.
Seems you are bu
On 01 February, 2017 12:35 CET, Daniel Vetter wrote:
> 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
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() and
drm_panel_enable() while switching on the display pipeline and
drm_p
Tested-by: Breno Lima
From: Thierry Reding
Sent: Wednesday, February 1, 2017 3:22 PM
To: Fabio Estevam
Cc: airl...@linux.ie; ma...@denx.de; dri-devel@lists.freedesktop.org; Breno
Matheus Lima
Subject: Re: [PATCH] drm: mxsfb: Implement drm_panel handling
On Wed
On 02/01/2017 12:52 AM, Daniel Vetter wrote:
> 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* co
On Sat, Jan 28, 2017 at 03:21:30PM +0100, Peter Senna Tschudin wrote:
> Devicetree binding documentation for the second video output
> of the GE B850v3:
>STDP4028-ge-b850v3-fw bridges (LVDS-DP)
>STDP2690-ge-b850v3-fw bridges (DP-DP++)
>
> Added entry for MegaChips at:
> Documentation/devi
https://bugs.freedesktop.org/show_bug.cgi?id=99637
Bug ID: 99637
Summary: VLC video has corrupted colors when using VDPAU output
on Radeon SI
Product: Mesa
Version: 17.0
Hardware: Other
OS: All
S
https://bugs.freedesktop.org/show_bug.cgi?id=99637
Matt Whitlock changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
OS|All
https://bugs.freedesktop.org/show_bug.cgi?id=99418
--- Comment #30 from Michel Dänzer ---
(In reply to lei.pero from comment #29)
> 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 (i
https://bugs.freedesktop.org/show_bug.cgi?id=99418
--- Comment #31 from lei.p...@gmail.com ---
(In reply to Michel Dänzer from comment #30)
> (In reply to lei.pero from comment #29)
> > Just want to add few things, did reported bug to gnome project, but, problem
> > does not happen when "vblank_mo
https://bugs.freedesktop.org/show_bug.cgi?id=99418
--- Comment #32 from Michel Dänzer ---
(In reply to lei.pero from comment #31)
> It's still odd behaviour, in both cases Chrome caps FPS to refresh rate (this
> case 85FPS),
Sounds like Chrome just has its own framerate throttling which works
in
https://bugs.freedesktop.org/show_bug.cgi?id=99418
--- Comment #33 from lei.p...@gmail.com ---
(In reply to Michel Dänzer from comment #32)
> (In reply to lei.pero from comment #31)
> > It's still odd behaviour, in both cases Chrome caps FPS to refresh rate
> > (this
> > case 85FPS),
>
> Sounds
https://bugs.freedesktop.org/show_bug.cgi?id=99637
--- Comment #1 from Nayan Deshmukh ---
The problem is already fixed in the master branch. This patch fixes the issue.
Commit: 31908d6a4a3309f4cd4b953d6eecdf41595b1299
st/vdpau: only send buffers with B8G8R8A8 format to X
PresentPixmap onl
Thanks for the review Thierry. My comments inline.
Regards
Shashank
On 2/1/2017 9:40 PM, Thierry Reding wrote:
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 t
Regards
Shashank
On 2/1/2017 10:02 PM, Thierry Reding wrote:
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 scra
Thanks for the review Ville. My comments inline.
Regards
Shashank
On 2/1/2017 10:03 PM, Ville Syrjälä wrote:
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
Regards
Shashank
On 2/1/2017 10:02 PM, Ville Syrjälä wrote:
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 scram
Regards
Shashank
On 2/1/2017 10:06 PM, Ville Syrjälä wrote:
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
Thanks for the review, Dhinakaran.
Regards
Shashank
On 2/2/2017 1:23 AM, Pandiyan, Dhinakaran wrote:
On Wed, 2017-02-01 at 18:14 +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
https://bugs.freedesktop.org/show_bug.cgi?id=99418
--- Comment #34 from Michel Dänzer ---
(In reply to lei.pero from comment #33)
> Yeah, but by setting 1 and using any other WM results in Chromium/Chrome
> being VSYNC-ed, [...]
With a compositing manager, tearing or not is up to that.
> [...
https://bugs.freedesktop.org/show_bug.cgi?id=93341
--- Comment #17 from Jean-François Fortin Tam ---
I'm unfortunately still seeing this on an up-to-date Fedora 25 with kernel
4.9.6, DRM 2.48.0, LLVM 3.8.1, mesa 13.0.3, xorg-x11-drv-ati 7.7.1 (2016-09-28
git 3fc839ff) etc.
Nicolai, would it help
On 02/02/17 12:59 AM, Arnd Bergmann wrote:
> 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 CONFI
https://bugs.freedesktop.org/show_bug.cgi?id=93341
--- Comment #18 from Michel Dänzer ---
Please attach the current Xorg log file.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.free
https://bugs.freedesktop.org/show_bug.cgi?id=99418
--- Comment #35 from lei.p...@gmail.com ---
(In reply to Michel Dänzer from comment #34)
> (In reply to lei.pero from comment #33)
> > Yeah, but by setting 1 and using any other WM results in Chromium/Chrome
> > being VSYNC-ed, [...]
>
> With a c
101 - 134 of 134 matches
Mail list logo
