On 2019-09-12 at 00:15:32 +, Harry Wentland wrote:
> Adding a couple AMD guys.
>
> I know this is already merged but I have a few questions after some
> internal discussions.
>
> On 2019-05-07 12:27 p.m., Ramalingam C wrote:
> > On every hdcp revocation check request SRM is read from fw file
Hi,
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
> Gwan-gyeong Mun
> Sent: torstai 12. syyskuuta 2019 6.25
> To: intel-...@lists.freedesktop.org
> Cc: imir...@alum.mit.edu; dri-devel@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH
https://bugs.freedesktop.org/show_bug.cgi?id=103769
--- Comment #17 from DillanWatsica ---
This is the main thing that if we want to get education then we should do
everything for this. I can say that of you are willing to get education then
you can go beyond https://assignment-helpers.co.uk/assi
A full-screen memcpy() moves the console's shadow buffer to hardware; with
possibly significant runtime overhead. [1]
The console's dirty worker now waits for the vblank to rate limit the
output frequency. Screen output can pile up while waiting and there's a
chance that multiple screen updates ca
Before updating the display from the console's shadow buffer, the dirty
worker now waits for vblank. This allows several screen updates to pile
up and acts as a rate limiter.
v2:
* don't hold helper->lock while waiting for vblank
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_
Register constants are upper case. Fix MGAREG_Status accordingly.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +++---
drivers/gpu/drm/mgag200/mgag200_reg.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_
There's no VBLANK interrupt on Matrox chipsets. The workaround that is
being used here and in other free Matrox drivers is to program
to the value of and enable the VLINE interrupt. This triggers
an interrupt at the time when VBLANK begins.
VLINE uses separate registers for enabling and clearing
https://bugzilla.kernel.org/show_bug.cgi?id=204817
Bug ID: 204817
Summary: IP resume fail after changing dpm states rapidly
Product: Drivers
Version: 2.5
Kernel Version: 5.3.0-050300rc8-generic
Hardware: x86-64
OS: Linux
According to Bspec, GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet. It adds new VIDEO_DIP_GMP_DATA_SIZE for
GEN11. And it makes handle different register size for
HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN
platforms. It addresses Um
It attaches HDR metadata property to DP connector on GLK+.
It enables HDR metadata infoframe sdp on GLK+ to be used to send
HDR metadata to DP sink.
v2: Minor style fix
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 5 +
1 file changed
> -Original Message-
> From: Wentland, Harry
> Sent: Wednesday, September 11, 2019 8:16 PM
> To: Ramalingam C ; intel-
> g...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> daniel.vet...@intel.com
> Cc: gwan-gyeong@intel.com; Kumar, Ranjeet
> ; Deucher, Alexander
> ; Lakha,
Support for HDR10 video was introduced in DisplayPort 1.4.
On GLK+ platform, in order to use DisplayPort HDR10, we need to support
BT.2020 colorimetry and HDR Static metadata.
It implements the CTA-861-G standard for transport of static HDR metadata.
It enables writing of HDR metadata infoframe SDP
It refactors and renames a function which handled vsc sdp header and data
block setup for supporting colorimetry format.
Function intel_dp_setup_vsc_sdp handles vsc sdp header and data block
setup for pixel encoding / colorimetry format.
In order to use colorspace information of a connector, it add
Becasue between HDMI and DP have different colorspaces, it renames
drm_mode_create_colorspace_property() function to
drm_mode_create_hdmi_colorspace_property() function for HDMI connector.
And it adds drm_mode_create_dp_colorspace_property() function for creating
of DP colorspace property.
In order
Adding a couple AMD guys.
I know this is already merged but I have a few questions after some
internal discussions.
On 2019-05-07 12:27 p.m., Ramalingam C wrote:
> On every hdcp revocation check request SRM is read from fw file
> /lib/firmware/display_hdcp_srm.bin
>
According to section 5 of th
These changes are based on Jason's latest hmm branch.
Patch 1 was previously posted here [1] but was dropped from the orginal
series. Hopefully, the tests will reduce concerns about edge conditions.
I'm sure more tests could be usefully added but I thought this was a good
starting point.
[1] https
It attaches the colorspace connector property to a DisplayPort connector.
Based on colorspace change, modeset will be triggered to switch to a new
colorspace.
Based on colorspace property value create a VSC SDP packet with appropriate
colorspace. This would help to enable wider color gamut like BT
Allow hmm_range_fault() to return success (0) when the range has no access
(!(vma->vm_flags & VM_READ)). The range->pfns[] array will be filled with
range->values[HMM_PFN_NONE] in this case.
This allows the caller to get a snapshot of a range without having to
lookup the vma before calling hmm_rang
Allow hmm_range_fault() to return success (0) when the CPU pagetable
entry points to the special shared zero page.
The caller can then handle the zero page by possibly clearing device
private memory instead of DMAing a zero page.
Signed-off-by: Ralph Campbell
Cc: "Jérôme Glisse"
Cc: Jason Guntho
Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
header and data block setup for HDR Static Metadata. It enables writing of
HDR metadata infoframe SDP to panel. Support for HDR video was introduced
in DisplayPort 1.4. It implements the CTA-861-G standard for transport of
sta
On Wed, 2019-09-11 at 21:10 +0300, Ville Syrjälä wrote:
> On Wed, Sep 11, 2019 at 10:56:02AM -0700, José Roberto de Souza
> wrote:
> > This 3 non-atomic drivers all have the same function getting the
> > only encoder available in the connector, also atomic drivers have
> > this fallback. So moving
hmm_range_fault() calls find_vma() and walk_page_range() in a loop.
This is unnecessary duplication since walk_page_range() calls find_vma()
in a loop already.
Simplify hmm_range_fault() by defining a walk_test() callback function
to filter unhandled vmas.
This also fixes a bug where hmm_range_faul
Hi Dave and Daniel,
Here goes drm-intel-next-fixes-2019-09-11:
Few fixes on GGTT and PPGTT around pin, locks, fence and vgpu.
This also includes GVT fixes with two recent fixes:
one for recent guest hang regression and another for guest reset fix.
Thanks,
Rodrigo.
The following changes since c
On Wed, Sep 11, 2019 at 08:01:55PM +, Souza, Jose wrote:
> On Wed, 2019-09-11 at 21:10 +0300, Ville Syrjälä wrote:
> > On Wed, Sep 11, 2019 at 10:56:02AM -0700, José Roberto de Souza
> > wrote:
> > > This 3 non-atomic drivers all have the same function getting the
> > > only encoder available i
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #18 from Shmerl ---
Just for the reference, I'm using firmware from here:
https://people.freedesktop.org/~agd5f/radeon_ucode/navi10/
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #17 from Shmerl ---
(In reply to Timothy Arceri from comment #14)
> Are you sure it is hanging? There is a huge amount of stuttering due to the
> game compiling shaders in-game. Its really bad the first time I run the
> apitrace but
When BT.2020 Colorimetry output is used for DP, we should program BT.2020
Colorimetry to MSA and VSC SDP. It adds output_colorspace to
intel_crtc_state struct as a place holder of pipe's output colorspace.
In order to distinguish needed colorimetry for VSC SDP, it adds
intel_dp_needs_vsc_sdp functi
Stefan Wahren writes:
> Since release of the new BCM2835 PM driver there has been several reports
> of V3D probing issues. This is caused by timeouts during powering-up the
> GRAFX PM domain:
>
> bcm2835-power: Timeout waiting for grafx power OK
>
> I was able to reproduce this reliable on my R
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #36 from rol...@rptd.ch ---
# mkdir -p /etc/portage/patches/media-libs/mesa/
# cd /etc/portage/patches/media-libs/mesa/
wget 'https://gitlab.freedesktop.org/mesa/mesa/merge_requests/1852.patch'
--2019-09-11 18:35:51--
https://gitlab
Add self tests for HMM.
Signed-off-by: Ralph Campbell
---
MAINTAINERS|3 +
drivers/char/Kconfig | 11 +
drivers/char/Makefile |1 +
drivers/char/hmm_dmirror.c | 1504
include/Kbuild
https://bugs.freedesktop.org/show_bug.cgi?id=111459
--- Comment #6 from peter m ---
(In reply to tajgaividra from comment #5)
> Hi,
>
> Have you tried reverting the xorg amdgpu package to an older version? Of
> course that is just a workaround.
only kernel driver is used
dnf list available |
This 3 non-atomic drivers all have the same function getting the
only encoder available in the connector, also atomic drivers have
this fallback. So moving it a common place and sharing between atomic
and non-atomic drivers.
While at it I also removed the mention of
drm_atomic_helper_best_encoder(
On Wed, Sep 11, 2019 at 10:56:02AM -0700, José Roberto de Souza wrote:
> This 3 non-atomic drivers all have the same function getting the
> only encoder available in the connector, also atomic drivers have
> this fallback. So moving it a common place and sharing between atomic
> and non-atomic driv
Hi
Am 11.09.19 um 17:21 schrieb Ville Syrjälä:
> On Wed, Sep 11, 2019 at 05:08:45PM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 10.09.19 um 16:01 schrieb Ville Syrjälä:
>>> On Mon, Sep 09, 2019 at 04:06:33PM +0200, Thomas Zimmermann wrote:
Support for vblank requires VSYNC to signal an int
From: Dhinakaran Pandiyan
Currently we restrict the number of encoders that can be linked to
a connector to 3, increase it to match the maximum number of encoders
that can be initialized(32).
To more effiently do that lets switch from an array of encoder ids to
bitmask.
v2: Fixing missed return
Userspace requested command buffer allocations could be too large
to make as a contiguous allocation. Use vmalloc if necessary to
satisfy those allocations.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 +-
drivers/gpu/drm/virtio/virtgpu_vq.c| 78 +++
https://bugs.freedesktop.org/show_bug.cgi?id=111077
--- Comment #37 from Matt Turner ---
(In reply to rol...@rptd.ch from comment #36)
> # mkdir -p /etc/portage/patches/media-libs/mesa/
> # cd /etc/portage/patches/media-libs/mesa/
> wget 'https://gitlab.freedesktop.org/mesa/mesa/merge_requests/18
https://bugs.freedesktop.org/show_bug.cgi?id=109628
--- Comment #17 from peter m ---
updated to kernel 5.2.13-200.fc30.x86_64
dmesg prints no more WARNING messages, but screen still black after login
screen
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=111591
--- Comment #16 from vggl ---
"The games shaders use GLSL 4.30 which mean interpolation qualifiers must match
across shader interfaces otherwise it is a link-time error. In GLSL 4.40 this
restriction was relaxed."
I believe that relaxation cam
From: Allen Chen
This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.
Signed-off-by: Jitao Shi
Signed-off-by: Yilun Lin
Signed-off-by: Allen Chen
Signed-off-by: Pi-Hsun Shih
---
drivers/gpu/drm/bridge/Kconfig |7 +
drivers/gpu/drm/bridge/Makefile
The IT6505 is a high-performance DisplayPort 1.1a transmitter, fully compliant
with DisplayPort 1.1a, HDCP 1.3 specifications. The IT6505 supports color depth
of up to 36 bits (12 bits/color) and ensures robust transmission of
high-quality uncompressed video content, along with uncompressed and
From: Allen Chen
Add a DT binding documentation for IT6505.
Signed-off-by: Allen Chen
Signed-off-by: Pi-Hsun Shih
---
cros-ec does not have an associated driver that uses the standard Linux USB-C
driver class.
extcon is used to model the Type-C connector.(crbug.com/982932)
---
.../bindings
Add #cooling-cells for when the gpu acts as a cooling device.
Signed-off-by: Guido Günther
---
.../devicetree/bindings/display/etnaviv/etnaviv-drm.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
b/Documentation/d
Temperature and hysteresis were picked after the CPU.
Changes from v1:
- Update dt bindings
- Fix broken phandle
Guido Günther (2):
dts: arm64: imx8mq: Enable gpu passive throttling
dt-bindings: etnaviv: Add #cooling-cells
.../bindings/display/etnaviv/etnaviv-drm.txt | 1 +
arch/arm
Temperature and hysteresis were picked after the CPU.
Signed-off-by: Guido Günther
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 15 +++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 4fdd6
On Wed, Sep 4, 2019 at 3:26 AM Andrzej Hajda wrote:
> On 03.09.2019 18:18, John Stultz wrote:
> > On Mon, Sep 2, 2019 at 6:22 AM Andrzej Hajda wrote:
> >> On 30.08.2019 19:00, Rob Clark wrote:
> >>> On Thu, Aug 29, 2019 at 11:52 PM Andrzej Hajda
> >>> wrote:
> Of course it seems you have d
Presently, the driver code artificially limits test pattern mode to a
single pattern with fixed color selection. It being a kernel module
parameter makes switching "test pattern" <-> "proper output" modes
on-the-fly clunky and outright impossible if the driver is built into
the kernel.
To improve
Expose underlying implementation of bridge's enable/disable functions,
so it would be possible to use them in other parts of the driver.
Signed-off-by: Andrey Smirnov
Cc: Andrzej Hajda
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Cc: Cory Tusar
Cc: Chris Healy
Cc: Lucas Stach
Cc: dri-devel@lists
Everyone:
This series is a couple of patches exposing TestCtl register of
tc358767, which can be pretty handy when troubleshooting link problems.
Changes since [v1]:
- Debugfs moved into a standalone directory and is now created as
a part of probe()
- Added tstctl_lock to ensure m
On Thu, Sep 12, 2019 at 2:41 AM Qian Cai wrote:
>
>
>
> > On Sep 11, 2019, at 1:37 PM, Maxime Ripard
> > wrote:
> >
> > Hi,
> >
> > Le mer. 11 sept. 2019 à 19:35, Qian Cai a écrit :
> > The commit c0e09200dc08 ("drm: reorganise drm tree to be more future
> > proof.") changed the behavior from o
This patch depends on the vmbus side change of the definition of
struct hv_driver.
Signed-off-by: Dexuan Cui
---
This patch is basically a pure Hyper-V specific change and it has a
build dependency on the commit 271b2224d42f ("Drivers: hv: vmbus: Implement
suspend/resume for VSC drivers for hibe
On Wed, 11 Sep 2019 13:48:36 -0500
Dan Murphy wrote:
> >> @@ -535,6 +538,13 @@ static int lm3630a_probe(struct i2c_client *client,
> >>}
> >>pchip->pdata = pdata;
> >>
> >> + pchip->enable_gpio = devm_gpiod_get_optional(&client->dev, "enable",
> >> +
Hi Kieran, Jacopo,
On Wed, Sep 11, 2019 at 8:16 PM Kieran Bingham
wrote:
> On 06/09/2019 14:54, Jacopo Mondi wrote:
> > Add CMM units to Renesas R-Car Gen3 SoC that support it, and reference them
> > from the Display Unit they are connected to.
> >
> > Sort the 'vsps' and 'renesas,cmm' entries in
Add direct support for the r8a77980 (V3H).
The V3H shares a common, compatible configuration with the r8a77970
(V3M) so that device info structure is reused.
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff
Hi Jacopo,
On 06/09/2019 14:54, Jacopo Mondi wrote:
> Add device tree bindings documentation for the Renesas R-Car Display
> Unit Color Management Module.
>
> CMM is the image enhancement module available on each R-Car DU video
> channel on R-Car Gen2 and Gen3 SoCs (V3H and V3M excluded).
>
> Si
On 9/11/19 5:25 AM, Daniel Thompson wrote:
On Tue, Sep 10, 2019 at 11:29:09PM +0200, Andreas Kemnade wrote:
For now just enable it in the probe function to allow i2c
access. Disabling also means resetting the register values
to default and according to the datasheet does not give
power savings
Hi Jacopo,
On 06/09/2019 14:54, Jacopo Mondi wrote:
> Enable the GAMMA_LUT KMS property using the framework helpers to
> register the property and set the associated gamma table maximum size.
>
> Reviewed-by: Ulrich Hecht
> Reviewed-by: Laurent Pinchart
LGTM.
Reviewed-by: Kieran Bingham
> S
Hi Jacopo,
On 06/09/2019 14:54, Jacopo Mondi wrote:
> Add CMM to the list of supported features for Gen3 SoCs that provide it:
> - R8A7795
> - R8A7796
> - R8A77965
> - R8A7799x
>
> Leave R8A77970 out as V3M and V3H are the only Gen3 SoCs that do not
> support CMM.
>
> Reviewed-by: Ulrich Hecht
Andreas
On 9/11/19 5:08 AM, Daniel Thompson wrote:
On Tue, Sep 10, 2019 at 11:29:08PM +0200, Andreas Kemnade wrote:
add enable-gpios to describe HWEN pin
Signed-off-by: Andreas Kemnade
Acked-by: Daniel Thompson
---
changes in v2: add example
.../bindings/leds/backlight/lm3630a-backlight
Hi Jacopo,
On 06/09/2019 14:54, Jacopo Mondi wrote:
> Enable/disable the CMM associated with a CRTC at CRTC start and stop
> time and enable the CMM unit through the Display Extensional Functions
> register at group setup time.
>
> Reviewed-by: Ulrich Hecht
> Reviewed-by: Laurent Pinchart
> Sig
Hi Jacopo,
On 06/09/2019 14:54, Jacopo Mondi wrote:
> Add CMM units to Renesas R-Car Gen3 SoC that support it, and reference them
> from the Display Unit they are connected to.
>
> Sort the 'vsps' and 'renesas,cmm' entries in the DU unit consistently
> in all the involved DTS.
I think if you cho
Factor function in preparation to generating scatterlist prior to locking.
Signed-off-by: David Riley
---
drivers/gpu/drm/virtio/virtgpu_vq.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c
b/drivers/gpu/drm/virtio/vi
Userspace requested command buffer allocations could be too large
to make as a contiguous allocation. Use vmalloc if necessary to
satisfy those allocations.
v1: Initial version.
v2: Properly account for number of free descriptors required.
v3: Remove offset handling for vmalloc'd buffers.
v4: Reb
> On Sep 11, 2019, at 1:37 PM, Maxime Ripard wrote:
>
> Hi,
>
> Le mer. 11 sept. 2019 à 19:35, Qian Cai a écrit :
> The commit c0e09200dc08 ("drm: reorganise drm tree to be more future
> proof.") changed the behavior from only compiling drm/ if CONFIG_DRM=y
> to always compiling drm/. This r
They were based off of Linus' https://github.com/torvalds/linux
master from yesterday.
I can rebase onto drm-misc-next.
On Tue, Sep 10, 2019 at 10:12 PM Gerd Hoffmann wrote:
>
> On Tue, Sep 10, 2019 at 01:06:50PM -0700, David Riley wrote:
> > Factor function in preparation to generating scatter
The commit c0e09200dc08 ("drm: reorganise drm tree to be more future
proof.") changed the behavior from only compiling drm/ if CONFIG_DRM=y
to always compiling drm/. This restores the behavior, so people don't
need to waste time compiling stuff they don't need.
Fixes: c0e09200dc08 ("drm: reorganis
For now just enable it in the probe function to allow i2c
access. Disabling also means resetting the register values
to default and according to the datasheet does not give
power savings.
Tested on Kobo Clara HD.
Signed-off-by: Andreas Kemnade
---
changes in v2:
- simplification
- correct gpio d
add enable-gpios to describe HWEN pin
Signed-off-by: Andreas Kemnade
Acked-by: Daniel Thompson
---
changes in v2: added example
changes in v3: added Acked-by
.../bindings/leds/backlight/lm3630a-backlight.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git
a/Documentation/devi
To be able to handle the HWEN pin of the lm3630a, add
an enable gpio to the driver and a property.
Tested on Kobo Clara HD.
Changes in v2:
simplification and reordering
Changes in v3:
added acked-by
removed legacy include
Andreas Kemnade (2):
dt-bindings: backlight: lm3630a: add enable_gpios
On Wed, Sep 11, 2019 at 12:52:04AM -0700, Dmitry Torokhov wrote:
> This series attempts to add support for software nodes to gpiolib, using
> software node references that were introduced recently. This allows us
> to convert more drivers to the generic device properties and drop
> support for cust
On Thu, Sep 12, 2019 at 12:54 AM Jernej Škrabec wrote:
>
> Dne sreda, 11. september 2019 ob 18:23:59 CEST je Neil Armstrong napisal(a):
> > On 11/09/2019 10:26, Cheng-Yi Chiang wrote:
> > > From: Yakir Yang
> > >
> > > When transmitting IEC60985 linear PCM audio, we configure the
> > > Aduio Samp
Dne sreda, 11. september 2019 ob 18:23:59 CEST je Neil Armstrong napisal(a):
> On 11/09/2019 10:26, Cheng-Yi Chiang wrote:
> > From: Yakir Yang
> >
> > When transmitting IEC60985 linear PCM audio, we configure the
> > Aduio Sample Channel Status information in the IEC60958 frame.
> > The status b
On 11/09/2019 10:26, Cheng-Yi Chiang wrote:
> From: Yakir Yang
>
> When transmitting IEC60985 linear PCM audio, we configure the
> Aduio Sample Channel Status information in the IEC60958 frame.
> The status bit is already available in iec.status of hdmi_codec_params.
>
> This fix the issue that
Please use C style comments rather than C++.
Alex
From: Thomas Zimmermann
Sent: Wednesday, September 4, 2019 7:56 AM
To: dan...@ffwll.ch ; nor...@tronnes.org ;
airl...@linux.ie ; rong.a.c...@intel.com
; feng.t...@intel.com ;
ying.hu...@intel.com ; s...@poorly.r
Hi Jacopo,
On 06/09/2019 14:54, Jacopo Mondi wrote:
> Document the newly added 'cmms' property which accepts a list of phandle
> and channel index pairs that point to the CMM units available for each
> Display Unit output video channel.
>
> Signed-off-by: Jacopo Mondi
> Reviewed-by: Laurent Pinc
Hi Jacopo,
On 06/09/2019 14:43, Jacopo Mondi wrote:
> Add a driver for the R-Car Display Unit Color Correction Module.
>
> In most of Gen3 SoCs, each DU output channel is provided with a CMM unit
> to perform image enhancement and color correction.
>
> Add support for CMM through a driver that s
>
> qxl has two modes: "native" (used by the drm driver) and "vga" (vga
> compatibility mode, typically used for boot display and firmware
> framebuffers).
>
> Accessing any vga ioport will switch the qxl device into vga mode.
> The qxl driver never does that, but other drivers accessing vga port
> -Original Message-
> From: Hans de Goede
> Sent: Tuesday, September 10, 2019 5:36 AM
> To: Michel Dänzer ; Deucher, Alexander
> ; Koenig, Christian
> ; Zhou, David(ChunMing)
>
> Cc: David Airlie ; dri-devel@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org; Daniel Vetter
> Subje
On Wed, Sep 11, 2019 at 05:08:45PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 10.09.19 um 16:01 schrieb Ville Syrjälä:
> > On Mon, Sep 09, 2019 at 04:06:33PM +0200, Thomas Zimmermann wrote:
> >> Support for vblank requires VSYNC to signal an interrupt, which is broken
> >> on Matrox chipsets.
> >
Hi
Am 10.09.19 um 16:01 schrieb Ville Syrjälä:
> On Mon, Sep 09, 2019 at 04:06:33PM +0200, Thomas Zimmermann wrote:
>> Support for vblank requires VSYNC to signal an interrupt, which is broken
>> on Matrox chipsets.
>
> I don't remember there being anything wrong with the vsync interrupt.
> What
On 9/11/19 4:06 PM, Koenig, Christian wrote:
Am 11.09.19 um 12:10 schrieb Thomas Hellström (VMware):
[SNIP]
The problem seen in TTM is that we want to be able to change the
vm_page_prot from the fault handler, but it's problematic since we
have the mmap_sem typically only in read mode. Hence the
Hi Dave & Daniel -
A couple more fixes for v5.3, both cc: stable.
drm-intel-fixes-2019-09-11:
Final drm/i915 fixes for v5.3:
- Fox DP MST high color depth regression
- Fix GPU hangs on Vulkan compute workloads
BR,
Jani.
The following changes since commit f74c2bb98776e2de508f4d607cd51987306511
https://bugs.freedesktop.org/show_bug.cgi?id=111659
Michel Dänzer changed:
What|Removed |Added
Attachment #145334|text/x-log |text/plain
mime type|
Am 11.09.19 um 12:10 schrieb Thomas Hellström (VMware):
[SNIP]
>>> The problem seen in TTM is that we want to be able to change the
>>> vm_page_prot from the fault handler, but it's problematic since we
>>> have the mmap_sem typically only in read mode. Hence the fake vma
>>> hack. From what I can
On Tue, 10 Sep 2019 at 08:36, Greg KH wrote:
>
> On Thu, Sep 05, 2019 at 10:17:45AM -0600, Mathieu Poirier wrote:
> > From: Roger Quadros
> >
> > commit 42bf02ec6e420e541af9a47437d0bdf961ca2972 upstream
> >
> > Some platforms (e.g. TI's DRA7 USB2 instance) have more trouble
> > with the metastabi
On 2019-09-11 4:47 a.m., Benjamin Gaignard wrote:
> Remove always false comparisons due to limited range of nfl_bpg_offset
> and scale_increment_interval fields.
> Warnings detected when compiling with W=1.
>
> Signed-off-by: Benjamin Gaignard
Reviewed-by: Harry Wentland
Harry
> ---
> driver
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #15 from tempel.jul...@gmail.com ---
To clarify: There is no connection to any compositor. You can also reproduce
the issue with any desktop environment where you can disable the compositor.
Instead of using a compositor then, simply
Am 11.09.19 um 13:50 schrieb Huang, Ray:
> From: Alex Deucher
>
> If one bo is secure (created with AMDGPU_GEM_CREATE_ENCRYPTED), the TMZ bits
> of
> PTEs that belongs that bo should be set. Then psp is able to protect the pages
> of this bo to avoid the access from an "untrust" domain such as CP
Patches #1-#4, #8, #9 are Reviewed-by: Christian König
Patches #10, #11 are Acked-by: Christian König
Patches #7 and the resulting workaround in patch #13 are a clear NAK.
The ttm_mem_reg can't be used like this to get back to the ttm_bo object.
Going to reply separately on patch #14 regardi
FYI this is actually version 3 of the patch set posted at
[1] and [2]
[1] https://lists.freedesktop.org/archives/dri-devel/2019-July/227823.html
[2] https://lists.freedesktop.org/archives/dri-devel/2019-July/228074.html
Am 11.09.19 um 14:03 schrieb Thomas Zimmermann:
> The ast and mgag200 drivers
The VRAM helper's vmap interfaces provide pinning and mapping of BO
memory. This patch replaces the respective code in ast cursor handling.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_mode.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git
The ast and mgag200 drivers pin() and kmap() cursor buffers; essentially
reimplementing vmap(). We can share some code by using the respective
functionality from GEM VRAM buffer objects.
Thomas Zimmermann (3):
drm/vram: Provide vmap and vunmap operations for GEM VRAM objects
drm/ast: Use drm_g
The implementation of vmap and vunmap for GEM VRAM helpers is
already in PRIME helpers. The patch moves the operations to separate
functions and exports them for general use.
v3:
* remove v2's obsolete note on ref-counting
v2:
* fix documentation
* add cross references to f
The VRAM helper's vmap interfaces provide pinning and mapping of BO
memory. This patch replaces the respective code in mgag200 cursor handling.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_cursor.c | 22 +++---
1 file changed, 7 insertions(+), 15 deletions
This patch expands the context control function to support trusted flag while we
want to set command buffer in trusted mode.
Signed-off-by: Huang Rui
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 5 +++--
drivers/gpu/dr
This patch expands the emit_tmz function to support trusted flag while we want
to set command buffer in trusted mode.
Signed-off-by: Huang Rui
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.h | 4 ++--
drivers/gpu/drm/amd/
From: Alex Deucher
If one bo is secure (created with AMDGPU_GEM_CREATE_ENCRYPTED), the TMZ bits of
PTEs that belongs that bo should be set. Then psp is able to protect the pages
of this bo to avoid the access from an "untrust" domain such as CPU.
v1: design and draft the skeletion of tmz bits se
While user mode submit a command with secure context, we should set the command
buffer with trusted mode.
v2: fix the null job pointer while in vmid 0 submission.
Signed-off-by: Huang Rui
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 +
drivers/gpu/drm/amd/amdgpu/am
From: Alex Deucher
Add a flag to the GEM_CREATE ioctl to create encrypted buffers.
Buffers with this flag set will be created with the TMZ bit set
in the PTEs or engines accessing them. This is required in order
to properly access the data from the engines.
Signed-off-by: Alex Deucher
Reviewed
From: Alex Deucher
Add a flag for when allocating a context to flag it as
secure. The kernel driver will use this flag to determine
whether a rendering context is secure or not so that the
engine can be transitioned between secure or unsecure
or the work can be submitted to a secure queue depend
1 - 100 of 143 matches
Mail list logo
