30.10.2021 03:47, Dmitry Osipenko пишет:
> 29.10.2021 21:06, Rafael J. Wysocki пишет:
> ...
> I just noticed that RPM core doesn't reset RPM-enable count of a device
> on driver's unbind (pm_runtime_reinit). It was a bad idea to use
> devm_pm_runtime_enable() + pm_runtime_force_suspend(
Hi AngeloGioacchino,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v5.15-rc7 next-20211029]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--bas
29.10.2021 21:06, Rafael J. Wysocki пишет:
...
I just noticed that RPM core doesn't reset RPM-enable count of a device
on driver's unbind (pm_runtime_reinit). It was a bad idea to use
devm_pm_runtime_enable() + pm_runtime_force_suspend() here, since RPM is
disabled twice on driv
On Tue, Oct 26, 2021 at 05:48:21PM -0700, Umesh Nerlige Ramappa wrote:
With GuC handling scheduling, i915 is not aware of the time that a
context is scheduled in and out of the engine. Since i915 pmu relies on
this info to provide engine busyness to the user, GuC shares this info
with i915 for al
Prior to commit 6c836d965bad ("drm/rockchip: Use the helpers for PSR"),
"PSR exit" used non-blocking analogix_dp_send_psr_spd(). The refactor
started using the blocking variant, for a variety of reasons -- quoting
Sean Paul's potentially-faulty memory:
"""
- To avoid racing a subsequent PSR entry
On Wed, Oct 20, 2021 at 06:23:35PM -0700, Brian Norris wrote:
> On Wed, Oct 20, 2021 at 5:40 PM Sean Paul wrote:
> > The actual latency gains from doing this synchronously are minimal since the
> > panel will display new content as soon as it can regardless of whether the
> > kernel is blocking. T
Series applied, thanks!
Cheers,
-Paul
Le ven., oct. 29 2021 at 18:55:50 +0200, Christophe Branchereau
a écrit :
Reviewed-by: Christophe Branchereau
On Tue, Oct 26, 2021 at 8:13 PM Paul Cercueil
wrote:
Attach a top-level bridge to each encoder, which will be used for
negociating the b
Hi AngeloGioacchino,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v5.15-rc7 next-20211029]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '-
Quoting Kalyan Thota (2021-10-29 05:30:19)
> New required programming in CTL for SC7280. Group ID informs
> HW of which VM owns that CTL. Force this group ID to
> default/disabled until virtualization support is enabled in SW.
>
> Changes in v1:
> - Fix documentation and add descritpion for the ch
Hi
Am 29.10.21 um 13:50 schrieb John Keeping:
The Rockchip fbdev code does not add anything compared to
drm_fbdev_generic_setup(); the one custom function for .fb_mmap does the
same thing as gem_prime_mmap which is called by the helper.
Signed-off-by: John Keeping
---
drivers/gpu/drm/rockchi
Hi
Am 27.10.21 um 23:25 schrieb Marcel Ziswiler:
From: Marcel Ziswiler
Today's -next fails building arm64 defconfig as follows:
ERROR: modpost: module drm_cma_helper uses symbol dma_buf_vunmap from
namespace DMA_BUF, but does not import it.
ERROR: modpost: module drm_cma_helper uses symbol
Hi Dave, Daniel,
Fixes for 5.16.
The following changes since commit 31fa8cbce4664946a1688898410fee41ad05364d:
drm: Add R10 and R12 FourCC (2021-10-28 17:20:45 +1000)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-next-5.16-2021-10-29
f
On Fri, Oct 29, 2021 at 6:29 PM Dmitry Osipenko wrote:
>
> 29.10.2021 18:56, Rafael J. Wysocki пишет:
> > On Fri, Oct 29, 2021 at 5:20 PM Dmitry Osipenko wrote:
> >>
> >> 26.10.2021 01:40, Dmitry Osipenko пишет:
> >>> + ret = devm_pm_runtime_enable(&pdev->dev);
> >>> + if (ret)
> >>> +
JFYI - the wrapping was because of evolution, sorry about that. Going to make
sure that gets fixed the next time I have to send out a topic branch
On Fri, 2021-10-29 at 13:35 +0300, Jani Nikula wrote:
> On Fri, 29 Oct 2021, Jani Nikula wrote:
> > On Wed, 27 Oct 2021, Lyude Paul wrote:
> > > topi
On 2021-10-27 23:38, Stephen Boyd wrote:
Quoting Sankeerth Billakanti (2021-10-27 18:54:48)
DP driver needs a 10 second delay before phy_init so that
the usb combo phy initializes and sets up the necessary
clocks for usb devices such as keyboard and mouse.
eDP controller uses a standalone phy a
Reviewed-by: Christophe Branchereau
On Tue, Oct 26, 2021 at 8:13 PM Paul Cercueil wrote:
>
> Attach a top-level bridge to each encoder, which will be used for
> negociating the bus format and flags.
>
> All the bridges are now attached with DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>
> Signed-off-by: Paul
Reviewed-by: Christophe Branchereau
On Tue, Oct 26, 2021 at 8:13 PM Paul Cercueil wrote:
>
> When using C8 color mode, make sure that the palette is always uploaded
> before a frame; otherwise the very first frame will have wrong colors.
>
> Do that by changing the link order of the DMA descript
Reviewed-by: Christophe Branchereau
On Tue, Oct 26, 2021 at 8:13 PM Paul Cercueil wrote:
>
> Setting the DMA descriptor chain register in the probe function has been
> fine until now, because we only ever had one descriptor per foreground.
>
> As the driver will soon have real descriptor chains,
Reviewed-by: Christophe Branchereau
On Tue, Oct 26, 2021 at 8:13 PM Paul Cercueil wrote:
>
> The IPU scaling information is computed in the plane's ".atomic_check"
> callback, and used in the ".atomic_update" callback. As such, it is
> state-specific, and should be moved to a private state struc
Reviewed-by: Christophe Branchereau
On Tue, Oct 26, 2021 at 8:12 PM Paul Cercueil wrote:
>
> Until now, the ingenic-drm as well as the ingenic-ipu drivers used to
> put state-specific information in their respective private structure.
>
> Add boilerplate code to support private objects in the tw
Hi Paul,
Reviewed-by: Christophe Branchereau
On Tue, Oct 26, 2021 at 8:12 PM Paul Cercueil wrote:
>
> Instead of having one 'hwdesc' variable for the plane #0, one for the
> plane #1 and one for the palette, use a 'hwdesc[3]' array, where the
> DMA hardware descriptors are indexed by the plan
29.10.2021 18:56, Rafael J. Wysocki пишет:
> On Fri, Oct 29, 2021 at 5:20 PM Dmitry Osipenko wrote:
>>
>> 26.10.2021 01:40, Dmitry Osipenko пишет:
>>> + ret = devm_pm_runtime_enable(&pdev->dev);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = devm_tegra_core_dev_init_opp
29.10.2021 18:28, Ulf Hansson пишет:
> On Fri, 29 Oct 2021 at 17:20, Dmitry Osipenko wrote:
>>
>> 26.10.2021 01:40, Dmitry Osipenko пишет:
>>> + ret = devm_pm_runtime_enable(&pdev->dev);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = devm_tegra_core_dev_init_opp_table_c
On 27.10.2021 01:25, Laurent Pinchart wrote:
Hi Andrzej,
On Mon, Oct 25, 2021 at 10:11:47PM +0200, Andrzej Hajda wrote:
On 25.10.2021 13:21, Laurent Pinchart wrote:
On Mon, Oct 25, 2021 at 01:00:10PM +0200, Andrzej Hajda wrote:
On 21.10.2021 22:21, Sam Ravnborg wrote:
On Thu, Oct 21, 2021
On Fri, Oct 29, 2021 at 5:20 PM Dmitry Osipenko wrote:
>
> 26.10.2021 01:40, Dmitry Osipenko пишет:
> > + ret = devm_pm_runtime_enable(&pdev->dev);
> > + if (ret)
> > + return ret;
> > +
> > + ret = devm_tegra_core_dev_init_opp_table_common(&pdev->dev);
> > + if (ret)
>
Hi Bert,
On Tue, Oct 26, 2021 at 05:18:47PM -0700, Bert Schiettecatte wrote:
> I have an application I'm working on where I'm using OpenGLES / EGL
> and dri/drm/kms. The main loop of my application looks like the code
> below. When running htop, I see that the number of minor faults
> (memory) are
On Fri, 29 Oct 2021 at 17:20, Dmitry Osipenko wrote:
>
> 26.10.2021 01:40, Dmitry Osipenko пишет:
> > + ret = devm_pm_runtime_enable(&pdev->dev);
> > + if (ret)
> > + return ret;
> > +
> > + ret = devm_tegra_core_dev_init_opp_table_common(&pdev->dev);
> > + if (ret)
> >
26.10.2021 01:40, Dmitry Osipenko пишет:
> + ret = devm_pm_runtime_enable(&pdev->dev);
> + if (ret)
> + return ret;
> +
> + ret = devm_tegra_core_dev_init_opp_table_common(&pdev->dev);
> + if (ret)
> + return ret;
> +
> + ret = pm_runtime_resume_and_get(&
On 10/29/21 14:21, Matthew Auld wrote:
We were overzealous here; even though discrete is non-LLC, it should
still be always coherent.
v2(Thomas & Daniel)
- Be extra cautious and limit to DG1
- Add some more commentary
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Daniel Vetter
On Mon, Oct 04, 2021 at 02:58:41PM -0500, Bjorn Andersson wrote:
> On Fri 01 Oct 10:11 CDT 2021, Sean Paul wrote:
>
> > From: Sean Paul
> >
> > This patch adds the bindings for the MSM DisplayPort HDCP registers
> > which are required to write the HDCP key into the display controller as
> > well
Hi,
On Fri, Oct 29, 2021 at 09:15:28AM -0400, George Kennedy wrote:
>
> Asking if you have any input on how to deal with hsub and vsub = zero?
That's just a straight mistake on those formats - they should
be 1. My bad for not spotting it in review.
On the one hand, having formats in this table
The current ELD handling takes the internal connector ELD buffer and
shares it to the I2S and AHB sub-driver.
But with DRM_BRIDGE_ATTACH_NO_CONNECTOR, the connector is created
elsewhere (not not), and an eventual connector is known only
if the bridge chain up to a connector is enabled.
The curren
On 2021-10-29 09:43, Sean Paul wrote:
> On Thu, Oct 28, 2021 at 11:03:54PM -0400, Mark Yacoub wrote:
>> On Thu, Oct 28, 2021 at 8:42 PM Sean Paul wrote:
>>>
>>> On Tue, Oct 26, 2021 at 03:21:00PM -0400, Mark Yacoub wrote:
From: Mark Yacoub
[Why]
This function and enum do no
On Thu, Oct 28, 2021 at 11:03:54PM -0400, Mark Yacoub wrote:
> On Thu, Oct 28, 2021 at 8:42 PM Sean Paul wrote:
> >
> > On Tue, Oct 26, 2021 at 03:21:00PM -0400, Mark Yacoub wrote:
> > > From: Mark Yacoub
> > >
> > > [Why]
> > > This function and enum do not do generic checking on the luts but th
In function ps8640_bridge_poweron(), in case of a failure not relative
to the regulators enablement, the code was disabling the regulators but
the gpio changes that happened during the poweron sequence were not
being reverted back to a clean poweroff state.
Since it is expected that, when we enter
If the bridge cannot get powered on, there's no reason to try to
communicate with it: change the ps8640_bridge_poweron function to
return an error value to the caller, so that we can avoid calling
ps8640_bridge_vdo_control() in ps8640_pre_enable() if the poweron
sequence fails.
Signed-off-by: Ange
In preparation for varying the poweron error handling in function
ps8640_bridge_poweron(), move function ps8640_bridge_poweroff() up
and also move the actual logic to power off the chip to a new
__ps8640_bridge_poweroff() function.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/gpu/drm/b
On 10/28/2021 10:04 AM, Ville Syrjälä wrote:
On Thu, Oct 28, 2021 at 08:57:17AM -0500, George Kennedy wrote:
Do a sanity check on struct drm_format_info hsub and vsub values to
avoid divide by zero.
Syzkaller reported a divide error in framebuffer_check() when the
DRM_FORMAT_Q410 or DRM_FORMA
New required programming in CTL for SC7280. Group ID informs
HW of which VM owns that CTL. Force this group ID to
default/disabled until virtualization support is enabled in SW.
Changes in v1:
- Fix documentation and add descritpion for the change (Stephen)
Signed-off-by: Kalyan Thota
---
driv
On Fri, 29 Oct 2021 at 15:30, Kalyan Thota wrote:
>
> New required programming in CTL for SC7280. Group ID informs
> HW of which VM owns that CTL. Force this group ID to
> default/disabled until virtualization support is enabled in SW.
>
> Changes in v1:
> - Fix documentation and add descritpion
We were overzealous here; even though discrete is non-LLC, it should
still be always coherent.
v2(Thomas & Daniel)
- Be extra cautious and limit to DG1
- Add some more commentary
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_dmabu
[Public]
Thanks Lyude for patiently guiding on this : )
Would like to learn more as following
> -Original Message-
> From: Lyude Paul
> Sent: Wednesday, October 27, 2021 3:35 AM
> To: Lin, Wayne ; dri-devel@lists.freedesktop.org
> Cc: Kazlauskas, Nicholas ; Wentland, Harry
> ; Zuo, Jerr
On Thu, Oct 28, 2021 at 5:24 PM Daniel Vetter wrote:
>
> On Wed, Oct 27, 2021 at 03:19:34PM +0200, Javier Martinez Canillas wrote:
> > On 10/27/21 14:18, Arnd Bergmann wrote:
> >
> > [snip]
> >
> > > Right, how about this change on top?
> > >
> > > --- a/drivers/gpu/drm/Kconfig
> > > +++ b/drivers
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 when
DRM_KMS_HELPER and FB are both loadable modules and DRM is linked into
th
The Rockchip fbdev code does not add anything compared to
drm_fbdev_generic_setup(); the one custom function for .fb_mmap does the
same thing as gem_prime_mmap which is called by the helper.
Signed-off-by: John Keeping
---
drivers/gpu/drm/rockchip/Makefile | 1 -
drivers/gpu/drm/ro
On 29.10.21 05:55, Yunfei Dong wrote:
Decoder will use component framework to manage hardware, it is big
difference with encoder.
Reviewed-by: Rob Herring
Signed-off-by: Yunfei Dong
---
.../media/mediatek,vcodec-decoder.yaml| 176 +
.../media/mediatek,vcodec-encode
On 29.10.21 05:55, Yunfei Dong wrote:
Need to build decoder pm file as module for master and comp
use the same pm interface.
Do you still use the component framework in this patchset?
In the cover letter you write: "- Use of_platform_populate to manage multi hardware,
not component framewor
On 29.10.21 05:55, Yunfei Dong wrote:
Using the needed param for pm init/release function and remove unused
param mtkdev in 'struct mtk_vcodec_pm'.
Reviewed-by: Tzung-Bi Shih
Reviewed-By: AngeloGioacchino Del Regno
Signed-off-by: Yunfei Dong
Hi,
I already commented on v7 that since the
As ffs() returns one more than the index of the first bit set (zero
means no bits set), the color key mode value is shifted one position too
much.
Fix this by using FIELD_GET() instead.
Fixes: c96103b6c49ff9a8 ("drm/armada: move colorkey properties into overlay
plane state")
Signed-off-by: Geert
From: Maarten Lankhorst
TTM already requires this, and we require it for delayed destroy.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu
From: Maarten Lankhorst
Lets be thorough here. Users of the TTM backend would likely expect this
behaviour.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/g
From: Maarten Lankhorst
In the next commit, we don't evict when refcount = 0, so we need to
call drain freed objects, because we want to pin new bo's in the same
place, causing a test failure.
Furthermore, since each subtest is separated, it's a lot better to use
i915_live_selftests, so each sub
From: Maarten Lankhorst
It's just an alias to vma->obj->base.resv, no need to duplicate it.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Niranjana Vishwanathapura
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/i915_vma.c
From: Maarten Lankhorst
We currently have to special case vma->obj being NULL because
of gen6 ppgtt and mock_engine. Fix gen6 ppgtt, so we may soon
be able to remove a few checks. As the object only exists as
a fake object pointing to ggtt, we have no backing storage,
so no real object is created
From: Maarten Lankhorst
vma->obj and vma->resv are now never NULL, and some checks can be removed.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c |
From: Maarten Lankhorst
This allows us to finally get rid of all the assumptions that vma->obj
is NULL.
Changes since v1:
- Ensure the mock_ring vma is pinned to prevent a fault.
- Pin it high to avoid failure in evict_for_vma selftest.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Aul
From: Maarten Lankhorst
gen6_ppgtt_unpin_all is unused, kill it.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 11 ---
drivers/gpu/drm/i915/gt/gen6_ppgtt.h | 1 -
2 files changed, 12 deletions(-)
di
On Fri, 29 Oct 2021, Jani Nikula wrote:
> On Wed, 27 Oct 2021, Lyude Paul wrote:
>> topic/amdgpu-dp2.0-mst-2021-10-27:
>> UAPI Changes:
>> Nope!
>>
>> Cross-subsystem Changes:
>> drm_dp_update_payload_part1() takes a new argument for specifying what the
>> VCPI slot start is
>>
>> Core Changes:
>
On Wed, 27 Oct 2021, Lyude Paul wrote:
> topic/amdgpu-dp2.0-mst-2021-10-27:
> UAPI Changes:
> Nope!
>
> Cross-subsystem Changes:
> drm_dp_update_payload_part1() takes a new argument for specifying what the
> VCPI slot start is
>
> Core Changes:
> Make the DP MST helpers aware of the current starti
On Fri, Oct 29, 2021 at 11:40:26AM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
>
> On Fri, Oct 29, 2021 at 11:33 AM Russell King (Oracle)
> wrote:
> > On Fri, Oct 29, 2021 at 10:28:22AM +0200, Geert Uytterhoeven wrote:
> > > No, you can still use port:
> > >
> > > +oneOf:
> > > + - required:
User get width and height are 64 align when set format. Need to make
sure all is 64 align when use width and height to calculate buffer size.
Signed-off-by: Yunfei Dong
---
drivers/media/platform/mtk-vcodec/vdec/vdec_h264_req_if.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -
Hi Russell,
On Fri, Oct 29, 2021 at 11:33 AM Russell King (Oracle)
wrote:
> On Fri, Oct 29, 2021 at 10:28:22AM +0200, Geert Uytterhoeven wrote:
> > No, you can still use port:
> >
> > +oneOf:
> > + - required:
> > + - port
> > + - required:
> > + - ports
> >
> > When using ports, no f
On Fri, Oct 29, 2021 at 10:28:22AM +0200, Geert Uytterhoeven wrote:
> Hi Russell,
>
> Thanks for your comments!
>
> No, you can still use port:
>
> +oneOf:
> + - required:
> + - port
> + - required:
> + - ports
>
> When using ports, no further requirements are set, but perhaps port@
Hi "Christian,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on next-20211028]
[cannot apply to drm/drm-next drm-intel/for-linux-next
drm-exynos/exynos-drm-next tegra-drm/drm/tegra/for-next linus/master
airlied/drm-next v5.15-rc7]
On Fri, Oct 29, 2021 at 10:36:00AM +0200, Marek Szyprowski wrote:
> Hi Mexime,
>
> On 29.10.2021 10:05, Maxime Ripard wrote:
> > On Fri, Oct 29, 2021 at 08:23:45AM +0200, Marek Szyprowski wrote:
> >> On 25.10.2021 17:15, Maxime Ripard wrote:
> >>> In order to avoid any probe ordering issue, the be
Hi Mexime,
On 29.10.2021 10:05, Maxime Ripard wrote:
> On Fri, Oct 29, 2021 at 08:23:45AM +0200, Marek Szyprowski wrote:
>> On 25.10.2021 17:15, Maxime Ripard wrote:
>>> In order to avoid any probe ordering issue, the best practice is to move
>>> the secondary MIPI-DSI device registration and atta
From: Maarten Lankhorst
TTM already requires this, and we require it for delayed destroy.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu
From: Maarten Lankhorst
It's just an alias to vma->obj->base.resv, no need to duplicate it.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Niranjana Vishwanathapura
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/i915_vma.c
From: Maarten Lankhorst
In the next commit, we don't evict when refcount = 0, so we need to
call drain freed objects, because we want to pin new bo's in the same
place, causing a test failure.
Furthermore, since each subtest is separated, it's a lot better to use
i915_live_selftests, so each sub
From: Maarten Lankhorst
Lets be thorough here. Users of the TTM backend would likely expect this
behaviour.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/g
From: Maarten Lankhorst
Resetting will clear the CONTEXT_VALID_BIT, so wait until after that to
test.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Niranjana Vishwanathapura
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 5 +++--
1 file changed, 3 insertions(+),
From: Maarten Lankhorst
vma->obj and vma->resv are now never NULL, and some checks can be removed.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +-
.../gpu/drm/i915/gt/intel_ring_submission.c |
From: Maarten Lankhorst
This allows us to finally get rid of all the assumptions that vma->obj
is NULL.
Changes since v1:
- Ensure the mock_ring vma is pinned to prevent a fault.
- Pin it high to avoid failure in evict_for_vma selftest.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Aul
From: Maarten Lankhorst
We currently have to special case vma->obj being NULL because
of gen6 ppgtt and mock_engine. Fix gen6 ppgtt, so we may soon
be able to remove a few checks. As the object only exists as
a fake object pointing to ggtt, we have no backing storage,
so no real object is created
From: Maarten Lankhorst
gen6_ppgtt_unpin_all is unused, kill it.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 11 ---
drivers/gpu/drm/i915/gt/gen6_ppgtt.h | 1 -
2 files changed, 12 deletions(-)
di
From: Maarten Lankhorst
When reworking the code to move the eviction fence to the object,
the best code is removed code.
Remove some functions that are unused, and change the function definition
if it's only used in 1 place.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Niranjana Vishwanathapu
Hi Russell,
Thanks for your comments!
On Fri, Oct 29, 2021 at 10:08 AM Russell King (Oracle)
wrote:
> On Thu, Oct 28, 2021 at 08:04:48PM -0500, Rob Herring wrote:
> > On Thu, Oct 21, 2021 at 03:18:53PM +0200, Geert Uytterhoeven wrote:
> > > +properties:
> > > + port@0:
> > > +ty
As we start to introduce asynchronous failsafe object migration,
where we update the object state and then submit asynchronous
commands we need to record what memory resources are actually used
by various part of the command stream. Initially for three purposes:
1) Error capture.
2) Asynchronous m
With asynchronous migrations, the vma state may be several migrations
ahead of the state that matches the request we're capturing.
Address that by introducing an i915_vma_snapshot structure that
can be used to snapshot relevant state at request submission.
In order to make sure we access the correc
The capture code is typically run entirely in the fence signalling
critical path. Recently added lockdep annotation reveals a lockdep splat
similar to the below one.
Fix the splats and the associated potential deadlocks using GFP_NOWAIT
rather than GFP_KERNEL for memory allocation in the capture p
This patch series prepares error capture for asynchronous migration,
where the vma pages may not reflect the pages the GPU is currently
executing from but may be several migrations ahead.
The first patch deals with refcounting sg-list so that they don't
disappear under the capture code, which typi
From: Thomas Hellström
The vma resource are needed for asynchronous bind management and are
similar to TTM resources. They contain the data needed for
asynchronous unbinding (typically the vm range, any backend
private information and a means to do refcounting and to hold
the unbinding for error
On Thu, Oct 28, 2021 at 08:04:48PM -0500, Rob Herring wrote:
> On Thu, Oct 21, 2021 at 03:18:53PM +0200, Geert Uytterhoeven wrote:
> > +properties:
> > + port@0:
> > +type: object
> > +description: FIXME
>
> Looks like the input from the example
>
> > +
> > + port@1:
Hi Marek,
On Fri, Oct 29, 2021 at 08:23:45AM +0200, Marek Szyprowski wrote:
> Hi,
>
> On 25.10.2021 17:15, Maxime Ripard wrote:
> > In order to avoid any probe ordering issue, the best practice is to move
> > the secondary MIPI-DSI device registration and attachment to the
> > MIPI-DSI host at pr
On Thu, Oct 28, 2021 at 06:27:53PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the char-misc tree got a conflict in:
>
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
>
> between commit:
>
> 5740211ea442 ("drm/i915/dmabuf: fix broken build")
>
> from the drm-intel
Add cmdq support for mtk-mmsys config API.
The mmsys config register settings need to take effect with the other
HW settings(like OVL_ADAPTOR...) at the same vblanking time.
If we use CPU to write the mmsys reg, we can't guarantee all the
settings can be written in the same vblanking time.
Cmdq is
Add mt8195 vdosys1 clock driver name and routing table to
the driver data of mtk-mmsys.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h| 136 +
drivers/soc/mediatek/mtk-mmsys.c | 10 ++
include/linux/soc/mediatek/mtk-mmsys.h | 2 +
3 files ch
MT8195 vdosys1 has more than 32 reset bits and a different reset base
than other chips. Modify mmsys for support 64 bit and different reset
base.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h | 1 +
drivers/soc/mediatek/mtk-mmsys.c| 21 -
drivers/soc/m
Add vdosys1 RDMA definition.
Signed-off-by: Nancy.Lin
---
.../arm/mediatek/mediatek,mdp-rdma.yaml | 77 +++
1 file changed, 77 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,mdp-rdma.yaml
diff --git
a/Documentation/devicetree/bi
Add driver data of mt8195 vdosys1 to mediatek-drm and the sub driver.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 4 ++
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 13 ++---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 30 +--
drivers/gpu/drm/mediatek/m
The hardware path of vdosys1 with DPTx output need to go through by several
modules, such as, OVL_ADAPTOR and MERGE.
Add DRM and these modules support by the patches below:
Changes in v7:
- rebase on vdosys0 series v12 (ref[5])
- add dma description in ethdr binding document.
- refine vdosys1 bi
Add merge start/stop API for cmdq support. The ovl_adaptor merges
are configured with each drm plane update. Need to enable/disable
merge with cmdq making sure all the settings taken effect in the
same vblank.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 2 ++
driver
Add display node for vdosys1.
Signed-off-by: Nancy.Lin
---
arch/arm64/boot/dts/mediatek/mt8195.dtsi | 222 +++
1 file changed, 222 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8195.dtsi
b/arch/arm64/boot/dts/mediatek/mt8195.dtsi
index e136761345db..a69a7b57e070
Add merge mute/unmute setting for MT8195.
MT8195 Vdosys1 merge1~merge4 support HW mute function.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/mtk_disp_merge.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_disp_m
Add mmsys config API. The config API is used for config mmsys reg.
Some mmsys regs need to be setting according to the HW engine binding
to the mmsys simultaneously.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mt8195-mmsys.h| 62 ++
drivers/soc/mediatek/mtk-mmsy
Add merge new advance config API. The original merge API is
mtk_ddp_comp_funcs function prototype. The API interface parameters
cannot be modified, so add a new config API for extension. This is
the preparation for ovl_adaptor merge control.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/
Add MDP_RDMA driver for MT8195. MDP_RDMA is the DMA engine of
the ovl_adaptor component.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/Makefile | 3 +-
drivers/gpu/drm/mediatek/mtk_disp_drv.h | 7 +
drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 316
drivers
Add plane color encoding information for color space conversion.
It's a preparation for adding support for mt8195 ovl_adaptor mdp_rdma
csc control.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 1 +
drivers/gpu/drm/mediatek/mtk_drm_plane.h | 1 +
2 files changed, 2 inse
This is a preparation for adding support for mt8195 vdosys1 mutex.
The vdosys1 path component contains ovl_adaptor, merge5,
and dp_intf1. Ovl_adaptor is composed of several sub-elements,
so change it to support multi-bit control.
Signed-off-by: Nancy.Lin
---
drivers/soc/mediatek/mtk-mutex.c | 24
Add ovl_adaptor driver for MT8195.
Ovl_adaptor is an encapsulated module and designed for simplified
DRM control flow. This module is composed of 8 RDMAs, 4 MERGEs and
an ETHDR. Two RDMAs merge into one layer, so this module support 4
layers.
Signed-off-by: Nancy.Lin
---
drivers/gpu/drm/mediatek
1 - 100 of 114 matches
Mail list logo
