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:
> > >
> > >
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 marku
https://bugs.freedesktop.org/show_bug.cgi?id=110616
Andre Klapper changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEEDINFO
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:
> > > > Fr
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':
> drivers/gpu/drm/amd/amdgpu
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: m
https://bugs.freedesktop.org/show_bug.cgi?id=110752
Arek Hiler changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |arkadiusz.hi...@intel.com
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 require
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 here
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 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
> under
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 any
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: normal
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)
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 Bru
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
retur
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
---
drivers/video/console/dum
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
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
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 a/drivers/video/fbdev/omap2/omapfb/omapfb-s
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
---
drivers/video/fbdev/
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: Mar
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 9a5751cb4e16..452ef07b3a0
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 added
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 --
drivers/video/fbd
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 a/drivers/video/fb
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
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 Kroah-Hart
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: Jing
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 a/d
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: Ma
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
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
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
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
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
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
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
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
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 series
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
---
drivers/staging/olpc_dcon/olpc_dc
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
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 b/drivers/video/fbdev
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: Bart
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: "Michał
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 s
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"
C
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 w
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/
- https://patchwor
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 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 case
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 - rese
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 DCL
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
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:
> >
> > drivers/gpu/drm/amd/amdgpu/../display/amdgpu_d
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]
From
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 wh
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.
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 calculati
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 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:
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
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 panel_or
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 s
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 b/drivers/gpu/drm/qxl/qxl_
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
---
arch/arm/bo
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
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 brid
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 fo
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] machine
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/
> - https://patchwork.fre
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, 20
On 5/24/19 12:53 PM, Emil Velikov wrote:
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, 201
Hi,
On Tue, May 21, 2019 at 09:45:58AM +0100, james qian wang (Arm Technology
China) wrote:
> On Thu, May 16, 2019 at 09:57:49PM +0800, Ayan Halder wrote:
> > On Thu, Apr 04, 2019 at 12:06:14PM +0100, james qian wang (Arm Technology
> > China) wrote:
> > >
> > > +static int
> > > +komeda_fb_af
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 communic
Add COMPILE_TEST support to pvr2fb driver for better compile
testing coverage.
While at it:
- mark pvr2fb_interrupt() and pvr2fb_common_init() with
__maybe_unused tag (to silence build warnings when
!SH_DREAMCAST)
- convert mmio_base in struct pvr2fb_par to 'void __iomem *'
from 'unsigned
On Fri, 2019-05-24 at 08:19 +0200, Christoph Hellwig 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_
Add COMPILE_TEST support to pvr2fb driver for better compile
testing coverage.
While at it:
- mark pvr2fb_interrupt() and pvr2fb_common_init() with
__maybe_unused tag (to silence build warnings when
!SH_DREAMCAST)
- convert mmio_base in struct pvr2fb_par to 'void __iomem *'
from 'unsigned
On Fri, May 24, 2019 at 06:48:32AM -0400, tony camuso wrote:
> 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
> >>
Am 24.05.19 um 12:37 schrieb Thomas Hellstrom:
> [CAUTION: External Email]
>
> 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
On Thu, May 23, 2019 at 06:53:20PM +0200, Sam Ravnborg wrote:
> Hi Linus, Gerd.
>
> > This moves the modesetting code from drm_fb_helper to drm_client so it
> > can be shared by all internal clients.
>
> Could one of you take a look at this series.
> Daniel already ack'ed the series on irc, but a
On Fri, May 24, 2019 at 11:10:09AM +, Brian Starkey wrote:
> Hi,
>
> On Tue, May 21, 2019 at 09:45:58AM +0100, james qian wang (Arm Technology
> China) wrote:
> > On Thu, May 16, 2019 at 09:57:49PM +0800, Ayan Halder wrote:
> > > On Thu, Apr 04, 2019 at 12:06:14PM +0100, james qian wang (Arm
On Thu, May 23, 2019 at 07:48:03AM -0700, Vasily Khoruzhick wrote:
> On Wed, May 22, 2019 at 11:54 PM Torsten Duwe wrote:
> >
> >
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-teres-i.dts
> > @@ -65,6 +65,21 @@
> >
On 2019/05/23, Thomas Hellstrom wrote:
> Hi, Emil,
>
> On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Drop the custom ioctl io encoding check - core drm does it for us.
>
> I fail to see where the core does this, or do I miss something?
drm_ioctl() allows
Hi Kishon,
On Sun, May 12, 2019 at 7:49 AM Guido Günther wrote:
>
> This adds support for the Mixel DPHY as found on i.MX8 CPUs but since
> this is an IP core it will likely be found on others in the future. So
> instead of adding this to the nwl host driver make it a generic PHY
> driver.
>
> Th
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #23 from Sylvain BERTRAND ---
It seems I get the same freezes than you. It takes hours of gaming to get some
random hard hang (no log). I thought I was overheating, but realized that my
system is on
"vacation" while playing.
linux am
It seems I get the same freezes than you. It takes hours of gaming to get some
random hard hang (no log). I thought I was overheating, but realized that my
system is on
"vacation" while playing.
linux amd-staging-drm-new/x11 native/mesa/llvm(erk...), all git no older than a
week.
playing mostly do
On 5/24/19 2:03 PM, Koenig, Christian wrote:
Am 24.05.19 um 12:37 schrieb Thomas Hellstrom:
[CAUTION: External Email]
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, Chris
Booting up with DMA_API_DEBUG_SG=y generates a warning due to the driver
forgot to set dma_parms appropriately. Set it just after vmw_dma_masks()
in vmw_driver_load().
DMA-API: vmwgfx :00:0f.0: mapping sg segment longer than device
claims to support [len=2097152] [max=65536]
WARNING: CPU: 2 PI
On Thu, May 23, 2019 at 11:40:51PM -0700, Christoph Hellwig wrote:
> On Thu, May 23, 2019 at 04:10:38PM -0300, Jason Gunthorpe wrote:
> >
> > On Thu, May 23, 2019 at 02:24:58PM -0400, Jerome Glisse wrote:
> > > I can not take mmap_sem in range_register, the READ_ONCE is fine and
> > > they are no
Em Mon, 22 Apr 2019 11:37:21 +0200
Paul Cercueil escreveu:
> The GiantPlus GPM940B0 is a 24-bit TFT panel where the RGB components
> are transferred sequentially on a 8-bit bus.
>
> Signed-off-by: Paul Cercueil
> ---
>
> Notes:
> v2: New patch
>
> v3: No change
>
> include/uapi/
GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).
Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_pocket2 data struct may very well need to be updated
with some
GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).
Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_micropc data struct may very well need to be updated
with some
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 wrote:
> > > From: Emil Velikov
> > >
> > > Drop the custom ioctl io encoding check - core drm does it for
> > > us.
> >
> > I fa
1 - 100 of 170 matches
Mail list logo
