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
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 behi
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
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
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 Hellstrom:
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 10:47:
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 review
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
posi
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 list
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 s
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 looki
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 more
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 cha
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 "implement
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 +--
1
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(+)
diff
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
b/drivers/gpu/drm/bridge/tc358
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 workin
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 b
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 tc_strea
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.
Als
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
discon
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 H
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 inse
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 aux_link_s
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
---
drivers/gpu/drm/bridge
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: T
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 instea
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
---
drivers/gpu/drm/br
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
---
drivers/gpu/drm/bridge/tc3
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 wa
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 drm_bridge_funcs
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
a/Documentation/devic
For some reason the driver has a msleep(100) after writing to
DP_PHY_CTRL. Toshiba's documentation doesn't suggest any delay is
needed, and I have not seen any issues with the sleep removed.
Drop it, as msleep(100) is a rather big one.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Re
Add GPIO and interrupt related registers for HPD work. Mark INTSTS_G and
GPIOI as volatile.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu
Add support for interrupt and hotplug handling. Both are optional.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/tc358767.c | 163 ++
1 file changed, 145 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
b/drivers/gpu/drm/bridg
https://bugs.freedesktop.org/show_bug.cgi?id=110780
Bug ID: 110780
Summary: RX 580 and 5K displays, bandwidth validation failed
with multiple monitors
Product: DRI
Version: unspecified
Hardware: All
OS: Linu
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
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 cal
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 d
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: K
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 d
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 Mackerras
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
Reviewed-by:
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 Pato
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 functio
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
use
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 backing
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 i
Simply because olpc never unregisters the damn thing. It also
registers the framebuffer directly by poking around in fbdev
core internals, so it's all around rather broken.
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Acked-by: Greg Kroah-Hartman
Reviewed-by: Maarten Lankhorst
Cc: Gr
With the recursion broken in the previous patch we can drop the
FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion
prevention was it's only job.
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
C
There's a callchain of:
fbcon_fb_blanked -> do_(un)blank_screen -> consw->con_blank
-> fbcon_blank -> fb_blank
Things don't go horribly wrong because the BKL console_lock safes the
day, but that's about it. And the seeming recursion is broken in 2
ways:
- Starting from the fbdev ioctl we
It's dead code, and removing it avoids me having to understand
what it's doing with lock_fb_info.
v2: Also remove sh_mobile_lcdc_must_reconfigure, now unused (Sam).
Signed-off-by: Daniel Vetter
Reviewed-by: Geert Uytterhoeven (v1)
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: G
This is unused code since
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
when fbcon was made a compile-time static dependency of fbdev. We
can't exit fbcon anymore without exiting f
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
---
.../video/fbdev/omap2/omapfb/omapfb-sysfs.c | 21 +++
1 file changed, 7 insertions(+), 14 deletions
Entirely unused.
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: Russell King
Cc: linux-arm-ker...@lists.infradead.org
---
drivers/video/fbdev/cyber2000fb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/cyber2000fb.c
b/driver
While at it, clean up the interface a bit and push the console locking
into fbcon.c.
v2: Remove now outdated comment (Lukas).
v3: Forgot to add static inline to the dummy function.
Acked-by: Lukas Wunner
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc
With all the work I've done on replacing fb notifier calls with direct
calls into fbcon the backlight/lcd notifier is the only user left.
It will only receive events now that it cares about, hence we can
remove this check.
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maar
These are actually fbcon ioctls which just happen to be exposed
through /dev/fb*. They completely ignore which fb_info they're called
on, and I think the userspace tool even hardcodes to /dev/fb0.
Hence just forward the entire thing to fbcon.c wholesale.
Note that this patch drops the fb_lock/unl
this driver is pretty horrible from a design pov, and needs a complete
overhaul. Concrete thing that annoys me is that it looks at
registered_fb, which is an internal thing to fbmem.c and fbcon.c. And
ofc it gets the lifetime rules all wrong (it should at least use
get/put_fb_info).
Looking at the
It's not pretty.
Signed-off-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Reviewed-by: Maarten Lankhorst
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Yisheng Xie
---
drivers/video/fbdev/core/fbcon.c | 19 +++
1 file changed, 19 insertions(+)
diff --g
This reverts commit 994efacdf9a087b52f71e620b58dfa526b0cf928.
The justification is that if hw blanking fails (i.e. fbops->fb_blank)
fails, then we still want to shut down the backlight. Which is exactly
_not_ what fb_blank() does and so rather inconsistent if we end up
with different behaviour bet
Except for driver bugs (which we'll catch with a WARN_ON) this is only
to report failures of the new driver taking over the console. There's
nothing the outgoing driver can do about that, and no one ever
bothered to actually look at these return values. So remove them all.
v2: fixup unregister_fra
For some reasons the pm_vt_switch_unregister call was missing from the
direct unregister_framebuffer path. Fix this.
v2: fbinfo->dev is used to decided whether unlink_framebuffer has been
called already. I botched that in v1. Make this all clearer by
inlining __unlink_framebuffer.
v3: Fix typoe i
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
d
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 also
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 Zolnierkiewicz
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
Reviewed
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: P
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 f
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 ca
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.
>
> Signed
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 won
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 the
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 lookin
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 o
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:
Reviewed-by:
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 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,
* 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.
>
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 the
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 are
* 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 ab
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 of
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 *omap_cr
https://bugs.freedesktop.org/show_bug.cgi?id=110635
--- Comment #7 from tempel.jul...@gmail.com ---
The OGL issue occurs with both LLVM 8 and 9-git, so there might not be a
connection to your radv issue here. I suppose LLVM 9 would also be fine with
AMD_DEBUG=nodma & radeonsi, which indicates that
On 28/05/2019 13:18, Tony Lindgren wrote:
This change lets me boot. I don't know that's the correct place, though:
diff --git a/arch/arm/boot/dts/am5728.dtsi b/arch/arm/boot/dts/am5728.dtsi
index 82e5427ef6a9..c778f9a86b3a 100644
--- a/arch/arm/boot/dts/am5728.dtsi
+++ b/arch/arm/boot/dts/am572
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
--- a/drivers/gpu/drm/omapdrm/dss/omapdss-b
https://bugs.freedesktop.org/show_bug.cgi?id=102370
Jani Saarinen changed:
What|Removed |Added
Component|DRM/Intel |IGT
Assignee|intel-gfx-bugs@l
On 22/05/2019 18:02, Emil Velikov wrote:
From: Emil Velikov
Cc: Tomi Valkeinen
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/omapdrm/omap_drv.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapd
On 23/04/2019 10:50, Kefeng Wang wrote:
Using dev_get_drvdata directly.
Cc: Tomi Valkeinen
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kefeng Wang
---
.../gpu/drm/omapdrm/displays/panel-dsi-cm.c| 18 ++
1 file changed, 6 insert
On 27.05.2019 17:11, Tomi Valkeinen wrote:
> On 21/05/2019 17:18, Andrzej Hajda wrote:
>
>>> DisplayPort spec talks about doing the display-props reading and EDID
>>> reading when
>>> handling HPD.
>>>
>>> I think it would be best to change the code so that we read display props
>>> and EDID in H
1 - 100 of 211 matches
Mail list logo
