Hi Marek,
2018년 03월 08일 16:36에 Marek Szyprowski 이(가) 쓴 글:
> Hi Inki,
>
> On 2018-03-08 07:50, Inki Dae wrote:
>> 2018년 03월 08일 15:29에 Marek Szyprowski 이(가) 쓴 글:
>>> On 2018-03-08 05:01, Inki Dae wrote:
2018년 03월 08일 02:11에 Sylwester Nawrocki 이(가) 쓴 글:
> The #sound-dai-cells DT property i
https://bugs.freedesktop.org/show_bug.cgi?id=105302
--- Comment #6 from Andrew Sheldon ---
(In reply to Alex Deucher from comment #5)
> I'd rather not support running things out of spec in the driver. The source
> is open. If you want to adjust the code allow something like that you can.
Fair
https://bugs.freedesktop.org/show_bug.cgi?id=28433
--- Comment #4 from Gert Wollny ---
I can't see any artefacts on i915 with GM45. In fact there the rendering looks
better then with the llvmpipe software renderer and r600. These two create
over-bright pixels that are not present with i915.
Vers
https://bugs.freedesktop.org/show_bug.cgi?id=103234
--- Comment #16 from Roman Gilg ---
I can't reproduce the issue currently. What is weird, since it didn't work for
months.
Maybe it's working now again because I deleted the $HOME/.cache content?
Could someone with the same problem do the same
On Wed, 07 Mar 2018, a...@linux-foundation.org wrote:
> From: Andrew Morton
> Subject: drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union
> initializer issue
>
> gcc-4.4.4 has problems with initalizers of anon unions.
>
> drivers/gpu/drm/i915/intel_guc_log.c: In function 'guc_log_c
Hey John,
On 03/07/2018 12:19 AM, John Stultz wrote:
As suggested by Alexandru-Cosmin Gheorghe:
ConvertHALFormatToDrm logic would work only for 1 plane formats,
and probably gets rejected by drmModeAddFb2, but to save
debugging time maybe it worth removing DRM_FORMAT_YVU420 from
ConvertHALForm
Hey John,
This patch looks good to me.
I have yet to build it, and I haven't brought my HiKey960 up for testing quite
yet.
On 03/07/2018 12:19 AM, John Stultz wrote:
This allows for importing buffers allocated from the
hikey and hikey960 gralloc implelementations.
"implelementations" -> "i
Hi Inki,
Cc: alsa-de...@alsa-project.org
On 03/08/2018 09:15 AM, Inki Dae wrote:
> By the way, it seems 'sound-dai-cells' property never affect Exynos4210/4212>
> 5420/5433. It seems that even through ALSA TM2 audio driver(tm2_wm5110.c)
> exists the driver never check the property.
>
> However,
Quoting Matt Roper (2018-03-06 23:46:59)
> There are cases where a system integrator may wish to raise/lower the
> priority of GPU workloads being submitted by specific OS process(es),
> independently of how the software self-classifies its own priority.
> Exposing "priority offset" as an i915-spec
Hi Gustavo,
On 7 March 2018 at 19:54, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wvla, remove VLA and replace it
> with a fixed-length array instead. Also, remove variable 'len'.
>
What is the reason behind adding -Wvla? Is there a thread some that I
can read up on?
> Notice that n
From: Tomas Winkler
Whitelist HDCP client for in kernel drm use
v2:
Rebased.
Signed-off-by: Tomas Winkler
---
drivers/misc/mei/bus-fixup.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 0208c4b027c5..3d
In preparation for implementing HDCP2.2 in I915, this patch adds
HDCP register definitions for HDMI and DP HDCP adaptations.
HDMI specific HDCP2.2 register definitions are added into drm_hdcp.h,
where are HDCP2.2 register offsets in DPCD offsets are defined at
drm_dp_helper.h.
v2:
bit_field def
This patch defines the hdcp2.2 protocol messages for the
HDCP2.2 authentication.
v2:
bit_fields are removed. Instead bitmasking used. [Tomas and Jani]
prefix HDCP_2_2_ is added to the macros. [Tomas]
Signed-off-by: Ramalingam C
---
include/drm/drm_hdcp.h | 183 ++
Based on HDCP1.4 framework introduced by Sean Paul, this series
implements the HDCP2.2 in I915.
The sequence for HDCP2.2 authentication and encryption is implemented
in I915. Encoder specific implementations are moved into hdcp_shim.
Intel HWs supports HDCP2.2 through ME FW. Hence this series
int
ME FW is contributes a vital role in HDCP2.2 authentication.
HDCP2.2 driver needs to communicate to ME FW for each step of the
HDCP2.2 authentication.
ME FW prepare and HDCP2.2 authentication parameters and encrypt them
as per spec. With such parameter Driver prepares HDCP2.2 auth messages
and co
Checks whether mei client device for hdcp2.2 is enabled?
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c b/drivers/misc/mei/hdcp/mei_hdcp.c
index aa211763e520..25df
v2:
including the hdcp folder with a Makefile. [Tomas]
Signed-off-by: Ramalingam C
---
drivers/misc/mei/Kconfig | 6 ++
drivers/misc/mei/Makefile | 2 ++
drivers/misc/mei/hdcp/Makefile | 6 ++
3 files changed, 14 insertions(+)
create mode 100644 drivers/misc/mei/hdcp/Makefi
Interfaces to obtain and release the cl_device reference is developed.
Using these interfaces intel hdcp driver will get the reference to the
mei client devices, so that hdcp2.2 service calls can be routed to
that client device.
During registration, call back function will be registered with
mei_h
Defines the HDCP specific ME FW interfaces such as Request CMDs,
payload structure for CMDs and their response status codes.
This patch defines payload size(Excluding the Header)for each WIRED
HDCP2.2 CMDs.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.h | 525 +
Requests for verification for receiver certification and also the
preparation for next AKE auth message with km.
On Success ME FW validate the HDCP2.2 receivers certificate and do the
revocation check on the receiver ID. AKE_Stored_Km will be prepared if
the receiver is already paired, else AKE_No
Request ME FW to start the HDCP2.2 session for a intel port.
Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sent
to ME FW.
On Success, ME FW will start a HDCP2.2 session for the port and
provides the content for HDCP2.2 AKE_Init message.
v2:
Rebased.
Signed-off-by: Ramalingam C
Data structures and Enum for the I915-MEI_HDCP interface are defined
at
v2:
Rebased.
Signed-off-by: Ramalingam C
---
include/linux/mei_hdcp.h | 71
1 file changed, 71 insertions(+)
diff --git a/include/linux/mei_hdcp.h b/include/linux/mei_hdc
Requests ME to start the second stage of HDCP2.2 authentication,
called Locality Check.
On Success, ME FW will provide LC_Init message to send to hdcp sink.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 64
include/li
Request to ME to verify the LPrime received from HDCP sink.
On Success, ME FW will verify the received Lprime by calculating and
comparing with L.
This represents the completion of Locality Check.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 65 +++
Requests for the verifcation of AKE_Send_H_prime.
ME will calculation the H and comparing it with received H_Prime.
Here AKE_Send_H_prime is a HDCP2.2 Authentication msg.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 65 ++
Provides Pairing info to ME to store.
Pairing is a process to fast track the subsequent authentication
with the same HDCP sink.
On Success, received HDCP pairing info is stored in non-volatile
memory of ME.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 66 +
Request to ME to verify the M_Prime received from the HDCP sink.
ME FW will calculate the M and compare with M_prime received
as part of RepeaterAuth_Stream_Ready, which is HDCP2.2 protocol msg.
On successful completion of this stage, downstream propagation of
the stream management info is comple
Request to ME to prepare the encrypted session key.
On Success, ME provides Encrypted session key. Functions populates
the HDCP2.2 authentication msg SKE_Send_Eks.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdcp.c | 67
inc
Request ot ME to verify the downatream topology information received.
ME FW will validate the Repeaters receiver id list and
downstream topology.
On Success ME FW will provide the Least Significant
128bits of VPrime, which forms the repeater ack.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
Request to ME to configure a port as authenticated.
On Success, ME FW will mark th eport as authenticated and provides
HDCP chiper of the port with the encryption keys.
Enabling the Authentication can be requested once the all
stages of HDCP2.2 authentication is completed by interating with
ME FW
Request the ME to terminate the HDCP2.2 session for a port.
On Success, ME FW will mark the intel port as Deauthenticated and
terminate the wired HDCP2.2 Tx session started due to the cmd
WIRED_INITIATE_HDCP2_SESSION.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/misc/mei/hdcp/mei_hdc
For upcoming implementation of HDCP2.2 in I915, important variable
required for HDCP2.2 are defined.
HDCP_shim is extended to support encoder specific HDCP2.2 flows.
v2:
1.4 shim is extended to support hdcp2.2. [Sean Paul]
platform's/panel's hdcp ver capability is removed. [Sean Paul]
mei r
Adds the wrapper for all mei hdcp2.2 service functions.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 194 ++
1 file changed, 194 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_
Intel HDCP2.2 registers are defined with addr offsets and bit details.
v2:
Replaced the arith calc with _PICK [Sean Paul]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_reg.h | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/
Implements HDCP2.2 authentication for hdcp2.2 receivers, with
following steps:
Authentication and Key enchange (AKE).
Locality Check (LC).
Session Key Exchange(SKE).
DP Errata for stream type confuguration for receivers.
At AKE, the HDCP Receiver’s public key certif
Implements the HDCP2.2 repeaters authentication steps such as verifying
the downstream topology and sending stream management information.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 135 ++
1 file changed, 135 insertion
Considering the upcoming significant no HDCP2.2 variables, it will
be clean to have separate struct fo HDCP.
New structure called intel_hdcp is introduced.
v2:
struct hdcp statically allocated. [Sean Paul]
enable and disable function parameters are retained.[Sean Paul]
Signed-off-by: Ramalin
Implements a sequence of enabling and disabling the HDCP2.2
(auth and encryption).
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 75 +++
1 file changed, 75 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/d
Implements the enable and disable functions for HDCP2.2 encryption
of the PORT.
v2:
intel_wait_for_register is used instead of wait_for. [Chris Wilson]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 54 +++
1 file changed, 54 insertions
Implements the link integrity check once in 500mSec.
Once encryption is enabled, an ongoing Link Integrity Check is
performed by the HDCP Receiver to check that cipher synchronization
is maintained between the HDCP Transmitter and the HDCP Receiver.
On the detection of synchronization lost, the H
For reusability purpose, this patch implements the hdcp1.4 bksv's
read and validation as a functions.
For detecting the HDMI panel's HDCP capability this fucntions will be
used.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 38 +-
Initialize HDCP2.2 support. This includes the mei interface
initialization also.
v2:
mei interface handle is protected with mutex. [Chris Wilson]
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/i915_drv.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 7 +++
drivers/gpu/drm/i915/intel_
When repeater notifies a downstream topology change, this patch
reauthenticate the repeater alone with out disabling the hdcp
encryption. If that fails then complete reauthentication is executed.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 19 +
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
v2:
Included few optimization suggestions [Chris Wilson]
Commit message is updated as per the rebased version.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel
As a preparation for making the intel_hdcp_enable as common function
for both HDCP1.4 and HDCP2.2, HDCP1.4 check_link scheduling is moved
into _intel_hdcp_enable() function.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 11 +++
1 file changed, 7 insertions(+), 4 del
HDCP check link is invoked only on CP_IRQ detection, instead of all
short pulses.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4
On DP HDCP1.4 and 2.2, when CP_IRQ is received, start the link
integrity check for the HDCP version that is enabled.
v2:
Rebased. Function name is changed.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i91
When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
enabled.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdcp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdcp.c
b/drivers/gpu/drm/i915/intel_hdcp.
Implements a interface for single burst read of data that is larger
than 512 Bytes through gmbus.
HDCP2.2 spec expects HDCP2.2 transmitter to read 522Bytes of HDCP
receiver certificates in single burst read. On gmbus, to read more
than 511Bytes, HW provides a workaround for burst read.
This patch
Implements the DP adaptation specific HDCP2.2 functions.
These functions perform the DPCD read and write for communicating the
HDCP2.2 auth message back and forth.
Note: Chris Wilson suggested alternate method for waiting for CP_IRQ,
than completions concept. WIP to understand and implement that,
On DP connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_hdcp.c | 1 -
3 files ch
Implements the HDMI adapatation specific HDCP2.2 operations.
Basically these are DDC read and write for authenticating through
HDCP2.2 messages.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdmi.c | 203 ++
1 file changed, 203 in
On HDMI connector init, intel_hdcp_init is passed with a flag for hdcp2.2
support based on the platform capability.
v2:
Rebased.
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/intel_hdmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_h
> -Original Message-
> From: C, Ramalingam
> Sent: Thursday, March 08, 2018 13:58
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> seanp...@chromium.org; ch...@chris-wilson.co.uk; Winkler, Tomas
> ; jani.nik...@linux.intel.com
> Cc: Vivi, Rodrigo ; Sharma, Shashan
On Thursday 08 March 2018 06:00 PM, Winkler, Tomas wrote:
-Original Message-
From: C, Ramalingam
Sent: Thursday, March 08, 2018 13:58
To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
seanp...@chromium.org; ch...@chris-wilson.co.uk; Winkler, Tomas
; jani.nik...@lin
https://bugs.freedesktop.org/show_bug.cgi?id=103953
--- Comment #11 from Aleksei ---
I'm losing refresh rates higher than 60Hz with dc=1 on 4.15.6 kernel - is that
fixed too?
Monitor 1920x1080 144Hz, GPU RX 560, connection over DVI-D. With dc=0 I can set
1920x1080 144Hz, with dc=1 only 1920x1080
>
> v2:
> Rebased.
>
> Signed-off-by: Ramalingam C
> ---
> drivers/misc/mei/hdcp/mei_hdcp.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/drivers/misc/mei/hdcp/mei_hdcp.c
> b/drivers/misc/mei/hdcp/mei_hdcp.c
> index aa211763e520..25df7034cfb4 100644
> --- a/drivers/m
> Subject: [PATCH v2 04/42] misc/mei/hdcp: Client driver for HDCP application
I prefer this will be squashed together with [PATCH v2 05/42] misc/mei/hdcp:
Add KBuild for mei hdcp driver
so it can be compiled.
>
> ME FW is contributes a vital role in HDCP2.2 authentication.
> HDCP2.2 driver ne
> Interfaces to obtain and release the cl_device reference is developed.
> Using these interfaces intel hdcp driver will get the reference to the mei
> client devices, so that hdcp2.2 service calls can be routed to that client
> device.
>
> During registration, call back function will be registere
Quoting Chris Wilson (2018-03-08 11:32:04)
> Quoting Matt Roper (2018-03-06 23:46:59)
> > There are cases where a system integrator may wish to raise/lower the
> > priority of GPU workloads being submitted by specific OS process(es),
> > independently of how the software self-classifies its own pri
> Data structures and Enum for the I915-MEI_HDCP interface are defined at
>
>
> v2:
> Rebased.
>
> Signed-off-by: Ramalingam C
> ---
> include/linux/mei_hdcp.h | 71
>
> 1 file changed, 71 insertions(+)
>
> diff --git a/include/linux/mei_hdcp
>
> Request ME FW to start the HDCP2.2 session for a intel port.
> Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sent
> to ME FW.
>
> On Success, ME FW will start a HDCP2.2 session for the port and provides the
> content for HDCP2.2 AKE_Init message.
>
> v2:
> Rebased.
>
> S
https://bugs.freedesktop.org/show_bug.cgi?id=103953
--- Comment #12 from Alex Deucher ---
(In reply to Aleksei from comment #11)
> I'm losing refresh rates higher than 60Hz with dc=1 on 4.15.6 kernel - is
> that fixed too?
>
> Monitor 1920x1080 144Hz, GPU RX 560, connection over DVI-D. With dc=0
https://bugzilla.kernel.org/show_bug.cgi?id=199047
--- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 274621
--> https://bugzilla.kernel.org/attachment.cgi?id=274621&action=edit
possible fix
Does this fix it?
--
You are receiving this mail because:
You are watchin
https://bugs.freedesktop.org/show_bug.cgi?id=105401
Bug ID: 105401
Summary: Unable to start X on Vega AMDGPU(0):
amdgpu_setup_kernel_mem failed
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
https://bugs.freedesktop.org/show_bug.cgi?id=105401
--- Comment #1 from Timothy Pearson ---
Created attachment 137900
--> https://bugs.freedesktop.org/attachment.cgi?id=137900&action=edit
dmesg after xorg load attempt
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=105401
--- Comment #2 from Timothy Pearson ---
Created attachment 137901
--> https://bugs.freedesktop.org/attachment.cgi?id=137901&action=edit
Xorg.0.log after load attempt
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=105401
Timothy Pearson changed:
What|Removed |Added
Hardware|Other |PowerPC
OS|All
On Tue, Feb 27, 2018 at 10:49:39AM +0200, Ville Syrjälä wrote:
> On Tue, Feb 27, 2018 at 12:54:47AM -0500, Ilia Mirkin wrote:
> > 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
Am Freitag, 2. März 2018, 18:57:54 CET schrieb Enric Balletbo i Serra:
> From: Jeffy Chen
>
> Add missing error handling in bind().
>
> Fixes: 412d4ae6b7a5 ("drm/rockchip: hdmi: add Innosilicon HDMI support")
> Signed-off-by: Jeffy Chen
> Signed-off-by: Thierry Escande
> [moved clk_disable_unp
Am Freitag, 2. März 2018, 18:57:53 CET schrieb Enric Balletbo i Serra:
> From: Jeffy Chen
>
> In bind()'s error handling path call destroy functions instead of
> cleanup functions for encoder and connector and reorder to match how is
> called in bind().
>
> In unbind() call the connector and enc
Am Freitag, 2. März 2018, 18:57:55 CET schrieb Enric Balletbo i Serra:
> From: Jeffy Chen
>
> In bind the clk_prepare_enable of the HDMI pclk is called before adding the
> i2c_adapter. So it should be the other way around in unbind, first remove
> the i2c_adapter and then call the clk_disable_unp
Am Freitag, 2. März 2018, 18:57:56 CET schrieb Enric Balletbo i Serra:
> From: Jeffy Chen
>
> The HDMI vpll clock should be enabled when bind() is called. So move the
> clk_prepare_enable of that clock to bind() function and add the missing
> clk_disable_unprepare() required in error handling pat
Cc'ing mesa-dev, which was left out.
On 03/05/2018 01:40 PM, Ilia Mirkin wrote:
On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner
wrote:
On 02/05/2018 12:50 AM, Ilia Mirkin wrote:
In case anyone's curious about 30bpp framebuffer support, here's the
current status:
Kernel:
Ben and I have switch
On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner
wrote:
> Cc'ing mesa-dev, which was left out.
>
>
> On 03/05/2018 01:40 PM, Ilia Mirkin wrote:
>>
>> On Mon, Mar 5, 2018 at 2:25 AM, Mario Kleiner
>> wrote:
>>> Afaics EGL does the right thing wrt. channelmask matching of EGLConfigs
>>> to
>>> DRIcon
Den 06.03.2018 09.56, skrev Daniel Vetter:
On Thu, Feb 22, 2018 at 09:06:50PM +0100, Noralf Trønnes wrote:
This adds an API for writing in-kernel clients.
TODO:
- Flesh out and complete documentation.
- Cloned displays is not tested.
- Complete tiled display support and test it.
- Test plug/un
Hi,
On 8 March 2018 at 17:08, Ilia Mirkin wrote:
> On Thu, Mar 8, 2018 at 11:57 AM, Mario Kleiner
> wrote:
>> Under EGL there is matching of channel masks, so only X11+GLX is
>> problematic. Not sure if anything special would need to be done for
>> XWayland, haven't looked at that at all so far.
On 6 February 2018 at 21:19, Peter Seiderer wrote:
> From: Thomas Petazzoni
>
> The configure script currently tests the availability of libatomic_ops
> by checking the presence of atomic_ops.h. While this is good enough as
> an availability test, it is not sufficient as on some platforms,
> liba
On 5 March 2018 at 12:03, Eric Engestrom wrote:
> Ping? :)
> Both for this patch and the equivalent autotools patch it replies to.
>
The autotools one needs the CFLAGS added - meson does it automatically for us.
> On Wednesday, 2018-02-07 14:24:33 +, Eric Engestrom wrote:
>> Signed-off-by: Er
On 7 March 2018 at 08:48, Christian Gmeiner wrote:
> 2018-03-06 16:37 GMT+01:00 Eric Engestrom :
>> Fixes: 1384c081233751569473 "freedreno: add interface to get buffer address"
>> Signed-off-by: Eric Engestrom
>
> Reviewed-by: Christian Gmeiner
>
... and pushed to master since I was fitting that
On Thu, Mar 08, 2018 at 01:11:33PM +, Chris Wilson wrote:
> Quoting Chris Wilson (2018-03-08 11:32:04)
> > Quoting Matt Roper (2018-03-06 23:46:59)
> > > There are cases where a system integrator may wish to raise/lower the
> > > priority of GPU workloads being submitted by specific OS process(
https://bugs.freedesktop.org/show_bug.cgi?id=105308
--- Comment #12 from Michel Dänzer ---
This might work better if you enable DC with
amdgpu.dc=1
on the kernel command line.
--
You are receiving this mail because:
You are the assignee for the bug.___
Quoting Matt Roper (2018-03-08 18:22:06)
> On Thu, Mar 08, 2018 at 01:11:33PM +, Chris Wilson wrote:
> > Quoting Chris Wilson (2018-03-08 11:32:04)
> > > Quoting Matt Roper (2018-03-06 23:46:59)
> > > > There are cases where a system integrator may wish to raise/lower the
> > > > priority of GP
https://bugs.freedesktop.org/show_bug.cgi?id=99859
--- Comment #23 from erhar...@mailbox.org ---
Tried Glamor on a more recent xorg stack on my PM G5 11,2 which works perfectly
well! It's on a Radeon HD 6450 however, so a r600 card and not a radeonsi as
the HD 7750.
I am running:
sys-kernel/gento
Quoting Chris Wilson (2018-03-08 18:48:51)
> Quoting Matt Roper (2018-03-08 18:22:06)
> > * Option 2: Allow priority offset to be set in a much larger range
> >(e.g., [SHRT_MIN+1023,SHRT_MAX-1023]). This allows cgroups to have
> >effective priority ranges that don't overlap. cgroup rang
https://bugs.freedesktop.org/show_bug.cgi?id=105273
--- Comment #6 from erhar...@mailbox.org ---
Tried a Radeon HD 6450 on my PCIe PowerMac G5 11,2 for another comparison.
Graphics are rendered correctly! So it seems this bug is a specific r300 driver
problem, not a generic Big Endian problem.
$
https://bugs.freedesktop.org/show_bug.cgi?id=105401
Alex Deucher changed:
What|Removed |Added
Product|DRI |Mesa
Version|XOrg git
On Thu, Mar 08, 2018 at 06:55:34PM +, Chris Wilson wrote:
> Quoting Chris Wilson (2018-03-08 18:48:51)
> > Quoting Matt Roper (2018-03-08 18:22:06)
> > > * Option 2: Allow priority offset to be set in a much larger range
> > >(e.g., [SHRT_MIN+1023,SHRT_MAX-1023]). This allows cgroups to
On Thu, Mar 8, 2018 at 3:10 AM, Robert Foss wrote:
> Hey John,
>
>
> On 03/07/2018 12:19 AM, John Stultz wrote:
>>
>> As suggested by Alexandru-Cosmin Gheorghe:
>>
>> ConvertHALFormatToDrm logic would work only for 1 plane formats,
>> and probably gets rejected by drmModeAddFb2, but to save
>> deb
This patch adds support for DMT display modes over HDMI.
The modes timings configurations are from the Amlogic Vendor linux tree
and tested over multiples monitors.
Previously only a selected number of CEA modes were supported.
Only these following modes are supported with these changes:
- 640x48
https://bugzilla.kernel.org/show_bug.cgi?id=199047
--- Comment #7 from Johannes Hirte (johannes.hi...@datenkhaos.de) ---
(In reply to Alex Deucher from comment #6)
> Created attachment 274621 [details]
> possible fix
>
> Does this fix it?
Yes, fixed with this patch.
--
You are receiving this m
On Wed, Mar 07, 2018 at 10:36:24AM +0530, Viresh Kumar wrote:
> On 06-03-18, 08:37, Jordan Crouse wrote:
> > I'll try to explain but I might need Stephen or some of the other folks to
> > jump
> > in and save me.
>
> Maybe you should start using his kernel.org address then ? :)
>
> > On sdm845 t
https://bugs.freedesktop.org/show_bug.cgi?id=104854
--- Comment #2 from José Pekkarinen ---
Created attachment 137911
--> https://bugs.freedesktop.org/attachment.cgi?id=137911&action=edit
Initialization output on SMU firmware load.
Seems that autodetection of firmware method to load fails to g
https://bugs.freedesktop.org/show_bug.cgi?id=104854
--- Comment #3 from Alex Deucher ---
What kernel are you using? I don't see any way the fw loading type could not
be set correctly for any chip unless a module parameter was provided. Please
attach your full dmesg output. What module paramete
On Thu, 08 Mar 2018 12:06:46 +0200 Jani Nikula
wrote:
> On Wed, 07 Mar 2018, a...@linux-foundation.org wrote:
> > From: Andrew Morton
> > Subject: drivers/gpu/drm/i915/intel_guc_log.c: work around gcc-4.4.4 union
> > initializer issue
> >
> > gcc-4.4.4 has problems with initalizers of anon uni
https://bugs.freedesktop.org/show_bug.cgi?id=105401
--- Comment #3 from Andrey Grodzovsky ---
Please check your libdrm and verify it's version is 2.4.91
https://lists.freedesktop.org/archives/dri-devel/2018-March/168156.html
I believe it should be fixed by
amdgpu: Fix mistake in initial hole
https://bugs.freedesktop.org/show_bug.cgi?id=105401
Timothy Pearson changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #4 from Timothy
https://bugs.freedesktop.org/show_bug.cgi?id=93727
--- Comment #5 from erhar...@mailbox.org ---
Still core profile 3.2 on r600g, Mesa 18.0.0-rc4
$ glxinfo | grep -i opengl
OpenGL vendor string: X.Org
OpenGL renderer string: AMD CAICOS (DRM 2.49.0 / 4.9.85-gentoo)
OpenGL core profile version stri
On Thu, Mar 8, 2018 at 3:16 AM, Robert Foss wrote:
> Hey John,
>
> This patch looks good to me.
>
> I have yet to build it, and I haven't brought my HiKey960 up for testing
> quite yet.
>
>
> On 03/07/2018 12:19 AM, John Stultz wrote:
>>
>> This allows for importing buffers allocated from the
>> h
Am Montag, 5. März 2018, 23:22:53 CET schrieb Enric Balletbo i Serra:
> From: zain wang
>
> There's a race between when bridge_disable and when vop_crtc_disable
> are called. If the flush timer triggers a new psr work between these,
> we will operate eDP without power shutdowned by bridge_disable
1 - 100 of 128 matches
Mail list logo
