next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161118/c597e3f0/attachment-0001.html>
On 11/18/16 07:00, Christopher Spinrath wrote:
> Hi Jyri,
>
> On 11/17/2016 02:28 PM, Jyri Sarha wrote:
>> Add very basic ti-ftp410 DVI transmitter driver. The only feature
>
> s/ftp/tfp ?
>
My fingers just want type these three letter is that order, wonder why :).
>> separating this from a co
On 11/18/16 15:34, Bartosz Golaszewski wrote:
> 2016-11-16 13:41 GMT+01:00 Jyri Sarha :
>> Revision 1 LCDC support also sync lost errors and can benefit from
>> sync lost recovery routine.
>>
>
> Hi Jyri,
>
> I think I found the issue with this patch. Please see below.
>
>> Signed-off-by: Jyri S
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161118/673ca7ed/attachment.html>
On 11/18/16 18:10, Bartosz Golaszewski wrote:
> 2016-11-18 16:34 GMT+01:00 Bartosz Golaszewski :
>> 2016-11-16 13:41 GMT+01:00 Jyri Sarha :
>>> Load palette at the end of mode_set_nofb() and only if the palette has
>>> not been loaded since last runtime resume. Moving the palette loading
>>> to mod
On Thu, Nov 17, 2016 at 1:42 AM, Archit Taneja
wrote:
> In add_components_mdp, we parse the endpoints in MDP output ports
> using the helper for_each_endpoint_of_node(). Our function calls
> of_node_put() on the endpoint node before we iterate over the
> next one. This is already done by the help
net
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20161118/2442c7d2/attachment.html>
org/archives/dri-devel/attachments/20161118/3443addf/attachment.html>
On 16-11-18 21:53:13, Ville Syrjälä wrote:
>From: Ville Syrjälä
>
>By providing our own format information for the CCS formats, we should
>be able to make framebuffer_check() do the right thing for the CCS
>surface as well.
>
I was hoping to see that patch as well :-). If you're adding the ne
On Fri, Nov 18, 2016 at 07:39:50AM -0800, Manasi Navare wrote:
> On Fri, Nov 18, 2016 at 03:22:49PM +0200, Jani Nikula wrote:
> > On Fri, 18 Nov 2016, Manasi Navare wrote:
> > > If link training fails, then we need to fallback to lower
> > > link rate first and if link training fails at RBR, then
At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of the
link, but it's possible we can't reach this in practice. The DP spec
describes how the link should be reduced, but we can't reduce the link
below the requireme
In the usual working scenarios, this property is "Good".
If something fails during modeset, the DRM driver can
set the link status to "Bad", prune the mode list based on the
link rate/lane count fallback values and send hotplug uevent
so that userspace that is aware of this property can take an
ap
If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure.
v5:
* Start the fallback at the lane count value passed not
the
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link rate to prune the modes
The idea presented in these patches is to address link training failure
in a way that:
a) changes the current happy day scenario as little as possible, to avoid
regressions, b) can be implemented the same way by all drm drivers, c)
is still opt-in for the drivers and userspace, and opting out doesn
In the usual working scenarios, this property is "Good".
If something fails during modeset, the DRM driver can
set the link status to "Bad", prune the mode list based on the
link rate/lane count fallback values and send hotplug uevent
so that userspace that is aware of this property can take an
ap
CRTC state connector_changed needs to be set to true
if connector link status property has changed. This will tell the
driver to do a complete modeset due to change in connector property.
Acked-by: Harry Wentland
Acked-by: Tony Cheng
Cc: dri-devel at lists.freedesktop.org
Cc: Jani Nikula
Cc: Da
If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link rate to prune the modes
At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of the
link, but it's possible we can't reach this in practice. The DP spec
describes how the link should be reduced, but we can't reduce the link
below the requireme
If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure.
v5:
* Start the fallback at the lane count value passed not
the
If 'sun4i_backend_drm_format_to_layer()' does not return 0, then 'val' is
left unmodified.
As it is not initialized either, the return value can be anything.
It is likely that returning the error code was expected here.
As the only caller of 'sun4i_backend_update_layer_formats()' does not check
t
Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)).
Signed-off-by: Geliang Tang
---
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index 7abc55
Hi Jyri,
On 11/17/2016 02:28 PM, Jyri Sarha wrote:
> Add very basic ti-ftp410 DVI transmitter driver. The only feature
s/ftp/tfp ?
> separating this from a completely dummy bridge is the EDID read
> support trough DDC I2C. Even that functionality should be in a
> separate generic connector drive
On Fri, Nov 11, 2016 at 02:37:23PM +, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently the revision isn't available via sysfs/libudev thus if one
> wants to know the value they need to read through the config file.
>
> This in itself wakes/powers up the device, causing unwanted delay
>
The probe function requests the interrupt before initializing
the ddp component. Which leads to a null pointer dereference at boot.
Fix this by requesting the interrput after all components got
initialized properly.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC
MT8173.")
Sign
Hi,
While testing HDMI with Xorg on the Juno board, I find that when Xorg
starts up or shuts down, the display is shifted significantly to the
right and wrapped in the active region. (No sync bars are visible.)
The timings are correct, it behaves as if the start address has been
shifted many pixe
On Fri, Nov 18, 2016 at 10:48:46AM +0100, Daniel Vetter wrote:
> On Fri, Nov 18, 2016 at 10:42:07AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 17, 2016 at 08:40:10PM -0600, Bjorn Helgaas wrote:
> > > On Fri, Nov 18, 2016 at 10:42:20AM +0900, Michel Dänzer wrote:
> > > > On 18/11/16 08:48 AM, Bjor
101 - 127 of 127 matches
Mail list logo