On Wed, 1 Jul 2020 at 09:10, Sam Ravnborg wrote:
>
> Hi Guenter.
>
> On Tue, Jun 30, 2020 at 05:10:02PM -0700, Guenter Roeck wrote:
> > The following backtrace is seen when running aspeed G5 kernels.
> >
> > WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_fb_helper.c:2233
> > drm_fbdev_generic_setu
> Subject: [PATCH 05/20] Documentation: fpga: eliminate duplicated word
>
> Drop the doubled word "this".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Wu Hao
> Cc: linux-f...@vger.kernel.org
Acked-by: Wu Hao
Thanks Randy.
Hao
_
On Wed, Jul 08, 2020 at 06:37:51PM -0500, Adam Ford wrote:
> On Mon, Jul 6, 2020 at 6:18 AM Adam Ford wrote:
> >
> > On Mon, Jul 6, 2020 at 1:02 AM Tomi Valkeinen wrote:
> > >
> > > Hi,
> > >
> > > On 03/07/2020 22:36, Sam Ravnborg wrote:
> > > > Hi Tomi.
> > > >
> > > > On Fri, Jul 03, 2020 at 1
On 2020-06-23 at 11:58:59 -0400, Sean Paul wrote:
> From: Sean Paul
>
> This patch is required for HDCP over MST. If a port is being used for
> multiple HDCP streams, we don't want to fully disable HDCP on a port if
> one of them is disabled. Instead, we just disable the HDCP signalling on
> that
On 2020-06-23 at 11:58:58 -0400, Sean Paul wrote:
> From: Sean Paul
>
> Add an out label and un-indent hdcp disable in preparation for
> hdcp_mutex. No functional changes
>
> Signed-off-by: Sean Paul
Reviewed-by: Ramalingam C
> Link:
> https://patchwork.freedesktop.org/patch/msgid/2020042919
Hi, Dennis,
Thanks for this patch.
It's better to send another tree for this patch.
Because this tree is only for soc/mediatek.
Please do not forget to add the dependency information.
Bibby
On Tue, 2020-07-07 at 23:45 +0800, Dennis YC Hsieh wrote:
> No need to clear event again since event alw
On Mon, Jul 6, 2020 at 6:18 AM Adam Ford wrote:
>
> On Mon, Jul 6, 2020 at 1:02 AM Tomi Valkeinen wrote:
> >
> > Hi,
> >
> > On 03/07/2020 22:36, Sam Ravnborg wrote:
> > > Hi Tomi.
> > >
> > > On Fri, Jul 03, 2020 at 10:17:29AM +0300, Tomi Valkeinen wrote:
> > >> On 30/06/2020 21:26, Adam Ford wr
From: Lee Shawn C
So far, max dot clock rate for MST mode rely on physcial
bandwidth limitation. It would caused compatibility issue
if source display resolution exceed MST hub output ability.
For example, source DUT had DP 1.2 output capability.
And MST docking just support HDMI 1.4 spec. When
This is just an atomic version of mode_valid, which is intended to be
used for situations where a driver might need to check the atomic state
of objects other than the connector itself. One such example is with
MST, where the maximum possible bandwidth on a connector can change
dynamically irregard
Something we've been missing for a while with drivers that support MST
is being able to prune modes that can't be set due to bandwidth
limitations. So, let's go ahead and add that. This also adds a new hook
that was needed, mode_valid_ctx, so that we can grab additional locks as
needed when validat
Hi Hans,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.8-rc4]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede wrote:
>
> Fix the following kerneldoc warning:
>
> drivers/gpu/drm/drm_connector.c:2189:
> warning: missing initial short description on line
>
> Signed-off-by: Hans de Goede
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_connector.c | 4 ++--
On Wed, Jul 8, 2020 at 12:43 PM Hans de Goede wrote:
>
> Hi All,
>
> Here is the privacy-screen related code which we discussed a while ago.
> This series consists of a number of different parts:
>
> 1. A new version of Rajat's privacy-screen connector properties patch,
> this adds new userspace A
Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency
out of get_backlight_max_vbt().
This is a preparation patch for honering the VBT PWM frequency for
devices which use an external PWM controller (devices using
pwm_setup_backlight()).
Acked-by: Jani Nikula
Signed-off-by: Hans de
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.
Signed-off-by: Hans de Goede
---
Changes in v3:
- Keep crc_pwm_calc_clk_div() helper to avoid needless churn
---
drivers/pwm/pwm-crc.c | 89 ++-
1 file chan
The datasheet specifies that programming the base_unit part of the
ctrl register to 0 results in a contineous low signal.
Adjust the get_state method to reflect this by setting pwm_state.period
to 1 and duty_cycle to 0.
Suggested-by: Uwe Kleine-König
Signed-off-by: Hans de Goede
---
Changes in
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the period-time passed to
pwm_config() to 21333 ns.
I suspect this was done because many VBTs set the PWM frequency to 200
which corresponds to a period-time of 500 ns, which grea
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the fastse
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
this commit makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set i
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Reviewed-by: Andy Shevchenko
Signed-off-by: Hans de Goede
---
Changes in v4:
- Use DIV_ROUND_UP when calculating the period and duty_cycle from the
controller's register values
Changes in v3:
- Add An
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the minimum allowed
PWM level to 0. But several of these devices specify a non 0 minimum
setting in their VBT.
Change pwm_setup_backlight() to use get_backlight_min_vbt() to get
the m
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets poked from the _PS0 method of the graphics-card device:
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
If (((Local0 & 0x03) == 0x03))
{
PSAT &= 0xFFFC
Local1 = PSA
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter ove
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with a value between 1-128,
and there are 256 duty-cycle steps.
The pwm-crc code before this commit assumed that a clo
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.
So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested f
Hi All,
Here is v4 of my patch series converting the i915 driver's code for
controlling the panel's backlight with an external PWM controller to
use the atomic PWM API. See below for the changelog.
Initially the plan was for this series to consist of 2 parts:
1. convert the pwm-crc driver to supp
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
I strongly suspect that the BACKLIGHT_EN register at address 0x51 really
controls a separate output-only GPIO which is connected to the LCD panels
backlight-ena
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.
So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input cl
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets turned off from the _PS3 method of the graphics-card dev:
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
...
PWMB = PWMC /* \_SB_.PCI
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main consume
Hi Hans,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc4]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
Hi,
Le 08/07/2020 à 19:08, Angelo Ribeiro a écrit :
> Hi,
>
> Is this patch good to go?
> @dan...@ffwll.ch, @Philippe CORNU
>
> Was already tested by @Yannick FERTRE
> and @Adrian Pop
> on https://lkml.org/lkml/2020/4/6/691 .
It would be great to have a review or an ack before applying.
Neil
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #51 from rtmasura+ker...@hotmail.com ---
that didn't read well, with vblank_mode off for XFWM I don't have this issue at
all.
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
Hi Hans,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc4]
[cannot apply to drm-intel/for-linux-next drm-tip/drm-tip next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #50 from rtmasura+ker...@hotmail.com ---
I have 3 monitors, 2 1080p and one 1440p. Happens when I use vblank_mode glx or
xpresent, off and I'm stable.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On Wed, Jul 08, 2020 at 10:46:32AM -0700, José Roberto de Souza wrote:
> Two new patches landed in kernel adding new PCI ids:
> 123f62de419f ("drm/i915/rkl: Add RKL platform info and PCI ids")
> 52797a8e8529 ("drm/i915/ehl: Add new PCI ids")
>
> Cc: Matt Roper
> Signed-off-by: José Roberto de Sou
On Tue, Jul 07, 2020 at 12:36:42PM +0100, Robin Murphy wrote:
> On 2020-06-26 21:04, Jordan Crouse wrote:
> >Add support to create a io-pgtable for use by targets that support
> >per-instance pagetables. In order to support per-instance pagetables the
> >GPU SMMU device needs to have the qcom,adre
Hi Dave and Daniel,
A few patches this week while I'm covering Joonas vacation.
Most of the patches below also target stable trees (5.5+)
Here goes drm-intel-fixes-2020-07-08:
One display's fbc patch fixing fence_y_offset calculation
from Ville and 4 patches from Chris on GEM: 1 fixing a debugfs
On Wed, 2020-07-08 at 21:45 +0300, Imre Deak wrote:
> On Wed, Jul 08, 2020 at 01:25:14PM -0400, Lyude Paul wrote:
> > JFYI - found an issue with this patch that wouldn't have shown up on i915,
> > info
> > down below:
> >
> > On Wed, 2020-07-08 at 01:40 +0300, Imre Deak wrote:
> > > Sorry for the
On Wed, Jul 08, 2020 at 01:25:14PM -0400, Lyude Paul wrote:
>
> JFYI - found an issue with this patch that wouldn't have shown up on i915,
> info
> down below:
>
> On Wed, 2020-07-08 at 01:40 +0300, Imre Deak wrote:
> > Sorry for the delay, the review as I promised:
> >
> > On Tue, May 26, 202
On Wed, Jul 08, 2020 at 01:22:35PM +1000, Ben Skeggs wrote:
> On Wed, 8 Jul 2020 at 03:31, Gustavo A. R. Silva
> wrote:
> >
> > Replace the existing /* fall through */ comments and its variants with
> > the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary
> > fall-through marking
Hi GVRao,
Thank you for pinging me privately.
On Mon, Jun 22, 2020 at 02:19:22PM +, Venkateshwar Rao Gannavarapu wrote:
> On Wednesday, June 17, 2020 3:18 AM, Laurent Pinchart wrote:
> > On Tue, Jun 09, 2020 at 02:48:25AM +, Venkateshwar Rao Gannavarapu
> > wrote:
> >> Hi Laurent,
> >>
>
Two new patches landed in kernel adding new PCI ids:
123f62de419f ("drm/i915/rkl: Add RKL platform info and PCI ids")
52797a8e8529 ("drm/i915/ehl: Add new PCI ids")
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
---
intel/i915_pciids.h | 13 +
1 file changed, 13 insertions(+)
JFYI - found an issue with this patch that wouldn't have shown up on i915, info
down below:
On Wed, 2020-07-08 at 01:40 +0300, Imre Deak wrote:
> Sorry for the delay, the review as I promised:
>
> On Tue, May 26, 2020 at 02:23:09PM -0400, Lyude Paul wrote:
> > This is just an atomic version of
On Wed, Jul 08, 2020 at 09:49:09AM +0200, Thomas Zimmermann wrote:
> As a first step to managed MM code in ast, switch over VRAM MM helpers.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/drm/ast/ast_mm.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/
Hi Thomas.
On Wed, Jul 08, 2020 at 09:49:07AM +0200, Thomas Zimmermann wrote:
> Calling drmm_vram_helper_alloc_mm() sets up a managed instance of
> VRAM MM. Releasing the DRM device also frees the memory manager.
>
> The patch also updates the DRM documentation for VRAM helpers. The
> tutorial no
https://bugzilla.kernel.org/show_bug.cgi?id=208333
--- Comment #4 from Roberto Guerrini (robyguerr...@yahoo.it) ---
Il giorno lun, 06/07/2020 alle 05.10 +, bugzilla-
dae...@bugzilla.kernel.org ha scritto:
> https://bugzilla.kernel.org/show_bug.cgi?id=208333
>
> Ilia Mirkin (imir...@alum.mit.e
Get the privacy-screen / lcdshadow ACPI handles once and cache them,
instead of retrieving them every time we need them.
Signed-off-by: Hans de Goede
---
drivers/platform/x86/thinkpad_acpi.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/platform/
Add support for eDP panels with a built-in privacy screen using the
new drm_privacy_screen class.
One thing which stands out here is the addition of these 2 lines to
intel_atomic_commit_tail:
for_each_new_connector_in_state(&state->base, connector, ...
drm_connector_update
Fix the following kerneldoc warning:
drivers/gpu/drm/drm_connector.c:2189:
warning: missing initial short description on line
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_connector.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c
Add support for privacy-screen consumers to register a notifier to
be notified of external (e.g. done by the hw itself on a hotkey press)
state changes.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_privacy_screen.c | 67 +++
include/drm/drm_privacy_screen_consume
On some new laptops the LCD panel has a builtin electronic privacy-screen.
We want to export this functionality as a property on the drm connector
object. But often this functionality is not exposed on the GPU but on some
other (ACPI) device.
This commit adds a privacy-screen class allowing the dr
Register a privacy-screen device on laptops with a privacy-screen,
this exports the PrivacyGuard features to user-space using a
standardized vendor-agnostic sysfs interface. Note the sysfs interface
is read-only.
Registering a privacy-screen device with the new privacy-screen class
code will also
From: Rajat Jain
Add support for generic electronic privacy screen properties, that
can be added by systems that have an integrated EPS.
Changes in v2 (Hans de Goede)
- Create 2 properties, "privacy-screen sw-state" and
"privacy-screen hw-state", to deal with devices where the OS might be
lo
Hi All,
Here is the privacy-screen related code which we discussed a while ago.
This series consists of a number of different parts:
1. A new version of Rajat's privacy-screen connector properties patch,
this adds new userspace API in the form of new properties
2. Since on most devices the priva
Add 2 drm_connector privacy-screen helper functions:
1. drm_connector_attach_privacy_screen_provider(), this function creates
and attaches the standard privacy-screen properties and registers a
generic notifier for generating sysfs-connector-status-events on external
changes to the privacy-screen
Add X86 specific arch init code, which fills the privacy-screen lookup
table by checking for various vendor specific ACPI interfaces for
controlling the privacy-screen.
This initial version only checks for the Lenovo Thinkpad specific ACPI
methods for privacy-screen control.
Signed-off-by: Hans d
On Wed, Jul 8, 2020 at 6:11 PM Daniel Vetter wrote:
>
> On Wed, Jul 8, 2020 at 5:05 PM Christian König
> wrote:
> >
> > Am 08.07.20 um 17:01 schrieb Daniel Vetter:
> > > On Wed, Jul 8, 2020 at 4:37 PM Christian König
> > > wrote:
> > >> Am 08.07.20 um 11:54 schrieb Daniel Vetter:
> > >>> On We
On Wed, Jul 8, 2020 at 5:05 PM Christian König wrote:
>
> Am 08.07.20 um 17:01 schrieb Daniel Vetter:
> > On Wed, Jul 8, 2020 at 4:37 PM Christian König
> > wrote:
> >> Am 08.07.20 um 11:54 schrieb Daniel Vetter:
> >>> On Wed, Jul 08, 2020 at 11:22:00AM +0200, Christian König wrote:
> Am 07
drm_gem_dumb_map_offset() now exists and does everything
vgem_gem_dump_map does and *ought* to do.
In particular, vgem_gem_dumb_map() was trying to reject mmapping an
imported dmabuf by checking the existence of obj->filp. Unfortunately,
we always allocated an obj->filp, even if unused for an impo
From: Navid Emamdoost
[ Upstream commit d4f5a095daf0d25f0b385e1ef26338608433a4c5 ]
in mic_pre_enable, pm_runtime_get_sync is called which
increments the counter even in case of failure, leading to incorrect
ref count. In case of failure, decrement the ref count before returning.
Signed-off-by:
From: Navid Emamdoost
[ Upstream commit d4f5a095daf0d25f0b385e1ef26338608433a4c5 ]
in mic_pre_enable, pm_runtime_get_sync is called which
increments the counter even in case of failure, leading to incorrect
ref count. In case of failure, decrement the ref count before returning.
Signed-off-by:
From: Bernard Zhao
[ Upstream commit 177d3819633cd520e3f95df541a04644aab4c657 ]
In function msm_submitqueue_create, the queue is a local
variable, in return -EINVAL branch, queue didn`t add to ctx`s
list yet, and also didn`t kfree, this maybe bring in potential
memleak.
Signed-off-by: Bernard Z
From: Krishna Manikandan
[ Upstream commit 2e7ec6b5297157efabb50e5f82adc628cf90296c ]
In the current implementation, mutex initialization
for encoder mutex locks are done during encoder
setup. This can lead to scenarios where the lock
is used before it is initialized. Move mutex_init
to dpu_enco
From: Navid Emamdoost
[ Upstream commit d4f5a095daf0d25f0b385e1ef26338608433a4c5 ]
in mic_pre_enable, pm_runtime_get_sync is called which
increments the counter even in case of failure, leading to incorrect
ref count. In case of failure, decrement the ref count before returning.
Signed-off-by:
From: Krishna Manikandan
[ Upstream commit 2e7ec6b5297157efabb50e5f82adc628cf90296c ]
In the current implementation, mutex initialization
for encoder mutex locks are done during encoder
setup. This can lead to scenarios where the lock
is used before it is initialized. Move mutex_init
to dpu_enco
From: Marek Szyprowski
[ Upstream commit b9c633882de4601015625f9136f248e9abca8a7a ]
Propagate the proper error codes from the called functions instead of
unconditionally returning 0.
Reported-by: kbuild test robot
Signed-off-by: Marek Szyprowski
Merge conflict so merged it manually.
Signed-of
From: Navid Emamdoost
[ Upstream commit d4f5a095daf0d25f0b385e1ef26338608433a4c5 ]
in mic_pre_enable, pm_runtime_get_sync is called which
increments the counter even in case of failure, leading to incorrect
ref count. In case of failure, decrement the ref count before returning.
Signed-off-by:
From: Bernard Zhao
[ Upstream commit 177d3819633cd520e3f95df541a04644aab4c657 ]
In function msm_submitqueue_create, the queue is a local
variable, in return -EINVAL branch, queue didn`t add to ctx`s
list yet, and also didn`t kfree, this maybe bring in potential
memleak.
Signed-off-by: Bernard Z
From: Marek Szyprowski
[ Upstream commit b9c633882de4601015625f9136f248e9abca8a7a ]
Propagate the proper error codes from the called functions instead of
unconditionally returning 0.
Reported-by: kbuild test robot
Signed-off-by: Marek Szyprowski
Merge conflict so merged it manually.
Signed-of
From: Bernard Zhao
[ Upstream commit 177d3819633cd520e3f95df541a04644aab4c657 ]
In function msm_submitqueue_create, the queue is a local
variable, in return -EINVAL branch, queue didn`t add to ctx`s
list yet, and also didn`t kfree, this maybe bring in potential
memleak.
Signed-off-by: Bernard Z
On Wed, Jul 8, 2020 at 5:19 PM Alex Deucher wrote:
>
> On Wed, Jul 8, 2020 at 11:13 AM Daniel Vetter wrote:
> >
> > On Wed, Jul 8, 2020 at 4:57 PM Christian König
> > wrote:
> > >
> > > Could we merge this controlled by a separate config option?
> > >
> > > This way we could have the checks ups
On Wed, Jul 8, 2020 at 11:13 AM Daniel Vetter wrote:
>
> On Wed, Jul 8, 2020 at 4:57 PM Christian König
> wrote:
> >
> > Could we merge this controlled by a separate config option?
> >
> > This way we could have the checks upstream without having to fix all the
> > stuff before we do this?
>
> S
On Wed, Jul 8, 2020 at 4:57 PM Christian König wrote:
>
> Could we merge this controlled by a separate config option?
>
> This way we could have the checks upstream without having to fix all the
> stuff before we do this?
Since it's fully opt-in annotations nothing blows up if we don't merge
any
Am 08.07.20 um 17:01 schrieb Daniel Vetter:
On Wed, Jul 8, 2020 at 4:37 PM Christian König wrote:
Am 08.07.20 um 11:54 schrieb Daniel Vetter:
On Wed, Jul 08, 2020 at 11:22:00AM +0200, Christian König wrote:
Am 07.07.20 um 20:35 schrieb Chris Wilson:
Quoting lepton (2020-07-07 19:17:51)
On T
drm_gem_dumb_map_offset() now exists and does everything
vgem_gem_dump_map does and *ought* to do.
In particular, vgem_gem_dumb_map() was trying to reject mmapping an
imported dmabuf by checking the existence of obj->filp. Unfortunately,
we always allocated an obj->filp, even if unused for an impo
On Wed, Jul 8, 2020 at 4:37 PM Christian König wrote:
>
> Am 08.07.20 um 11:54 schrieb Daniel Vetter:
> > On Wed, Jul 08, 2020 at 11:22:00AM +0200, Christian König wrote:
> >> Am 07.07.20 um 20:35 schrieb Chris Wilson:
> >>> Quoting lepton (2020-07-07 19:17:51)
> On Tue, Jul 7, 2020 at 10:20
Could we merge this controlled by a separate config option?
This way we could have the checks upstream without having to fix all the
stuff before we do this?
Thanks,
Christian.
Am 07.07.20 um 22:12 schrieb Daniel Vetter:
Design is similar to the lockdep annotations for workers, but with
some
Quoting Daniel Vetter (2020-07-08 10:56:19)
> On Tue, Jul 07, 2020 at 05:00:12PM +0100, Chris Wilson wrote:
> > drm_gem_dumb_map_offset() now exists and does everything
> > vgem_gem_dump_map does and *ought* to do.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/vgem/vgem_drv.c |
Hi
Am 08.07.20 um 16:26 schrieb Daniel Vetter:
> On Wed, Jul 8, 2020 at 4:22 PM Thomas Zimmermann wrote:
>>
>> Hi
>>
>> Am 08.07.20 um 15:46 schrieb Ilpo Järvinen:
>>> On Wed, 8 Jul 2020, Thomas Zimmermann wrote:
>>>
Hi
Am 08.07.20 um 12:05 schrieb Ilpo Järvinen:
> Hi,
>
>>
Am 08.07.20 um 11:54 schrieb Daniel Vetter:
On Wed, Jul 08, 2020 at 11:22:00AM +0200, Christian König wrote:
Am 07.07.20 um 20:35 schrieb Chris Wilson:
Quoting lepton (2020-07-07 19:17:51)
On Tue, Jul 7, 2020 at 10:20 AM Chris Wilson wrote:
Quoting lepton (2020-07-07 18:05:21)
On Tue, Jul 7
On Wed, Jul 8, 2020 at 10:20 AM Christian König
wrote:
>
> Am 08.07.20 um 11:49 schrieb Daniel Vetter:
> > On Wed, Jul 08, 2020 at 11:38:31AM +0200, Christian König wrote:
> >> Am 07.07.20 um 23:58 schrieb Xiong, Jianxin:
> -Original Message-
> From: Christian König
> Am 03
Looks good to me.
Reviewed-by: Nicholas Kazlauskas
Regards,
Nicholas Kazlauskas
On 2020-07-08 10:15 a.m., Deucher, Alexander wrote:
[AMD Public Use]
[AMD Public Use]
Acked-by: Alex Deucher
*From:* Aaron Ma
*Sent:*
On Wed, Jul 8, 2020 at 4:22 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 08.07.20 um 15:46 schrieb Ilpo Järvinen:
> > On Wed, 8 Jul 2020, Thomas Zimmermann wrote:
> >
> >> Hi
> >>
> >> Am 08.07.20 um 12:05 schrieb Ilpo Järvinen:
> >>> Hi,
> >>>
> >>> After upgrading kernel from 5.3 series to 5.6.16 s
Hi
Am 08.07.20 um 16:22 schrieb Thomas Zimmermann:
> Hi
>
> Am 08.07.20 um 15:46 schrieb Ilpo Järvinen:
>> On Wed, 8 Jul 2020, Thomas Zimmermann wrote:
>>
>>> Hi
>>>
>>> Am 08.07.20 um 12:05 schrieb Ilpo Järvinen:
Hi,
After upgrading kernel from 5.3 series to 5.6.16 something seems
Hi
Am 08.07.20 um 15:46 schrieb Ilpo Järvinen:
> On Wed, 8 Jul 2020, Thomas Zimmermann wrote:
>
>> Hi
>>
>> Am 08.07.20 um 12:05 schrieb Ilpo Järvinen:
>>> Hi,
>>>
>>> After upgrading kernel from 5.3 series to 5.6.16 something seems to
>>> prevent me from achieving high resolutions with the ast
On 08/07/2020 12:44, Daniel Vetter wrote:
> Gives us proper nonblocking support for free, and a pile of other
> things. The tilcdc code is simply old enough that it was never
> converted over, but was stuck forever with the copypasta from when it
> was initially merged.
>
> The riskiest thing with
Gives us proper nonblocking support for free, and a pile of other
things. The tilcdc code is simply old enough that it was never
converted over, but was stuck forever with the copypasta from when it
was initially merged.
The riskiest thing with this conversion is maybe that there's an issue
with t
Am 08.07.20 um 11:49 schrieb Daniel Vetter:
On Wed, Jul 08, 2020 at 11:38:31AM +0200, Christian König wrote:
Am 07.07.20 um 23:58 schrieb Xiong, Jianxin:
-Original Message-
From: Christian König
Am 03.07.20 um 15:14 schrieb Jason Gunthorpe:
On Fri, Jul 03, 2020 at 02:52:03PM +0200, Da
[AMD Public Use]
Acked-by: Alex Deucher
From: Aaron Ma
Sent: Wednesday, July 8, 2020 4:16 AM
To: Wentland, Harry ; Li, Sun peng (Leo)
; Deucher, Alexander ; Koenig,
Christian ; airl...@linux.ie ;
dan...@ffwll.ch ; amd-...@lists.freedesktop.org
; dri-devel@lis
From: Antonio Borneo
Current code only sends LP commands in command mode.
Allows sending LP commands also in video mode by setting the
proper flag in DSI_VID_MODE_CFG.
Signed-off-by: Antonio Borneo
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 8
1 file changed, 8 insertions(+)
Den 08.07.2020 14.49, skrev Paul Cercueil:
> Hi Daniel,
>
> Le mer. 8 juil. 2020 à 9:23, Daniel Vetter a écrit :
>> On Tue, Jul 07, 2020 at 04:32:25PM +0200, Noralf Trønnes wrote:
>>> (cc Dillon)
>>>
>>> Den 03.07.2020 19.26, skrev Sam Ravnborg:
>>> > Hi Noralf/Paul.
>>> >
>>> > Trying to
On Tue, Jul 07, 2020 at 11:04:12AM -0700, Randy Dunlap wrote:
> Drop the doubled word "in".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: James Bottomley
> Cc: Jarkko Sakkinen
> Cc: Mimi Zohar
> Cc: linux-integr...@vger.kernel.org
> Cc: keyri...@v
On 07/07/2020 23:12, Daniel Vetter wrote:
> Gives us proper nonblocking support for free, and a pile of other
> things. The tilcdc code is simply old enough that it was never
> converted over, but was stuck forever with the copypasta from when it
> was initially merged.
>
> The riskiest thing with
On Tue, Jul 07, 2020 at 11:03:58AM -0700, Randy Dunlap wrote:
> Drop the doubled word "driver".
>
> Signed-off-by: Randy Dunlap
> Cc: Jonathan Corbet
> Cc: linux-...@vger.kernel.org
> Cc: Jason Wessel
> Cc: Daniel Thompson
> Cc: Douglas Anderson
> Cc: kgdb-bugrep...@lists.sourceforge.net
Ack
On 07/07/2020 23:12, Daniel Vetter wrote:
> Ends right after hw_done(), totally standard case.
>
> Signed-off-by: Daniel Vetter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
Acked-by: Jyri Sarha
> ---
> drivers/gpu/drm/tidss/tidss_kms.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/
On Wed, 8 Jul 2020 at 14:06, Daniel Thompson
wrote:
> On Wed, Jul 08, 2020 at 02:04:19PM +0100, Lee Jones wrote:
> > Firstly, all lines must begin with a '*'. Secondly, arg descriptions
> > must be spelt correctly, so fix misspelling of 'gpioD_enable' and
> > 'short_detecTion_threshold'
> >
> >
On Wed, Jul 08, 2020 at 02:04:19PM +0100, Lee Jones wrote:
> Firstly, all lines must begin with a '*'. Secondly, arg descriptions
> must be spelt correctly, so fix misspelling of 'gpioD_enable' and
> 'short_detecTion_threshold'
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/vi
Firstly, all lines must begin with a '*'. Secondly, arg descriptions
must be spelt correctly, so fix misspelling of 'gpioD_enable' and
'short_detecTion_threshold'
Fixes the following W=1 kernel build warning(s):
drivers/video/backlight/sky81452-backlight.c:46: warning: bad line:
Hi Dave and Daniel,
here's the PR for the current drm-misc-fixes. Only two patches this week.
drm-misc-fixes-2020-07-08:
* meson: OSD burst-length fixes
* hibmc: fix runtime warning by setting up generic fbdev after
registering device
The following changes since commit bda8eaa6dee7525f4dac95
1 - 100 of 198 matches
Mail list logo
