On Tue, May 28, 2019 at 11:57:05AM +0800, Lowry Li (Arm Technology China) wrote:
> From: "Lowry Li (Arm Technology China)"
>
> Komeda series hardware doesn't support Rot90 for AFBC wide block. So
> add limitation check to reject it if such configuration has been posted.
>
> Signed-off-by: Lowry
Robin, Steven,
would you or someone else at Arm be able to run the IGT tests [0] on
5.2-rc2 with this patch on top?
I don't have any hw with Bifrost and am not planning to work on the
userspace any time soon, but I think it would be good to at least
check that the kernel doesn't have any obvious
Le lun. 27 mai 2019 à 14:28, Philippe CORNU a écrit :
>
> Hi Benjamin,
>
> Many thanks for this fix (and more generally for pushing STM patches on
> misc :-)
>
> Acked-by: Philippe Cornu
Applied on drm-misc-next,
sorry for the mistake.
Benjamin
>
> Philippe :-)
>
> On 5/27/19 1:58 PM, Benjamin
Am 28.05.19 um 09:38 schrieb Daniel Vetter:
> [SNIP]
>> Might be a good idea looking into reverting it partially, so that at
>> least command submission and buffer allocation is still blocked.
> I thought the issue is a lot more than vainfo, it's pretty much every
> hacked up compositor under the
On Tue, May 28, 2019 at 8:58 AM Koenig, Christian
wrote:
>
> Am 27.05.19 um 17:26 schrieb Daniel Vetter:
> > On Mon, May 27, 2019 at 3:42 PM Koenig, Christian
> > wrote:
> >> Am 27.05.19 um 15:26 schrieb Emil Velikov:
> >>> On 2019/05/27, Daniel Vetter wrote:
> On Mon, May 27, 2019 at
On Tue, May 28, 2019 at 11:57:00AM +0800, Lowry Li (Arm Technology China) wrote:
> From: "Lowry Li (Arm Technology China)"
>
> - Adds rotation property to plane.
> - Komeda display rotation support diverges from the specific formats,
> so need to check the user required rotation type with the
On Mon, 27 May 2019, Ashutosh Dixit wrote:
> On Sun, 26 May 2019 12:50:51 -0700, Ilpo Järvinen wrote:
>>
>> Hi all,
>>
>> I've a workstation which has internal VGA that is detected as AST 2400 and
>> with it EDID has been always quite flaky (except for some time it worked
>> with 4.14 long enough
Hi, Tom,
Could you shed some light on this?
Thanks,
Thomas
On 5/24/19 5:08 PM, Alex Deucher wrote:
+ Tom
He's been looking into SEV as well.
On Fri, May 24, 2019 at 8:30 AM Thomas Hellstrom wrote:
On 5/24/19 2:03 PM, Koenig, Christian wrote:
Am 24.05.19 um 12:37 schrieb Thomas
Hi Shawn, Lucas,
On Tue, May 28, 2019 at 09:38:02AM +0800, Shawn Guo wrote:
> Caution: EXT Email
>
> Hi Lucas,
>
> On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> > We have been looking at how to support DCSS in mainline for a while,
> > but most of the actual work got pushed
On Sun, May 26, 2019 at 8:05 PM Sam Ravnborg wrote:
> The num_supplies variable is not used, delete it.
> Build tested.
>
> Signed-off-by: Sam Ravnborg
> Cc: Thierry Reding
> Cc: David Airlie
> Cc: Daniel Vetter
Reviewed-by: Linus Walleij
Yours,
Linus Walleij
Am 27.05.19 um 17:26 schrieb Daniel Vetter:
> On Mon, May 27, 2019 at 3:42 PM Koenig, Christian
> wrote:
>> Am 27.05.19 um 15:26 schrieb Emil Velikov:
>>> On 2019/05/27, Daniel Vetter wrote:
On Mon, May 27, 2019 at 10:47:39AM +, Koenig, Christian wrote:
> Am 27.05.19 um 10:17 schrieb
This change does a rename of match_string() -> __match_string().
There are a few parts to the intention here (with this change):
1. Align with sysfs_match_string()/__sysfs_match_string()
2. This helps to group users of `match_string()`:
a. those that use ARRAY_SIZE(_a) to specify the number of
The documentation the `_match_string()` helper mentions that `n`
should be:
* @n: number of strings in the array or -1 for NULL terminated arrays
The behavior of the function is different, in the sense that it exits on
the first NULL element in the array, regardless of whether `n` is -1 or a
mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which needs
ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called,
ovl irq will be disabled. If drm_crtc_wait_one_vblank() is called after last
irq, it will timeout with this message: "vblank wait timed out
This change re-introduces `match_string()` as a macro that uses
ARRAY_SIZE() to compute the size of the array.
After this change, work can start on migrating subsystems to use this new
helper. Since the original helper is pretty used, migrating to this new one
will take a while, and will be
https://bugs.freedesktop.org/show_bug.cgi?id=110749
--- Comment #3 from Cyrax ---
Created attachment 144359
--> https://bugs.freedesktop.org/attachment.cgi?id=144359=edit
dmesg dump via journalctl -b -1 command
It seems that the error message is different now when forcing Saints Row The
Third
https://bugs.freedesktop.org/show_bug.cgi?id=109754
--- Comment #2 from Felix Schwarz ---
possible fix: https://patchwork.freedesktop.org/series/61224/
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
Hi Laurentiu,
On Tue, May 28, 2019 at 07:03:54AM +, Laurentiu Palcu wrote:
> Hi Shawn, Lucas,
>
> On Tue, May 28, 2019 at 09:38:02AM +0800, Shawn Guo wrote:
> > Caution: EXT Email
> >
> > Hi Lucas,
> >
> > On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> > > We have been
Hi Laurent,
On Sun, May 12, 2019 at 12:06:57AM +0300, Laurent Pinchart wrote:
> The DRM core and DU driver guarantee that the LVDS bridge will not be
> double-enabled or double-disabled. Remove the corresponding unnecessary
> checks.
>
> Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Hi Laurent,
On Sun, May 12, 2019 at 12:07:00AM +0300, Laurent Pinchart wrote:
> Add the new renesas,companion property to the LVDS0 node to point to the
> companion LVDS encoder LVDS1.
>
> Signed-off-by: Laurent Pinchart
Provided this does not enable dual-link operations by default:
HI Laurent,
On Sun, May 12, 2019 at 12:06:59AM +0300, Laurent Pinchart wrote:
> In dual-link LVDS mode, the LVDS1 encoder is used as a companion for
> LVDS0, and both encoders transmit data from DU0. The LVDS1 output of DU1
> can't be used in that case, don't create an encoder and connector for
>
Hi, Hsin-Yi:
On Tue, 2019-05-28 at 15:39 +0800, Hsin-Yi Wang wrote:
> mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which
> needs
> ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called,
> ovl irq will be disabled. If drm_crtc_wait_one_vblank() is
Hi Shawn,
Am Dienstag, den 28.05.2019, 09:38 +0800 schrieb Shawn Guo:
> Hi Lucas,
>
> On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> > We have been looking at how to support DCSS in mainline for a while,
> > but most of the actual work got pushed behind in schedule due to other
>
Minor cleanups:
- Use bool for boolean fields
- Use DP_MAX_DOWNSPREAD_0_5 instead of BIT(0)
- debug print down-spread and scrambler status
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/tc358767.c | 13 -
1 file
Hi,
tc358767 bridge was originally implemented for eDP use with an embedded
panel. I've been working to add DP and HPD support, and this series is
the result. I did have a lot of issues with link training, but with
these, it's been working reliably with my devices.
Changes in v2
* Drop
It is nicer to have enable/disable functions instead of set(bool enable)
style function.
Split tc_main_link_stream into tc_stream_enable and tc_stream_disable.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 81 +--
We need to reset DPCD voltage-swing & pre-emphasis before starting the
link training, as otherwise tc358767 will use the previous values as
minimums.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 7 +++
1 file changed, 7 insertions(+)
swing and preemp fields are not used. Remove them.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/tc358767.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
DP always uses ANSI 8B10B encoding. Some monitors (old?) may not have
the ANSI 8B10B bit set in DPCD, even if it should always be set.
The tc358767 driver currently respects that flag, and turns the encoding
off if the monitor does not have the bit set, which then results in the
monitor not
On Tue, May 28, 2019 at 10:20 AM Lucas Stach wrote:
>
> Hi Shawn,
>
> Am Dienstag, den 28.05.2019, 09:38 +0800 schrieb Shawn Guo:
> > Hi Lucas,
> >
> > On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> > > We have been looking at how to support DCSS in mainline for a while,
> > > but
I'm not entirely clear on what new_modelist actually does, it seems
exclusively for a sysfs interface. Which in the end does amount to a
normal fb_set_par to check the mode, but then takes a different path
in both fbmem.c and fbcon.c.
I have no idea why these 2 paths are different, but then I
With the sh_mobile notifier removed we can just directly call the
fbcon code here.
v2: Remove now unused local variable.
v3: fixup !CONFIG_FRAMEBUFFER_CONSOLE, noticed by kbuild
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: Bartlomiej
Also remove the error return value. That's all errors for either
driver bugs (trying to unbind something that isn't bound), or errors
of the new driver that will take over.
There's nothing the outgoing driver can do about this anyway, so
switch over to void.
Signed-off-by: Daniel Vetter
Pretty simple case really.
v2: Forgot to remove a break;
v3: Add static inline to the dummy versions.
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: "Steven Rostedt (VMware)"
Cc:
Hi Laurent,
On Sun, May 12, 2019 at 12:06:55AM +0300, Laurent Pinchart wrote:
> Set a drm_bridge_timings in the drm_bridge, and use it to report the
> input bus mode (single-link or dual-link). The other fields of the
> timings structure are kept to 0 as they do not apply to LVDS buses.
>
>
It's properly protected by reboot_lock.
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: Mikulas Patocka
Cc: "David S. Miller"
Cc: "Ville Syrjälä"
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
---
drivers/video/fbdev/aty/atyfb_base.c | 3 +--
1
Create a new wrapper function for this, feels like there's some
refactoring room here between the two modes.
v2: backlight notifier is also interested in the mode change event,
it calls lcd->set_mode, of which there are 3 implementations. Thanks
to Maarten for spotting this. So we keep that. We
Instead of wiring almost everything down to the very last line using
goto soup (but not consistently, where would the fun be otherwise)
drop out early when checks fail. This allows us to flatten the huge
indent levels to just 1.
Aside: If a driver doesn't set ->fb_check_var, then FB_ACTIVATE_NOW
On 27/05/2019 14:21, Tony Lindgren wrote:
>> Looks good to me. For some reason I can't boot 5.2-rc2 (on x15) so I haven't
>> been able to test yet. I'll pick the series up in any case, and I'll test it
>> when I get the kernel booting.
>
> Great good to have these merged finally :)
>
> Hmm I
Hi Laurent,
On Sun, May 12, 2019 at 12:06:56AM +0300, Laurent Pinchart wrote:
> Add a new optional renesas,companion property to point to the companion
> LVDS encoder. This is used to support dual-link operation where the main
> LVDS encoder splits even-numbered and odd-numbered pixels between
Lucas and Daniel,
On Tue, May 28, 2019 at 10:36:43AM +0200, Daniel Vetter wrote:
> Caution: EXT Email
>
> On Tue, May 28, 2019 at 10:20 AM Lucas Stach wrote:
> >
> > Hi Shawn,
> >
> > Am Dienstag, den 28.05.2019, 09:38 +0800 schrieb Shawn Guo:
> > > Hi Lucas,
> > >
> > > On Mon, May 27, 2019 at
Hi Guido,
On Tue, May 28, 2019 at 11:33:00AM +0200, Guido Günther wrote:
> Caution: EXT Email
>
> Hi Laurentiu,
> On Tue, May 28, 2019 at 07:03:54AM +, Laurentiu Palcu wrote:
> > Hi Shawn, Lucas,
> >
> > On Tue, May 28, 2019 at 09:38:02AM +0800, Shawn Guo wrote:
> > > Caution: EXT Email
> >
Hi Laurentiu,
Am Dienstag, den 28.05.2019, 10:04 + schrieb Laurentiu Palcu:
> Lucas and Daniel,
[...]
> > > It's a totally different hardware, with very different behavior, so
> > > there is basically no potential for any code sharing. The downstream
> > > driver is a hell of "oh, things
Motivated because it contains a struct display, which is a fbcon
internal data structure that I want to rename. It seems to have been
formerly used in drivers, but that's very long time ago.
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: Daniel Vetter
With
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
we have a static dependency between fbcon and fbdev, and we can
replace the indirection through the notifier chain with a
This seems to be entirely defunct:
- The FB_EVEN_SUSPEND/RESUME events are only sent out by
fb_set_suspend. Which is supposed to be called by drivers in their
suspend/resume hooks, and not itself call into drivers. Luckily
sh_mob doesn't call fb_set_suspend, so this seems to do nothing
Ever since
commit c47747fde931c02455683bd00ea43eaa62f35b0e
Author: Linus Torvalds
Date: Wed May 11 14:58:34 2011 -0700
fbmem: make read/write/ioctl use the frame buffer at open time
fbdev has gained proper refcounting for the fbinfo attached to any
open files, which means that the
Which means lock_fb_info can never fail. Remove the error handling.
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Rob Clark
---
drivers/video/fbdev/core/fbsysfs.c | 10 ++
1 file changed, 2
This was formerly used in fbdev drivers (not sure why, predates most
git history), but now it's entirely an fbcon internal thing. Give it a
more specific name.
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
As part of trying to understand the locking (or lack thereof) in the
fbcon/vt/fbdev maze, annotate everything.
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc:
I honestly have no idea what the subtle differences between
con_is_visible, con_is_fg (internal to vt.c) and con_is_bound are. But
it looks like both vc->vc_display_fg and con_driver_map are protected
by the console_lock, so probably better if we hold that when checking
this.
To do that I had to
Motivated because it contains a struct display, which is a fbcon
internal data structure that I want to rename. It seems to have been
formerly used in drivers, but that's very long time ago.
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: Paul
For symmetry reasons with do_unblank_screen, except without the
oops_in_progress special case.
Just a drive-by annotation while I'm trying to untangle the fbcon vs.
fbdev screen blank/unblank maze.
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Acked-by: Greg Kroah-Hartman
Just drive-by, nothing systematic yet.
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: "Michał Mirosław"
Cc: Peter Rosin
Cc: Hans de Goede
Cc: Thomas Zimmermann
Cc: Manfred Schlaegl
Cc: Mikulas
Hi all,
I think we're slowly getting there. Previous cover letters with more
context:
https://lists.freedesktop.org/archives/dri-devel/2019-May/218362.html
tldr; I have a multi-year plan to improve fbcon locking, because the
current thing is a bit a mess.
Cover letter of this version, where I
Hi Laurent,
a small note.
On Sun, May 12, 2019 at 12:06:58AM +0300, Laurent Pinchart wrote:
> In dual-link mode the LVDS0 encoder transmits even-numbered pixels, and
> sends odd-numbered pixels to the LVDS1 encoder for transmission on a
> separate link.
>
> To implement support for this mode of
Hi Laurentiu,
On Tue, May 28, 2019 at 07:03:54AM +, Laurentiu Palcu wrote:
> Hi Shawn, Lucas,
>
> On Tue, May 28, 2019 at 09:38:02AM +0800, Shawn Guo wrote:
> > Caution: EXT Email
> >
> > Hi Lucas,
> >
> > On Mon, May 27, 2019 at 03:36:53PM +0200, Lucas Stach wrote:
> > > We have been
Hi,
* Tomi Valkeinen [190528 09:19]:
> On 27/05/2019 14:21, Tony Lindgren wrote:
>
> >> Looks good to me. For some reason I can't boot 5.2-rc2 (on x15) so I
> >> haven't
> >> been able to test yet. I'll pick the series up in any case, and I'll test
> >> it
> >> when I get the kernel booting.
Hi Laurent,
On Sun, May 12, 2019 at 12:06:52AM +0300, Laurent Pinchart wrote:
> Hello everybody,
>
> This patch series implements support for LVDS dual-link mode in the
> R-Car DU and R-Car LVDS encoder drivers, and well as in the thc63lvd1024
> LVDS decoder driver.
>
> LVDS dual-link is a mode
* Tomi Valkeinen [190528 10:05]:
> On 28/05/2019 12:39, Tony Lindgren wrote:
> > Hi,
> >
> > * Tomi Valkeinen [190528 09:19]:
> > > On 27/05/2019 14:21, Tony Lindgren wrote:
> > >
> > > > > Looks good to me. For some reason I can't boot 5.2-rc2 (on x15) so I
> > > > > haven't
> > > > > been
Hi Sebastian,
On 23/05/2019 23:07, Sebastian Reichel wrote:
@@ -302,6 +328,30 @@ void omap_crtc_vblank_irq(struct drm_crtc *crtc)
DBG("%s: apply done", omap_crtc->name);
}
+void omap_crtc_framedone_irq(struct drm_crtc *crtc, uint32_t irqstatus)
+{
+ struct omap_crtc
On 27/05/2019 23:41, Thomas Meyer wrote:
Make sure (of/i2c/platform)_device_id tables are NULL terminated.
Signed-off-by: Thomas Meyer
---
diff -u -p a/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
b/drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c
---
On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
wrote:
>
> Am 28.05.19 um 09:38 schrieb Daniel Vetter:
> > [SNIP]
> >> Might be a good idea looking into reverting it partially, so that at
> >> least command submission and buffer allocation is still blocked.
> > I thought the issue is a lot
The driver currently sets the video stream registers in
tc_main_link_setup. One should be able to establish the DP link without
any video stream, so a more logical place is to configure the stream in
the tc_main_link_stream. So move them there.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej
tc_aux_get_status() does not report AUX_TIMEOUT correctly, as it only
checks the AUX_TIMEOUT if aux is still busy. Fix this by always checking
for AUX_TIMEOUT.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 11 +++
1 file changed, 7
The driver sets up AUX link at probe time, but, for some reason, also
sets the main link's number of lanes using tc->link.base.num_lanes. This
is not needed nor correct, as the number of lanes has not been decided
yet. The number of lanes will be set later during main link setup.
Modify
We need to know the link bandwidth to filter out modes we cannot
support, so we need to have read the display props before doing the
filtering.
To ensure we have up to date display props, call tc_get_display_props()
in the beginning of tc_connector_get_modes().
Signed-off-by: Tomi Valkeinen
---
drm_connector_helper_funcs.best_encoder is only needed when the
connector can have more than one encoder, and that is never the case
here.
So remove tc_connector_best_encoder.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
The current link training code does unnecessary retry-loops, and does
extra writes to the registers. It is easier to follow the flow and
ensure it's similar to Toshiba's documentation if we deal with LT inside
tc_main_link_enable() function.
This patch adds tc_wait_link_training() which handles
tc_main_link_enable() checks if videomode has been set, and fails if
there's no videomode. As tc_main_link_enable() no longer depends on the
videomode, we can drop the check.
Also, while tc_stream_enable() does depend on the videomode, we can
expect that a mode has been set before
Add DT property for defining the pin used for HPD.
Signed-off-by: Tomi Valkeinen
Cc: devicet...@vger.kernel.org
Cc: Rob Herring
Reviewed-by: Rob Herring
---
.../devicetree/bindings/display/bridge/toshiba,tc358767.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
Currently we have tc_main_link_setup(), which configures and enabled the
link, but we have no counter-part for disabling the link.
Add tc_main_link_disable, and rename tc_main_link_setup to
tc_main_link_enable.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
The driver has a loop after ending link training, where it reads the
DPCD link status and prints an error if that status is not ok.
The loop is unnecessary, as far as I can understand from DP specs, so
let's remove it. We can also print the more specific errors to help
debugging.
Signed-off-by:
In tc_bridge_mode_set callback, we store the pointer to the given
drm_display_mode, and use the mode later. Storing a pointer in such a
way looks very suspicious to me, and I have observed odd issues where
the timings were apparently (at least mostly) zero.
Do a copy of the drm_display_mode
We have tc_connector_mode_valid() to filter out videomdoes that the
tc358767 cannot support. As it is a bridge limitation, change the code
to use drm_bridge_funcs's mode_valid instead.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
Link training will sometimes fail if the DP link is enabled when
tc_main_link_enable() is called. The driver makes sure the DP link is
disabled when the DP output is disabled, and we never enable the DP
without first disabling it, so this should never happen.
However, as the HW behavior seems to
Currently the code writes 0 to DP0CTL in tc_stream_disable(), which
disables the whole DP link instead of just the video stream. We always
disable the link and the stream together from tc_bridge_disable(), so
this doesn't cause any issues.
Nevertheless, fix this by only clearing VID_EN in
We set up the PXL PLL inside tc_main_link_setup. This is unnecessary,
and makes tc_main_link_setup depend on the video-mode, which should not
be the case. As PXL PLL is used only for the video stream (and only when
using the HW test pattern), let's move the PXL PLL setup into
tc_stream_enable.
At the end of the link training, two steps have to be taken: 1)
tc358767's LT mode is disabled by a write to DP0_SRCCTRL, and 2) Remove
LT flag in DPCD 0x102.
Toshiba's documentation tells to first write the DPCD, then modify
DP0_SRCCTRL. In my testing this often causes issues, and the link
On 28/05/19 3:09 PM, Tony Lindgren wrote:
Hi,
* Tomi Valkeinen [190528 09:19]:
On 27/05/2019 14:21, Tony Lindgren wrote:
Looks good to me. For some reason I can't boot 5.2-rc2 (on x15) so I haven't
been able to test yet. I'll pick the series up in any case, and I'll test it
when I get
https://bugs.freedesktop.org/show_bug.cgi?id=110787
--- Comment #1 from Manuel Vögele ---
Created attachment 144367
--> https://bugs.freedesktop.org/attachment.cgi?id=144367=edit
Output of glxinfo
--
You are receiving this mail because:
You are the assignee for the
From: Sean Paul
This comment doesn't make any sense, remove it.
Suggested-by: Jordan Crouse
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
On Wed, 29 May 2019 at 02:47, Emil Velikov wrote:
>
> On 2019/05/28, Koenig, Christian wrote:
> > Am 28.05.19 um 18:10 schrieb Emil Velikov:
> > > On 2019/05/28, Daniel Vetter wrote:
> > >> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
> > >> wrote:
> > >>> Am 28.05.19 um 09:38 schrieb
From: Sean Paul
There's a comment in _dpu_kms_hw_destroy() that reads "safe to call
these more than once during shutdown", referring to
_dpu_kms_mmu_destroy(). Unfortunately that's not the case, mmu_destroy
will fail hard if it's called twice. So fix that function to ensure it
can be called
https://bugs.freedesktop.org/show_bug.cgi?id=110786
Bug ID: 110786
Summary: Adaptive sync (vrr, freesync): Cinnamon DE isn't
blacklisted properly
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=110786
dron1...@gmail.com changed:
What|Removed |Added
Severity|normal |enhancement
--
You are receiving
On Tue, May 28, 2019 at 10:06:12AM -0700, Jeffrey Hugo wrote:
> The A540 is a derivative of the A530, and is found in the MSM8998 SoC.
>
> Signed-off-by: Jeffrey Hugo
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 22 +++
> drivers/gpu/drm/msm/adreno/a5xx_power.c| 76
https://bugs.freedesktop.org/show_bug.cgi?id=106302
--- Comment #4 from s...@vestigecounty.com ---
Thank you for being exactly on point, it turns out I was using a frivolous
interpretation of "change" rather than the one specified in OpenGL ES. The bug
can safely be closed as invalid, as fence
Sigh ... looks like this doesn't actually do what we want. See the
last couple comments in:
https://bugs.freedesktop.org/show_bug.cgi?id=110660
It seems to work as expected with "mode" instead of "adjusted_mode".
Does that make sense? It kinda does based on the later code, which
copies mode into
[Why]
For userspace to send static HDR metadata to the display we need to
attach the property on the connector and send it to DC.
[How]
The property is attached to HDMI and DP connectors. Since the metadata
isn't actually available when creating the connector this isn't a
property we can
This patch series enables HDR output metadata support in amdgpu using the
DRM HDR interface merged in drm-misc-next. Enabled for DCE and DCN ASICs
over DP and HDMI.
It's limited to static HDR metadata support for now since that's all the
DRM interface supports. It requires a modeset for entering
[Why]
We can issue HDR static metadata as part of stream updates for
non-modesets as long as we force a modeset when entering or exiting HDR.
This avoids unnecessary blanking for simple metadata updates.
[How]
When changing scaling and abm for the stream also check if HDR has
changed and send
On Tue, May 28, 2019 at 02:26:45PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> This comment doesn't make any sense, remove it.
>
> Suggested-by: Jordan Crouse
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 -
> 1 file changed, 1 deletion(-)
Reviewed-by:
On Tue, May 28, 2019 at 2:45 PM Jordan Crouse wrote:
>
> On Tue, May 28, 2019 at 10:06:12AM -0700, Jeffrey Hugo wrote:
> > The A540 is a derivative of the A530, and is found in the MSM8998 SoC.
> >
> > Signed-off-by: Jeffrey Hugo
> > ---
> > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 22
https://bugs.freedesktop.org/show_bug.cgi?id=110787
Bug ID: 110787
Summary: Glitches in console of the Julia language plugin for
Atom (Juno)
Product: Mesa
Version: 19.0
Hardware: x86-64 (AMD64)
OS: Linux
On Tue, May 28, 2019 at 07:32:14PM -0600, Jeffrey Hugo wrote:
> On Tue, May 28, 2019 at 7:17 PM Brian Masney wrote:
> >
> > On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > > On Thu, May 9, 2019 at 4:04 AM Brian Masney wrote:
> > >
> > > > Here is a patch series that adds
Hi, Hsin-Yi:
On Mon, 2019-05-27 at 12:50 +0800, Hsin-Yi Wang wrote:
> There is no clk_prepare() called in mtk_drm_crtc_reset(), when unbinding
> drm device, mtk_drm_crtc_destroy() will be triggered, and the clocks will
> be disabled and unprepared in mtk_crtc_ddp_clk_disable. If clk_unprepare()
>
https://bugs.freedesktop.org/show_bug.cgi?id=110658
--- Comment #4 from Timothy Arceri ---
I've run it on llvm 8 and mesa 19.0.5 and was unable to reproduce the issues
seen in the screen capture on my Vega 64.
--
You are receiving this mail because:
You are the assignee for the
On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> On Thu, May 9, 2019 at 4:04 AM Brian Masney wrote:
>
> > Here is a patch series that adds initial display support for the LG
> > Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> > of these patches are RFC
On Tue, May 28, 2019 at 7:37 PM Brian Masney wrote:
>
> On Tue, May 28, 2019 at 07:32:14PM -0600, Jeffrey Hugo wrote:
> > On Tue, May 28, 2019 at 7:17 PM Brian Masney wrote:
> > >
> > > On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > > > On Thu, May 9, 2019 at 4:04 AM Brian
1 - 100 of 211 matches
Mail list logo
