https://bugs.freedesktop.org/show_bug.cgi?id=107956
--- Comment #5 from Maarten Lankhorst ---
Doing some more investigation. This is expected behavior. So the dmesg-warn in
this case is invalid..
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=109554
--- Comment #1 from Rafał Miłecki ---
Created attachment 143319
--> https://bugs.freedesktop.org/attachment.cgi?id=143319=edit
Corruption photo
--
You are receiving this mail because:
You are the assignee for the
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" emphasizes much more the "assemble a
Den 06.02.2019 16.26, skrev Daniel Vetter:
> On Tue, Feb 05, 2019 at 06:57:50PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 05.02.2019 17.31, skrev Daniel Vetter:
>>> On Tue, Feb 05, 2019 at 11:20:55AM +0100, Noralf Trønnes wrote:
Den 05.02.2019 10.11, skrev Daniel Vetter:
> On
Component framework is extended to support multiple components for
a struct device. These will be matched with different masters based on
its sub component value.
We are introducing this, as I915 needs two different components
with different subcomponent value, which will be matched to two
Someone owes me a beer ...
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" emphasizes
Now that component has docs it's worth spending a few words and
hyperlinks on recommended best practices in drm.
Cc: Russell King - ARM Linux admin
Signed-off-by: Daniel Vetter
---
Documentation/driver-api/component.rst | 2 ++
Documentation/gpu/drm-internals.rst| 5 +
Hi,
On 06-02-19 16:58, Daniel Vetter wrote:
On Mon, Feb 04, 2019 at 07:54:16PM +0100, Sam Ravnborg wrote:
Hi Daniel
On Mon, Feb 04, 2019 at 11:31:14AM +0100, Daniel Vetter wrote:
Noticed why wonder what vboxvideo is using the ->master_set/drop hooks
for.
Can you improve the gammar a little,
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,10 @@ static int dsi_display_init_dsi(struct
On Mon, Feb 04, 2019 at 07:54:16PM +0100, Sam Ravnborg wrote:
> Hi Daniel
>
> On Mon, Feb 04, 2019 at 11:31:14AM +0100, Daniel Vetter wrote:
> > Noticed why wonder what vboxvideo is using the ->master_set/drop hooks
> > for.
> Can you improve the gammar a little, I find it hard to read.
>
> >
>
On Wed, Feb 06, 2019 at 12:01:16PM -0200, Rodrigo Siqueira wrote:
> Fixes license inconsistent related to the VKMS driver and remove the
> redundant boilerplate comment.
>
> Fixes: 854502fa0a38 ("drm/vkms: Add basic CRTC initialization")
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Rodrigo
On Tue, Feb 05, 2019 at 06:57:50PM +0100, Noralf Trønnes wrote:
>
>
> Den 05.02.2019 17.31, skrev Daniel Vetter:
> > On Tue, Feb 05, 2019 at 11:20:55AM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 05.02.2019 10.11, skrev Daniel Vetter:
> >>> On Mon, Feb 04, 2019 at 06:35:28PM +0100, Noralf
When the pipeline is reconfigured with a different mode, changes take
effect immediately for the CRTC and encoder while the HVS takes some
time to switch the active display list. This results in a period of
time where the pipeline is out of sync, that is very likely to cause
an underrun to be
In order to test whether the load tracker is working as expected, we
need the ability to compare the commit result with the underrun
indication. With the load tracker always enabled, commits that are
expected to trigger an underrun are always rejected, so userspace
cannot get the actual underrun
From: Boris Brezillon
The HVS block is supposed to fill the pixelvalve FIFOs fast enough to
meet the requested framerate. The problem is, the HVS and memory bus
bandwidths are limited, and if we don't take these limitations into
account we might end up with HVS underflow errors.
This patch is
Hi,
Here is a fourth iteration of the VC4 load tracking series, which was
initially developed by Boris Brezillon and that I have now taken over.
This new iteration takes in account comments from v3 and comes with a
new approach for avoiding underrun reports when reconfiguring the
pipeline. It is
From: Boris Brezillon
Add a debugfs entry and helper for reporting HVS underrun errors as
well as helpers for masking and unmasking the underrun interrupts.
Add an IRQ handler and initial IRQ configuration.
Rework related register definitions to take the channel number.
Signed-off-by: Boris
On Wed, Feb 6, 2019 at 10:12 PM Maxime Ripard wrote:
>
> Hi Chen-Yu,
>
> On Wed, Feb 06, 2019 at 12:48:21AM +0800, Chen-Yu Tsai wrote:
> > On Wed, Jan 30, 2019 at 11:23 AM Chen-Yu Tsai wrote:
> > >
> > > On Wed, Jan 23, 2019 at 11:54 PM Maxime Ripard
> > > wrote:
> > > >
> > > > The current
On Tue, Feb 05, 2019 at 11:16:34PM -0800, Manasi Navare wrote:
> This patch adds appropiate kernel documentation for DRM DP helpers
> used for enabling Display Stream compression functionality in
> drm_dp_helper.h and drm_dp_helper.c as well as for the DSC spec
> related structure definitions and
Hi Chen-Yu,
On Wed, Feb 06, 2019 at 12:48:21AM +0800, Chen-Yu Tsai wrote:
> On Wed, Jan 30, 2019 at 11:23 AM Chen-Yu Tsai wrote:
> >
> > On Wed, Jan 23, 2019 at 11:54 PM Maxime Ripard
> > wrote:
> > >
> > > The current calculation for the video start delay in the current DSI
> > > driver
> > >
Fixes license inconsistent related to the VKMS driver and remove the
redundant boilerplate comment.
Fixes: 854502fa0a38 ("drm/vkms: Add basic CRTC initialization")
Cc: sta...@vger.kernel.org
Signed-off-by: Rodrigo Siqueira
---
Changes in V2:
- Add "Cc: sta...@vger.kernel.org" tag
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #66 from Lefteris Chatzimparmpas ---
While the workaround with power_dpm_force_performance_level/pp_dpm_mclk works
for me, I found another way to stop the flickering, which I mention here in
case it helps debugging.
My monitor has
Signed-off-by: Qiang Yu
---
include/uapi/drm/drm_fourcc.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 0b44260a5ee9..953b59eb3fd2 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@
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 several
months, so I think it's ready to be upstreamed.
This
On Tue, Feb 05, 2019 at 07:29:22PM -0800, Kevin Strasser wrote:
> 64 bpp half float formats are supported on hdr planes only and are subject
> to the following restrictions:
> * 90/270 rotation not supported
> * Yf Tiling not supported
> * Frame Buffer Compression not supported
> * Color
On Tue, Feb 05, 2019 at 07:29:21PM -0800, Kevin Strasser wrote:
> Change the api in order to enable callers that can't supply a valid
> intel_plane pointer, as would be the case prior to calling
> drm_universal_plane_init.
>
> Cc: Uma Shankar
> Cc: Shashank Sharma
> Cc: Ville Syrjälä
> Cc:
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, Maxime Ripard wrote:
> >>> Hi,
> >>>
> >>> Here is a set
On Wed, Feb 06, 2019 at 10:49:12AM +0100, Wolfram Sang wrote:
>
> > And there is a regression! Good that I didn't push out before
> > double-checking. No one noticed that this breaks registering child
> > devices because of_i2c_register_devices() doesn't have a pointer to work
> > with anymore?
>
On Wed, Feb 06, 2019 at 10:16:08AM +0100, Maxime Ripard wrote:
> On Tue, Feb 05, 2019 at 09:49:17AM -0800, Vasily Khoruzhick wrote:
> > On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard
> > wrote:
> > >
> > > On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> > > > On Mon, Feb 4,
Hi,
On 11/01/2019 05:50, Laurent Pinchart wrote:
> Hello,
>
> This patch series consolidates the three pending series for the omapdrm and
> tfp410 drivers that all together implement drm_bridge and drm_panel support
> for omapdrm.
>
> The series starts with four patches not posted before as
>
> > >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.
>
> And there is a regression! Good that I didn't push out before
> double-checking. No one noticed that this breaks registering child
> devices because of_i2c_register_devices() doesn't have a pointer to work
> with anymore?
Well, sorry, I forgot an important detail. There is no regression
On Tue, Feb 05, 2019 at 01:44:44PM +0100, Wolfram Sang wrote:
> On Fri, Jan 25, 2019 at 02:11:42PM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > If an I2C adapter doesn't match the provided device tree node, also try
> > matching the parent's device tree node. This allows finding
On Tue, Feb 05, 2019 at 09:49:17AM -0800, Vasily Khoruzhick wrote:
> On Tue, Feb 5, 2019 at 7:42 AM Maxime Ripard
> wrote:
> >
> > On Mon, Feb 04, 2019 at 10:50:17AM -0800, Vasily Khoruzhick wrote:
> > > On Mon, Feb 4, 2019 at 8:29 AM Icenowy Zheng wrote:
> > > > >> IIRC, from the previous
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) without ulps/disconnect.
>>
>> I think
>
> >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
101 - 136 of 136 matches
Mail list logo
