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
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
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 #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
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.
> [...
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
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
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
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, 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 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
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
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=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 #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 #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=99637
Matt Whitlock changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
OS|All
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
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
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
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
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
>
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
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 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
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
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 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
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
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
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=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://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]
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=99524
wwa <10dma...@gmail.com> changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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
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 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
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 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 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
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
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
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
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 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 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 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 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 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()
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 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
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 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
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
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
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
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 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 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
https://bugs.freedesktop.org/show_bug.cgi?id=69897
Jan Vesely changed:
What|Removed |Added
Attachment #86758|text/plain |application/tar+gzip
mime type|
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
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
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: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
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
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
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
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
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
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
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
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
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
> >
https://bugs.freedesktop.org/show_bug.cgi?id=99628
Alex Deucher changed:
What|Removed |Added
Priority|highest |medium
--- Comment #1 from Alex Deucher
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
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:
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
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
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 -
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
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
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
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
1 - 100 of 134 matches
Mail list logo
