https://bugzilla.kernel.org/show_bug.cgi?id=208611
Ivan Molodetskikh (yalt...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
tree: git://anongit.freedesktop.org/drm/drm-misc for-linux-next
head: 82d750e9d2f5d0594c8f7057ce59127e701af781
commit: 6b252cf42281045a9f803d2198023500cfa6ebd2 [10/12] drm/nouveau: nvkm/vmm:
implement raw ops to manage uvmm
config: mips-allyesconfig
On Thu, 03 Aug 2023 22:47:23 +0300, Danila Tikhonov wrote:
> Document the DPU hardware found on the Qualcomm SM7150 platform.
>
> Signed-off-by: Danila Tikhonov
> ---
> .../bindings/display/msm/qcom,sm7150-dpu.yaml | 116 ++
> 1 file changed, 116 insertions(+)
> create mode
On Fri, Aug 4, 2023 at 8:10 PM Olaf Skibbe wrote:
>
> Dear all,
>
> On Fri, 4 Aug 2023 at 14:15, Karol Herbst wrote:
>
> >>> 62aecf23f3d1 drm/nouveau: add nv_encoder pointer check for NULL
> >>> fb725beca62d drm/nouveau/dp: check for NULL nv_connector->native_mode
> >>> 90748be0f4f3 drm/nouveau:
Randy Dunlap writes:
Hello Randy,
> On 8/4/23 05:51, Javier Martinez Canillas wrote:
>> The commit c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
>> emulation is enabled") changed DRM_FBDEV_EMULATION from 'depends on FB'
>> to an effective 'select FB_CORE', so any config that
Hi David,
> >
> Right, the "the zero pages are changed into writable pages" in your
> above comment just might not apply, because there won't be any
> >> page
> replacement (hopefully :) ).
> >>
> >>> If the page replacement does not happen when there are new
>
From: Rob Clark
Similar to the previous patch, move the allocation out from under
dev_pm_qos_mtx, by speculatively doing the allocation and handle
any race after acquiring dev_pm_qos_mtx by freeing the redundant
allocation.
Suggested-by: Rafael J. Wysocki
Signed-off-by: Rob Clark
---
This is
On Fri, 2023-08-04 at 16:02 -0400, Rodrigo Vivi wrote:
> On Wed, Jul 19, 2023 at 07:50:21PM +, Zanoni, Paulo R wrote:
> > On Sat, 2023-07-15 at 17:45 +0200, Thomas Hellström wrote:
> > > Add a motivation for and description of asynchronous VM_BIND operation
> >
> > I think I may have missed
https://bugzilla.kernel.org/show_bug.cgi?id=217764
Bug ID: 217764
Summary: nouveau: system hangs when changing pstate on GeForce
GT 320M (NVAF (MCP89))
Product: Drivers
Version: 2.5
Hardware: i386
OS: Linux
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is
Now that most panels have been updated not to track/double-check their
prepared/enabled state update the TODO with next steps.
Signed-off-by: Douglas Anderson
---
Documentation/gpu/todo.rst | 33 +
1 file changed, 13 insertions(+), 20 deletions(-)
diff --git
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is
The goal of this file is to contain helper functions for panel drivers
to use. To start off with, let's add drm_panel_helper_shutdown() for
use by panels that want to make sure they're powered off at
shutdown/remove time if they happen to be powered on.
The main goal of introducting this function
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is
As talked about in commit d2aacaf07395 ("drm/panel: Check for already
prepared/enabled in drm_panel"), we want to remove needless code from
panel drivers that was storing and double-checking the
prepared/enabled state. Even if someone was relying on the
double-check before, that double-check is
On Tue, Aug 1, 2023, at 19:05, Russell King (Oracle) wrote:
> On Fri, Jul 07, 2023 at 11:52:23AM +0200, Arnd Bergmann wrote:
>> From: Arnd Bergmann
>>
>> The list of dependencies here is phrased as an opt-out, but this is missing
>> a lot of architectures that don't actually support VGA
On Fri, Aug 4, 2023 at 10:38 PM Rob Clark wrote:
>
> On Fri, Aug 4, 2023 at 12:11 PM Rafael J. Wysocki wrote:
> >
> > On Fri, Aug 4, 2023 at 8:38 PM Rob Clark wrote:
> > >
> > > On Fri, Aug 4, 2023 at 10:07 AM Rafael J. Wysocki
> > > wrote:
> > > >
> > > > On Fri, Aug 4, 2023 at 12:02 AM Rob
On Fri, Aug 4, 2023 at 12:11 PM Rafael J. Wysocki wrote:
>
> On Fri, Aug 4, 2023 at 8:38 PM Rob Clark wrote:
> >
> > On Fri, Aug 4, 2023 at 10:07 AM Rafael J. Wysocki wrote:
> > >
> > > On Fri, Aug 4, 2023 at 12:02 AM Rob Clark wrote:
> > > >
> > > > From: Rob Clark
> > > >
> > > > In the
On Fri, Jun 30, 2023 at 06:44:52PM +0200, Thomas Hellström wrote:
> Add the first version of the VM_BIND locking document which is
> intended to be part of the xe driver upstreaming agreement.
>
> The document describes and discuss the locking used during exec-
> functions, evicton and for
On Wed, Jul 19, 2023 at 07:50:21PM +, Zanoni, Paulo R wrote:
> On Sat, 2023-07-15 at 17:45 +0200, Thomas Hellström wrote:
> > Add a motivation for and description of asynchronous VM_BIND operation
>
> I think I may have missed some other documentation, which would explain
> some of my
On 8/4/23 05:51, Javier Martinez Canillas wrote:
> The commit c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
> emulation is enabled") changed DRM_FBDEV_EMULATION from 'depends on FB'
> to an effective 'select FB_CORE', so any config that previously had DRM=y
> and FB=n now has
On Fri, Aug 4, 2023 at 8:38 PM Rob Clark wrote:
>
> On Fri, Aug 4, 2023 at 10:07 AM Rafael J. Wysocki wrote:
> >
> > On Fri, Aug 4, 2023 at 12:02 AM Rob Clark wrote:
> > >
> > > From: Rob Clark
> > >
> > > In the process of adding lockdep annotation for drm GPU scheduler's
> > > job_run() to
The pull request you sent on Fri, 4 Aug 2023 15:07:56 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2023-08-04
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4142fc6743d39271e712936d9fb284cd84cb6010
Thank you!
--
Deet-doot-dot, I am a bot.
Dne petek, 04. avgust 2023 ob 16:27:06 CEST je Uwe Kleine-König napisal(a):
> Instead of requiring each driver to care for assigning the owner member
> of struct pwm_ops, handle that implicitly using a macro. Note that the
> owner member has to be moved to struct pwm_chip, as the ops structure
>
On 8/4/23 07:27, Uwe Kleine-König wrote:
Instead of requiring each driver to care for assigning the owner member
of struct pwm_ops, handle that implicitly using a macro. Note that the
owner member has to be moved to struct pwm_chip, as the ops structure
usually lives in read-only memory and so
On Fri, Aug 4, 2023 at 5:28 PM Uwe Kleine-König
wrote:
>
> Instead of requiring each driver to care for assigning the owner member
> of struct pwm_ops, handle that implicitly using a macro. Note that the
> owner member has to be moved to struct pwm_chip, as the ops structure
> usually lives in
On Fri, Aug 4, 2023 at 10:07 AM Rafael J. Wysocki wrote:
>
> On Fri, Aug 4, 2023 at 12:02 AM Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > In the process of adding lockdep annotation for drm GPU scheduler's
> > job_run() to detect potential deadlock against shrinker/reclaim, I hit
> > this
Provide the driver indirection iterating over all DRM GPU VA spaces to
enable the common 'gpuvas' debugfs file for dumping DRM GPU VA spaces.
Reviewed-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 39 +++
1 file changed, 39
This commit provides the implementation for the new uapi motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl for UMDs to specify the portion of VA
space managed by the kernel and
The new VM_BIND UAPI uses the DRM GPU VA manager to manage the VA space.
Hence, we a need a way to manipulate the MMUs page tables without going
through the internal range allocator implemented by nvkm/vmm.
This patch adds a raw interface for nvkm/vmm to pass the resposibility
for managing the
The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting fences.
If a job times out, we need a way to recover from this situation. For
now, simply kill the channel to unblock all hung up jobs and signal
userspace that
The new VM_BIND UAPI implementation introduced in subsequent commits
will allow asynchronous jobs processing push buffers and emitting
fences.
If a fence context is killed, e.g. due to a channel fault, jobs which
are already queued for execution might still emit new fences. In such a
case a job
The new (VM_BIND) UAPI exports DMA fences through DRM syncobjs. Hence,
in order to emit fences within DMA fence signalling critical sections
(e.g. as typically done in the DRM GPU schedulers run_job() callback) we
need to separate fence allocation and fence emitting.
Reviewed-by: Dave Airlie
On 2023-08-04 14:20, Hamza Mahfooz wrote:
> We should be checking to see if async flips are supported in
> amdgpu_dm_atomic_check() (i.e. not dm_crtc_helper_atomic_check()). Also,
> async flipping isn't supported if a plane's framebuffer changes memory
> domains during an atomic commit. So,
Move the usercopy helpers to a common driver header file to make it
usable for the new API added in subsequent commits.
Reviewed-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_drv.h | 26 ++
drivers/gpu/drm/nouveau/nouveau_gem.c | 26
Initialize the GEM's DRM GPU VA manager interface in preparation for the
(u)vmm implementation, provided by subsequent commits, to make use of it.
Reviewed-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 6 ++
1 file changed, 6 insertions(+)
diff
Provide a getter function for the client's current vmm context. Since
we'll add a new (u)vmm context for UMD bindings in subsequent commits,
this will keep the code clean.
Reviewed-by: Dave Airlie
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
From: Dave Airlie
nouveau > 10 years ago had a plan for new multiplexer inside a multiplexer
API using nvif. It never fully reached fruition, fast forward 10 years,
and the new vulkan driver is avoiding libdrm and calling ioctls, and
these 3 ioctls, getparam, channel alloc + free don't seem to
This commit provides the interfaces for the new UAPI motivated by the
Vulkan API. It allows user mode drivers (UMDs) to:
1) Initialize a GPU virtual address (VA) space via the new
DRM_IOCTL_NOUVEAU_VM_INIT ioctl. UMDs can provide a kernel reserved
VA area.
2) Bind and unbind GPU VA space
When no custom lock is set to protect a GEMs GPUVA list, lockdep checks
should fall back to the GEM objects dma-resv lock. With the current
implementation we're setting the lock_dep_map of the GEM objects 'resv'
pointer (in case no custom lock_dep_map is set yet) on
drm_gem_private_object_init().
This patch series provides a new UAPI for the Nouveau driver in order to
support Vulkan features, such as sparse bindings and sparse residency.
Furthermore, with the DRM GPUVA manager it provides a new DRM core feature to
keep track of GPU virtual address (VA) mappings in a more generic way
We should be checking to see if async flips are supported in
amdgpu_dm_atomic_check() (i.e. not dm_crtc_helper_atomic_check()). Also,
async flipping isn't supported if a plane's framebuffer changes memory
domains during an atomic commit. So, move the check from
dm_crtc_helper_atomic_check() to
On 2023-08-04 11:56, Hamza Mahfooz wrote:
> We should be checking to see if async flips are supported in
> amdgpu_dm_atomic_check() (i.e. not dm_crtc_helper_atomic_check()). Also,
> async flipping isn't supported if a plane's framebuffer changes memory
> domains during an atomic commit. So,
On Fri, Aug 4, 2023 at 12:02 AM Rob Clark wrote:
>
> From: Rob Clark
>
> In the process of adding lockdep annotation for drm GPU scheduler's
> job_run() to detect potential deadlock against shrinker/reclaim, I hit
> this lockdep splat:
>
>
Hi,
On Thu, Aug 3, 2023 at 10:34 AM Rob Clark wrote:
>
> From: Rob Clark
>
> For normal GPU devfreq, we need to acquire the GMU lock while already
> holding devfreq locks. But in the teardown path, we were calling
> dev_pm_domain_detach() while already holding the GMU lock, resulting in
> this
Arthur Grillo writes:
> On 04/08/23 09:51, Javier Martinez Canillas wrote:
>> The commit c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
>> emulation is enabled") changed DRM_FBDEV_EMULATION from 'depends on FB'
>> to an effective 'select FB_CORE', so any config that previously had
From: Chris Morgan
Document the Anbernic RG351V panel, which appears to be identical to
the panel used in their 353 series except for in inclusion of an
additional DSI format flag.
Signed-off-by: Chris Morgan
---
.../display/panel/newvision,nv3051d.yaml | 18 +++---
1 file
From: Chris Morgan
Add support for the Anbernic 351V. Just like the 353 series the
underlying vendor is unknown/unmarked (at least not visible in a
non-destructive manner). The panel had slightly different init
sequences and timings in the BSP kernel, but works fine with the
same ones used in
From: Chris Morgan
Add support for the Anbernic RG351V panel. This panel is mostly
identical to the one used in the 353 series, except it has a different
panel ID when queried (0x4000 for the 351V, 0x3052 for the 353 panel)
and will not work without the inclusion of the
On Fri, Aug 04, 2023 at 11:11:12AM +0800, suijingfeng wrote:
> On 2023/8/3 20:25, kernel test robot wrote:
> > Hi Sui,
> >
> > kernel test robot noticed the following build errors:
> >
> > [auto build test ERROR on pci/next]
> > [also build test ERROR on pci/for-linus linus/master v6.5-rc4
On 2023-08-04 9:29, Arnd Bergmann wrote:
From: Arnd Bergmann
When CONFIG_DYNAMIC_DEBUG is disabled altogether, calling
_dynamic_func_call_no_desc() does not work:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c: In function
'svm_range_set_attr':
On 04/08/23 09:51, Javier Martinez Canillas wrote:
> The commit c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
> emulation is enabled") changed DRM_FBDEV_EMULATION from 'depends on FB'
> to an effective 'select FB_CORE', so any config that previously had DRM=y
> and FB=n now has
We should be checking to see if async flips are supported in
amdgpu_dm_atomic_check() (i.e. not dm_crtc_helper_atomic_check()). Also,
async flipping isn't supported if a plane's framebuffer changes memory
domains during an atomic commit. So, move the check from
dm_crtc_helper_atomic_check() to
Hi Damian,
(CC'ing Tomi)
On Fri, Aug 04, 2023 at 11:49:32AM -0400, Damian Hobson-Garcia wrote:
> On 2023/08/03 20:06, Laurent Pinchart wrote:
> > On Fri, Aug 04, 2023 at 02:53:17AM +0300, Laurent Pinchart wrote:
> >> On Fri, Aug 04, 2023 at 02:47:04AM +0300, Laurent Pinchart wrote:
> >>> Hi
From: Andrew Morton
> Sent: 03 August 2023 18:25
>
> On Thu, 3 Aug 2023 16:19:18 +0300 Andy Shevchenko
> wrote:
>
> > abs_diff() belongs to math.h. Move it there.
> > This will allow others to use it.
> >
> > ...
> >
> > --- a/include/linux/math.h
> > +++ b/include/linux/math.h
> > @@ -155,6
On Wed, 02 Aug 2023 10:01:13 -0700, Jessica Zhang wrote:
> Drop vsync_event and vsync_event_work handlers as they are unnecessary.
> In addition drop the dpu_enc_ktime_template event class as it will be
> unused after the vsync_event handlers are dropped.
>
>
Applied, thanks!
[1/1]
On Fri, 04 Aug 2023 15:57:46 +0800, Jiapeng Chong wrote:
> No functional modification involved.
>
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:183 dpu_core_perf_crtc_check()
> warn: inconsistent indenting.
>
>
Applied, thanks!
[1/1] drm/msm/dpu: clean up some inconsistent indenting
On Wed, 02 Aug 2023 13:04:18 +0300, Dmitry Baryshkov wrote:
> Having an explicit init of interrupt fields to -1 for not existing IRQs
> makes it easier to forget and/or miss such initialisation, resulting in
> a wrong interrupt definition.
>
> Instead shift all IRQ indices to turn '0' to be the
On Fri, 04 Aug 2023 12:48:04 +0300, Dmitry Baryshkov wrote:
> When removing the core perf tune overrides, I also occasionaly removed the
> initialisation of the clk_rate variable. Initialise it to 0 to let max()
> correctly calculate the maximum of requested clock rates.
>
>
Applied, thanks!
On Thu, 03 Aug 2023 22:45:21 +0200, Daniel Vetter wrote:
> Apparently no one noticed that mdp5 plane states leak like a sieve
> ever since we introduced plane_state->commit refcount a few years ago
> in 21a01abbe32a ("drm/atomic: Fix freeing connector/plane state too
> early by tracking commits,
On Fri, Aug 04, 2023 at 02:20:29PM +0800, Wayne Lin wrote:
> [...]
> diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> b/drivers/gpu/drm/display/drm_dp_mst_topology.c
> index e04f87ff755a..4270178f95f6 100644
> --- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
> +++
On Fri, 28 Jul 2023 at 00:23, Rob Clark wrote:
>
> From: Rob Clark
>
> Since the revision becomes an opaque identifier with future GPUs, move
> away from treating different ranges of bits as having a given meaning.
> This means that we need to explicitly list different patch revisions in
> the
Commit 03e909acd95a ("drm/panel: simple: Add support for AUO G121EAN01.4
panel") added support for this panel model, but the timings it implements
are very different from what the datasheet describes. I checked both the
G121EAN01.0 datasheet from [0] and the G121EAN01.4 one from [1] and they
all
This panel has been implemented in commit 225213f24c79 ("drm/panel-simple:
Add Innolux G156HCE-L01 panel entry") with a higher clock than the typical
one mentioned on the documentation to avoid flickering on the unit
tested. Testing on a different unit shows that the panel actually works
with the
On Fri, Aug 4, 2023 at 12:48 PM Tomi Valkeinen
wrote:
>
> The driver calls lt8912_bridge_detach() from its lt8912_remove()
> function. As the DRM core detaches bridges automatically, this leads to
> calling lt8912_bridge_detach() twice. The code probably has tried to
> manage the double-call with
On Fri, Aug 4, 2023 at 12:48 PM Tomi Valkeinen
wrote:
>
> The lt8912b driver, in its bridge detach function, calls
> drm_connector_unregister() and drm_connector_cleanup().
>
> drm_connector_unregister() should be called only for connectors
> explicitly registered with drm_connector_register(),
On 8/4/2023 2:48 AM, Dmitry Baryshkov wrote:
When removing the core perf tune overrides, I also occasionaly removed the
initialisation of the clk_rate variable. Initialise it to 0 to let max()
correctly calculate the maximum of requested clock rates.
Reported-by: Dan Carpenter
Fixes:
Hi Wayne,
kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-misc/drm-misc-next]
[also build test WARNING on drm-intel/for-linux-next-fixes drm/drm-next
linus/master v6.5-rc4 next-20230804]
[cannot apply to drm-intel/for-linux-next]
[If your patch is applied
On 7/12/2023 12:30 AM, Dan Carpenter wrote:
On Tue, Jul 11, 2023 at 11:33:25AM -0600, Jeffrey Hugo wrote:
On 7/11/2023 2:20 AM, Dan Carpenter wrote:
Fixed in v4: Send the correct [PATCH 1/5] patch.
Fixed in v3: Redo messed up threading
Fixed two things in v2: Include the file. Change
the
Hi Marek, Neil,
On Fri, 4 Aug 2023 10:19:12 +0200
Luca Ceresoli wrote:
> Hi Marek,
>
> On Thu, 3 Aug 2023 19:10:35 +0200
> Marek Vasut wrote:
>
> > On 8/3/23 17:06, Luca Ceresoli wrote:
> > > Hi Marek,
> > >
> > > On Thu, 3 Aug 2023 16:25:37 +0200
> > > Marek Vasut wrote:
> > >
> >
Instead of requiring each driver to care for assigning the owner member
of struct pwm_ops, handle that implicitly using a macro. Note that the
owner member has to be moved to struct pwm_chip, as the ops structure
usually lives in read-only memory and so cannot be modified.
The upside is that new
Hello,
(implicit) v1 of this series can be found at
https://lore.kernel.org/linux-pwm/20230803140633.138165-1-u.kleine-koe...@pengutronix.de
.
Changes since then only affect documentation that I missed to adapt before.
Thanks to Laurent for catching that
Best regards
Uwe
Uwe Kleine-König (2):
On Fri, Aug 04, 2023 at 10:50:36AM +0200, Daniel Vetter wrote:
> On Thu, Aug 03, 2023 at 11:35:30AM +0200, Christian König wrote:
> > Am 03.08.23 um 10:58 schrieb Daniel Vetter:
> > > On Thu, 3 Aug 2023 at 10:53, Christian König
> > > wrote:
> > > > Am 01.08.23 um 22:50 schrieb Matthew Brost:
>
On Fri, Aug 04, 2023 at 01:57:40PM +0300, Tomi Valkeinen wrote:
> smatch reports:
>
> drivers/gpu/drm/drm_framebuffer.c:654 drm_mode_getfb2_ioctl() error:
> uninitialized symbol 'ret'.
>
> 'ret' is possibly not set when there are no errors, causing the error
> above. I can't say if that ever
"Arnd Bergmann" writes:
> On Fri, Aug 4, 2023, at 15:07, Daniel Vetter wrote:
>> On Fri, 4 Aug 2023 at 14:52, Javier Martinez Canillas
>> wrote:
>>>
>>> The commit c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
>>> emulation is enabled") changed DRM_FBDEV_EMULATION from 'depends
Javier Martinez Canillas writes:
> Thomas Zimmermann writes:
>
[...]
>> The reasoning is that userspace should always be in control of the
>> format (sans that one exception). If userspace wants packed 24-bits it
>> can support RGB888 explicitly. For the color-format transformation,
>>
On Fri, 4 Aug 2023 at 16:44, Sebastian Wick wrote:
>
> On Fri, Aug 4, 2023 at 3:27 PM Dmitry Baryshkov
> wrote:
> >
> > On Fri, 28 Jul 2023 at 20:03, Jessica Zhang
> > wrote:
> > >
> > > Document and add support for solid_fill property to drm_plane. In
> > > addition, add support for setting
On Fri, Aug 4, 2023, at 15:07, Daniel Vetter wrote:
> On Fri, 4 Aug 2023 at 14:52, Javier Martinez Canillas
> wrote:
>>
>> The commit c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
>> emulation is enabled") changed DRM_FBDEV_EMULATION from 'depends on FB'
>> to an effective 'select
On Fri, Aug 04, 2023 at 01:57:39PM +0300, Tomi Valkeinen wrote:
> smatch reports:
>
> drivers/gpu/drm/drm_file.c:967 drm_show_memory_stats() error: uninitialized
> symbol 'supported_status'.
>
> 'supported_status' is only set in one code path. I'm not familiar with
> the code to say if that
On Friday, 4 August 2023 15:11:46 CEST Olaf Skibbe wrote:
> (On the occasion a maybe silly question: am I right assuming that the
> kernel has to be build on the machine we want to reproduce the bug on?
> Otherwise it could use much faster hardware (running also bookworm).)
If that is also an
https://bugzilla.kernel.org/show_bug.cgi?id=217664
Jose Roberto (colombo...@gmail.com) changed:
What|Removed |Added
CC|
On Fri, Aug 4, 2023 at 3:27 PM Dmitry Baryshkov
wrote:
>
> On Fri, 28 Jul 2023 at 20:03, Jessica Zhang wrote:
> >
> > Document and add support for solid_fill property to drm_plane. In
> > addition, add support for setting and getting the values for solid_fill.
> >
> > To enable solid fill
On Mon, Jul 31, 2023 at 6:01 AM Dmitry Baryshkov
wrote:
>
> On 28/07/2023 20:02, Jessica Zhang wrote:
> > Document and add support for solid_fill property to drm_plane. In
> > addition, add support for setting and getting the values for solid_fill.
> >
> > To enable solid fill planes, userspace
On Fri, Aug 04, 2023 at 03:02:34PM +0200, Michael Riesch wrote:
> The ST7789V controller features support for the partial mode. Here,
> the area to be displayed can be restricted in one direction (by default,
> in vertical direction). This is useful for panels that are partially
> occluded by
From: Arnd Bergmann
When CONFIG_DYNAMIC_DEBUG is disabled altogether, calling
_dynamic_func_call_no_desc() does not work:
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c: In function
'svm_range_set_attr':
drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_svm.c:52:9: error: implicit
declaration of
Hi,
On Fri, 04 Aug 2023 15:02:31 +0200, Michael Riesch wrote:
> This series adds support for the partial display mode to the Sitronix
> ST7789V panel driver. This is useful for panels that are partially
> occluded by design, such as the Jasonic JT240MHQS-HWT-EK-E3. Support
> for this particular
On Fri, 28 Jul 2023 at 20:03, Jessica Zhang wrote:
>
> Document and add support for solid_fill property to drm_plane. In
> addition, add support for setting and getting the values for solid_fill.
>
> To enable solid fill planes, userspace must assign a property blob to
> the "solid_fill" plane
On Fri, 4 Aug 2023 at 10:57, Jiapeng Chong
wrote:
>
> No functional modification involved.
>
> drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c:183 dpu_core_perf_crtc_check()
> warn: inconsistent indenting.
>
> Reported-by: Abaci Robot
> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=6096
On Fri, Jul 28, 2023 at 7:03 PM Jessica Zhang wrote:
>
> Add support for pixel_source property to drm_plane and related
> documentation. In addition, force pixel_source to
> DRM_PLANE_PIXEL_SOURCE_FB in DRM_IOCTL_MODE_SETPLANE as to not break
> legacy userspace.
>
> This enum property will allow
On Wed, 2 Aug 2023 at 20:01, Jessica Zhang wrote:
>
> Drop vsync_event and vsync_event_work handlers as they are unnecessary.
> In addition drop the dpu_enc_ktime_template event class as it will be
> unused after the vsync_event handlers are dropped.
>
> Signed-off-by: Jessica Zhang
> ---
>
On 04/08/2023 15:02, Michael Riesch wrote:
The Jasonic JT240MHQS-HWT-EK-E3 is a custom panel using the Sitronix
ST7789V controller. While the controller features a resolution of
320x240, only an area of 280x240 is visible by design.
Signed-off-by: Michael Riesch
---
On Fri, 4 Aug 2023 at 14:52, Javier Martinez Canillas
wrote:
>
> The commit c242f48433e7 ("drm: Make FB_CORE to be selected if DRM fbdev
> emulation is enabled") changed DRM_FBDEV_EMULATION from 'depends on FB'
> to an effective 'select FB_CORE', so any config that previously had DRM=y
> and FB=n
On 04/08/2023 15:02, Michael Riesch wrote:
The ST7789V controller features support for the partial mode. Here,
the area to be displayed can be restricted in one direction (by default,
in vertical direction). This is useful for panels that are partially
occluded by design. Add support for the
On Tue, Jun 27, 2023 at 10:23:23AM -0300, André Almeida wrote:
> Create a section that specifies how to deal with DRM device resets for
> kernel and userspace drivers.
>
> Acked-by: Pekka Paalanen
> Signed-off-by: André Almeida
> ---
>
> v4:
>
Add compatible for the Jasonic Technology Ltd. JT240MHQS-HWT-EK-E3
display.
Acked-by: Conor Dooley
Signed-off-by: Michael Riesch
---
Documentation/devicetree/bindings/display/panel/sitronix,st7789v.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
1 - 100 of 200 matches
Mail list logo
