Hi Enric,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on ljones-mfd/for-mfd-next]
[also build test ERROR on robh/for-next linus/master v5.6-rc4 next-20200305]
[cannot apply to linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to hel
On Wed, 2020-02-26 at 18:52 +0100, Hans de Goede wrote:
> Hi,
>
> On 2/26/20 5:05 PM, Alex Deucher wrote:
> > On Wed, Feb 26, 2020 at 10:43 AM Hans de Goede
> > wrote:
> > > Hi,
> > >
> > > On 2/26/20 4:29 PM, Alex Deucher wrote:
> > > > On Wed, Feb 26, 2020 at 10:16 AM Hans de Goede
> > > > wr
While fixing some regressions caused by introducing bandwidth checking
into the DP MST atomic helpers, I realized there was another much more
subtle regression that got introduced by a seemingly harmless patch to
fix unused variable errors while compiling with W=1 (mentioned in patch
2). Basically,
Noticed this while having some problems with hubs sometimes not being
detected on the first plug. Every single dpcd read or write function
returns the number of bytes transferred on success or a negative error
code, except apparently for drm_dp_mst_dpcd_write() - which returns 0 on
success.
There'
We actually expect this to return a 0 on success, or negative error code
on failure. In order to do that, we check whether or not we managed to
write the whole GUID and then return 0 if so, otherwise return a
negative error code. Also, let's add an error message here so it's a
little more obvious w
Sigh, this is mostly my fault for not giving commit cd82d82cbc04
("drm/dp_mst: Add branch bandwidth validation to MST atomic check")
enough scrutiny during review. The way we're checking bandwidth
limitations here is mostly wrong:
For starters, drm_dp_mst_atomic_check_bw_limit() determines the
pbn
AMD's patch series for adding DSC support to the MST helpers
unfortunately introduced a few regressions into the kernel that I didn't
get around to fixing until just now. I would have reverted the changes
earlier, but seeing as that would have reverted all of amd's DSC support
+ everything that was
It's already prefixed by dp_mst, so we don't really need to repeat
ourselves here. One of the changes I should have picked up originally
when reviewing MST DSC support.
There should be no functional changes here
Cc: Mikita Lipski
Cc: Sean Paul
Cc: Hans de Goede
Signed-off-by: Lyude Paul
---
We used to punt off reprobing path resources to the link address probe
work, but now that we handle CSNs asynchronously from the driver's HPD
handling we can do whatever the heck we want from the CSN!
So, reprobe the path resources from drm_dp_mst_handle_conn_stat(). Also,
get rid of the path reso
DisplayPort specifications are fun. For a while, it's been really
unclear to us what available_pbn actually does. There's a somewhat vague
explanation in the DisplayPort spec (starting from 1.2) that partially
explains it:
The minimum payload bandwidth number supported by the path. Each node
u
The pull request you sent on Fri, 6 Mar 2020 22:08:54 +0100:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-03-06-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2f501bb1802dbbf1467e754588da31f635ad
Thank you!
--
Deet-doot-dot, I am a bot.
https://
Hi Stephen,
Missatge de Stephen Boyd del dia dv., 6 de març
2020 a les 22:37:
>
> Quoting Enric Balletbo i Serra (2020-03-06 08:30:16)
> > Hi Stephen,
> >
> > On 5/3/20 22:01, Stephen Boyd wrote:
> > > Quoting Enric Balletbo i Serra (2020-03-02 03:01:26)
> > >> From: Matthias Brugger
> > >>
> >
Quoting Enric Balletbo i Serra (2020-03-06 08:30:16)
> Hi Stephen,
>
> On 5/3/20 22:01, Stephen Boyd wrote:
> > Quoting Enric Balletbo i Serra (2020-03-02 03:01:26)
> >> From: Matthias Brugger
> >>
> >> There is no strong reason for this to use CLK_OF_DECLARE instead of
> >> being a platform driv
Hi Thomas.
On Thu, Mar 05, 2020 at 04:59:33PM +0100, Thomas Zimmermann wrote:
> The gma500 driver uses empty implementations for some of its encoders.
> Replace the code with the generic simple encoder.
This parts looks good.
> As a side effect, the
> patch also removes an indirection in the enc
On Thu, Mar 05, 2020 at 04:59:31PM +0100, Thomas Zimmermann wrote:
> The exynos driver uses empty implementations for its encoders. Replace
> the code with the generic simple encoder.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/exynos/exynos_dp.c
On Thu, Mar 05, 2020 at 04:59:30PM +0100, Thomas Zimmermann wrote:
> The atmel-hlcdc driver uses an empty implementation for its encoder.
> Replace the code with the generic simple encoder.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Sam Ravnborg
> ---
> drivers/gpu/drm/atmel-hlcdc/atme
final correction: I probably could actually get rid of this patch and do this
a bit more nicely by just making sure that we reprobe path resources for
connectors while under drm_dp_mst_topology_mgr->base.lock on CSNs, instead of
punting it off to the link address work like we seem to be doing. So,
On Thu, Mar 05, 2020 at 04:59:29PM +0100, Thomas Zimmermann wrote:
> The arc driver uses empty implementations for its encoders. Replace
> the code with the generic simple encoder.
We should , as a follow-up patch, embed the encoder in
arcgpu_drm_private.
Then we drop the kzalloc() and avoid that
Hi Linus,
Here's the pull for the lone vgacon fix that we discussed. I added a short
explanation to the commit message where the overflow safety check is.
drm-fixes-2020-03-06-1:
one vgacon input check for stable
Cheers, Daniel
The following changes since commit 2ac4853e295bba53209917e14af701c4
On Mon, Mar 02, 2020 at 11:26:00PM +0100, Daniel Vetter wrote:
> We need to add a drmm_kstrdup for this, but let's start somewhere.
>
> This is not exactly perfect onion unwinding, but it's jsut a kfree so
> doesn't really matter at all.
>
> Signed-off-by: Daniel Vetter
Reluctanlyt... But anywa
On Tue, Mar 03, 2020 at 09:45:20AM +0100, Daniel Vetter wrote:
> A few things:
> - Update the example driver in the documentation.
> - We can drop the old kfree in drm_dev_release.
> - Add a WARN_ON check in drm_dev_register to make sure everyone calls
> drmm_add_final_kfree and there's no leaks.
On Mon, Mar 02, 2020 at 11:25:59PM +0100, Daniel Vetter wrote:
> A few things:
> - Update the example driver in the documentation.
> - We can drop the old kfree in drm_dev_release.
> - Add a WARN_ON check in drm_dev_register to make sure everyone calls
> drmm_add_final_kfree and there's no leaks.
On Mon, Mar 02, 2020 at 11:25:58PM +0100, Daniel Vetter wrote:
> These are the leftover drivers that didn't have a ->release hook that
> needed to be updated.
>
> Acked-by: Liviu Dudau
> Signed-off-by: Daniel Vetter
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Mihail Atanassov
> Cc: Russ
On Mon, Mar 02, 2020 at 11:25:57PM +0100, Daniel Vetter wrote:
> With this we can drop the final kfree from the release function.
>
> Reviewed-by: Hans de Goede
> Signed-off-by: Daniel Vetter
> Cc: Hans de Goede
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/tiny/gm12u320.c | 3 ++-
> 1 fil
On Mon, Mar 02, 2020 at 11:25:56PM +0100, Daniel Vetter wrote:
> With this we can drop the final kfree from the release function.
>
> Reviewed-by: Paul Cercueil
> Signed-off-by: Daniel Vetter
> Cc: Paul Cercueil
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/ingenic/ingenic-drm.c | 5 ++---
On Mon, Mar 02, 2020 at 11:25:55PM +0100, Daniel Vetter wrote:
> With this we can drop the final kfree from the release function.
>
> Reviewed-by: Noralf Trønnes
> Signed-off-by: Daniel Vetter
> Cc: "Noralf Trønnes"
Acked-by: Sam Ravnborg
> ---
> drivers/gpu/drm/tiny/repaper.c | 5 ++---
>
On Mon, Mar 02, 2020 at 11:26:12PM +0100, Daniel Vetter wrote:
> Allows us to drop the drm_driver.release callback.
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is
On Mon, Mar 02, 2020 at 11:26:11PM +0100, Daniel Vetter wrote:
> Allows us to drop the drm_driver.release callback.
>
> This is made possible by a preceeding patch which added a drmm_
> cleanup action to drm_mode_config_init(), hence all we need to do to
> ensure that drm_mode_config_cleanup() is
On Mon, Mar 02, 2020 at 11:26:08PM +0100, Daniel Vetter wrote:
> Instead rely on the automatic clean, for which we just need to check
> that drm_mode_config_init succeeded. To avoid an inversion in the
> cleanup we also have to move the dev_private allocation over to
> drmm_kzalloc.
>
> This is ma
Hi Daniel.
On Mon, Mar 02, 2020 at 11:26:06PM +0100, Daniel Vetter wrote:
> drm_mode_config_cleanup is idempotent, so no harm in calling this
> twice. This allows us to gradually switch drivers over by removing
> explicit drm_mode_config_cleanup calls.
>
> With this step it's now also possible th
On Thu, 2020-03-05 at 20:29 +0200, Ville Syrjälä wrote:
> On Thu, Mar 05, 2020 at 01:13:36PM -0500, Lyude Paul wrote:
> > On Thu, 2020-03-05 at 15:11 +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 04, 2020 at 05:36:12PM -0500, Lyude Paul wrote:
> > > > It's next to impossible for us to do connector
Hi Daniel.
> v2: Do all the kerneldoc at the end, to avoid lots of fairly pointless
> shuffling while getting everything into shape.
>
> v3: Add static to add/del_dr (Neil)
> Move typo fix to the right patch (Neil)
>
> v4: Enforce contract for drmm_add_final_kfree:
>
> Use ksize() to check that
Just as a comment, u8 for max_vfreq in struct drm_adaptive_sync_info
might be not very future proof?
I just read that ASUS announced a "TUF Gaming VG259QM" monitor which
seems to have an adaptive sync range of 48 Hz to 280 Hz, exceeding the
max 255 Hz of u8?
-mario
On Fri, Mar 6, 2020 at 4:02
On Fri, 6 Mar 2020 at 14:00, Pekka Paalanen wrote:
>
> On Wed, 19 Feb 2020 13:27:28 +
> Emil Velikov wrote:
>
> > From: Emil Velikov
> >
>
> ...
>
> > +/*
> > + * In the olden days the SET/DROP_MASTER ioctls used to return EACCES when
> > + * CAP_SYS_ADMIN was not set. This was used to preve
On Fri, Mar 06, 2020 at 12:30:46PM +0200, Jani Nikula wrote:
> On Thu, 05 Mar 2020, Manasi Navare wrote:
> > This patch adds defines for the detailed monitor
> > range flags as per the EDID specification.
> >
> > Suggested-by: Ville Syrjälä
> > Cc: Ville Syrjälä
> > Cc: Harry Wentland
> > Cc: C
On Tue, 3 Mar 2020 at 16:51, Emil Velikov wrote:
> > + objs = drm_gem_object_lookup(file, mode_cmd->handles[0]);
> > + if (!objs) {
> > + DRM_DEBUG_KMS("Failed to lookup GEM object\n");
> > + return ERR_PTR(-EINVAL);
> > +
Hi,
On Fri, Mar 06, 2020 at 04:06:28PM +0530, Harigovindan P wrote:
> Add support for Visionox panel driver.
>
> Signed-off-by: Harigovindan P
> ---
>
> Changes in v2:
> - Dropping redundant space in Kconfig(Sam Ravnborg).
> - Changing structure for include files(Sam Ravnborg).
>
Variables declared in a switch statement before any case statements
cannot be automatically initialized with compiler instrumentation (as
they are not part of any execution flow). With GCC's proposed automatic
stack variable initialization feature, this triggers a warning (and they
don't get initia
On Thu, 5 Mar 2020 at 13:15, tang pengchuan wrote:
> On Tue, Mar 3, 2020 at 2:29 AM Emil Velikov wrote:
>> Have you seen a case where the 0 or default case are reached? AFAICT they
>> will
>> never trigger. So one might as well use:
>>
>> switch (angle) {
>> case DRM_MODE_FOO:
>>
Hi Dafna,
Am Dienstag, 21. Januar 2020, 16:43:14 CET schrieb Dafna Hirschfeld:
> convert the binding file rockchip-drm.txt to yaml format.
> This was tested and verified on ARM and ARM64 with:
> make dt_binding_check
> DT_SCHEMA_FILES=Documentation/devicetree/bindings/display/rockchip/rockchip-dr
On 05/03/2020 17:59, Thomas Zimmermann wrote:
> The tilcdc driver uses empty implementations for its encoders. Replace
> the code with the generic simple encoder.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Jyri Sarha
> ---
> drivers/gpu/drm/tilcdc/tilcdc_external.c | 10 +++---
> driv
On 05/03/2020 17:59, Thomas Zimmermann wrote:
> The tidss driver uses an empty implementation for its encoder. Replace
> the code with the generic simple encoder.
>
> Signed-off-by: Thomas Zimmermann
Acked-by: Jyri Sarha
> ---
> drivers/gpu/drm/tidss/tidss_encoder.c | 10 +++---
> 1 file
On Fri, 6 Mar 2020 15:40:01 +0100
Neil Armstrong wrote:
> Hi Pekka, Brian, Daniel,
>
> On 06/03/2020 11:13, Daniel Vetter wrote:
> > On Tue, Mar 03, 2020 at 05:33:32PM +0200, Pekka Paalanen wrote:
...
> >> Sorry, it's waypipe, not pipewire:
> >> https://gitlab.freedesktop.org/mstoeckl/waypip
On Tue, Jun 19, 2018 at 5:50 PM Daniel Vetter wrote:
>
> The stuff never really worked, and leads to lots of fun because it
> out-of-order frees atomic states. Which upsets KASAN, among other
> things.
>
> For async updates we now have a more solid solution with the
> ->atomic_async_check and ->at
Hi Laurent
Am 06.03.20 um 15:22 schrieb Laurent Pinchart:
> Hi Thomas,
>
> Thank you for the patch.
>
> On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote:
>> A call to drm_simple_encoder_init() initializes an encoder without
>> further functionality. It only provides the destroy
Hi
Am 06.03.20 um 11:56 schrieb Daniel Vetter:
> On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote:
>> A call to drm_simple_encoder_init() initializes an encoder without
>> further functionality. It only provides the destroy callback to
>> cleanup the encoder's state. Only few driv
On Tue, Feb 25, 2020 at 05:58:35PM +0100, Daniel Vetter wrote:
> Only user left is the shadow attach for legacy drivers.
>
> v2: Shift the #ifdef CONFIG_DRM_LEGACY to now also include
> drm_get_pci_dev() (Thomas)
>
> Cc: Thomas Zimmermann
> Cc: Emil Velikov
> Cc: Alex Deucher
> Reviewed-by: Th
Please send a proper patch using git format-patch. Have you actually
tested this patch? Can you provide the details of your specific
board? The reason the clock as forced lower was due to stability
issues with the higher clocks on most HAINAN boards. If it's working
for you, I'd suggest just re
On 2020-03-05 8:42 p.m., Manasi Navare wrote:
Adaptive Sync is a VESA feature so add a DRM core helper to parse
the EDID's detailed descritors to obtain the adaptive sync monitor range.
Store this info as part fo drm_display_info so it can be used
across all drivers.
This part of the code is stri
coder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: arm64-defconfig (attached as .config)
compiler: clang version 11.0.0 (git://gitmirror/llvm_project
a0cd413426479abb207381bdbab862f3dfb3ce7d)
reproduce:
# FIXME the reproduce steps for clang is not ready yet
If y
On Fri, Mar 06, 2020 at 02:13:08PM +, Rob Herring wrote:
> On Thu, Mar 5, 2020 at 8:34 PM Nick Fan wrote:
> >
> > Sorry for my late reply.
> > I have checked internally.
> > The MT8183_POWER_DOMAIN_MFG_2D is just a legacy name, not really 2D
> > domain.
> >
> > If the naming too confusing, we
Hi Pekka, Brian, Daniel,
On 06/03/2020 11:13, Daniel Vetter wrote:
> On Tue, Mar 03, 2020 at 05:33:32PM +0200, Pekka Paalanen wrote:
>> On Tue, 3 Mar 2020 15:25:41 +0200
>> Pekka Paalanen wrote:
>>
>>> On Tue, 3 Mar 2020 12:37:16 +0100
>>> Daniel Vetter wrote:
>>>
On Tue, Mar 3, 2020 at 11:
Hi Randy,
On Thu, Mar 05, 2020 at 07:17:49PM -0800, Randy Dunlap wrote:
> From: Randy Dunlap
>
> DRM_RCAR_CMM depends on DRM_RCAR_DU. Since the following Kconfig
> symbols do not depend on DRM_RCAR_DU, the menu presentation is
> broken for these and following non-R-Car Kconfig symbols.
>
> Is i
Hi Thomas,
Thank you for the patch.
On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote:
> A call to drm_simple_encoder_init() initializes an encoder without
> further functionality. It only provides the destroy callback to
> cleanup the encoder's state. Only few drivers implement m
On Thu, Mar 5, 2020 at 8:34 PM Nick Fan wrote:
>
> Sorry for my late reply.
> I have checked internally.
> The MT8183_POWER_DOMAIN_MFG_2D is just a legacy name, not really 2D
> domain.
>
> If the naming too confusing, we can change this name to
> MT8183_POWER_DOMAIN_MFG_CORE2 for consistency.
Can
On Wed, 19 Feb 2020 13:27:28 +
Emil Velikov wrote:
> From: Emil Velikov
>
...
> +/*
> + * In the olden days the SET/DROP_MASTER ioctls used to return EACCES when
> + * CAP_SYS_ADMIN was not set. This was used to prevent rogue applications
> + * from becoming master and/or failing to relea
coder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: arm64-defconfig (attached as .config)
compiler: clang version 11.0.0 (git://gitmirror/llvm_project
a0cd413426479abb207381bdbab862f3dfb3ce7d)
reproduce:
# FIXME the reproduce steps for clang is not ready yet
If y
On Thu, Mar 05, 2020 at 05:34:27PM +0530, Pankaj Bharadiya wrote:
> This series addresses below drm_fb_helper tasks from
> Documentation/gpu/todo.rst.
>
> - The max connector argument for drm_fb_helper_init() isn't used
> anymore and can be removed.
>
> - The helper doesn't keep an array of con
Hi Vinay,
Thank you for the patch.
On Fri, Mar 06, 2020 at 06:06:36PM +0530, Vinay Simha B N wrote:
> hi andrzej,
>
> I had a doubt In the tc358764 driver,VP_CTRL, VP_CTRL_VSDELAY(15) is
> hardcoded to 15, but this has to be dynamic based on the resolution of
> panel used?
>
> Please see the re
[AMD Public Use]
> -Original Message-
> From: Sean Paul
> Sent: Friday, March 6, 2020 1:19 AM
> To: Lin, Wayne
> Cc: dri-devel@lists.freedesktop.org; ly...@redhat.com; Sean Paul
> ; Maarten Lankhorst
> ; Maxime Ripard ;
> David Airlie
> Subject: Re: [PATCH 3/3] drm/dp_mst: Remove s
On Fri, Mar 6, 2020 at 7:12 AM Daniel Vetter wrote:
>
> I'll stuff it into a pull and throw that your way, that's simplest.
Thanks.
> btw we did add dri-devel to lore a while back, so should be there:
Indeed. I tried (incompetently) to look up your message ID, but I
didn't put the dri-devel par
On Fri, Mar 6, 2020 at 1:55 PM Linus Torvalds
wrote:
>
> On Fri, Mar 6, 2020 at 4:38 AM Daniel Vetter wrote:
> >
> > Linus, since this missed the -fixes pull from Dave maybe double check I'm
> > not grossly wrong here and apply directly?
>
> Hmm. I don't have the original email, mind just sending
The pull request you sent on Fri, 6 Mar 2020 12:35:37 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2020-03-06
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ba0ae9ac46078c53adbb4485adbb3df779228287
Thank you!
--
Deet-doot-dot, I am a bot.
https://ko
On Fri, Mar 6, 2020 at 4:38 AM Daniel Vetter wrote:
>
> Linus, since this missed the -fixes pull from Dave maybe double check I'm
> not grossly wrong here and apply directly?
Hmm. I don't have the original email, mind just sending it to me (with
the proper added sign-off chain)?
It does strike m
From: Laurentiu Palcu
This patch adds the node for iMX8MQ Display Controller Subsystem.
Signed-off-by: Laurentiu Palcu
---
arch/arm64/boot/dts/freescale/imx8mq.dtsi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
b/arch/ar
From: Laurentiu Palcu
Hi,
This patchset adds initial DCSS support for iMX8MQ chip. Initial support
includes only graphics plane support (no video planes), no HDR10 capabilities,
no graphics decompression (only linear, tiled and super-tiled buffers allowed).
Support for the rest of the features
From: Laurentiu Palcu
Currently the drm/imx/ directory is compiled only if DRM_IMX is set. Adding a
new IMX related IP in the same directory would need DRM_IMX to be set, which
would
bring in also IPUv3 core driver...
The current patch would allow adding new IPs in the imx/ directory without
n
From: Laurentiu Palcu
Add bindings for iMX8MQ Display Controller Subsystem.
Signed-off-by: Laurentiu Palcu
---
.../bindings/display/imx/nxp,imx8mq-dcss.yaml | 85 +++
1 file changed, 85 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/imx/nxp,imx8mq-
From: Laurentiu Palcu
This adds initial support for iMX8MQ's Display Controller Subsystem (DCSS).
Some of its capabilities include:
* 4K@60fps;
* HDR10;
* one graphics and 2 video pipelines;
* on-the-fly decompression of compressed video and graphics;
The reference manual can be found here:
The assert sometimes incorrectly triggers when pinned BOs are destroyed.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2445e2bd6267..ca5a8d
coder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: arm64-defconfig (attached as .config)
compiler: clang version 11.0.0 (git://gitmirror/llvm_project
a0cd413426479abb207381bdbab862f3dfb3ce7d)
reproduce:
# FIXME the reproduce steps for clang is not ready yet
If y
On Fri, 6 Mar 2020 11:13:28 +0100
Daniel Vetter wrote:
> On Tue, Mar 03, 2020 at 05:33:32PM +0200, Pekka Paalanen wrote:
> > On Tue, 3 Mar 2020 15:25:41 +0200
> > Pekka Paalanen wrote:
> >
> > > On Tue, 3 Mar 2020 12:37:16 +0100
> > > Daniel Vetter wrote:
> > >
> > > > On Tue, Mar 3, 2020
On Fri, Mar 6, 2020 at 8:07 PM Ondřej Jirman wrote:
>
> On Fri, Mar 06, 2020 at 04:53:46PM +0800, Icenowy Zheng wrote:
> > 在 2020-03-06星期五的 09:46 +0100，Enric Balletbo i Serra写道：
> > > Hi Ondrej,
> > >
> > > On 5/3/20 20:35, Ondřej Jirman wrote:
> > > > Hi,
> > > >
> > > > On Thu, Mar 05, 2020 at 1
to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Nicolas-Boichat/Add-dts-for-mt8183-GPU-and-misc-panfrost-patches/20200
coder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: arm64-defconfig (attached as .config)
compiler: clang version 11.0.0 (git://gitmirror/llvm_project
a0cd413426479abb207381bdbab862f3dfb3ce7d)
reproduce:
# FIXME the reproduce steps for clang is not ready yet
If y
Hi Philipp,
On Fri, Mar 06, 2020 at 11:20:51AM +0100, Philipp Zabel wrote:
> Hi Laurentiu,
>
> On Fri, 2020-03-06 at 11:58 +0200, Laurentiu Palcu wrote:
> > On Wed, Feb 26, 2020 at 02:19:11PM +0100, Lucas Stach wrote:
> [...]
> > > > +/* This function will be called from interrupt context. */
> >
On Fri, Mar 06, 2020 at 11:29:37AM +0100, Benjamin Gaignard wrote:
> Fix kernel doc comments to avoid warnings when compiling with W=1.
>
> Signed-off-by: Benjamin Gaignard
> ---
> version 2:
> - Since it is legacy interface do not fix the description but
> replace /** by /* to remove kerneldoc
Quoting Randy Dunlap (2020-03-06 01:26:10)
> From: Randy Dunlap
>
> Unbreak the DRM menu. This Kconfig symbol does not depend on DRM,
> so the menu is broken at that point.
>
> Move the symbol to a location in the Kconfig file so that it does
> not break the dependency continuity.
I suspect it
Hi,
On 3/6/20 11:41 AM, Daniel Vetter wrote:
On Thu, Mar 05, 2020 at 03:22:38PM +0100, Hans de Goede wrote:
Hi,
On 3/5/20 11:55 AM, Gustavo A. R. Silva wrote:
The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
On Fri, 2020-03-06 at 11:39 +0100, Daniel Vetter wrote:
> On Wed, Mar 04, 2020 at 01:08:32PM +0100, Christian König wrote:
> > Am 04.03.20 um 13:07 schrieb Lukas Bulwahn:
> > > Commit 52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv")
> > > renamed include/linux/reservation.h to includ
On Thu, Mar 05, 2020 at 04:59:28PM +0100, Thomas Zimmermann wrote:
> A call to drm_simple_encoder_init() initializes an encoder without
> further functionality. It only provides the destroy callback to
> cleanup the encoder's state. Only few drivers implement more
> sophisticated encoders than that
On Thu, Mar 05, 2020 at 05:00:11AM -0600, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced i
On Thu, Mar 05, 2020 at 04:57:07AM -0600, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced i
On Thu, Mar 05, 2020 at 03:22:38PM +0100, Hans de Goede wrote:
> Hi,
>
> On 3/5/20 11:55 AM, Gustavo A. R. Silva wrote:
> > The current codebase makes use of the zero-length array language
> > extension to the C90 standard, but the preferred mechanism to declare
> > variable-length types such as t
On Thu, Mar 05, 2020 at 04:53:06AM -0600, Gustavo A. R. Silva wrote:
> The current codebase makes use of the zero-length array language
> extension to the C90 standard, but the preferred mechanism to declare
> variable-length types such as these ones is a flexible array member[1][2],
> introduced i
On Wed, Mar 04, 2020 at 01:08:32PM +0100, Christian König wrote:
> Am 04.03.20 um 13:07 schrieb Lukas Bulwahn:
> > Commit 52791eeec1d9 ("dma-buf: rename reservation_object to dma_resv")
> > renamed include/linux/reservation.h to include/linux/dma-resv.h, but
> > missed the reference in the MAINTAIN
On Wed, Mar 04, 2020 at 10:24:29AM +0800, Zhang Xiaoxu wrote:
> When syzkaller tests, there is a UAF:
> BUG: KASan: use after free in vgacon_invert_region+0x9d/0x110 at addr
> 8810
> Read of size 2 by task syz-executor.1/16489
> page:ea004000 count:0 mapcount:-127 mapp
On Thu, 05 Mar 2020, Manasi Navare wrote:
> This patch adds defines for the detailed monitor
> range flags as per the EDID specification.
>
> Suggested-by: Ville Syrjälä
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Clinton A Taylor
> Cc: Kazlauskas Nicholas
> Signed-off-by: Manasi Navare
>
Hi Andy
On 05.03.2020 10:03, Andy Yan wrote:
>
> I tested it on a rk3399 board, but the eDP was broken after this patch
> applied:
>
>
> [ 0.891873] registered taskstats version 1
> [ 0.892243] Loading compiled-in X.509 certificates
> [ 0.929147] rockchip-dp ff97.edp: no DP phy confi
Hi Laurentiu,
On Fri, 2020-03-06 at 11:58 +0200, Laurentiu Palcu wrote:
> On Wed, Feb 26, 2020 at 02:19:11PM +0100, Lucas Stach wrote:
[...]
> > > +/* This function will be called from interrupt context. */
> > > +void dcss_scaler_write_sclctrl(struct dcss_scaler *scl)
> > > +{
> > > + int chnum;
On Thu, 05 Mar 2020, Rajat Jain wrote:
> OK, will do. In order to do that I may need to introduce driver level
> hooks that i915 driver can populate and drm core can call (or may be
> some functions to add privacy screen property that drm core exports
> and i915 driver will call).
The latter. Loo
On Tue, Mar 03, 2020 at 05:33:32PM +0200, Pekka Paalanen wrote:
> On Tue, 3 Mar 2020 15:25:41 +0200
> Pekka Paalanen wrote:
>
> > On Tue, 3 Mar 2020 12:37:16 +0100
> > Daniel Vetter wrote:
> >
> > > On Tue, Mar 3, 2020 at 11:53 AM Brian Starkey
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > >
coder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: arm64-defconfig (attached as .config)
compiler: clang version 11.0.0 (git://gitmirror/llvm_project
a0cd413426479abb207381bdbab862f3dfb3ce7d)
reproduce:
# FIXME the reproduce steps for clang is not ready yet
If y
Hi Lucas,
Thanks for the in-depth review. I will send a new version shortly, with
most of your sugestions implemented. Had to run some regression tests
on the new version though, hence my late reply... :/
There are several answers to your questions in-line. Didn't reply to all
of them though as y
On Wed, Mar 04, 2020 at 04:42:09PM +, Benjamin GAIGNARD wrote:
>
>
> On 3/4/20 5:07 PM, Emil Velikov wrote:
> > On Mon, 3 Feb 2020 at 08:11, Benjamin Gaignard
> > wrote:
> >> Fix kernel doc comments to avoid warnings when compiling with W=1.
> >>
> >> Signed-off-by: Benjamin Gaignard
> >>
On Thu, 05 Mar 2020, Rajat Jain wrote:
> On Thu, Mar 5, 2020 at 1:41 AM Jani Nikula
> wrote:
>>
>> On Wed, 04 Mar 2020, Rajat Jain wrote:
>> 1) See if we can postpone creating and attaching properties to connector
>> ->late_register hook. (I didn't have the time to look into it yet, at
>> all.)
use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Tian-Tao/drm-hisilicon-Add-the-load-and-unload-for-hibmc_driver/20200306-150600
base:47466dcf84ee66a973ea7d2fca7e58
coder_init/20200306-045931
base:47466dcf84ee66a973ea7d2fca7e582fe9328932
config: arm64-defconfig (attached as .config)
compiler: clang version 11.0.0 (git://gitmirror/llvm_project
a0cd413426479abb207381bdbab862f3dfb3ce7d)
reproduce:
# FIXME the reproduce steps for clang is not ready yet
If y
Empty Message
mutt-yassine-HP-1000-4480-19426451861488017513
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Jani,
Thank you for the comments. Please see my responses inline.
On Thu, Mar 5, 2020 at 2:02 AM Jani Nikula wrote:
>
> On Wed, 04 Mar 2020, Rajat Jain wrote:
> > Certain laptops now come with panels that have integrated privacy
> > screens on them. This patch adds support for such panels by
1 - 100 of 140 matches
Mail list logo
