[AMD Official Use Only]
Hi Jani:
> -Original Message-
> From: Jani Nikula
> Sent: Wednesday, November 3, 2021 7:31 PM
> To: Yuan, Perry ; Maarten Lankhorst
> ; Maxime Ripard
> ; Thomas Zimmermann ;
> David Airlie ; Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org; linux-ker...@vger.
Hi Dave, Daniel,
Here's this week drm-misc-next-fixes PR
Thanks!
Maxime
drm-misc-next-fixes-2021-11-05:
A refcounting fix for outstanding fence callbacks.
The following changes since commit b3ec8cdf457e5e63d396fe1346cc788cf7c1b578:
fbdev: Garbage collect fbdev scrolling acceleration, part 1 (
From: Jing Yao
coccicheck complains about the use of snprintf() in sysfs show
functions:
WARNING use scnprintf or sprintf
Use sysfs_emit instead of scnprintf, snprintf or sprintf makes more
sense.
Reported-by: Zeal Robot
Signed-off-by: Jing Yao
---
drivers/video/fbdev/omap2/omapfb/displays/p
From: Jing Yao
coccicheck complains about the use of snprintf() in sysfs show
functions:
WARNING use scnprintf or sprintf
Use sysfs_emit instead of scnprintf, snprintf or sprintf makes more
sense.
Reported-by: Zeal Robot
Signed-off-by: Jing Yao
---
.../video/fbdev/omap2/omapfb/displays/panel
Hi
Am 04.11.21 um 21:09 schrieb Javier Martinez Canillas:
Hello Jani,
On 11/4/21 20:57, Jani Nikula wrote:
On Thu, 04 Nov 2021, Javier Martinez Canillas wrote:
+/**
+ * drm_drv_enabled - Checks if a DRM driver can be enabled
+ * @driver: DRM driver to check
+ *
+ * Checks whether a DRM drive
On Fri, Oct 08, 2021 at 10:23:34PM +0200, Thierry Reding wrote:
> Hi Dave, Daniel,
>
> The following changes since commit c3dbfb9c49eef7d07904e5fd5e158dd6688bbab3:
>
> gpu: host1x: Plug potential memory leak (2021-09-16 18:06:52 +0200)
>
> are available in the Git repository at:
>
> ssh://g
Hi
Am 04.11.21 um 17:07 schrieb Javier Martinez Canillas:
The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
but the exported vgacon_text_force() symbol is only used by DRM drivers.
It makes much more sense for the parameter logic to be in the subsystem
of the drivers that
The drm_gem_handle_delete is called by DRM_IOCTL_GEM_CLOSE from
userspace.
drm_gem_handle_delete(handle)
drm_gem_object_release_handle(handle)
drm_gem_remove_prime_handles()
drm_prime_remove_buf_handle_locked()
if (member->dma_buf == dma_buf)
free member
On Fri, 05 Nov 2021, Thomas Zimmermann wrote:
> Hi
>
> Am 04.11.21 um 17:07 schrieb Javier Martinez Canillas:
>> The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
>> but the exported vgacon_text_force() symbol is only used by DRM drivers.
>>
>> It makes much more sense for
Turn drm_gem_shmem_create_with_handle() into an internal helper
function. It's not used outside of the compilation unit.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 3 +--
include/drm/drm_gem_shmem_helper.h | 5 -
2 files changed, 1 insertion(+), 7 delet
The interface of GEM SHMEM helpers inconsistently uses either struct
drm_gem_object or drm_gem_shmem_object for the GEM object. Convert GEM
SHMEM functions to accept struct drm_gem_shmem_object, provide small
wrappers for GEM object callbacks and update all users.
Converting all GEM object functio
Wrap GEM SHMEM functions for struct drm_gem_object_funcs and update
all callers. This will allow for an update of the public interfaces
of the GEM SHMEM helper library.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 45 -
drivers/gpu/drm/lima/lima_gem.c
Change all GEM SHMEM object functions that receive a GEM object
of type struct drm_gem_object to expect an object of type
struct drm_gem_shmem_object instead.
This change reduces the number of upcasts from struct drm_gem_object
by moving them into callers. The C compiler can now verify that the
GE
Hi
Am 05.11.21 um 10:22 schrieb Jani Nikula:
On Fri, 05 Nov 2021, Thomas Zimmermann wrote:
Hi
Am 04.11.21 um 17:07 schrieb Javier Martinez Canillas:
The "nomodeset" kernel cmdline parameter is handled by the vgacon driver
but the exported vgacon_text_force() symbol is only used by DRM driver
Hello Thomas,
On 11/5/21 09:43, Thomas Zimmermann wrote:
> Hi
>
> Am 04.11.21 um 21:09 schrieb Javier Martinez Canillas:
>> Hello Jani,
>>
>> On 11/4/21 20:57, Jani Nikula wrote:
>>> On Thu, 04 Nov 2021, Javier Martinez Canillas wrote:
+/**
+ * drm_drv_enabled - Checks if a DRM driver
On 11/5/21 10:00, Thomas Zimmermann wrote:
[snip]
>> +
>> +static int __init disable_modeset(char *str)
>> +{
>> +drm_nomodeset = true;
>> +
>> +pr_warn("You have booted with nomodeset. This means your GPU drivers
>> are DISABLED\n");
>> +pr_warn("Any video related functionality will
On 11/5/21 10:39, Thomas Zimmermann wrote:
[snip]
+obj-$(CONFIG_VGA_CONSOLE) += drm_nomodeset.o
+
>>>
>>> This now depends on the VGA textmode console. Even if you have no VGA
>>> console, you'd want drm_nomodeset.o. Simpledrm might be built-in and can
>>> provide graphics. Non
On Fri, 05 Nov 2021, Javier Martinez Canillas wrote:
> Hello Thomas,
>
> On 11/5/21 09:43, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 04.11.21 um 21:09 schrieb Javier Martinez Canillas:
>>> Hello Jani,
>>>
>>> On 11/4/21 20:57, Jani Nikula wrote:
On Thu, 04 Nov 2021, Javier Martinez Canillas w
On Thu, Nov 04, 2021 at 05:15:43PM -0400, Ilia Mirkin wrote:
> On Thu, Nov 4, 2021 at 4:03 PM Mark Yacoub wrote:
> >
> > From: Mark Yacoub
> >
> > [Why]
> > 1. drm_atomic_helper_check doesn't check for the LUT sizes of either Gamma
> > or Degamma props in the new CRTC state, allowing any invalid
On Thu, Oct 28, 2021 at 04:42:56PM -0300, Jason Gunthorpe wrote:
> On Thu, Oct 28, 2021 at 05:14:52PM +0200, Daniel Vetter wrote:
> > Hm totally lost this, I'm trying to not be too responsible for mm changes
> > since it scares me :-) Plus dropping this very late in the release feels a
> > bit risk
On Mon, Oct 25, 2021 at 01:53:53PM +0200, Johan Hovold wrote:
> USB control-message timeouts are specified in milliseconds and should
> specifically not vary with CONFIG_HZ.
>
> Fixes: 5320918b9a87 ("drm/udl: initial UDL driver (v4)")
> Cc: sta...@vger.kernel.org # 3.4
> Signed-off-by: Johan
Hi
Am 05.11.21 um 10:48 schrieb Javier Martinez Canillas:
Hello Thomas,
On 11/5/21 09:43, Thomas Zimmermann wrote:
Hi
Am 04.11.21 um 21:09 schrieb Javier Martinez Canillas:
Hello Jani,
On 11/4/21 20:57, Jani Nikula wrote:
On Thu, 04 Nov 2021, Javier Martinez Canillas wrote:
+/**
+ * drm_
On Thu, Oct 28, 2021 at 01:36:58PM -0400, Alex Deucher wrote:
> On Thu, Oct 28, 2021 at 1:09 PM Daniel Vetter wrote:
> >
> > Somehow we only have a list of subdirectories, which apparently made
> > it harder for folks to find the gpu maintainers. Fix that.
> >
> > References:
> > https://lore.ker
Hello,
On Thu, Nov 04, 2021 at 02:58:38PM -0300, Maíra Canal wrote:
> Remove legacy PWM interface (pwm_config, pwm_enable, pwm_disable) and
> replace it for the atomic PWM API.
>
> Signed-off-by: Maíra Canal
LGTM,
Reviewed-by: Uwe Kleine-König
Thanks
Uwe
--
Pengutronix e.K.
On Fri, 05 Nov 2021, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 1 Nov 2021 19:42:23 +1100 Stephen Rothwell
> wrote:
>>
>> On Fri, 15 Oct 2021 20:26:48 +1100 Stephen Rothwell
>> wrote:
>> >
>> > After merging the drm-misc tree, today's linux-next build (arm
>> > multi_v7_defconfig) failed li
On Thu, Nov 04, 2021 at 12:27:56PM -0400, Harry Wentland wrote:
>
>
> On 2021-11-04 04:38, Pekka Paalanen wrote:
> > On Wed, 3 Nov 2021 11:08:13 -0400
> > Harry Wentland wrote:
> >
> >> On 2021-09-06 17:38, Uma Shankar wrote:
> >>> Existing LUT precision structure is having only 16 bit
> >>> pr
On Mon, 25 Oct 2021 16:11:04 +0200, Maxime Ripard wrote:
> This is a follow-up of the series here:
> https://lore.kernel.org/all/20210924135530.1036564-1-max...@cerno.tech/
>
> and the discussion that occured here:
> https://lore.kernel.org/all/YWgteNaNeaS9uWDe@phenom.ffwll.local/
>
> The origina
Hi,
On Fri, Nov 05, 2021 at 01:03:43PM +0200, Jani Nikula wrote:
> On Fri, 05 Nov 2021, Stephen Rothwell wrote:
> > Hi all,
> >
> > On Mon, 1 Nov 2021 19:42:23 +1100 Stephen Rothwell
> > wrote:
> >>
> >> On Fri, 15 Oct 2021 20:26:48 +1100 Stephen Rothwell
> >> wrote:
> >> >
> >> > After mergi
On 11/5/21 11:04, Jani Nikula wrote:
> On Fri, 05 Nov 2021, Javier Martinez Canillas wrote:
[snip]
>>
>> Do you envision other condition that could be added later to disable a
>> DRM driver ? Or do you think that just from a code readability point of
>> view makes worth it ?
>
> Taking a step b
On Thu, Nov 04, 2021 at 12:44:34PM -0400, Harry Wentland wrote:
> +Nick
>
> It looks to be the old drm_plane_state->fb holds that reference. See
> dm_plane_helper_cleanup_fb() in amdgpu_dm.c.
BTW looks like you have a possible leak during fb init;
amdgpu_display_framebuffer_init() grabs the refs
On Wed, Nov 03, 2021 at 11:10:37AM -0400, Harry Wentland wrote:
>
>
> On 2021-09-06 17:38, Uma Shankar wrote:
> > Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > planes have different capabilities, implemented respective
> > structure for the HDR planes.
> >
> > Signed-off-b
Hi
Am 05.11.21 um 13:00 schrieb Javier Martinez Canillas:
On 11/5/21 11:04, Jani Nikula wrote:
On Fri, 05 Nov 2021, Javier Martinez Canillas wrote:
[snip]
Do you envision other condition that could be added later to disable a
DRM driver ? Or do you think that just from a code readability
Gem-TTM objects that are backed by shmem might have populated
page-vectors without having the Gem pages set. Those objects
aren't moved to the correct shrinker / purge list by the
gem_madvise. Furthermore they are purged directly on
MADV_DONTNEED rather than waiting for the shrinker to do that.
Fo
On Thu, Nov 04, 2021 at 02:58:38PM -0300, Maíra Canal wrote:
> Remove legacy PWM interface (pwm_config, pwm_enable, pwm_disable) and
> replace it for the atomic PWM API.
>
> Signed-off-by: Maíra Canal
Reviewed-by: Daniel Thompson
Daniel.
On 05/11/2021 13:03, Thomas Hellström wrote:
Gem-TTM objects that are backed by shmem might have populated
page-vectors without having the Gem pages set. Those objects
aren't moved to the correct shrinker / purge list by the
gem_madvise. Furthermore they are purged directly on
MADV_DONTNEED rathe
Hi, gentle ping on this. Is it something that could go through the tip
tree?
thanks
Lucas De Marchi
On Thu, Oct 21, 2021 at 11:15:11AM -0700, Lucas De Marchi wrote:
PAGE_KERNEL_IO is only defined for x86 and nowadays is the same as
PAGE_KERNEL. It was different for some time, OR'ing a `_PAGE_IO
Hi,
On Thu, Nov 4, 2021 at 9:32 PM Steev Klimaszewski wrote:
>
>
> On 11/4/21 5:28 PM, Rob Clark wrote:
> > From: Rob Clark
> >
> > Reported-by: Douglas Anderson
> > Fixes: 9bc95570175a ("drm/msm: Devfreq tuning")
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/msm/msm_gpu_devfreq.c
On 2021-11-04 17:32, Jocelyn Falempe wrote:
> When using Xorg/Logind and an external monitor connected with an MST dock.
> After disconnecting the external monitor, switching to VT may not work,
> the (internal) monitor sill display Xorg, and you can't see what you are
> typing in the VT.
>
> This
https://bugzilla.kernel.org/show_bug.cgi?id=214921
Paul Gover (pmw.go...@yahoo.co.uk) changed:
What|Removed |Added
CC||pmw.go...@yahoo.co.uk
On Fri 05 Nov 10:28 PDT 2021, Kuogee Hsieh wrote:
> From: Kuogee Hsieh
>
> Combo phy supports both USB and DP simultaneously. There may has a
> possible conflict during phy initialization phase between USB and
> DP driver which may cause USB phy timeout when USB tries to power
> up its phy. This
On 05/11/2021 16:50, Michel Dänzer wrote:
On 2021-11-04 17:32, Jocelyn Falempe wrote:
When using Xorg/Logind and an external monitor connected with an MST dock.
After disconnecting the external monitor, switching to VT may not work,
the (internal) monitor sill display Xorg, and you can't see wha
On Fri, Oct 29, 2021 at 02:02:38PM +0200, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> My previous patch correctly addressed the possible link failure, but as
> Jani points out, the dependency is now stricter than it needs to be.
>
> Change it again, to allow DRM_FBDEV_EMULATION to be used whe
On Mon, Nov 01, 2021 at 11:59:15PM +0800, kernel test robot wrote:
> Hi Thomas,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on next-20211029]
> [cannot apply to drm/drm-next shawnguo/for-next pinchartl-media/drm/du/next
> v5.15 v5.15-rc7 v5.15-rc6 v5.15]
> [If you
On Thu, Nov 04, 2021 at 05:37:21PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 02, 2021 at 03:59:33PM +0100, Maxime Ripard wrote:
> > --- a/include/drm/drm_modes.h
> > +++ b/include/drm/drm_modes.h
> > @@ -424,6 +424,21 @@ static inline bool drm_mode_is_stereo(const struct
> > drm_display_mode *mode
On 04 November 2021 at 10:42 pm, Vivek Kasireddy wrote:
> When virgl is not enabled, vfpriv pointer would not be allocated.
> Therefore, check for a valid value before dereferencing.
>
> Reported-by: Christian Zigotzky
> Cc: Gurchetan Singh
> Cc: Gerd Hoffmann
> Signed-off-by: Vivek Kasireddy
On Wed, Nov 03, 2021 at 09:11:12PM -0300, Fabio Estevam wrote:
> This reverts commit f4b34faa08428d813fc3629f882c503487f94a12.
>
> Since commit f4b34faa0842 ("drm/imx: Annotate dma-fence critical section in
> commit path") the following possible circular dependency is detected:
>
> [5.001811]
On Thu, Nov 04, 2021 at 12:44:34PM -0400, Harry Wentland wrote:
> +Nick
>
> It looks to be the old drm_plane_state->fb holds that reference. See
> dm_plane_helper_cleanup_fb() in amdgpu_dm.c.
Yup plane state holds reference for its entire existing (well this holds
in general as design principle
On Fri, Nov 05, 2021 at 07:02:30PM +0100, Daniel Vetter wrote:
> On Thu, Nov 04, 2021 at 05:37:21PM +0200, Ville Syrjälä wrote:
> > On Tue, Nov 02, 2021 at 03:59:33PM +0100, Maxime Ripard wrote:
> > > --- a/include/drm/drm_modes.h
> > > +++ b/include/drm/drm_modes.h
> > > @@ -424,6 +424,21 @@ stati
On Fri, Nov 05, 2021 at 10:35:57AM +0100, Thomas Zimmermann wrote:
> Wrap GEM SHMEM functions for struct drm_gem_object_funcs and update
> all callers. This will allow for an update of the public interfaces
> of the GEM SHMEM helper library.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/g
When I originally moved all of the VESA backlight code in i915 into DRM
helpers, one of the things I didn't have the hardware or time for
testing was machines that used a combination of PWM and DPCD in order to
control their backlights. This has since then caused some breakages and
resulted in us d
This simply adds proper support for panel backlights that can be controlled
via VESA's backlight control protocol, but which also require that we
enable and disable the backlight via PWM instead of via the DPCD interface.
We also enable this by default, in order to fix some people's backlights
that
Since we don't support hybrid AUX/PWM backlights in nouveau right now,
let's add some explicit checks so that we don't break nouveau once we
enable support for these backlights in other drivers.
Reviewed-by: Karol Herbst
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_backlight.c
As it turns out, apparently some machines will actually leave additional
backlight functionality like dynamic backlight control on before the OS
loads. Currently we don't take care to disable unsupported features when
writing back the backlight mode, which can lead to some rather strange
looking be
Now that we've added support to i915 for controlling panel backlights that
need PWM to be enabled/disabled, let's finalize this and add support for
controlling brightness levels via PWM as well. This should hopefully put us
towards the path of supporting _ALL_ backlights via VESA's DPCD interface
w
Hooray! We've managed to hit enough bugs upstream that I've been able to
come up with a pretty solid explanation for how backlight controls are
actually supposed to be detected and used these days. As well, having the
rest of the PWM bits in VESA's backlight interface implemented seems to
have fixe
Hi Jason, Greg, DRM-everyone,
This patchset has 3 separate but related parts:
1. DEFINE_DYNAMIC_DEBUG_BITGRPS [patch 1/10]
Declares DRM.debug style bitmap, bits control pr_debugs by matching formats
Adds callback to translate bits to $cmd > dynamic_debug/control
This could obsolete EXPO
DEFINE_DYNAMIC_DEBUG_BITGRPS(fsname, var, bitmap_desc, bitmap)
allows users to create a drm.debug style (bitmap) sysfs interface,
mapping each bit to a group of pr_debugs, matching on their formats.
This works well when the formats systematically include a prefix
string such as ERR|WARN|INFO, etc.
allocates and initializes ...
Signed-off-by: Jim Cromie
---
include/drm/drm_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 0cd95953cdf5..4b29261c4537 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -
logger_types.h defines many DC_LOG_*() categorized debug wrappers.
Most of these already use DRM debug API, so are controllable using
drm.debug, but others use a bare pr_debug("$prefix: .."), with 1 of 13
different class-prefixes matching [:uppercase:]
Use DEFINE_DYNAMIC_DEBUG_BITGRPS to create a
The gvt component of this driver has ~120 pr_debugs with formats using
one of 9 fixed string prefixes, which are quite similar to those
enumerated in DRM debug categories. Following the interface model of
drm.debug, add a parameter to map bits to these format prefixes.
static struct dyndbg_bitdes
Taking embedded spaces out of existing prefixes makes them more easily
searchable; simplifying the extra quoting needed otherwise:
$> echo format "^gvt: core:" +p >control
Dropping the internal spaces means any trailing space in a query will
more clearly terminate the prefix being searched for.
Duplicate drm_debug_enabled() code into both "basic" and "dyndbg"
ifdef branches. Then add a pr_debug("todo: ...") into the "dyndbg"
branch.
Then convert the "dyndbg" branch's code to a macro, so that the
pr_debug() get its callsite info from the invoking function, instead
of from drm_debug_enabl
drm's debug system writes 10 distinct categories of messages to syslog
using a small API[1]: drm_dbg*(10 names), DRM_DEV_DEBUG*(3 names),
DRM_DEBUG*(8 names). There are thousands of these callsites, each
categorized in this systematized way.
These callsites can be enabled at runtime by their cate
add sysfs knobs to enable modules' pr_debug()s ---> tracefs
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/amd/display/dc/core/dc_debug.c | 8
drivers/gpu/drm/drm_print.c| 13 ++---
drivers/gpu/drm/i915/intel_gvt.c | 15 ---
3 files
With the recent addition of pr_debug to tracefs via +T flag, we now
want to add drm.trace; like its model: drm.debug, it maps bits to
pr_debug categories, but this one enables/disables writing to tracefs
(iff CONFIG_TRACING).
Do this by:
1. add flags to dyndbg_bitmap_param, holds "p" or "T" to wo
Sean Paul proposed, in:
https://patchwork.freedesktop.org/series/78133/
drm/trace: Mirror DRM debug logs to tracefs
His patchset's objective is to be able to independently steer some of
the drm.debug stream to an alternate tracing destination, by splitting
drm_debug_enabled() into syslog & trace f
v2: Introduces a TTM documentation change to clarify the discussion that
happened after the first version of this series was sent.
Also, removing pointless "unlikely" in the "Introduce a new placement for
MOB page tables" commit that Thomas noticed.
This is a largely trivial set that makes vmwgfx
The ttm mem global state was leaking if the vmwgfx driver load failed.
In case of a driver load failure we have to make sure we also release
the ttm mem global state.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 26 --
TTM during the transition to the new page allocator lost the ability
to constrain the allocations via the lower_mem_limit. The code has
been unused since the change:
256dd44bd897 ("drm/ttm: nuke old page allocator")
and there's no reason to keep it.
Fixes: 256dd44bd897 ("drm/ttm: nuke old page all
Some of our hosts have a bug where rescaning a pci bus results in stale
fifo memory being mapped on the host. This makes any fifo communication
impossible resulting in various kernel crashes.
Instead of unexpectedly crashing, predictably fail to load the driver
which will preserve the system.
Fix
TTM was designed to allow TTM_PL_SYSTEM buffer to be fenced but over
the years the code that was meant to handle it was broken and new
changes can not deal with buffers which have been placed in TTM_PL_SYSTEM
buf do not remain idle.
CPU buffers which need to be fenced and shared with accelerators s
There's never a need to access our internal kernel bo's from
user-space. Those objects are used exclusively for internal
support to guest backed surfaces (in otable setup and mob
page tables) and there's no need to have them be of device
type, i.e. mmappable from user-space.
Signed-off-by: Zack Ru
For larger (bigger than a page) and noncontiguous mobs we have
to create page tables that allow the host to find the memory.
Those page tables just used regular system memory. Unfortunately
in TTM those BO's are not allowed to be busy thus can't be
fenced and we have to fence those bo's because we
From: Rob Clark
Reported-by: Douglas Anderson
Fixes: 9bc95570175a ("drm/msm: Devfreq tuning")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
b/drivers/gpu/drm/msm/msm_gpu_devfreq
This driver was made for a prototype and as far as I know it never went
into production because it was too slow. So let's remove it.
Signed-off-by: Noralf Trønnes
---
drivers/staging/fbtft/Kconfig| 6 -
drivers/staging/fbtft/Makefile | 1 -
drivers/staging/fbtft/fb_watterott.c
Hi,
On Fri, Nov 5, 2021 at 11:34 AM Lyude Paul wrote:
>
> As it turns out, apparently some machines will actually leave additional
> backlight functionality like dynamic backlight control on before the OS
> loads. Currently we don't take care to disable unsupported features when
> writing back th
Hi,
On Fri, Nov 5, 2021 at 1:15 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Reported-by: Douglas Anderson
> Fixes: 9bc95570175a ("drm/msm: Devfreq tuning")
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpu_devfreq.c | 5 +
> 1 file changed, 5 insertions(+)
Reviewed-by: Dougl
Den 30.10.2021 18.29, skrev Noralf Trønnes:
> Commit b4a1ed0cd18b ("fbdev: make FB_BACKLIGHT a tristate") forgot to
> update fbtft breaking its backlight support when FB_BACKLIGHT is a module.
>
> Fix this by using IS_ENABLED().
>
> Fixes: b4a1ed0cd18b ("fbdev: make FB_BACKLIGHT a tristate")
>
On 11/5/21 3:20 PM, Rob Clark wrote:
From: Rob Clark
Reported-by: Douglas Anderson
Fixes: 9bc95570175a ("drm/msm: Devfreq tuning")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gpu_devfr
Commit b4a1ed0cd18b ("fbdev: make FB_BACKLIGHT a tristate") forgot to
update fbtft breaking its backlight support when FB_BACKLIGHT is a module.
Since FB_TFT selects FB_BACKLIGHT there's no need for this conditional
so just remove it and we're good.
Fixes: b4a1ed0cd18b ("fbdev: make FB_BACKLIGHT
Hi Daniel,
Just got bitten by this warning when trying to do some refactoring in
amdgpu for trying to get rid of the DRM private object we use for our DC
state.
From a userspace perspective I understand that we want to avoid judder,
-EBUSY and other issues affecting the compositor from kerne
Den 01.11.2021 15.15, skrev Thomas Zimmermann:
> Provide a function that computes the offset into a blit destination
> buffer. This will allow to move destination-buffer clipping into the
> format-helper callers.
>
> v2:
> * provide documentation (Sam)
> * return 'unsigned int' (Sam
Hi,
On Wed, Nov 3, 2021 at 1:59 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpu_devfreq.c | 31 +--
> 1 file changed, 29 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gpu_devfreq.c
> b/dr
On 11/6/2021 1:50 AM, Rob Clark wrote:
From: Rob Clark
Reported-by: Douglas Anderson
Fixes: 9bc95570175a ("drm/msm: Devfreq tuning")
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu_devfreq.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gpu_devfr
On Fri, Nov 05, 2021 at 09:24:48PM +0100, Noralf Trønnes wrote:
> This driver was made for a prototype and as far as I know it never went
> into production because it was too slow. So let's remove it.
>
> Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
On Fri, Nov 05, 2021 at 09:43:58PM +0100, Noralf Trønnes wrote:
> Commit b4a1ed0cd18b ("fbdev: make FB_BACKLIGHT a tristate") forgot to
> update fbtft breaking its backlight support when FB_BACKLIGHT is a module.
>
> Since FB_TFT selects FB_BACKLIGHT there's no need for this conditional
> so just
Quoting Bjorn Andersson (2021-11-05 10:48:37)
> On Fri 05 Nov 10:28 PDT 2021, Kuogee Hsieh wrote:
>
> > From: Kuogee Hsieh
> >
> > Combo phy supports both USB and DP simultaneously. There may has a
> > possible conflict during phy initialization phase between USB and
> > DP driver which may cause
Quoting Kuogee Hsieh (2021-11-05 10:28:11)
> From: Kuogee Hsieh
>
> Combo phy supports both USB and DP simultaneously. There may has a
> possible conflict during phy initialization phase between USB and
> DP driver which may cause USB phy timeout when USB tries to power
> up its phy. This patch ha
Hi Jani,
On Fri, 05 Nov 2021 13:03:43 +0200 Jani Nikula wrote:
>
> I probably should have pushed c4f08d7246a5 ("drm/locking: fix
> __stack_depot_* name conflict") to drm-misc-next-fixes.
Please do so as builds will start failing otherwise :-(
--
Cheers,
Stephen Rothwell
pgpAxSxKLNrL7.pgp
Des
89 matches
Mail list logo
