https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #16 from Clément Guérin (li...@protonmail.com) ---
Nicholas, I found a TODO in the freesync btr code for pre-DCE12 GPUs
(pre-Vega?).
https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/amd/display/modules/freesync/freesync.c#
https://bugs.freedesktop.org/show_bug.cgi?id=108514
Paul Dufresne changed:
What|Removed |Added
Summary|heavy screen flickering |heavy screen flickering
Hi Guido,
Thanks for picking this up. It's interesting to see that a lot has
changed in the PHY API and the phy can be now configured through the
API instead of exported function as I did in the NXP tree.
I was going through your implementation and I noticed you also added
the phy_ref clock to th
* Tomi Valkeinen [190206 16:09]:
> On 06/02/2019 18:00, Tony Lindgren wrote:
>
> > OK I'll give it a try. Based on a quick glance, we need to still
> > check for enabled regulator to avoid unpaired calls.
> >
> >> static int dsi_dump_dsi_clocks(struct seq_file *s, void *p)
> >> @@ -4108,6 +4094
Hi,
On 06/02/19 5:55 PM, Maxime Ripard wrote:
> Hi Kishon,
>
> On Wed, Feb 06, 2019 at 05:43:12PM +0530, Kishon Vijay Abraham I wrote:
>> On 05/02/19 2:16 PM, Daniel Vetter wrote:
>>> On Mon, Feb 04, 2019 at 03:33:31PM +0530, Kishon Vijay Abraham I wrote:
On 21/01/19 9:15 PM, Maxim
From: Melchior Franz
The FB_PRE_INIT_FB option keeps the kernel from reinitializing the display
and prevents flickering during the transition from a bootloader splash
screen to the kernel logo screen.
Make this option available for the mxsfb driver.
Signed-off-by: Melchior Franz
Signed-off-by:
Hi,
On 05/02/19 2:16 PM, Daniel Vetter wrote:
> On Mon, Feb 04, 2019 at 03:33:31PM +0530, Kishon Vijay Abraham I wrote:
>>
>>
>> On 21/01/19 9:15 PM, Maxime Ripard wrote:
>>> Hi,
>>>
>>> Here is a set of patches to allow the phy framework consumers to test and
>>> apply runtime configurations.
>>>
On Wed, Jan 30, 2019 at 11:31:23AM +, Brian Starkey wrote:
>
> On Tue, Jan 29, 2019 at 03:44:53PM -0800, Liam Mark wrote:
> > On Fri, 18 Jan 2019, Liam Mark wrote:
> >
> > > On Fri, 18 Jan 2019, Andrew F. Davis wrote:
> > >
> > > > On 1/18/19 12:37 PM, Liam Mark wrote:
> > > > > The ION begi
On Fri, 25 Jan 2019 at 11:35, Ard Biesheuvel wrote:
>
> On Fri, 25 Jan 2019 at 12:30, Christian König
> wrote:
> >
> > Am 25.01.19 um 09:43 schrieb Ard Biesheuvel:
> > > On Thu, 24 Jan 2019 at 15:01, Alex Deucher wrote:
> > >> On Thu, Jan 24, 2019 at 9:00 AM Ard Biesheuvel
> > >> wrote:
> > >>>
* Tomi Valkeinen [190206 09:13]:
> On 05/02/2019 19:58, Tony Lindgren wrote:
> > * Tomi Valkeinen [190205 11:07]:
> >> Yep... So there's the DSI internal code which needs to deal with ulps
> >> and disconnect_lanes, and then the external interface to the DSI PLL (so
> >> that DPI can use DSI PLL)
https://bugs.freedesktop.org/show_bug.cgi?id=108514
Paul Dufresne changed:
What|Removed |Added
See Also||https://launchpad.net/bugs/
Hi Dave/Daniel,
Fixes for v5.0-rc6. :)
drm-misc-fixes-2019-02-07:
drm-misc-fixes for v5.0-rc6:
- Fixes to omap/dsi encoder.
- Clock fix for sun4i.
- Licensing header fix for rockchip.
- Fix division by zero in the mode when trying to set a mode on
i915 with GVT-g enabled.
The following changes
https://bugs.freedesktop.org/show_bug.cgi?id=109561
--- Comment #4 from Nicolai Hähnle ---
Yeah, sorry, I wrote the patch directly on top of the offending commit for
testing purposes.
--
You are receiving this mail because:
You are the assignee for the bug.__
Hi,
On Mon, 2019-01-21 at 16:45 +0100, Maxime Ripard wrote:
> Now that we have everything in place in the PHY framework to deal in a
> generic way with MIPI D-PHY phys, let's convert our PHY driver and its
> associated DSI driver to that new API.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Pa
Hi,
On Wed, 2019-01-09 at 10:33 +0100, Maxime Ripard wrote:
> Now that we have everything in place in the PHY framework to deal in a
> generic way with MIPI D-PHY phys, let's convert our PHY driver and its
> associated DSI driver to that new API.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Pa
Hi,
On Mon, 2019-01-21 at 16:45 +0100, Maxime Ripard wrote:
> Now that our MIPI D-PHY driver has been converted to the phy framework,
> let's move it into the drivers/phy directory.
>
> Signed-off-by: Maxime Ripard
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> ---
> drivers/gpu/drm/sun4i/K
On Thu, Feb 7, 2019 at 3:17 AM Eric Anholt wrote:
>
> Qiang Yu writes:
>
> > From: Lima Project Developers
> >
> > Signed-off-by: Andreas Baierl
> > Signed-off-by: Erico Nunes
> > Signed-off-by: Heiko Stuebner
> > Signed-off-by: Marek Vasut
> > Signed-off-by: Neil Armstrong
> > Signed-off-b
This makes it possible to pass a connector with an already
attached external encoder into the simple KMS helper.
This is helpful for my MCDE drivers, as it is pretty simple
but uses DSI to communicate with the displays and bridges.
DSI requires the use of the DSI bus which in turn requires
us to s
This adds the device tree bindings for the ST-Ericsson
Multi Channel Display Engine MCDE as found in the U8500
SoCs.
Cc: devicet...@vger.kernel.org
Signed-off-by: Linus Walleij
---
.../devicetree/bindings/display/ste,mcde.txt | 110 ++
1 file changed, 110 insertions(+)
create m
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.1-wip
head: c05834c8acc8278f87203cf4ec2a513be3a6aa7d
commit: 67dd1a36334ffce82bebeb2d633e152aa436d370 [212/267] drm/amdgpu: Add
AMDGPU_CHUNK_ID_SCHEDULED_DEPENDENCIES
smatch warnings:
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1096 am
This adds a driver for the ST-Ericsson MCDE.
I had to come up with some way to support passing an external
encoder to the simple KMS helper to make DSI work with the
simple KMS helper.
This work was motivated by the ongoing work on the LIMA driver,
as Ux500 has the MALI400 so once that driver is
This adds and updates the device tree nodes for the MCDE
display controller and connects the Samsung display to
the TVK1281618 user interface board (UIB) so we get
nicely working graphics on this reference design.
Signed-off-by: Linus Walleij
---
arch/arm/boot/dts/ste-dbx5x0.dtsi | 36 +
Hi,
On Mon, 2019-01-21 at 16:45 +0100, Maxime Ripard wrote:
> The current configuration of the DSI bridge and its associated D-PHY is
> intertwined. In order to ease the future conversion to the phy framework
> for the D-PHY part, let's split the configuration in two.
See below about a silly mist
A BO's address has to be at least the minimum offset. Sharing this
test in ttm_bo_mmap() removes code from drivers. A full buffer-address
validation is still done within drm_vma_offset_lockup_locked().
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 9 ++--
The vboxvideo driver mmaps BOs at 0x1000 or higher. Changing the
offset to 0x1 aligns the driver with all other DRM drivers.
Signed-off-by: Thomas Zimmermann
---
drivers/staging/vboxvideo/vbox_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/v
Almost all TTM-based drivers use the same values for the mmap-able
range of BO addresses. Each driver therefore duplicates the
DRM_FILE_PAGE_OFFSET constant. OTOH, the mmap range's size is not
configurable by drivers.
This patch set replaces driver-specific configuration with a single
setup. All
GEM defines DRM_FILE_PAGE_OFFSET_{START,SIZE} constants for the
mmap-able range of addresses. TTM can use them as well.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem.c | 17 -
drivers/gpu/drm/ttm/ttm_bo.c| 4 ++--
drivers/gpu/drm/ttm/ttm_bo_vm.c | 2 +-
The parameter file_page_offset is a constant shared by all drivers. Just
replace it with the constant itself.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 1 -
drivers/gpu/drm/ast/ast_ttm.c | 1 -
drivers/gpu/drm/bochs/bochs_mm.c| 1
Most TTM drivers define the constant DRM_FILE_PAGE_OFFSET of the same
value. The only exception is vboxvideo, which is being converted to the
new offset by this patch. Unifying the constants in a single place
simplifies the driver code.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/am
On 06/02/2019 18:29, Tony Lindgren wrote:
> OK. Looks good to me otherwise.
>
> So I guess we should fix. Do you want me to post it all
> as a single patch after some testing?
Yes please =)
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-
On Wed, Feb 06, 2019 at 09:14:55PM +0800, Qiang Yu wrote:
> Kernel DRM driver for ARM Mali 400/450 GPUs.
>
> Since last RFC, all feedback has been addressed. Most Mali DTS
> changes are already upstreamed by SoC maintainers. The kernel
> driver and user-kernel interface are quite stable for severa
On Thu, Feb 07, 2019 at 09:44:46AM +0100, Paul Kocialkowski wrote:
> Hi,
>
> On Mon, 2019-01-21 at 16:45 +0100, Maxime Ripard wrote:
> > The current configuration of the DSI bridge and its associated D-PHY is
> > intertwined. In order to ease the future conversion to the phy framework
> > for the
On Thu, Feb 07, 2019 at 09:36:44AM +0100, Linus Walleij wrote:
> This makes it possible to pass a connector with an already
> attached external encoder into the simple KMS helper.
>
> This is helpful for my MCDE drivers, as it is pretty simple
> but uses DSI to communicate with the displays and br
Hi Kishon,
On Wed, Feb 06, 2019 at 06:00:19PM +0530, Kishon Vijay Abraham I wrote:
> On 06/02/19 5:55 PM, Maxime Ripard wrote:
> > On Wed, Feb 06, 2019 at 05:43:12PM +0530, Kishon Vijay Abraham I wrote:
> >> On 05/02/19 2:16 PM, Daniel Vetter wrote:
> >>> On Mon, Feb 04, 2019 at 03:33:31PM +0530,
https://bugs.freedesktop.org/show_bug.cgi?id=108898
--- Comment #1 from Eero Tamminen ---
Hangs are still happening with the latest Mesa (a203eaa4f4fb) and drm-tip
kernel (v5.0-rc4) git versions:
[ 2776.782754] Iteration 3/3: bin/testfw_app --gfx glfw --gl_api desktop_core
--width 1920 --height 1
Am 07.02.19 um 09:59 schrieb Thomas Zimmermann:
> Almost all TTM-based drivers use the same values for the mmap-able
> range of BO addresses. Each driver therefore duplicates the
> DRM_FILE_PAGE_OFFSET constant. OTOH, the mmap range's size is not
> configurable by drivers.
>
> This patch set replac
Am 07.02.19 um 10:09 schrieb Daniel Vetter:
On Wed, Feb 06, 2019 at 09:14:55PM +0800, Qiang Yu wrote:
Kernel DRM driver for ARM Mali 400/450 GPUs.
Since last RFC, all feedback has been addressed. Most Mali DTS
changes are already upstreamed by SoC maintainers. The kernel
driver and user-kernel
Hi,
On 14/01/2019 17:36, Ayan Halder wrote:
> On Thu, Jan 10, 2019 at 03:57:09AM +0800, Randy Li wrote:
>> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
>> channel video format.
>>
>> P012 is a planar 4:2:0 YUV 12 bits per channel
>>
>> P016 is a planar 4:2:0 YUV with interleav
Am 07.02.19 um 10:36 schrieb Koenig, Christian:
> Am 07.02.19 um 09:59 schrieb Thomas Zimmermann:
>> Almost all TTM-based drivers use the same values for the mmap-able
>> range of BO addresses. Each driver therefore duplicates the
>> DRM_FILE_PAGE_OFFSET constant. OTOH, the mmap range's size is not
Hi
Am 07.02.19 um 09:59 schrieb Thomas Zimmermann:
> Most TTM drivers define the constant DRM_FILE_PAGE_OFFSET of the same
> value. The only exception is vboxvideo, which is being converted to the
> new offset by this patch. Unifying the constants in a single place
> simplifies the driver code.
J
On Mon, Jan 28, 2019 at 06:22:58PM +0100, Daniel Vetter wrote:
> Compared to the RFC[1] no changes to the patch itself, but igt moved
> forward a lot:
>
> - gitlab CI builds with: reduced configs/libraries, arm cross build
> and a sysroot build (should address all the build/cross platform
> co
https://bugs.freedesktop.org/show_bug.cgi?id=108689
Francesco Balestrieri changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |tvrtko.ursulin@linux.intel.
Hi Dave,
Just adding s5pv210 SoC support of rotator module and changing
email address of scaler module author.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit 2cc3b81dfa7f7de0d647e7f1473de811eef8b0de:
Merge tag 'drm-intel-next-2
Hi all,
In commit
4cbfa1e6c09e ("drm/vmwgfx: Fix setting of dma masks")
Fixes tag
Fixes: 0d00c488f3de: ("drm/vmwgfx: Fix the driver for large dma addresses")
has these problem(s):
- ':' unexpected after SHA1
In commit
479d59026fe4 ("drm/vmwgfx: Also check for crtc status while check
Op 06-02-2019 om 19:32 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> The fuzzy drm_calc_{h,v}scale_relaxed() helpers are no longer used.
> Throw them in the bin.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_rect.c | 108 -
> include/drm/drm_
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #17 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
I can reproduce the issue but vsync needs to be on. I'd recommend turning vsync
off for now to avoid flickering.
The issue lies in how amdgpu_dm handles waiting for vblank
Hi,
On Wed, Feb 06, 2019 at 02:28:39AM +0800, Chen-Yu Tsai wrote:
> > +static u16 sun6i_dsi_get_drq_edge1(struct sun6i_dsi *dsi,
> > + struct drm_display_mode *mode,
> > + u16 line_num)
> > +{
> > + struct mipi_dsi_device *dev
>
> From: Daniel Vetter
>
> While typing these I think doing an s/component_master/aggregate/ would be
> useful:
> - it's shorter :-)
> - I think component/aggregate is much more meaningful naming than
> component/puppetmaster or something like that. At least to my
> English ear "aggregate"
> All HDCP1.4 routines are gathered together, followed by the generic functions
> those can be extended for HDCP2.2 too.
>
> Signed-off-by: Ramalingam C
> Acked-by: Daniel Vetter
> Reviewed-by: Uma Shankar
Reviewed-by: Tomas Winkler
> ---
> drivers/gpu/drm/i915/intel_hdcp.c | 118 +++
>
> Header defines the interface for the I915 and MEI_HDCP drivers.
> This interface is specific to the usage of mei_hdcp from gen9+ platforms for
> ME FW based HDCP2.2 services.
>
> And Generic HDCP2.2 protocol specific definitions are added at
> drm/drm_hdcp.h.
>
> v2:
> Commit msg is enhanc
> v2:
> mei interface handle is protected with mutex. [Chris Wilson]
> v3:
> Notifiers are used for the mei interface state.
> v4:
> Poll for mei client device state
> Error msg for out of mem [Uma]
> Inline req for init function removed [Uma]
> v5:
> Rebase as Part of reordering.
> C
On Thu, Feb 7, 2019 at 5:09 PM Daniel Vetter wrote:
>
> On Wed, Feb 06, 2019 at 09:14:55PM +0800, Qiang Yu wrote:
> > Kernel DRM driver for ARM Mali 400/450 GPUs.
> >
> > Since last RFC, all feedback has been addressed. Most Mali DTS
> > changes are already upstreamed by SoC maintainers. The kerne
On Thu, Feb 7, 2019 at 10:20 AM Ard Biesheuvel
wrote:
>
> On Wed, 6 Feb 2019 at 19:38, Christian König
> wrote:
> >
> > Am 06.02.19 um 18:23 schrieb Ard Biesheuvel:
> > > On Fri, 25 Jan 2019 at 11:35, Ard Biesheuvel
> > > wrote:
> > >> On Fri, 25 Jan 2019 at 12:30, Christian König
> > >> wrote
On Thu, Feb 7, 2019 at 5:39 PM Christian König
wrote:
>
> Am 07.02.19 um 10:09 schrieb Daniel Vetter:
> > On Wed, Feb 06, 2019 at 09:14:55PM +0800, Qiang Yu wrote:
> >> Kernel DRM driver for ARM Mali 400/450 GPUs.
> >>
> >> Since last RFC, all feedback has been addressed. Most Mali DTS
> >> change
On Thu, Feb 07, 2019 at 11:21:52PM +0800, Qiang Yu wrote:
> On Thu, Feb 7, 2019 at 5:09 PM Daniel Vetter wrote:
> >
> > On Wed, Feb 06, 2019 at 09:14:55PM +0800, Qiang Yu wrote:
> > > Kernel DRM driver for ARM Mali 400/450 GPUs.
> > >
> > > Since last RFC, all feedback has been addressed. Most Mal
On 2/7/2019 8:43 PM, Winkler, Tomas wrote:
v2:
mei interface handle is protected with mutex. [Chris Wilson]
v3:
Notifiers are used for the mei interface state.
v4:
Poll for mei client device state
Error msg for out of mem [Uma]
Inline req for init function removed [Uma]
v5:
Re
https://bugzilla.kernel.org/show_bug.cgi?id=202511
--- Comment #7 from Michael A. Leonetti (mikealeone...@gmail.com) ---
It could be special. If so I'd love to know what it is that I'm doing wrong. So
far all of the 4.17 kernels I've tried works and Windows works on the laptop.
I'll see if I can g
https://bugzilla.kernel.org/show_bug.cgi?id=202511
--- Comment #8 from Bjorn Helgaas (bhelg...@google.com) ---
Even if this is "special", e.g., some strange kconfig or build/install issue,
this is a really painful issue to debug. It would be tremendous if we could
fail more gracefully, with some
https://bugs.freedesktop.org/show_bug.cgi?id=109150
--- Comment #2 from Emil Velikov ---
The log says
systemd-logind: logind integration requires -keeptty and -keeptty was not
provided, disabling logind integration
Thus the FD is handled manually and for some reason fails on your end. Normally
On Tue, Feb 05, 2019 at 07:22:32PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> >Ville Syrjälä
> >Sent: Tuesday, February 5, 2019 11:43 PM
> >To: Shankar, Uma
> >Cc: intel-...@lists.freedesktop.org
On Thu, 2019-02-07 at 09:59 +0100, Thomas Zimmermann wrote:
> Most TTM drivers define the constant DRM_FILE_PAGE_OFFSET of the same
> value. The only exception is vboxvideo, which is being converted to
> the
> new offset by this patch. Unifying the constants in a single place
> simplifies the drive
Am 07.02.19 um 16:33 schrieb Qiang Yu:
> On Thu, Feb 7, 2019 at 5:39 PM Christian König
> wrote:
>> Am 07.02.19 um 10:09 schrieb Daniel Vetter:
>>> On Wed, Feb 06, 2019 at 09:14:55PM +0800, Qiang Yu wrote:
Kernel DRM driver for ARM Mali 400/450 GPUs.
Since last RFC, all feedback has
https://bugzilla.kernel.org/show_bug.cgi?id=202511
--- Comment #9 from Christian König (christian.koe...@amd.com) ---
Yeah, I also would be really interested what the root cause is.
As far as I know we don't have any large per CPU data in amdgpu, so no idea how
this can happen.
--
You are recei
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #15 from Paul Dufresne ---
Created attachment 143324
--> https://bugs.freedesktop.org/attachment.cgi?id=143324&action=edit
Paul's dmesg with drm.debug=4 on kernel 3.14_79 (No flickering)
--
You are receiving this mail because:
Yo
Qiang Yu writes:
> On Thu, Feb 7, 2019 at 3:17 AM Eric Anholt wrote:
>>
>> Qiang Yu writes:
>> > +int lima_gem_wait(struct drm_file *file, u32 handle, u32 op, u64
>> > timeout_ns)
>> > +{
>> > + bool write = op & LIMA_GEM_WAIT_WRITE;
>> > + struct drm_gem_object *obj;
>> > + struct
On Thu, Feb 07, 2019 at 02:33:57AM +0530, Ramalingam C wrote:
> Defining the mei-i915 interface functions and initialization of
> the interface.
>
> v2:
> Adjust to the new interface changes. [Tomas]
> Added further debug logs for the failures at MEI i/f.
> port in hdcp_port data is equipped
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #16 from Paul Dufresne ---
Created attachment 143325
--> https://bugs.freedesktop.org/attachment.cgi?id=143325&action=edit
Paul Dufresne's Xorg.0.log for k3.14.79 no_flickering
--
You are receiving this mail because:
You are the
On Thu, Feb 07, 2019 at 08:40:08PM +0100, Daniel Vetter wrote:
> On Thu, Feb 07, 2019 at 02:33:57AM +0530, Ramalingam C wrote:
> > Defining the mei-i915 interface functions and initialization of
> > the interface.
> >
> > v2:
> > Adjust to the new interface changes. [Tomas]
> > Added further d
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #17 from Paul Dufresne ---
Created attachment 143326
--> https://bugs.freedesktop.org/attachment.cgi?id=143326&action=edit
dufresnep's dmesg for kernel 4.15.0-45-generic (Linux Mint) with drm.debug=4
with a lot of flickering
--
Y
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #18 from Paul Dufresne ---
Created attachment 143327
--> https://bugs.freedesktop.org/attachment.cgi?id=143327&action=edit
dufresnep's Xorg.0.log for kernel 4.15.0-45 (Mint 19) with drm.debug=4 lots of
flickering
--
You are recei
You'll get garbage measurements if the registers always read back
0xdeadbeef
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_debugfs.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/v3d/v3d_debugfs.c
b/drivers/gpu/drm/v3d/v3d_debugfs.c
index eb2b2d2f8553..a24
No compatible string for it yet, just the version-dependent changes.
They've now tied the hub and the core interrupt lines into a single
interrupt line coming out of the block. It also turns out I made a
mistake in modeling the V3D v3.3 and v4.1 bridge as a part of V3D
itself -- the bridge is goin
The register now has another field, QRMAXCNT for how many TMU requests
get serviced before thread switch. We were accidentally reducing it
from its default of 0x3 (4 requests) to 0x0 (1).
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_gem.c | 4 +++-
drivers/gpu/drm/v3d/v3d_regs.h | 2
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_drv.c b/drivers/gpu/drm/v3d/v3d_drv.c
index 22fff0d3aecd..1f22ce542a04 100644
--- a/drivers/gpu/drm/v3d/v3d_drv.c
+++ b/drivers/gpu/drm/v3
On Wed, Feb 06, 2019 at 01:31:01PM -0500, Lyude Paul wrote:
> Looks like when making the final revision of:
>
> 022debad063e ("drm/atomic: Add drm_atomic_state->duplicated")
>
> I forgot to remove some of the comments that I had added to
> drm_dp_atomic_find_vcpi_slots() and drm_dp_atomic_release
https://bugs.freedesktop.org/show_bug.cgi?id=108031
--- Comment #5 from Alexander Schlarb ---
Using the latest Debian kernel (4.19.0-2, which apparently corresponds to Linux
version 4.19.16, with 4.19.0-1 having corresponded to 4.19.13) this issue does
not affect me anymore.
I looked through the
On Sun, Feb 03, 2019 at 04:41:55PM +0100, Noralf Trønnes wrote:
> If userspace has open fd(s) when drm_dev_unplug() is run, it will result
> in drm_dev_unregister() being called twice. First in drm_dev_unplug() and
> then later in drm_release() through the call to drm_put_dev().
>
> Since userspac
On Thu, Feb 7, 2019 at 10:17 AM Daniel Vetter wrote:
> On Thu, Feb 07, 2019 at 09:36:44AM +0100, Linus Walleij wrote:
> > This makes it possible to pass a connector with an already
> > attached external encoder into the simple KMS helper.
> >
> > This is helpful for my MCDE drivers, as it is pret
> ME FW 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 messag
On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
> The only thing now that makes drm_dev_unplug() special is that it sets
> drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> can remove drm_dev_unplug().
>
> Signed-off-by: Noralf Trønnes
> ---
>
> Maybe s/u
On Sun, Feb 03, 2019 at 04:41:58PM +0100, Noralf Trønnes wrote:
> drm_dev_unplug() has been stripped down and is going away. Open code its
> 2 remaining function calls.
>
> Cc: Dave Airlie
> Cc: Sean Paul
Reviewed-by: Sean Paul
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/udl/udl
On Sun, Feb 03, 2019 at 04:42:00PM +0100, Noralf Trønnes wrote:
> There are no users left.
>
> Signed-off-by: Noralf Trønnes
Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/drm_drv.c | 17 -
> include/drm/drm_drv.h | 1 -
> 2 files changed, 18 deletions(-)
>
> diff --git
> -Original Message-
> From: C, Ramalingam
> Sent: Wednesday, February 06, 2019 23:04
> To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> daniel.vet...@ffwll.ch; Winkler, Tomas ; Shankar,
> Uma
> Cc: C, Ramalingam
> Subject: [PATCH v11 29/42] misc/mei/hdcp: Verify
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #19 from Paul Dufresne ---
Created attachment 143328
--> https://bugs.freedesktop.org/attachment.cgi?id=143328&action=edit
dufresnep's dmesg for kernel 4.15.0-45-generic with drm.debug=0 with strangely
no flickering
--
You are re
> Request ME FW to start the HDCP2.2 session for an intel port.
> Prepares payloads for command WIRED_INITIATE_HDCP2_SESSION and sends
> 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.
> v3:
> cl
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #20 from Paul Dufresne ---
Created attachment 143329
--> https://bugs.freedesktop.org/attachment.cgi?id=143329&action=edit
dufresnep's xorg log for kernel 4.15.0 with drm.debug=0 strangely without
flickering
--
You are receiving
On Sat, Jan 26, 2019 at 01:25:22PM +0100, Sam Ravnborg wrote:
> Updated patchset, with merged patches removed, new patches added.
>
> > From the original mail:
>
> - drmP.h is now stripped down to include files
> and forward declarations.
> - All header files in include/
>
> Requests for the verification of AKE_Send_H_prime.
>
> ME will calculate the H and comparing it with received H_Prime.
> The result will be returned as status.
>
> Here AKE_Send_H_prime is a HDCP2.2 Authentication msg.
>
> v2: Rebased.
> v3:
> cldev is passed as first parameter [Tomas]
>
>
> 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.
> v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
> v4:
>
> 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.
> v3:
> cldev is passed as first parameter [Tomas]
> Red
> 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.
> v3:
> cldev is passed as first parameter [Tomas]
> Redundant com
> Request ME to verify the downstream 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.
> v3:
> cldev is pass
On Thu, Feb 07, 2019 at 10:02:17PM +0100, Linus Walleij wrote:
> On Thu, Feb 7, 2019 at 10:17 AM Daniel Vetter wrote:
> > On Thu, Feb 07, 2019 at 09:36:44AM +0100, Linus Walleij wrote:
>
> > > This makes it possible to pass a connector with an already
> > > attached external encoder into the simp
>
> Request to ME to prepare the encrypted session key.
>
> On Success, ME provides Encrypted session key. Function populates the
> HDCP2.2 authentication msg SKE_Send_Eks.
>
> v2: Rebased.
> v3:
> cldev is passed as first parameter [Tomas]
> Redundant comments and cast are removed [Tomas]
>
>
> Request to ME to configure a port as authenticated.
>
> On Success, ME FW will mark the port as authenticated and provides HDCP
> cipher with the encryption keys.
>
> Enabling the Authentication can be requested once all stages of
> HDCP2.2 authentication is completed by interacting with ME
>
> 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.
> v3:
> cldev is passed as first parameter [To
>
> 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
> manageme
On Thu, Feb 07, 2019 at 04:07:33PM -0500, Sean Paul wrote:
> On Sun, Feb 03, 2019 at 04:41:56PM +0100, Noralf Trønnes wrote:
> > The only thing now that makes drm_dev_unplug() special is that it sets
> > drm_device->unplugged. Move this code to drm_dev_unregister() so that we
> > can remove drm_dev
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #21 from Paul Dufresne ---
Created attachment 143330
--> https://bugs.freedesktop.org/attachment.cgi?id=143330&action=edit
dmesg for kernel 5.0rc5 with flickering and debug=4
--
You are receiving this mail because:
You are the as
https://bugs.freedesktop.org/show_bug.cgi?id=108514
Paul Dufresne changed:
What|Removed |Added
CC||dufres...@gmail.com
--- Comment #22 fro
1 - 100 of 133 matches
Mail list logo
