Since USB connector bindings are available we can describe it on TM2(e).
Signed-off-by: Andrzej Hajda
---
arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
b/arch/arm64/boot/dts/
OF graph describes MHL data lanes between MHL and respective USB
connector.
Signed-off-by: Andrzej Hajda
---
v5: removed extra parenthesis (kbuild test robot)
v4: added missing reg property in connector's port node (Krzysztof)
---
.../boot/dts/exynos/exynos5433-tm2-common.dtsi | 31 +
These bindings allow to describe most known standard USB connectors
and it should be possible to extend it if necessary.
USB connectors, beside USB can be used to route other protocols,
for example UART, Audio, MHL. In such case every device passing data
through the connector should have appropriat
Samsung micro-USB 11-pin connector beside standard micro-USB pins,
has pins dedicated to route MHL traffic.
Signed-off-by: Andrzej Hajda
Reviewed-by: Rob Herring
---
v4:
- removed description of property inherited from usb-connector (Rob),
- fixed example description.
---
.../connector/samsung,
From: Maciej Purski
Currently MHL chip must be turned on permanently to detect MHL cable. It
duplicates micro-USB controller's (MUIC) functionality and consumes
unnecessary power. Lets use extcon attached to MUIC to enable MHL chip
only if it detects MHL cable.
Signed-off-by: Maciej Purski
Sign
Hi,
Thanks for reviews of previous iterations.
This patchset introduces USB physical connector bindings, together with
working example.
I have removed RFC prefix - the patchset seems to be heading
to a happy end :)
v5: fixed extra parenthesis in dts, renamed extcon function.
v4: improved binding
Since extcon property is not allowed in DT, extcon subsystem requires
another way to get extcon device. Lets try the simplest approach - get
edev by of_node.
Signed-off-by: Andrzej Hajda
Acked-by: Chanwoo Choi
---
v5: function renamed to extcon_find_edev_by_node (Andy)
v2: changed label to follo
On Tue, Feb 27, 2018 at 01:29:27PM +1100, Julian Calaby wrote:
> Hi Jernej,
>
> On Tue, Feb 27, 2018 at 3:27 AM, Jernej Škrabec
> wrote:
> > Hi,
> >
> > Dne ponedeljek, 26. februar 2018 ob 17:21:05 CET je Icenowy Zheng
> > napisal(a):
> >> 于 2018年2月27日 GMT+08:00 上午12:16:44, "Jernej Škrabec"
> >
On 26.02.2018 16:21, Krzysztof Kozlowski wrote:
> On Wed, Feb 21, 2018 at 9:55 AM, Andrzej Hajda wrote:
>> OF graph describes MHL data lanes between MHL and respective USB
>> connector.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> v4:
>> - added missing reg property in connector's port node (Krzy
On 02/27/2018 01:47 AM, Boris Ostrovsky wrote:
On 02/23/2018 10:35 AM, Oleksandr Andrushchenko wrote:
On 02/23/2018 05:26 PM, Boris Ostrovsky wrote:
On 02/21/2018 03:03 AM, Oleksandr Andrushchenko wrote:
+static struct xen_gem_object *gem_create(struct drm_device *dev,
size_t size)
+{
+str
On Thu, Feb 22, 2018 at 08:59:33PM -0300, Rodrigo Siqueira wrote:
> This patchset fixes warnings and errors found by checkpatch.pl in the
> drm/virtio:
Added to drm-qemu queue, will land in drm-misc soon.
thanks,
Gerd
___
dri-devel mailing list
dri-d
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip
head: 1d0e528594e2040c6c208be32bad4ad57437aabb
commit: 1d0e528594e2040c6c208be32bad4ad57437aabb [390/390] drm/amdgpu: used
cached pcie gen info for SI
config: powerpc64-allyesconfig (attached as .config)
compiler: powerpc64-
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip
head: 1d0e528594e2040c6c208be32bad4ad57437aabb
commit: 1d0e528594e2040c6c208be32bad4ad57437aabb [390/390] drm/amdgpu: used
cached pcie gen info for SI
config: x86_64-randconfig-u0-02271135 (attached as .config)
compiler: gcc
On 02/22/2018 01:16 PM, Alex Deucher wrote:
On Thu, Feb 22, 2018 at 1:49 PM, Bas Nieuwenhuizen
wrote:
On Thu, Feb 22, 2018 at 7:04 PM, Kristian Høgsberg wrote:
On Wed, Feb 21, 2018 at 4:00 PM Alex Deucher wrote:
On Wed, Feb 21, 2018 at 1:14 AM, Chad Versace
wrote:
On Thu 21 Dec 2017, Da
On Tue, Feb 20, 2018 at 9:25 AM, Ilia Mirkin wrote:
> On Tue, Feb 20, 2018 at 8:48 AM, Ville Syrjala
> wrote:
>> From: Ville Syrjälä
>>
>> Replace the ad-hoc iturbt_709 property with the new standard
>> COLOR_ENCODING property. Compiles, but not tested.
>>
>> Cc: Daniel Vetter
>> Cc: nouv...@li
https://bugs.freedesktop.org/show_bug.cgi?id=105018
--- Comment #21 from L.S.S. ---
Another problem: When I woke up the screen, sometimes the system would have
intermittent soft lockups that made the system kind of unusable... This is
after I included the patch to the latest 4.15 kernel, 4.15.5 (
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 1dec943aa3f9e9a9c39559851239e382ad1e436c
commit: 944b5289c92d9c1aad3760c012daf4cf2478381f [699/715] ASoC: AMD: enable
ACP3x drivers build
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (De
https://bugs.freedesktop.org/show_bug.cgi?id=104064
--- Comment #5 from Bjorn ---
I certainly wouldn't mind.
I've never really done anything of the sort before however, so is there an easy
way for me to set it up? For reference, I'm on Ubuntu 17.10 and while I know my
way around git and compiler
https://bugs.freedesktop.org/show_bug.cgi?id=105256
Logan McNaughton changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
Hi Jernej,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20180226]
[cannot apply to robh/for-next v4.16-rc3]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system
On 02/26/2018 09:07 AM, Shuah Khan wrote:
On 02/19/2018 11:33 AM, Daniel Vetter wrote:
On Mon, Feb 19, 2018 at 10:18:21AM -0800, Laura Abbott wrote:
On 02/19/2018 07:31 AM, Daniel Vetter wrote:
On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote:
Ion is designed to be a framework use
https://bugs.freedesktop.org/show_bug.cgi?id=104142
--- Comment #8 from Harry Wentland ---
Thanks for the update.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https
https://bugs.freedesktop.org/show_bug.cgi?id=104142
Mike Lothian changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=104200
--- Comment #3 from Harry Wentland ---
We have a few new patches in our staging trees relating to suspend and driver
unload.
Would you be able to try syncing amd-staging-drm-next and see if the issue has
been fixed?
--
You are receiving this
https://bugzilla.kernel.org/show_bug.cgi?id=197925
Harry Wentland (harry.wentl...@amd.com) changed:
What|Removed |Added
CC||harry.wentl...@a
https://bugs.freedesktop.org/show_bug.cgi?id=104142
--- Comment #6 from Harry Wentland ---
We have a few new patches in our staging trees relating to suspend and driver
unload.
Would you be able to try amd-staging-drm-next or drm-next-4.17-wip from
https://cgit.freedesktop.org/~agd5f/linux/?h=dr
https://bugs.freedesktop.org/show_bug.cgi?id=105256
Roland Scheidegger changed:
What|Removed |Added
Summary|Slow performance using |Slow performance using
https://bugs.freedesktop.org/show_bug.cgi?id=104064
--- Comment #4 from Harry Wentland ---
We have a few new patches in our staging trees relating to suspend and driver
unload.
Would you be able to try amd-staging-drm-next or drm-next-4.17-wip from
https://cgit.freedesktop.org/~agd5f/linux/?h=dr
Hi everyone,
Just a quick word to remind you that the X.Org Foundation got accepted
to the Google Summer of Code 2018!
As a potential mentor, if you have a project falling under the
foundation's (large) umbrella that you would like to kick start or get
help finishing, please add it to the list on
https://bugs.freedesktop.org/show_bug.cgi?id=105083
--- Comment #10 from Harry Wentland ---
We have some patches that rework our gamma programming in our staging trees.
Would you be able to try amd-staging-drm-next or drm-next-4.17-wip from
https://cgit.freedesktop.org/~agd5f/linux/?h=drm-next-4.
https://bugs.freedesktop.org/show_bug.cgi?id=104825
--- Comment #4 from Harry Wentland ---
Good to hear DC issues are gone. Not sure about the unlock balance myself.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-deve
On Mon, Feb 26, 2018 at 10:42:34PM +0530, Ramalingam C wrote:
> This series addresses the requriement of below HDCP compliance tests
> DP: 1A-06 and 1B-05
> HDMI: 1A-04 and 1A-07a
>
> One of the patch uses the I915 power infra-structure for checking
> the power state of PW#1. Which en
https://bugs.freedesktop.org/show_bug.cgi?id=105039
--- Comment #4 from Emanuel Couto ---
(In reply to Harry Wentland from comment #3)
> This should be fixed in our staging branches.
>
> Can you try either the amd-staging-drm-next or drm-next-4.17-wip branch from
> Alex's repo. You can find it a
Quoting Ramalingam C (2018-02-26 17:12:39)
> DP and HDMI HDCP specifications are varying with respect to
> detecting the R0 and ksv_fifo availability.
>
> DP will produce CP_IRQ and set a bit for indicating the R0 and
> FIFO_READY status.
>
> Whereas HDMI will set a bit for FIFO_READY but there i
https://bugs.freedesktop.org/show_bug.cgi?id=105262
--- Comment #1 from Pavel Vinogradov ---
Created attachment 137623
--> https://bugs.freedesktop.org/attachment.cgi?id=137623&action=edit
Xorg.log
Xorg.log with today's build of mesa from git.
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=105262
Bug ID: 105262
Summary: ttf fonts are invisible
Product: Mesa
Version: git
Hardware: Other
OS: Linux (All)
Status: NEW
Severity: normal
Priorit
Some VSP instances have two blending units named BRU (Blend/ROP Unit)
and BRS (Blend/ROP Sub unit). The BRS is a smaller version of the BRU
with only two inputs, but otherwise offers similar features and offers
the same register interface. The BRU and BRS can be used exchangeably in
VSP pipelines (
The VSPDL variant drives two DU channels through two LIF and two
blenders, BRU and BRS. The DU channels thus share the five available
VSPDL inputs and expose them as five KMS planes.
The current implementation assigns the BRS to the second LIF and thus
artificially limits the number of planes for
Display list completion is already reported to the frame end handler,
but that mechanism is global to all display lists. In order to implement
BRU and BRS reassignment in DRM pipelines we will need to wait for
completion of a particular display list. Extend the display list and
frame end handler AP
https://bugs.freedesktop.org/show_bug.cgi?id=104274
--- Comment #10 from Jordan L ---
Hi Luke, it actually looks like you're running with DC disabled. Can you also
try with amdgpu.dc=1 explicitly set? Potentially there are issues in multiple
IP blocks, though we fixed a driver unload issue recent
The vsp1_du_setup_lif() function setups the DRM pipeline input manually.
This duplicates the code from the vsp1_du_pipeline_setup_input()
function. Replace the manual implementation by a call to the function.
As the pipeline has no enabled input in vsp1_du_setup_lif(), the
vsp1_du_pipeline_setup_i
To implement fully dynamic plane assignment to pipelines, we need to
reassign the BRU and BRS to the DRM pipelines in the atomic commit
handler. In preparation for this setup factor out the BRU source pad
code and call it both at LIF setup and atomic commit time.
Signed-off-by: Laurent Pinchart
-
Move the duplicated DRM pipeline configuration code to a function and
call it from vsp1_du_setup_lif() and vsp1_du_atomic_flush().
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_drm.c | 95 +++---
1 file changed, 43 insertions(+), 52 deletions(-)
Dynamic assignment of the BRU and BRS to pipelines is prone to
regressions, add messages to make debugging easier. Keep it as a
separate commit to ease removal of those messages once the code will
deem to be completely stable.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_
When disabling a DRM plane, the corresponding RPF is only marked as
removed from the pipeline in the atomic update handler, with the actual
removal happening when configuring the pipeline at atomic commit time.
This is required as the RPF has to be disabled in the hardware, which
can't be done from
The DRM pipeline setup code used at atomic commit time is similar to the
setup code used when enabling the pipeline. Move it to a separate
function in order to share it.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_drm.c | 347 +
1 file cha
The DRM pipeline handling code uses the entity's pipe list head to check
whether the entity is already included in a pipeline. This method is a
bit fragile in the sense that it uses list_empty() on a list_head that
is a list member. Replace it by a simpler check for the entity pipe
pointer.
Signed
In order to make the vsp1_du_setup_lif() easier to read, and for
symmetry with the DRM pipeline input setup, move the pipeline output
setup code to a separate function.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_drm.c | 107 +++--
1 file chan
The DRM support code manages a pipeline of VSP entities, each backed by
a media entity. When starting or stopping the pipeline, it starts and
stops the media pipeline through the media API in order to store the
pipeline pointer in every entity.
The driver doesn't use the pipe pointer in media enti
Hello,
On R-Car H3 ES2.0+ and M3-N SoCs, two display pipelines are served by the same
VSP instance (named VSPDL). The VSPDL includes two blending units named BRU
and BRS, unlike the other display-related VSPD that serves a single display
channel with a single blending unit.
The VSPDL has five inp
The vsp1_drm_pipeline enabled field is set but never used. Remove it.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_drm.c | 4
drivers/media/platform/vsp1/vsp1_drm.h | 2 --
2 files changed, 6 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/driver
Various types of objects subclassing vsp1_entity currently store a
pointer to the pipeline. Move the pointer to vsp1_entity to simplify the
code and avoid storing the pipeline in more entity subclasses later.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_drm.c| 20
The entities in the pipeline are all started when the LIF is setup.
Remove the outdated comment that state otherwise.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_drm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/media/platform/vsp1/vs
https://bugs.freedesktop.org/show_bug.cgi?id=103234
--- Comment #13 from Roman Gilg ---
GDB output near to current master (at 8d1f1ce412, later does not compile on my
system at the moment):
Thread 17 "gallium_drv:0" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f67d592f7
https://bugs.freedesktop.org/show_bug.cgi?id=101672
--- Comment #24 from MirceaKitsune ---
I can confirm that the exact same system freeze happens with both the radeon
and amdgpu driver: Using either module makes absolutely no difference.
This is the last piece of confirmation I needed to conclu
https://bugs.freedesktop.org/show_bug.cgi?id=105257
--- Comment #5 from Ivan Levshin ---
Hi Mathias,
Thanks for your comment. So it looks like a Mesa bug, will check if downgrade
helps. Anyway I'd like to get a fix for actual Mesa version.
--
You are receiving this mail because:
You are the as
https://bugs.freedesktop.org/show_bug.cgi?id=105256
Roland Scheidegger changed:
What|Removed |Added
Resolution|NOTABUG |FIXED
--- Comment #4 from Roland S
https://bugs.freedesktop.org/show_bug.cgi?id=105256
Logan McNaughton changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=105256
--- Comment #2 from Logan McNaughton ---
Interesting, is this documented somewhere? How do you know what data formats
the HW supports? Is there any other hardware besides these cards that don't
support it?
I'll have the users test using GL_UNSI
https://bugs.freedesktop.org/show_bug.cgi?id=105256
--- Comment #1 from Roland Scheidegger ---
At a quick glance, I'd suspect the problem isn't really drawElementsBaseVertex
per se, but the use of GL_UNSIGNED_BYTE indices as the code seemed to do.
The hw doesn't support ubyte indices, and this ha
Hi,
On Thu, Feb 8, 2018 at 9:48 AM, Sean Paul wrote:
> This patch adds an override mode for kevin devices. The mode increases
> both back porches to allow a pixel clock of 2kHz as opposed to the
> 'typical' value of 252750kHz. This is needed to avoid interference with
> the touch digitizer on
https://bugs.freedesktop.org/show_bug.cgi?id=105257
--- Comment #4 from Mathias Fröhlich ---
If it helps:
Same story on fedora 27 with a skylake system.
Poor mens bisect on downgradable rpms show:
Shows up somewhere between mesa-17.3.3-1.fc27 and mesa-17.3.5-1.fc27.
best
Mathias
--
You are r
On Mon, Feb 26, 2018 at 10:42:39PM +0530, Ramalingam C wrote:
> DP and HDMI HDCP specifications are varying with respect to
> detecting the R0 and ksv_fifo availability.
>
> DP will produce CP_IRQ and set a bit for indicating the R0 and
> FIFO_READY status.
I'm not sure what the benefit is? Keepi
https://bugs.freedesktop.org/show_bug.cgi?id=105257
--- Comment #3 from Ivan Levshin ---
Created attachment 137614
--> https://bugs.freedesktop.org/attachment.cgi?id=137614&action=edit
Presentation sample
--
You are receiving this mail because:
You are the assignee for the bug.___
On Mon, Feb 26, 2018 at 10:42:38PM +0530, Ramalingam C wrote:
> In a connected state, If a HDMI HDCP sink is responded with NACK for
> HDCP I2C register access, then HDMI HDCP spec mandates the polling
> of any HDCP space registers for accessibility, minimum once in 2Secs
> atleast for 4Secs.
>
I
On Mon, Feb 26, 2018 at 10:42:37PM +0530, Ramalingam C wrote:
> HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
> is enabled. Using the I915 power well infrastruture, above requirement
> is verified.
>
> This patch enables the hdcp initialization for HSW, BDW, and BXT.
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=105257
--- Comment #2 from Ivan Levshin ---
Created attachment 137613
--> https://bugs.freedesktop.org/attachment.cgi?id=137613&action=edit
Output of "xrandr --verbose"
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=105257
--- Comment #1 from Ivan Levshin ---
Created attachment 137612
--> https://bugs.freedesktop.org/attachment.cgi?id=137612&action=edit
Output of "cat /sys/class/drm/card0/error"
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=105257
Bug ID: 105257
Summary: GPU HANG: ecode 9:0:0x86dd, in Xorg, reason: Hang
on render ring, action: reset
Product: Mesa
Version: unspecified
Hardware: Other
On Mon, Feb 26, 2018 at 10:42:36PM +0530, Ramalingam C wrote:
> In case of V prime mismatch, DP HDCP spec mandates the re-read of
> Vprime atleast twice.
>
> DP HDCP CTS Test: 1B-05
>
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 10 +-
> 1 file changed, 9 in
On Mon, Feb 26, 2018 at 10:42:35PM +0530, Ramalingam C wrote:
> As per DP spec when R0 mismatch is detected, HDCP source supported
> re-read the R0 atleast twice.
>
> And For HDMI and DP minimum wait required for the R0 availability is
> 100mSec. So this patch changes the wait time to 100mSec but
DP and HDMI HDCP specifications are varying with respect to
detecting the R0 and ksv_fifo availability.
DP will produce CP_IRQ and set a bit for indicating the R0 and
FIFO_READY status.
Whereas HDMI will set a bit for FIFO_READY but there is no bit
indication for R0 ready. And also polling of REA
This series addresses the requriement of below HDCP compliance tests
DP: 1A-06 and 1B-05
HDMI: 1A-04 and 1A-07a
One of the patch uses the I915 power infra-structure for checking
the power state of PW#1. Which enables the init path for all legacy
platforms.
And encoder specific msg
In a connected state, If a HDMI HDCP sink is responded with NACK for
HDCP I2C register access, then HDMI HDCP spec mandates the polling
of any HDCP space registers for accessibility, minimum once in 2Secs
atleast for 4Secs.
Just to make it simple, this is generically implemented for both HDMI
and
In case of V prime mismatch, DP HDCP spec mandates the re-read of
Vprime atleast twice.
DP HDCP CTS Test: 1B-05
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/dr
HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
is enabled. Using the I915 power well infrastruture, above requirement
is verified.
This patch enables the hdcp initialization for HSW, BDW, and BXT.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 31 ++
As per DP spec when R0 mismatch is detected, HDCP source supported
re-read the R0 atleast twice.
And For HDMI and DP minimum wait required for the R0 availability is
100mSec. So this patch changes the wait time to 100mSec but retries
twice with the time interval of 100mSec for each attempt.
DP CT
On 02/19/2018 11:33 AM, Daniel Vetter wrote:
> On Mon, Feb 19, 2018 at 10:18:21AM -0800, Laura Abbott wrote:
>> On 02/19/2018 07:31 AM, Daniel Vetter wrote:
>>> On Thu, Feb 15, 2018 at 05:24:45PM -0800, Laura Abbott wrote:
Ion is designed to be a framework used by other clients who perform
>>>
On 02/15/2018 06:24 PM, Laura Abbott wrote:
> There's no need to print messages each time we alloc and free. Remove them.
>
> Signed-off-by: Laura Abbott
> ---
> tools/testing/selftests/android/ion/ionutils.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/tools/testing/selftests/
On Mon, Feb 26, 2018 at 06:04:37PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 26, 2018 at 03:59:21PM +, Alexandru Gheorghe wrote:
> > This is an attempt to revive the color space conversation that started
> > here [1] and was materialized with the color encoding and color range
> > properties fo
https://bugs.freedesktop.org/show_bug.cgi?id=105256
Bug ID: 105256
Summary: Slow performance using glDrawElementsBaseVertex
Product: Mesa
Version: 17.3
Hardware: Other
OS: Linux (All)
Status: NEW
Severity:
https://bugs.freedesktop.org/show_bug.cgi?id=104285
--- Comment #8 from Alex Vorobyev ---
I think it's not the same bug. CS:GO works on my system as it should, while SCS
games still have broken shadows.
--
You are receiving this mail because:
You are the assignee for the bug.___
For the series:
Reviewed-by: Marek Olšák
Marek
On Mon, Feb 26, 2018 at 2:16 PM, Christian König
wrote:
> Return high addresses if requested and available.
>
> Signed-off-by: Christian König
> ---
> amdgpu/amdgpu.h | 1 +
> amdgpu/amdgpu_device.c | 6 --
> amdgpu/amdgpu_inter
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #22 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
I tried cold resets around 15 times (taking out the power cord) running lightdm
manger or directly xinit and haven't seen any hang.
Let me know your firmware versions -
cat /
https://bugs.freedesktop.org/show_bug.cgi?id=105244
--- Comment #1 from Alex Deucher ---
Created attachment 137609
--> https://bugs.freedesktop.org/attachment.cgi?id=137609&action=edit
possible fix
This patch should fix it.
--
You are receiving this mail because:
You are the assignee for the
On Mon, Feb 26, 2018 at 03:59:21PM +, Alexandru Gheorghe wrote:
> This is an attempt to revive the color space conversation that started
> here [1] and was materialized with the color encoding and color range
> properties for converting YUV2RGB, the last version of this patch
> series is here [
https://bugs.freedesktop.org/show_bug.cgi?id=102323
--- Comment #5 from Harry Wentland ---
Are you able to give Alex's amd-staging-drm-next or drm-next-4.17-wip branch
from https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-drm-next a try?
--
You are receiving this mail because:
You are t
From: Mihail Atanassov
Export drm_plane_enable_color_mgmt, which attaches the existing degamma,
ctm, and gamma properties to a plane. Add a color_mgmt_changed flag to
drm_plane_state, mimicking the drm_crtc_state flag of the same name.
Signed-off-by: Mihail Atanassov
Signed-off-by: Alexandru Gh
This is an attempt to revive the color space conversation that started
here [1] and was materialized with the color encoding and color range
properties for converting YUV2RGB, the last version of this patch
series is here [2].
However, we still need a way of specifing the color gamut and transfer
On Mon, Feb 26, 2018 at 09:18:57PM +0530, Nautiyal, Ankit K wrote:
>
>
> On 2/23/2018 8:24 PM, Ville Syrjälä wrote:
> > On Thu, Feb 15, 2018 at 05:51:01PM +0530, Nautiyal, Ankit K wrote:
> >> From: "Sharma, Shashank"
> >>
> >> Current DRM layer functions don't parse aspect ratio information
> >>
https://bugs.freedesktop.org/show_bug.cgi?id=100919
--- Comment #15 from Harry Wentland ---
Please open a separate ticket for the issue with amd-stg and the 2nd monitor,
including
* dmesg log with amdgpu.dc_log=1 and drm.debug=0x6 kernel options
* model of both monitors and how they're connected
On 2/23/2018 8:24 PM, Ville Syrjälä wrote:
On Thu, Feb 15, 2018 at 05:51:01PM +0530, Nautiyal, Ankit K wrote:
From: "Sharma, Shashank"
Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode wi
https://bugs.freedesktop.org/show_bug.cgi?id=100919
--- Comment #14 from Thomas R. ---
Harry, I tried amd-staging-drm-next and there is no corruption on the primary,
but my second monitor is dead. It may be something like bug #91202 or something
else entirely, the dmesg output is very sparse (egr
On Mon, Feb 26, 2018 at 03:35:34PM +0100, Hans de Goede wrote:
> Hi,
>
> On 26-02-18 15:24, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > sparse complains:
> > drivers/gpu/drm/drm_panel_orientation_quirks.c:133:5: warning: symbol
> > 'drm_get_panel_orientation_quirk' was not declared. Sh
On Fri, Feb 23, 2018 at 01:15:54PM -0500, Rob Clark wrote:
> On Fri, Feb 23, 2018 at 11:30 AM, Sean Paul wrote:
> > On Fri, Feb 23, 2018 at 08:17:54AM -0500, Rob Clark wrote:
> >> In a way, based on the original writeback patch from Jilai Wang, but a
> >> lot has shifted around since then.
> >>
>
On 2/23/2018 8:06 PM, Ville Syrjälä wrote:
On Thu, Feb 15, 2018 at 05:51:00PM +0530, Nautiyal, Ankit K wrote:
From: Ankit Nautiyal
We parse the EDID and add all the modes in the connector's modelist.
This adds CEA modes with aspect ratio information too, regadless of
whether user space reques
https://bugs.freedesktop.org/show_bug.cgi?id=105039
--- Comment #3 from Harry Wentland ---
This should be fixed in our staging branches.
Can you try either the amd-staging-drm-next or drm-next-4.17-wip branch from
Alex's repo. You can find it at
https://cgit.freedesktop.org/~agd5f/linux/?h=amd-s
On Wed, Feb 21, 2018 at 9:55 AM, Andrzej Hajda wrote:
> OF graph describes MHL data lanes between MHL and respective USB
> connector.
>
> Signed-off-by: Andrzej Hajda
> ---
> v4:
> - added missing reg property in connector's port node (Krzysztof)
> ---
> .../boot/dts/exynos/exynos5433-tm2-common
https://bugs.freedesktop.org/show_bug.cgi?id=105163
Eric Engestrom changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Ville,
I agree to all the comments here, and will correct the required things
in the next patch-set.
On 2/23/2018 7:58 PM, Ville Syrjälä wrote:
On Thu, Feb 15, 2018 at 05:50:59PM +0530, Nautiyal, Ankit K wrote:
From: Ankit Nautiyal
If the user-space does not support aspect-ratio, and re
1 - 100 of 172 matches
Mail list logo
