On Sun, 2019-05-19 at 17:36 +0800, Jitao Shi wrote:
> On Tue, 2019-05-07 at 17:52 +0800, CK Hu wrote:
> > Hi, Jitao:
> >
> > On Tue, 2019-04-16 at 14:04 +0800, Jitao Shi wrote:
> > > DSI panel driver need attach function which is inculde in
> > > mipi_dsi_host_ops.
> > >
> > > If mipi_dsi_host_re
Hi, Jitao:
On Sun, 2019-05-19 at 17:25 +0800, Jitao Shi wrote:
> DSI panel driver need attach function which is inculde in
> mipi_dsi_host_ops.
>
> If mipi_dsi_host_register is not in probe, dsi panel will
> probe fail or more delay.
In [1], you have agreed this patch just for delay not for prob
On Mon, 20 May 2019 at 00:00, Sam Ravnborg wrote:
>
> The following patchset remove use of the deprecated drmP.h
> header file in the nouveau driver(s).
> As preparation a dependency on drm_os_linux.h is dropped.
> The list of include files are sorted and are in some cases
> divided up in blocks o
On Thu, May 16, 2019 at 05:51:30PM +0200, Torsten Duwe wrote:
> From: Icenowy Zheng
>
> Allwinner A64's TCON0 can output RGB666 LCD signal.
>
> Add its pinmux.
>
> Signed-off-by: Icenowy Zheng
> Signed-off-by: Vasily Khoruzhick
> Signed-off-by: Torsten Duwe
Applied, with sed/DTS/dts/ in the co
On Thu, May 16, 2019 at 11:52 PM Torsten Duwe wrote:
>
> From: Harald Geyer
>
> The TERES-I has internal speakers (left, right), internal microphone
> and a headset combo jack (headphones + mic), "CTIA" (android) pinout.
>
> The headphone and mic detect lines of the A64 are connected properly,
>
On 16.05.2019 17:25, Sabyasachi Gupta wrote:
> Remove duplicate header which is included twice
>
> Signed-off-by: Sabyasachi Gupta
Queued to drm-misc-next.
Regards
Andrzej
> ---
> v2: rebased the code against drm -next and arranged the headers alphabetically
>
> drivers/gpu/drm/bridge/pane
On Mon, May 20, 2019 at 03:56:13PM +0800, Chen-Yu Tsai wrote:
> On Thu, May 16, 2019 at 11:52 PM Torsten Duwe wrote:
> >
> > From: Harald Geyer
> >
> > The TERES-I has internal speakers (left, right), internal microphone
> > and a headset combo jack (headphones + mic), "CTIA" (android) pinout.
>
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
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
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/
Hi all,
This patch series removes the fbcon notifier. It also contains the
beginnings of trying to understand how locking in this area works.
The super short summary of locking rules is that everything in fbcon needs
to be protected by the monolithic console_lock, including the setup code.
So not
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 |
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
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
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 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
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
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
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
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
Cc: Daniel Vetter
---
drivers/video/fbdev/sh_mobile_lcdcfb.c | 63 --
drivers/video/fbdev/sh_mobile_lcdcfb.h | 5 --
2 files changed, 68 deleti
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
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
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 -
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
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.
Signed-off-by:
With the sh_mobile notifier removed we can just directly call the
fbcon code here.
v2: Remove now unused local variable.
Signed-off-by: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: Greg Kroah-Hartman
Cc: Prarit Bhargava
Cc: Kees Cook
Cc: Konstantin Kh
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.
Signed-off-by: Daniel Ve
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
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
We cant remove FB_EVENT_BLANK because that's still used by the
backlight and lcd code, but that's kinda fine: No recursion between
fbdev core code and fbcon code possible for that case.
Signed-off-by: Daniel Vetter
Cc: Daniel Vetter
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Yisheng X
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
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
Pretty simple case really.
v2: Forgot to remove a break;
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ł Mirosław"
Cc: Peter Rosin
Cc: Mikulas Patoc
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
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
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
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
Create a new wrapper function for this, feels like there's some
refactoring room here between the two modes.
Signed-off-by: Daniel Vetter
Cc: Lee Jones
Cc: Daniel Thompson
Cc: Jingoo Han
Cc: Bartlomiej Zolnierkiewicz
Cc: Daniel Vetter
Cc: Hans de Goede
Cc: Yisheng Xie
Cc: "Michał Mirosław"
On Fri, 2019-05-17 at 15:36 +0200, Maarten Lankhorst wrote:
> Op 10-05-2019 om 03:53 schreef Gwan-gyeong Mun:
> > Function intel_pixel_encoding_setup_vsc handles vsc header and data
> > block
> > setup for pixel encoding / colorimetry format.
> >
> > Setup VSC header and data block in function
> >
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
While at it, clean up the interface a bit and push the console locking
into fbcon.c.
Signed-off-by: Daniel Vetter
Cc: Lukas Wunner
Cc: David Airlie
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: Bartlomiej Zolnierkiewicz
Cc: Hans de Goede
Cc: Yisheng Xie
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 the
Hi, Jitao:
On Sun, 2019-05-19 at 17:33 +0800, Jitao Shi wrote:
> On Wed, 2019-05-08 at 10:39 +0800, CK Hu wrote:
> > On Tue, 2019-04-16 at 14:04 +0800, Jitao Shi wrote:
> > > Config the different CMDQ reg address in driver data.
> > >
> > For MT8173, you change reg_cmd_off from 0x180 to 0x200, so
Hi
Am 20.05.19 um 10:21 schrieb Daniel Vetter:
...
> diff --git a/drivers/video/fbdev/core/fbmem.c
> b/drivers/video/fbdev/core/fbmem.c
> index fc3d34a8ea5b..ae2db31eeba7 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1660,7 +1660,6 @@ MODULE_PARM_D
Hi
Am 20.05.19 um 10:33 schrieb Thomas Zimmermann:
> Hi
>
> Am 20.05.19 um 10:21 schrieb Daniel Vetter:
> ...
>> diff --git a/drivers/video/fbdev/core/fbmem.c
>> b/drivers/video/fbdev/core/fbmem.c
>> index fc3d34a8ea5b..ae2db31eeba7 100644
>> --- a/drivers/video/fbdev/core/fbmem.c
>> +++ b/drive
On Mon, May 20, 2019 at 10:22:13AM +0200, Daniel Vetter wrote:
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -3146,16 +3146,16 @@ void fbcon_fb_unregistered(struct fb_info *info)
> }
>
> /* called with console_lock held */
> -static void fbcon_remap_all(
On Mon, May 20, 2019 at 10:25 AM Daniel Vetter wrote:
> 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
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven
On Mon, May 20, 2019 at 10:22 AM Daniel Vetter wrote:
> 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_
Most of these issues are reproduced while supporting Allwinner A64
MIPI-DSI [1] but to confirm it with other SoC this series is reworked
on A33 since the controller tested it A33 as of now.
Since we don't have proper evidence and documentation for dsi controller
in Allwinner, these changes are mor
The current code is computing vertical video start delay as
delay = mode->vtotal - (mode->vsync_end - mode->vdisplay) + start;
On which the second parameter
mode->vsync_end - mode->vdisplay = front porch + sync timings
according to "DRM kernel-internal display mode structure" in
include/drm/drm
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 while checking and
computing drq set bits in non-burst mode.
mode->hsync_end - mode->hdisplay => horizontal front porch + sync
Wit
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 DCLK divider based on
panel pixel clock along with input DCLK min, max divider values from
tcon driver and that would eventually set the
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 calculation"
(sha1: da676c6aa6413d59ab0a80c97bbc273025e640b2)
This existing start delay computation gives start value of 35,
for "bananapi
Bananapi S070WV20-CT16 ICN6211 is 800x480, 4-lane MIPI-DSI to RGB bridge
panel which can be used to connect via DSI port on BPI-M64 board,
so add a driver for it.
The same panel PCB comes with parallel RBG which is supported via
panel-simple driver with "bananapi,s070wv20-ct16" compatible.
Signed
tcon0 divider is used while computing drq edge0 for burst mode
devices, currently driver is using default macro value 4 via
SUN6I_DSI_TCON_DIV.
Unfortunately not all the panel devices are working with this
default divider value 4, so to make future changes on this divider
value get the divider fro
Sometimes tcon attributes like tcon divider, clock rate etc are needed
in interface drivers like DSI. So for such cases interface driver must
probe the respective tcon and get the attributes.
Since tcon0 probe is already available, via sun4i_get_tcon0 function,
export the same instead of probing t
Allwinner MIPI DSI controllers are supplied with SoC
DSI power rails via VCC-DSI pin.
Add support for this supply pin by adding voltage
regulator handling code to MIPI DSI driver.
Tested-by: Merlijn Wajer
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 14 ++
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
- DLDO1 as VDD 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
Allwinner MIPI DSI controllers are supplied with SoC DSI
power rails via VCC-DSI pin.
Some board still work without supplying this but give more
faith on datasheet and hardware schematics and document this
supply property in required property list.
Reviewed-by: Rob Herring
Tested-by: Merlijn Waj
Probe tcon0 during dsi_bind, so-that the tcon attributes like
divider value, clock rates are available whenever it required.
Tested-by: Merlijn Wajer
Signed-off-by: Jagan Teki
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 6 ++
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.h | 1 +
2 files changed, 7
On Mon, May 20, 2019 at 11:06 AM Geert Uytterhoeven
wrote:
>
> On Mon, May 20, 2019 at 10:22 AM Daniel Vetter wrote:
> > 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
> >
VSC SDP Payload for PSR is one of data block type of SDP (Secondaray Data
Packet). In order to generalize SDP packet structure name, it renames
struct edp_vsc_psr to struct dp_sdp. And each SDP data blocks have
different usages, each SDP type has different reserved data blocks and
Video_Stream_Conf
On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
And Link M/N values are calculated and applied based on the Full Clock
forYCbCr4
Data M/N calculations were assumed a bpp as RGB format. But when we are
using YCbCr 4:2:0 output format on DP, we should change bpp calculations
as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format,
therefore, it was multiplied with 3. But YCbCr 4:2:0 requires a multiplier
value to 1.5.
This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr 4:4:4.
On 16/05/2019 21:26, Daniel Vetter wrote:
> On Thu, May 16, 2019 at 03:14:46PM +0100, Steven Price wrote:
>> Provide a wrapper for drm_gem_map_offset() for clients of shmem. This
>> wrapper provides the correct semantics for the drm_gem_shmem_mmap()
>> callback.
>>
>> Signed-off-by: Steven Price
>
Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to
HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and
HDMI ports.
v2: Minor style fix.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1 fi
Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.
Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP H
When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for t
drm_gem_dumb_map_offset() is a useful helper for non-dumb clients, so
rename it to remove the _dumb.
Signed-off-by: Steven Price
Acked-by: Alyssa Rosenzweig
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_dumb_buffers.c | 4 ++--
drivers/gpu/drm/drm_gem.c | 6 +++---
driv
On 03.05.2019 14:29, Tomi Valkeinen wrote:
> 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
--
Regards
Andrzej
On 03.05.2019 14:29, Tomi Valkeinen wrote:
> 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
Hi,
On Thu, 2019-05-16 at 12:31 +0200, Maxime Ripard wrote:
> The Rockchip VOP driver has a function, scl_vop_cal_scl_fac, that will
> lookup the drm_format_info structure from the fourcc passed to it by its
> caller.
>
> However, its only caller already derefences the drm_format_info structure
>
If SVGA_3D_CMD_DX_SET_SHADER is called with a shader ID
of SVGA3D_INVALID_ID, and a shader type of
SVGA3D_SHADERTYPE_INVALID, the calculated binding.shader_slot
will be 4294967295, leading to an out-of-bounds read in vmw_binding_loc()
when the offset is calculated.
Signed-off-by: Murray McAllister
This patch series add laye split support for komeda.
For layer split, a plane state will be split to two data flows and handled
by two separated komeda layer input pipelines. komeda supports two types of
layer split:
- none-scaling split:
/ layer-left -> \
plane_state
To achieve same caling effect compare with none split, the texel
calculation need to use the same scaling ratio before split, so add
"total_xxx" to pipeline to describe the hsize/vsize before split.
Update pipeline and d71_scaler_update accordingly.
Signed-off-by: James Qian Wang (Arm Technology C
Komeda supports two types of layer split:
- none-scaling split
- scaling split
Since D71 merger only support scaler as input, so for none-scaling split,
the two layer dflow will be output to compiz directly. for scaling_split,
the data flow will be merged by merger firstly, then output the merged
d
Introduce a new component komeda_merger, because D71 HW supports to split
a whole image to two half parts and does the scaling independently. Merger
merges two separate results to one, and output it to compositor or wb_layer
For this patch:
- Add the definition of komeda_merger/merger_state
- Repor
On 03.05.2019 14:29, Tomi Valkeinen wrote:
> 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.
>
> Neve
On 03.05.2019 14:29, Tomi Valkeinen wrote:
> 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 ne
On Friday, May 17, 2019 4:32:35 PM CEST Chris Wilson wrote:
> Quoting Janusz Krzysztofik (2019-05-17 15:06:17)
> > From: Janusz Krzysztofik
> >
> > During i915_driver_unload(), GEM contexts are verified restrictively
> > inside i915_gem_fini() if they don't consume shared resources which
> > shou
Hi,
On Thu 16 May 19, 12:31, Maxime Ripard wrote:
> So far, the drm_format_plane_cpp function was operating on the format's
> fourcc and was doing a lookup to retrieve the drm_format_info structure and
> return the cpp.
>
> However, this is inefficient since in most cases, we will have the
> drm_
Hi,
On Thu 16 May 19, 12:31, Maxime Ripard wrote:
> drm_format_info_plane_cpp() basically just returns the cpp array content
> found in the drm_format_info structure.
>
> Since it's pretty trivial, let's remove the function and have the users use
> the array directly
Reviewed-by: Paul Kocialkows
On 03.05.2019 14:29, Tomi Valkeinen wrote:
> 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.
>
> Th
Hi,
On Thu 16 May 19, 12:31, Maxime Ripard wrote:
> So far, the drm_format_plane_height/width functions were operating on the
> format's fourcc and was doing a lookup to retrieve the drm_format_info
> structure and return the cpp.
>
> However, this is inefficient since in most cases, we will have
On Mon, May 20, 2019 at 01:20:45PM +0200, Paul Kocialkowski wrote:
> Hi,
>
> On Thu 16 May 19, 12:31, Maxime Ripard wrote:
> > drm_format_info_plane_cpp() basically just returns the cpp array content
> > found in the drm_format_info structure.
> >
> > Since it's pretty trivial, let's remove the fun
Hi all,
In commit
0d90ccb70211 ("drm/i915: Delay semaphore submission until the start of the
signaler")
Fixes tag
Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchroni
has these problem(s):
- Subject has leading but no trailing parentheses
- Subject has leading
There is a DRM version of the mxsfb driver for quite some time
at drivers/gpu/drm/mxsfb/, so there is no need to keep maintaining
the fbdev version any longer.
Remove the fbdev mxsfb driver in favour of the DRM version.
Signed-off-by: Fabio Estevam
---
drivers/video/fbdev/Kconfig | 13 +-
dr
On Mon, May 20, 2019 at 3:59 AM Brian Masney wrote:
>
> The '#address-cells' and '#size-cells' properties were not defined in
> the lm3630a bindings and would cause the following error when
> attempting to validate the examples against the schema:
>
> Documentation/devicetree/bindings/leds/backlig
On Mon, May 20, 2019 at 08:14:03AM -0500, Rob Herring wrote:
> On Mon, May 20, 2019 at 3:59 AM Brian Masney wrote:
> >
> > The '#address-cells' and '#size-cells' properties were not defined in
> > the lm3630a bindings and would cause the following error when
> > attempting to validate the examples
This patch adds support for the YUV420 output from the Amlogic Meson SoCs
Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixe
In order to support the HDMI2.0 YUV420, YUV422 and the 10bit, 12bit and
16bits outpu use cases, add support for the recently introduced bridge
callback format_set().
This callback will setup the new input format and encoding from encoder,
then these information will be used instead of the default
Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support
for these modes in the connector if the platform supports them.
We limit these modes to DW-HDMI IP version >= 0x200a which
are designed to support HDMI2.0 display modes.
Signed-off-by: Neil Armstrong
Tested-by: Heiko Stuebner
This patch adds a new format_set() callback to the bridge ops permitting
the encoder to specify the new input format and encoding.
This allows supporting the very specific HDMI2.0 YUV420 output mode
when the bridge cannot convert from RGB or YUV444 to YUV420.
In this case, the encode must downsam
The Synopsys DW-HDMI CSC does not support downsampling to YUV420, so
the encoder must downsamle before, feeding the controller with a YUV420
pixel stream.
The encoder must declare the new bus format enc encoding the bridge, in
order to take it in account.
To solve this, a new format_set() bridge
With the YUV420 handling, we can dynamically setup the HDMI output
pixel format depending on the mode and connector info.
So now, we can output in YUV444, which is the native video pipeline
format, directly to the HDMI Sink if it's supported without
necessarily involving the HDMI Controller CSC.
S
https://bugs.freedesktop.org/show_bug.cgi?id=108824
--- Comment #9 from LoneVVolf ---
reverting commit
https://cgit.freedesktop.org/mesa/mesa/commit/?id=78e35df52aa2f7d770f929a0866a0faa89c261a9
solves the visual corruption and gets rid of the gpu fault messages in dmesg.
As that commit is 2/2 of
https://bugs.freedesktop.org/show_bug.cgi?id=108824
LoneVVolf changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=110701
LoneVVolf changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
Thanks, Murray,
I'll include in the next vmwgfx-fixes pull request.
On Mon, 2019-05-20 at 21:57 +1200, Murray McAllister wrote:
> If SVGA_3D_CMD_DX_SET_SHADER is called with a shader ID
> of SVGA3D_INVALID_ID, and a shader type of
> SVGA3D_SHADERTYPE_INVALID, the calculated binding.shader_slot
>
1 - 100 of 179 matches
Mail list logo
