Ted wrote:
> On Tue, May 10, 2022 at 09:32:13AM +0900, Byungchul Park wrote:
> > Yes, right. DEPT has never been optimized. It rather turns on
> > CONFIG_LOCKDEP and even CONFIG_PROVE_LOCKING when CONFIG_DEPT gets on
> > because of porting issue. I have no choice but to rely on those to
> >
Fix following coccicheck warning:
./drivers/gpu/drm/amd/amdgpu/vcn_v4_0.c:724:4-36: duplicated argument to & or |
Remove duplicated UVD_SUVD_CGC_GATE__SRE_H264_MASK.
Signed-off-by: Wan Jiabing
---
drivers/Gap/drm/amd/amdgpu/vcn_v4_0.c | 1 -
1 file changed, 1 deletion(-)
diff --git
On 5/9/22 4:45 PM, Rex-BC Chen wrote:
On Mon, 2022-05-09 at 15:31 +0800, Krzysztof Kozlowski wrote:
On 09/05/2022 06:43, Rex-BC Chen wrote:
From: "Nancy.Lin"
Add vdosys1 RDMA definition.
Signed-off-by: Nancy.Lin
Reviewed-by: AngeloGioacchino Del Regno <
Return boolean values ("true" or "false") instead of 1 or 0 from bool
functions.
Signed-off-by: Haowen Bai
---
drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/gmc_v11_0.c
On Mon, May 9, 2022 at 3:49 PM Piotr Oniszczuk
wrote:
>
> >
> > If you want to confirm the hardware is configured correctly you can
> > remove the cec pin from the hdmi node and set up a cec-gpio node.
> >
On Tue, May 10, 2022 at 09:32:13AM +0900, Byungchul Park wrote:
> Yes, right. DEPT has never been optimized. It rather turns on
> CONFIG_LOCKDEP and even CONFIG_PROVE_LOCKING when CONFIG_DEPT gets on
> because of porting issue. I have no choice but to rely on those to
> develop DEPT out of tree.
On Mon, May 09, 2022 at 06:28:17PM -0400, Theodore Ts'o wrote:
> Oh, one other problem with DEPT --- it's SLOW --- the overhead is
> enormous. Using kvm-xfstests[1] running "kvm-xfstests smoke", here
> are some sample times:
Yes, right. DEPT has never been optimized. It rather turns on
> On May 9, 2022, at 6:57 AM, Hans de Goede wrote:
>
> Hi Zack,
>
> On 4/11/22 16:24, Zack Rusin wrote:
>> On Mon, 2022-04-11 at 10:52 +0200, Hans de Goede wrote:
>>> Hi All,
>>>
>>> Fedora has received a bug report here:
>>>
>>>
On Mon, May 09, 2022 at 04:47:12PM -0400, Steven Rostedt wrote:
> On Mon, 9 May 2022 09:16:37 +0900
> Byungchul Park wrote:
>
> > CASE 2.
> >
> >lock L with depth n
> >lock A
> >lock_nested L' with depth n + 1
> >...
> >unlock L'
> >unlock A
> >unlock L
> >
> > This
When doing DP AUX transfers there are two actors that need to be
powered in order for the DP AUX transfer to work: the DP source and
the DP sink. Commit bacbab58f09d ("drm: Mention the power state
requirement on side-channel operations") added some documentation
saying that the DP source is
On Wed, Apr 27, 2022 at 08:41:35AM -0700, Niranjana Vishwanathapura wrote:
On Wed, Apr 20, 2022 at 03:45:25PM -0700, Niranjana Vishwanathapura wrote:
On Thu, Mar 31, 2022 at 10:28:48AM +0200, Daniel Vetter wrote:
Adding a pile of people who've expressed interest in vm_bind for their
drivers.
On 5/10/22 00:22, Andrzej Hajda wrote:
[snip]
>> static void drm_fbdev_fb_destroy(struct fb_info *info)
>> {
>> + if (info->cmap.len)
>> + fb_dealloc_cmap(>cmap);
>> +
>> drm_fbdev_release(info->par);
>> + framebuffer_release(info);
>
> I would put
On 2/9/2022 9:25 AM, Dmitry Baryshkov wrote:
There is no need to pass full dpu_hw_pipe_cfg instance to
_dpu_hw_sspp_setup_scaler3, pass just struct dpu_format pointer.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 9 -
Oh, one other problem with DEPT --- it's SLOW --- the overhead is
enormous. Using kvm-xfstests[1] running "kvm-xfstests smoke", here
are some sample times:
LOCKDEP DEPT
Time to first test 49 seconds 602 seconds
ext4/0012 s 22
On 09.05.2022 22:03, Javier Martinez Canillas wrote:
On 5/9/22 20:12, Thomas Zimmermann wrote:
[snip]
I actually thought about the same but then remembered what Daniel said in [0]
(AFAIU at least) that these should be done in .remove() so the current code
looks like matches that and only
dp_catalog_ctrl_reset() will software reset DP controller. But it will
not reset programmable registers to default value. DP driver still have
to clear mask bits to interrupt status registers to disable interrupts
after software reset of controller. This patch removes the enable flag
condition
On 5/6/2022 5:29 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-05-06 14:41:07)
dp_catalog_ctrl_reset() will software reset DP controller. But it will
not reset programmable registers to default value. DP driver still have
to clear mask bits to interrupt status registers to disable
Hi Jocelyn,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tegra-drm/drm/tegra/for-next]
[also build test ERROR on v5.18-rc6]
[cannot apply to drm/drm-next drm-tip/drm-tip airlied/drm-next next-20220509]
[If your patch is applied to the wrong git tree, kindly drop
I tried DEPT-v6 applied against 5.18-rc5, and it reported the
following positive.
The reason why it's nonsense is that in context A's [W] wait:
[ 1538.545054] [W] folio_wait_bit_common(pglocked:0):
[ 1538.545370] [] __filemap_get_folio+0x3e4/0x420
[ 1538.545763] stacktrace:
[ 1538.545928]
On 09/05/2022 18:04, Michel Dänzer wrote:
On 2022-05-09 16:22, Thomas Zimmermann wrote:
It might also make sense to adjust the starting value of the lut table such
that its final entry is used for the final entry in the HW palette. For typical
gamma ramps ~2, the curve is fairly flat for
On Mon, 9 May 2022 09:16:37 +0900
Byungchul Park wrote:
> CASE 2.
>
>lock L with depth n
>lock A
>lock_nested L' with depth n + 1
>...
>unlock L'
>unlock A
>unlock L
>
> This case is allowed by Lockdep.
> This case is *NOT* allowed by DEPT cuz it's a *DEADLOCK*.
>
On Mon, May 09, 2022 at 06:23:35PM +0200, Mauro Carvalho Chehab wrote:
> Currently, kernel/module annotates module dependencies when
> request_symbol is used, but it doesn't cover more complex inter-driver
> dependencies that are subsystem and/or driver-specific.
>
At this pount v5.18-rc7 is out
Den 09.05.2022 10.32, skrev Thomas Zimmermann:
> Hi Noralf
>
> Am 06.05.22 um 16:11 schrieb Thomas Zimmermann:
>> Hi
>>
>> Am 06.05.22 um 16:01 schrieb Noralf Trønnes:
>>> Hi Thomas,
>>>
>>> I'm getting this on Ubuntu 22.04:
>>>
>>> [ 0.00] Linux version 5.15.0-27-generic
On 5/9/22 20:12, Thomas Zimmermann wrote:
[snip]
>> I actually thought about the same but then remembered what Daniel said in [0]
>> (AFAIU at least) that these should be done in .remove() so the current code
>> looks like matches that and only framebuffer_release() should be moved.
>>
>> For
Hello Thomas,
On 5/9/22 20:32, Thomas Zimmermann wrote:
> Hi
>
> Am 09.05.22 um 18:33 schrieb Javier Martinez Canillas:
>> On 5/9/22 17:51, Andrzej Hajda wrote:
>>
>> [snip]
>>
>> +
> Regarding drm:
> What about drm_fb_helper_fini? It calls also framebuffer_release and is
>
>
> If you want to confirm the hardware is configured correctly you can
> remove the cec pin from the hdmi node and set up a cec-gpio node.
> https://elixir.bootlin.com/linux/v5.18-rc5/source/Documentation/devicetree/bindings/media/cec-gpio.txt
>
> For some reason the board developers decided to
Hi
Am 09.05.22 um 18:33 schrieb Javier Martinez Canillas:
On 5/9/22 17:51, Andrzej Hajda wrote:
[snip]
+
Regarding drm:
What about drm_fb_helper_fini? It calls also framebuffer_release and is
called often from _remove paths (checked intel/radeon/nouveau). I guess
it should be fixed as well.
On 05/03, Maxime Ripard wrote:
> Hi,
>
> Here's a series that fixes a significant issue we missed when adding support
> for the BCM2711 / RaspberryPi4 in the vc4 driver.
>
> Indeed, before the introduction of the BCM2711 support, the GPU was fairly
> intertwined with the display hardware, and
Also JFYI Mark - I just realized that your email client is defaulting to
sending HTML mail when you reply to me, that doesn't really make it onto the
mailing list at all so you probably want to fix that.
Also - I misspoke here again, I think it should actually be a call to
[Public]
> -Original Message-
> From: Bjorn Helgaas
> Sent: Wednesday, March 30, 2022 7:45 AM
> To: linux-...@vger.kernel.org
> Cc: Deucher, Alexander ; Robert Hancock
> ; dri-devel@lists.freedesktop.org
> Subject: RX 5500 XT: PCIe link speed stuck at Gen1 2.5GT/s by default
>
> See
>
Hi Javier
Am 09.05.22 um 18:33 schrieb Javier Martinez Canillas:
On 5/9/22 17:51, Andrzej Hajda wrote:
[snip]
+
Regarding drm:
What about drm_fb_helper_fini? It calls also framebuffer_release and is
called often from _remove paths (checked intel/radeon/nouveau). I guess
it should be fixed
[Public]
> -Original Message-
> From: Bjorn Helgaas
> Sent: Monday, May 9, 2022 12:23 PM
> To: Linux PCI
> Cc: r087...@yahoo.it; Deucher, Alexander
> ; Koenig, Christian
> ; Pan, Xinhui ; amd-gfx
> mailing list ; dri-devel de...@lists.freedesktop.org>
> Subject: Re: [Bug 215958] New:
On Mon, 2022-05-09 at 15:13 +0200, Mark Menzynski wrote:
> I think there are no direct issues with initialization in the state how it
> is now. I suspect it's because "drm_kms_helper_poll_enable()" starts the
> first worker thread with a delay, which gives enough time to initialize
> required
O 05/09, Melissa Wen wrote:
> On 05/03, Maxime Ripard wrote:
> > When doing an asynchronous page flip (PAGE_FLIP ioctl with the
> > DRM_MODE_PAGE_FLIP_ASYNC flag set), the current code waits for the
> > possible GPU buffer being rendered through a call to
> > vc4_queue_seqno_cb().
> >
> > On the
On 05/03, Maxime Ripard wrote:
> When doing an asynchronous page flip (PAGE_FLIP ioctl with the
> DRM_MODE_PAGE_FLIP_ASYNC flag set), the current code waits for the
> possible GPU buffer being rendered through a call to
> vc4_queue_seqno_cb().
>
> On the BCM2835-37, the GPU driver is part of the
Em Thu, 5 May 2022 23:35:29 +0200
Andi Shyti escreveu:
> Hi Mauro,
>
> [...]
>
> > +static int ref_module_dependency(struct module *mod, struct module *this)
> > +{
> > + int ret;
> > +
> > + if (!this || !this->name)
> > + return -EINVAL;
> > +
> > + if (mod == this)
> > +
On 05/03, Maxime Ripard wrote:
> The BCM2711 has a separate driver for the v3d, and thus we can't call
> into any of the driver entrypoints that rely on the v3d being there.
>
> Let's add a bunch of checks and complain loudly if that ever happen.
>
> Signed-off-by: Maxime Ripard
> ---
>
On 05/03, Maxime Ripard wrote:
> Prior to the BCM2711/RaspberryPi4, the GPU was a part of the display
> components of the SoC. It was thus a part of the vc4 driver.
>
> However, with the BCM2711, it got split out and thus the v3d driver was
> created. The vc4 driver now only handles the display
On Mon, May 9, 2022 at 9:02 AM Rob Clark wrote:
>
> Hi Dave & Daniel,
>
> Here is the main drm/msm pull request for v5.19, containing:
>
> - Fourcc modifier for tiled but not compressed layouts
> - Support for userspace allocated IOVA (GPU virtual address)
> - Devfreq clamp_to_idle fix
> -
On 5/9/22 17:51, Andrzej Hajda wrote:
[snip]
+
>>> Regarding drm:
>>> What about drm_fb_helper_fini? It calls also framebuffer_release and is
>>> called often from _remove paths (checked intel/radeon/nouveau). I guess
>>> it should be fixed as well. Do you plan to fix it?
>>>
>> I think you
Some Kernel modules use symbol_get() or symbol_request() in order
to bind into other drivers. That's the case, for instance, of
media dvb drivers that hook the frontend drivers via I2C using
dvb_attach() macro.
When such bindings happen, one needs first to unload/unbind the
driver that got the
On some devices, the hda driver needs to hook into a video driver,
in order to be able to properly access the audio hardware and/or
the power management function.
That's the case of several snd_hda_intel devices that depends on
i915 driver.
Ensure that a proper reference between the snd-hda
Sometimes, device drivers are bound into each other via try_module_get(),
making such references invisible when looking at /proc/modules or lsmod.
Add a function to allow setting up module references for such
cases, and call it when try_module_get() is used.
Reviewed-by: Dan Williams
Currently, kernel/module annotates module dependencies when
request_symbol is used, but it doesn't cover more complex inter-driver
dependencies that are subsystem and/or driver-specific.
That's because module_try_get() and symbol_get() doesn't try to
setup the module owner.
In the case of hdmi
There's no such function, and __symbol_get() is already declared
as GPL. So, this is likely a left-over.
Signed-off-by: Mauro Carvalho Chehab
---
See [PATCH v6 0/4] at:
https://lore.kernel.org/all/cover.1652113087.git.mche...@kernel.org/
include/linux/module.h | 1 -
1 file changed, 1
On Mon, May 09, 2022 at 03:49:03PM +0100, Lee Jones wrote:
> On Thu, 14 Apr 2022, Greg KH wrote:
>
> > On Tue, Apr 12, 2022 at 04:20:57PM +0100, Lee Jones wrote:
> > > [ Upstream commit b40a6ab2cf9213923bf8e821ce7fa7f6a0a26990 ]
> > >
> > > This is a partial cherry-pick of the above upstream
On 2022-05-09 16:22, Thomas Zimmermann wrote:
>
> It might also make sense to adjust the starting value of the lut table such
> that its final entry is used for the final entry in the HW palette. For
> typical gamma ramps ~2, the curve is fairly flat for small values and goes up
> steeply at
Hi Dave & Daniel,
Here is the main drm/msm pull request for v5.19, containing:
- Fourcc modifier for tiled but not compressed layouts
- Support for userspace allocated IOVA (GPU virtual address)
- Devfreq clamp_to_idle fix
- DPU: DSC (Display Stream Compression) support
- DPU: inline
On Sun, May 8, 2022 at 2:21 PM Piotr Oniszczuk
wrote:
>
>
> >>
> >> I think i have this already (pls see L231/L232 in
> >> https://pastebin.com/67wu9QrH )
> >
> > I see you have hdmitxm1_cec as the enabled pin. Are you certain it's
> > the m1 pin and not the m0 pin?
>
> It depends on board ver.
On 09.05.2022 17:30, Javier Martinez Canillas wrote:
Hello Andrzej,
On 5/9/22 16:56, Andrzej Hajda wrote:
On 06.05.2022 00:04, Javier Martinez Canillas wrote:
From: Daniel Vetter
Most fbdev drivers have issues with the fb_info lifetime, because call to
framebuffer_release() from their
On 09/05/2022 16:22, Thomas Zimmermann wrote:
Hi,
first of all
Tested-by: Thomas Zimemrmann
on G200EH. I clicked a bit in Gnome settings and the display changed
colors. It's pretty cool.
yeah, I also played a bit with https://github.com/zb3/gnome-gamma-tool
Am 09.05.22 um 11:49 schrieb
Hello Andrzej,
On 5/9/22 16:56, Andrzej Hajda wrote:
> On 06.05.2022 00:04, Javier Martinez Canillas wrote:
>> From: Daniel Vetter
>>
>> Most fbdev drivers have issues with the fb_info lifetime, because call to
>> framebuffer_release() from their driver's .remove callback, rather than
>> doing
On Mon, May 09, 2022 at 03:54:11PM +0200, Daniel Vetter wrote:
> On Fri, May 06, 2022 at 01:42:37PM +0100, Mark Brown wrote:
> > Not outside of the source. I did a presentation at ELC-E ages
> > ago which you can probably find but I'm not sure how much it
> > would add.
> I watched that one!
On Fri, May 06, 2022 at 12:18:20AM +, Jim Shargo wrote:
> Hi!
>
> I wanted to send this patch out early to get some feedback on the layout
> of the code and new ConfigFS directory. I intend to follow this up with
> a more complete patch set that uses this to, for instance, add more
>
Am 09.05.22 um 16:33 schrieb Daniel Vetter:
On Wed, May 04, 2022 at 09:47:39AM +0200, Christian König wrote:
VMWGFX is the only remaining user of this and should probably moved over
to drm_exec when it starts using GEM as well.
Signed-off-by: Christian König
I guess this is a bit annoying
Am 09.05.22 um 16:31 schrieb Daniel Vetter:
On Wed, May 04, 2022 at 09:47:32AM +0200, Christian König wrote:
[SNIP]
+/* Make sure we have enough room and add an object the container */
+static int drm_exec_objects_add(struct drm_exec_objects *container,
+ struct
On 06.05.2022 00:04, Javier Martinez Canillas wrote:
From: Daniel Vetter
Most fbdev drivers have issues with the fb_info lifetime, because call to
framebuffer_release() from their driver's .remove callback, rather than
doing from fbops.fb_destroy callback.
Doing that will destroy the fb_info
On Thu, 14 Apr 2022, Greg KH wrote:
> On Tue, Apr 12, 2022 at 04:20:57PM +0100, Lee Jones wrote:
> > [ Upstream commit b40a6ab2cf9213923bf8e821ce7fa7f6a0a26990 ]
> >
> > This is a partial cherry-pick of the above upstream commit.
> >
> > It ensures the file descriptor passed in by userspace is
On Sun, May 8, 2022 at 11:28 PM Dan Carpenter wrote:
>
> Hello Rob Clark,
>
> The patch e25e92e08e32: "drm/msm: devcoredump iommu fault support"
> from Jun 10, 2021, leads to the following Smatch static checker
> warning:
>
> drivers/gpu/drm/msm/msm_gpu.c:418 recover_worker() error: dereferencing
On 5/9/22 15:52, Geert Uytterhoeven wrote:
The Freescale i.MX8MP LDB bridge is only present on Freescale i.MX8MP
SoCs. Hence add a dependency on ARCH_MXC, to prevent asking the user
about this driver when configuring a kernel without i.MX SoC support.
Fixes: 463db5c2ed4aed01 ("drm: bridge:
Hello Tim,
On 5/9/22 16:01, pub...@timruffing.de wrote:
> Thanks for this patch. Do you think this can be backported to LTS 5.17.y and
You are welcome.
> 5.15.y, which are still buggy? It's not a big deal for me but others might
> profit.
>
> Background:
> The patch solves a regression from
On Wed, May 04, 2022 at 09:47:39AM +0200, Christian König wrote:
> VMWGFX is the only remaining user of this and should probably moved over
> to drm_exec when it starts using GEM as well.
>
> Signed-off-by: Christian König
I guess this is a bit annoying since it means we can't require drm_exec
On Wed, May 04, 2022 at 09:47:32AM +0200, Christian König wrote:
> This adds the infrastructure for an execution context for GEM buffers
> which is similar to the existinc TTMs execbuf util and intended to replace
> it in the long term.
>
> The basic functionality is that we abstracts the
Hi,
first of all
Tested-by: Thomas Zimemrmann
on G200EH. I clicked a bit in Gnome settings and the display changed
colors. It's pretty cool.
Am 09.05.22 um 11:49 schrieb Jocelyn Falempe:
Add support for atomic update of gamma lut.
With this patch the "Night light" feature of gnome3
is
On 07/05/2022 00:34, Matt Roper wrote:
On Thu, Apr 28, 2022 at 01:18:42PM +0100, Tvrtko Ursulin wrote:
Hi,
On 28/04/2022 00:07, Matt Roper wrote:
Rather than storing subslice masks internally as u8[] (inside the sseu
structure) and u32 (everywhere else), let's move over to using an
On Mon, May 09, 2022 at 08:56:41AM +0200, Christian König wrote:
> Am 04.05.22 um 12:08 schrieb Daniel Vetter:
> > On Mon, May 02, 2022 at 06:37:07PM +0200, Christian König wrote:
> > > Hello everyone,
> > >
> > > it's a well known problem that the DMA-buf subsystem mixed
> > > synchronization
On Fri, May 06, 2022 at 01:42:37PM +0100, Mark Brown wrote:
> On Fri, May 06, 2022 at 01:58:18PM +0300, Jani Nikula wrote:
>
> > Hey Mark, sorry for hijacking the thread a bit. regmap.h seems to have
> > comprehensive API documentation, but there's very little in terms of
> > higher level
The Freescale i.MX8MP LDB bridge is only present on Freescale i.MX8MP
SoCs. Hence add a dependency on ARCH_MXC, to prevent asking the user
about this driver when configuring a kernel without i.MX SoC support.
Fixes: 463db5c2ed4aed01 ("drm: bridge: ldb: Implement simple Freescale i.MX8MP
LDB
On Fri, May 06, 2022 at 03:10:43AM +0300, Dmitry Osipenko wrote:
> On 5/5/22 11:34, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 18.04.22 um 00:37 schrieb Dmitry Osipenko:
> >> Introduce a common DRM SHMEM shrinker. It allows to reduce code
> >> duplication among DRM drivers that implement theirs
On Fri, 06 May 2022 17:39:53 -0500
Rob Herring wrote:
> On Fri, 06 May 2022 15:05:32 +0100, Andre Przywara wrote:
> > The Arm Mali Display Processor (DP) 5xx/6xx is a series of IP that scans
> > out a framebuffer and hands the pixels over to a digital signal encoder.
> > It supports multiple
On Mon, May 09, 2022 at 03:08:46PM +0200, Javier Martinez Canillas wrote:
> Many of the kselftests in DRM can be converted to kunit tests instead,
> since that framework is more suitable for unit testing.
>
> Suggested-by: Maxime Ripard
> Signed-off-by: Javier Martinez Canillas
Acked-by:
On Fri, May 06, 2022 at 01:49:12AM +0300, Dmitry Osipenko wrote:
> On 5/5/22 11:12, Daniel Vetter wrote:
> > On Wed, May 04, 2022 at 06:56:09PM +0300, Dmitry Osipenko wrote:
> >> On 5/4/22 11:21, Daniel Vetter wrote:
> >> ...
> > - Maybe also do what you suggest and keep a separate lock for
I think there are no direct issues with initialization in the state how it
is now. I suspect it's because "drm_kms_helper_poll_enable()" starts the
first worker thread with a delay, which gives enough time to initialize
required resources. I changed the initialization part to keep it consistent
That should not be necessary any more when drivers should at least be
able to handle a move without a resource.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git
Allow BOs to exist without backing store.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2b01cb30694a..a55564c8b57c 100644
---
Make sure we can at least move and release BOs without backing store.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index
That should not be necessary any more when drivers should at least be
able to handle the move without a resource.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
Rename ttm_bo_init_reserved to ttm_bo_init_validate since that better
matches what the function is actually doing.
Remove the unused size parameter, move the function's kerneldoc to the
implementation and cleanup the whole error handling.
Signed-off-by: Christian König
---
Make sure we can at least move and release BOs without backing store.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git
Not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 26 -
include/drm/ttm/ttm_bo_api.h | 44
2 files changed, 70 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index
It's the only driver using this.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c
index 85a66014c2b6..c4f376d5e1d0 100644
---
Use the new interface instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index 05076e530e7d..858b9382036c
Use the new interface instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_gem_vram_helper.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index 123045b58fec..7449cbc2f925
Use the new interface instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon_object.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index
Hi everyone,
re-sending this because Daniel was requesting a background why this is
useful.
When TTM creates a buffer this object initially should not have any
backing store and there no resource object associated with it. The same
can happen when a driver requests that the backing store of an
Many of the kselftests in DRM can be converted to kunit tests instead,
since that framework is more suitable for unit testing.
Suggested-by: Maxime Ripard
Signed-off-by: Javier Martinez Canillas
---
Documentation/gpu/todo.rst | 11 +++
1 file changed, 11 insertions(+)
diff --git
On 09/05/2022 11:49, Matthew Auld wrote:
On 29/04/2022 11:04, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
We have a statement from HW designers that the GPU read regression when
using 2M pages was fixed from Icelake onwards, which was also confirmed
by bencharking Eero did last year:
"""
On 04.05.2022 13:40, Jagan Teki wrote:
> Samsung MIPI DSIM controller is common DSI IP that can be used in various
> SoCs like Exynos, i.MX8M Mini/Nano.
>
> In order to access this DSI controller between various platform SoCs,
> the ideal way to incorporate this in the drm stack is via the drm
On Mon, 09 May 2022 12:43:00 +0800, Rex-BC Chen wrote:
> From: "Nancy.Lin"
>
> Add vdosys1 RDMA definition.
>
> Signed-off-by: Nancy.Lin
> Reviewed-by: AngeloGioacchino Del Regno
>
> ---
> .../display/mediatek/mediatek,mdp-rdma.yaml | 94 +++
> 1 file changed, 94
On Mon, 09 May 2022 12:43:02 +0800, Rex-BC Chen wrote:
> From: "Nancy.Lin"
>
> Add vdosys1 ETHDR definition.
>
> Signed-off-by: Nancy.Lin
> Reviewed-by: Chun-Kuang Hu
> Reviewed-by: AngeloGioacchino Del Regno
>
> ---
> .../display/mediatek/mediatek,ethdr.yaml | 191 ++
We'll need to propagate drm_edid everywhere. Also make version_greater()
a function for type safety.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 29 +
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c
We'll need to propagate drm_edid everywhere.
v2: Rebase
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_displayid.c | 16
drivers/gpu/drm/drm_edid.c | 17 ++---
include/drm/drm_displayid.h | 6 +++---
include/drm/drm_edid.h | 6 --
4
We'll need to propagate drm_edid everywhere.
v2: Handle NULL EDID pointer (Ville, CI)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index
We'll need to propagate drm_edid everywhere.
v2: Rebase
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index
We'll need to propagate drm_edid everywhere.
v2: Handle NULL drm_edid
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index
We'll need to propagate drm_edid everywhere.
v2: Handle NULL EDID pointer (Ville, CI)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 37 ++---
1 file changed, 22 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c
We'll need to propagate drm_edid everywhere.
v2: Handle NULL EDID pointer (Ville, CI)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 33 -
1 file changed, 20 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c
We'll need to propagate drm_edid everywhere.'
v2: Handle NULL EDID pointer (Ville, CI)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 37 +++--
1 file changed, 23 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c
On 04.05.2022 13:40, Jagan Teki wrote:
> Add module init and exit functions for the bridge to register
> and unregister dsi_driver.
>
> Exynos drm driver stack will register the platform_driver separately
> in the common of it's exynos_drm_drv.c including dsi_driver.
>
> Register again would
We'll need to propagate drm_edid everywhere.
v2: Fix checkpatch warning on superfluous parens
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c
1 - 100 of 172 matches
Mail list logo
