On 2019-05-24 10:32, Sean Paul wrote:
From: Sean Paul
Instead of reaching into dev->primary for debugfs_root, use the minor
passed into debugfs_init.
This avoids creating the debug directory under /sys/kernel/debug/ and
instead creates the directory under the correct node in
On Tue, 21 May 2019 01:50:07 +0200, meg...@megous.com wrote:
> From: Ondrej Jirman
>
> Some Allwinner SoC using boards (Orange Pi 3 for example) need to enable
> on-board voltage shifting logic for the DDC bus using a gpio to be able
> to access DDC bus. Use ddc-en-gpios property on the
On 2019-05-23 5:06 a.m., Christian König wrote:
> [CAUTION: External Email]
>
> Leaving BOs on the LRU is harmless. We always did this for VM page table
> and per VM BOs.
>
> The key point is that BOs which couldn't be reserved can't be evicted.
> So what happened is that an application used
Hi Hans,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.2-rc1 next-20190524]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
On Fri, May 24, 2019 at 1:43 PM Stephen Boyd wrote:
>
> Quoting Sean Paul (2019-05-24 10:32:18)
> > From: Sean Paul
> >
> > Instead of reaching into dev->primary for debugfs_root, use the minor
> > passed into debugfs_init.
> >
> > This avoids creating the debug directory under
On 2019-05-24 10:32, Sean Paul wrote:
From: Sean Paul
Fold it into dpu_debugfs_init.
Cc: Stephen Boyd
Signed-off-by: Sean Paul
Reviewed-by: Abhinav Kumar
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=110659
--- Comment #6 from tempel.jul...@gmail.com ---
Situation is unchanged with 5.3-wip.
It also occurs with amdvlk instead of radv if you turn on pageflipping via
UseFlipHint,1 in amdPalSettings.cfg (for incomprehensible reasons it is
disabled by
Quoting Colin King (2019-05-24 22:26:27)
> From: Colin Ian King
>
> Currently when the allocation of ppgtt->work fails the error return
> path via err_free returns an uninitialized value in err. Fix this
> by setting err to the appropriate error return of -ENOMEM.
>
> Addresses-Coverity:
On Wed, 15 May 2019 18:04:28 +0200, Lukasz Majewski wrote:
> This commit adds documentation entry description for KOE's 5.7" display.
>
> Signed-off-by: Lukasz Majewski
>
> ---
> Previous discussion (and Rob's Reviewed-by) about this patch
> https://patchwork.kernel.org/patch/10339595/
>
>
Hi Hans,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v5.2-rc1 next-20190524]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
From: Sean Paul
If bind fails, we can call msm_drm_uninit before kms elements have been
created. In this case, drm_atomic_helper_shutdown will fail since there
are no drm objects. Only call drm unregistration and shutdown if drm is
registered.
Also while we're in here move the workqueue
From: Colin Ian King
Currently when the allocation of ppgtt->work fails the error return
path via err_free returns an uninitialized value in err. Fix this
by setting err to the appropriate error return of -ENOMEM.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: d3622099c76f
Hi, Emil
On Fri, 2019-05-24 at 16:26 +0100, Emil Velikov wrote:
> On 2019/05/24, Thomas Hellstrom wrote:
> > On Fri, 2019-05-24 at 13:14 +0100, Emil Velikov wrote:
> > > On 2019/05/23, Thomas Hellstrom wrote:
> > > > Hi, Emil,
> > > >
> > > > On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov
https://bugs.freedesktop.org/show_bug.cgi?id=109754
--- Comment #1 from Pierre-Eric Pelloux-Prayer ---
Thanks for your bug report.
I've opened a merge request to fix this bug:
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/946
--
You are receiving this mail because:
You are the
Tegra20 has a high priority request control that allow to configure
when display's memory client should perform read requests with a higher
priority (Tegra30+ uses other means). Set up the controls for a more
aggressive prefetching to reliably avoid FIFO underflow on a lower memory
frequency, this
Display controller (DC) performs isochronous memory transfers and thus
has a requirement for a minimum memory bandwidth that shall be fulfilled,
otherwise framebuffer data can't be fetched fast enough and this results
in a DC's data-FIFO underflow that follows by a visual corruption.
The External
Hello,
Display controllers have a need for minimum memory bandwidth in order to
maintain data-stream to output at a required rate. There is a visual
corruption once the requirement is violated and CRTC reset may be required
in order to recover. This series adds preliminary support for the memory
I found useful to know the total number of underflow events while was
working on adding support for memory bandwidth management. Currently
the debug stats are getting reset after disabling CRTC, let's account
the overall number of events that doesn't get reset.
Signed-off-by: Dmitry Osipenko
---
On Wed, 2019-05-22 at 21:09 +0200, Daniel Vetter wrote:
> On Wed, May 22, 2019 at 9:01 PM Thomas Hellstrom <
> thellst...@vmware.com> wrote:
> > Hi, Emil,
> >
> > On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> > > From: Emil Velikov
> > >
> > > Currently vmw_execbuf_ioctl() open-codes
On Thu, 23 May 2019, Jonathan Corbet wrote:
> With Sphinx 2.0 (or prior versions with the deprecation warnings fixed) the
> docs build fails with:
>
> Documentation/gpu/i915.rst:403: WARNING: Title level inconsistent:
>
> Global GTT Fence Handling
> ~
>
> reST
On Fri, May 24, 2019 at 8:05 AM Thomas Hellstrom wrote:
>
> On Wed, 2019-05-22 at 21:09 +0200, Daniel Vetter wrote:
> > On Wed, May 22, 2019 at 9:01 PM Thomas Hellstrom <
> > thellst...@vmware.com> wrote:
> > > Hi, Emil,
> > >
> > > On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> > > >
On Thu, May 23, 2019 at 10:37:19PM -0400, Qian Cai wrote:
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> index bf6c3500d363..5c567b81174f 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> @@ -747,6
https://bugs.freedesktop.org/show_bug.cgi?id=110616
Andre Klapper changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEEDINFO
On 5/21/2019 11:52 AM, Viresh Kumar wrote:
On 20-03-19, 15:19, Rajendra Nayak wrote:
This is a v2 of the RFC posted earlier by Stephen Boyd [1]
As part of v2 I still follow the same approach of dev_pm_opp_set_rate()
API using clk framework to round the frequency passed and making it
accept 0
On Thu, May 23, 2019 at 11:10:39AM -0500, Rob Herring wrote:
> On Thu, May 23, 2019 at 6:54 AM Maxime Ripard
> wrote:
> >
> > On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the drm-misc tree got a conflict in:
> > >
> > >
Hi Bartlomiej,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.2-rc1 next-20190524]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Le lun. 13 mai 2019 à 16:46, Philippe CORNU a écrit :
>
> Dear Yannick,
>
> Acked-by: Philippe Cornu
>
Applied on drm-misc-next,
Benjamin
> Thank you,
>
> Philippe :-)
>
> On 5/13/19 3:15 PM, Yannick Fertré wrote:
> > Clk_round_rate returns rounded clock without changing
> > the hardware in
Le ven. 10 mai 2019 à 18:31, Philippe CORNU a écrit :
>
>
> Dear Yannick,
> Thank you for your patch,
>
> Acked-by: Philippe Cornu
>
> Dear Benjamin,
> If you are fine with this patch, please push it *after* the patch named
> "drm/stm: dsi: add support of an optional regulator" (if I well
>
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
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
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
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
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
drm-misc-next-2019-05-24:
drm-misc-next for v5.3, try #2:
Cross-subsystem Changes:
- Fix device tree bindings in drm-misc-next after a botched merge.
Core Changes:
- Docbook fix for drm_hdmi_infoframe_set_hdr_metadata.
Driver Changes:
- mediatek: Fix compiler warning after merging the HDR
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
Cc: Jens Frederich
Cc: Daniel Drake
Cc: Jon Nettleton
---
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
It's not pretty.
Signed-off-by: Daniel Vetter
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 --git a/drivers/video/fbdev/core/fbcon.c
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
Cc:
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
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
Cc: Daniel Vetter
---
drivers/video/fbdev/sa1100fb.c | 25
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
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: Greg Kroah-Hartman
Cc: Kees Cook
Just drive-by, nothing systematic yet.
Signed-off-by: Daniel Vetter
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 Patocka
Cc: Kees Cook
---
drivers/video/fbdev/core/fbmem.c
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
Cc: Greg Kroah-Hartman
Cc: Nicolas Pitre
Cc: Adam Borowski
Cc:
Entirely unused.
Signed-off-by: Daniel Vetter
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/drivers/video/fbdev/cyber2000fb.c
index
Hi all,
I fixed the fbcon_exited mess that CI spotted (hopefully it works now, the
code is still rather brittle imo). Plus all the little nits 0day and
people found.
Maarten slapped an rb onto the entire pile, but I feel like enough has
changed that a 2nd look from him is warranted.
I also
It's dead code, and removing it avoids me having to understand
what it's doing with lock_fb_info.
Signed-off-by: Daniel Vetter
Reviewed-by: Geert Uytterhoeven
Cc: Geert Uytterhoeven
Cc: Daniel Vetter
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 63 --
Which means lock_fb_info can never fail. Remove the error handling.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Rob Clark
---
drivers/video/fbdev/core/fbsysfs.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git
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
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
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: Greg
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
Cc: Lee Jones
Cc: Daniel Thompson
Cc:
It's properly protected by reboot_lock.
Signed-off-by: Daniel Vetter
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 file changed, 1 insertion(+), 2 deletions(-)
diff --git
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
Which means lock_fb_info can never fail. Remove the error handling.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
---
.../video/fbdev/omap2/omapfb/omapfb-sysfs.c | 21 +++
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git
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
Cc: Paul Mackerras
Cc: linux-fb...@vger.kernel.org
---
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
Cc: Lukas Wunner
Cc: David Airlie
Cc: Daniel Vetter
Cc:
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
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
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
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
On 5/24/19 11:11 AM, Thomas Hellstrom wrote:
Hi, Christian,
On 5/24/19 10:37 AM, Koenig, Christian wrote:
Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware):
[CAUTION: External Email]
From: Thomas Hellstrom
With SEV encryption, all DMA memory must be marked decrypted
(AKA "shared") for
On Thu, May 23, 2019 at 10:36:38AM +0100, james qian wang (Arm Technology
China) wrote:
> Komeda driver uses a individual component to describe the HW's writeback
> caps, but drivers doesn't define a new structure and still uses the
> existing "struct komeda_layer" to describe this new component.
https://bugs.freedesktop.org/show_bug.cgi?id=110752
Bug ID: 110752
Summary: Make kms_ccs clearer
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority:
https://bugs.freedesktop.org/show_bug.cgi?id=110752
Arek Hiler changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |arkadiusz.hi...@intel.com
On Fri, May 24, 2019 at 12:29 AM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm-fixes tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: In function
> 'load_dmcu_fw':
>
On 29/04/2019 12:23, Jerome Brunet wrote:
> Imply the i2s part of the Synopsys HDMI driver for Amlogic SoCs.
> This will enable the i2s part by default when meson hdmi driver
> is enable but let platforms not supported by the audio subsystem
> disable it if necessary.
>
> Signed-off-by: Jerome
Yeah, that shouldn't be a problem. We just need to make sure we don't
busy wait for the BOs to become available.
Christian.
Am 24.05.19 um 07:35 schrieb Liang, Prike:
Use Abaqus torturing the amdgpu driver more times will running into locking
first busy BO deadlock .Then the caller will
Hi Daniel,
On Fri, 24 May 2019 10:09:28 +0200 Daniel Vetter wrote:
>
> On Fri, May 24, 2019 at 12:29 AM Stephen Rothwell
> wrote:
> >
> > After merging the drm-fixes tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> >
There is no good reason to flood the kernel log with a WARN
stacktrace just because someone tried to mmap a prime buffer.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_prime.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_prime.c
Some display panels would come up with a non-DSI output which
can have an option to connect DSI interface by means of bridge
converter.
This DSI to non-DSI bridge converter would require a bridge
driver that would communicate the DSI controller for bridge
functionalities.
So, add support for
This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M2M board.
Bananapi S070WV20-CT16 is a pure RGB output panel with ICN6211 DSI/RGB
convertor bridge, so enable bridge along with associated panel.
DSI panel connected via board DSI port with,
- DCDC1 as VCC-DSI supply
- PL5 gpio
This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M2M board.
DSI panel connected via board DSI port with,
- DCDC1 as VCC-DSI supply
- PL5 gpio for lcd reset gpio pin
- PB7 gpio for lcd enable gpio pin
- PL4 gpio for backlight enable pin
Signed-off-by: Jagan Teki
---
ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
It has a flexible configuration of MIPI DSI signal input
and produce RGB565, RGB666, RGB888 output format.
Add dt-bingings for it.
Signed-off-by: Jagan Teki
---
.../display/bridge/chipone,icn6211.txt| 78 +++
1 file
On Thu, 23 May 2019, tcamuso wrote:
> From Daniel Kwon
>
> The system was crashed due to invalid memory access while trying to access
> auxiliary device.
>
> crash> bt
> PID: 9863 TASK: 89d1bdf11040 CPU: 1 COMMAND: "ipmitool"
> #0 [89cedd7f3868] machine_kexec at b0663674
>
https://bugs.freedesktop.org/show_bug.cgi?id=110754
Bug ID: 110754
Summary: Add tests checking how stable the CRCs are
Product: DRI
Version: unspecified
Hardware: Other
OS: All
Status: NEW
Severity:
Pretty simple case really.
v2: Forgot to remove a break;
v3: Add static inline to the dummy versions.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: "Steven Rostedt (VMware)"
Cc: Prarit Bhargava
Cc: Kees Cook
Cc: Yisheng Xie
Cc:
There's a callchain of:
fbcon_fb_blaned -> 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
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
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Yisheng Xie
Cc: "Michał Mirosław"
From: "Lowry Li (Arm Technology China)"
Creates plane alpha and blend mode properties attached to plane.
This patch depends on:
- https://patchwork.freedesktop.org/series/59915/
- https://patchwork.freedesktop.org/series/58665/
- https://patchwork.freedesktop.org/series/59000/
-
On Fri, May 24, 2019 at 2:04 AM Maxime Ripard wrote:
>
> On Mon, May 20, 2019 at 02:33:08PM +0530, Jagan Teki wrote:
> > According to "DRM kernel-internal display mode structure" in
> > include/drm/drm_modes.h the current driver is trying to include
> > sync timings along with front porch value
On Fri, May 24, 2019 at 2:07 AM Maxime Ripard wrote:
>
> On Mon, May 20, 2019 at 02:33:09PM +0530, Jagan Teki wrote:
> > start value in video start delay computation done in below commit
> > is as per the legacy bsp drivers/video/sunxi/legacy..
> > "drm/sun4i: dsi: Change the start delay
On Fri, May 24, 2019 at 2:18 AM Maxime Ripard wrote:
>
> On Mon, May 20, 2019 at 02:33:10PM +0530, Jagan Teki wrote:
> > The current code is computing vertical video start delay as
> >
> > delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + start;
> >
> > On which the second parameter
> >
On Fri, May 24, 2019 at 05:20:24PM +0800, Lowry Li (Arm Technology China) wrote:
> From: "Lowry Li (Arm Technology China)"
>
> Creates plane alpha and blend mode properties attached to plane.
>
> This patch depends on:
> - https://patchwork.freedesktop.org/series/59915/
> -
From: Thomas Hellstrom
With SEV encryption, all DMA memory must be marked decrypted
(AKA "shared") for devices to be able to read it. In the future we might
want to be able to switch normal (encrypted) memory to decrypted in exactly
the same way as we handle caching states, and that would
fyi sfr reported that 55143dc23ca4 ("drm/amd/display: Don't load DMCU
for Raven 1") breaks the build on x86-64. But I can't repro and didn't
immediately see what Kconfig it would need to trigger this, so no
idea. So just heads up in case this is real and there's some odd
config that hits a bug
Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware):
> [CAUTION: External Email]
>
> From: Thomas Hellstrom
>
> With SEV encryption, all DMA memory must be marked decrypted
> (AKA "shared") for devices to be able to read it. In the future we might
> want to be able to switch normal (encrypted)
As part of trying to understand the locking (or lack thereof) in the
fbcon/vt/fbdev maze, annotate everything.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Kees Cook
Cc: Nicolas Pitre
---
Hi, Christian,
On 5/24/19 10:37 AM, Koenig, Christian wrote:
Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware):
[CAUTION: External Email]
From: Thomas Hellstrom
With SEV encryption, all DMA memory must be marked decrypted
(AKA "shared") for devices to be able to read it. In the future
On Fri, 24 May 2019 at 18:11, Daniel Vetter wrote:
>
> fyi sfr reported that 55143dc23ca4 ("drm/amd/display: Don't load DMCU
> for Raven 1") breaks the build on x86-64. But I can't repro and didn't
> immediately see what Kconfig it would need to trigger this, so no
> idea. So just heads up in
On 5/24/19 12:18 PM, Koenig, Christian wrote:
Am 24.05.19 um 11:55 schrieb Thomas Hellstrom:
[CAUTION: External Email]
On 5/24/19 11:11 AM, Thomas Hellstrom wrote:
Hi, Christian,
On 5/24/19 10:37 AM, Koenig, Christian wrote:
Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware):
[CAUTION:
Hey Linus,
Nothing too unusual here for rc2. Except the amdgpu DMCU firmware
loading fix caused build breakage with a different set of Kconfig
options. I've just reverted it for now until the AMD folks can rewrite
it to avoid that problem.
i915:
- boosting fix
- bump ready task fixes
- GVT -
On Fri, May 24, 2019 at 2:18 AM Maxime Ripard wrote:
>
> On Mon, May 20, 2019 at 02:33:11PM +0530, Jagan Teki wrote:
> > pll-video => pll-mipi => tcon0 => tcon0-pixel-clock is the typical
> > MIPI clock topology in Allwinner DSI controller.
> >
> > TCON dotclock driver is computing the desired
On Fri, Feb 1, 2019 at 8:01 PM Maxime Ripard wrote:
>
> On Tue, Jan 29, 2019 at 11:01:31PM +0530, Jagan Teki wrote:
> > On Tue, Jan 29, 2019 at 8:43 PM Maxime Ripard
> > wrote:
> > >
> > > On Mon, Jan 28, 2019 at 03:06:10PM +0530, Jagan Teki wrote:
> > > > On Sat, Jan 26, 2019 at 2:54 AM Maxime
Am 24.05.19 um 11:55 schrieb Thomas Hellstrom:
> [CAUTION: External Email]
>
> On 5/24/19 11:11 AM, Thomas Hellstrom wrote:
>> Hi, Christian,
>>
>> On 5/24/19 10:37 AM, Koenig, Christian wrote:
>>> Am 24.05.19 um 10:11 schrieb Thomas Hellström (VMware):
[CAUTION: External Email]
drm/bridge: Add ICN6211 MIPI-DSI/RGB bridge
This is v2 series for supporting Chipone ICN6211 DSI/RGB bridge,
here is the previous version set[1]
The overlay patch, has Bananapi panel which would depends on,
previous MIPI DSI fixes series[2] to make the panel works.
Changes for v2:
- use
Right now the driver is finding the panel using of_drm_find_panel,
replace the same with drm_of_find_panel_or_bridge which would help
to find the panel or bridge on the same call if bridge support added
in future.
Added NULL in bridge argument, same will replace with bridge parameter
once bridge
Hi all,
On Fri, 24 May 2019 20:15:48 +1000 Stephen Rothwell
wrote:
>
> Ah, in the drm-fixes tree, the definition of is protected by
^
ASICREV_IS_PICASSO
--
Cheers,
Stephen Rothwell
pgpbeG7pS2izu.pgp
Description: OpenPGP digital signature
On 5/24/19 4:36 AM, Jani Nikula wrote:
On Thu, 23 May 2019, tcamuso wrote:
From Daniel Kwon
The system was crashed due to invalid memory access while trying to access
auxiliary device.
crash> bt
PID: 9863 TASK: 89d1bdf11040 CPU: 1 COMMAND: "ipmitool"
#0 [89cedd7f3868]
ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
It has a flexible configuration of MIPI DSI signal input
and produce RGB565, RGB666, RGB888 output format.
Add bridge driver for it.
Signed-off-by: Jagan Teki
---
Note:
- drm_panel_bridge_add seems not working or incompatible
as per driver
On 2019/05/24, Daniel Vetter wrote:
> On Fri, May 24, 2019 at 8:05 AM Thomas Hellstrom
> wrote:
> >
> > On Wed, 2019-05-22 at 21:09 +0200, Daniel Vetter wrote:
> > > On Wed, May 22, 2019 at 9:01 PM Thomas Hellstrom <
> > > thellst...@vmware.com> wrote:
> > > > Hi, Emil,
> > > >
> > > > On Wed,
Hi,
On Fri, May 24, 2019 at 04:13:14PM +0530, Jagan Teki wrote:
> Some display panels would come up with a non-DSI output which
> can have an option to connect DSI interface by means of bridge
> converter.
>
> This DSI to non-DSI bridge converter would require a bridge
> driver that would
1 - 100 of 169 matches
Mail list logo
