tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 8a11187eb62b8b910d2c5484e1f5d160e8b11eb4 Add linux-next specific
files for 20220316
Error/Warning reports:
https://lore.kernel.org/linux-doc/202202240704.pqd40a9l-...@intel.com
https
Easily hit the below list corruption:
==
list_add corruption. prev->next should be next (c0ceb090), but
was ec604507edc8. (prev=ec604507edc8).
WARNING: CPU: 65 PID: 3959 at lib/list_debug.c:26
__list_add_valid+0x53/0x80
CPU: 65 PID: 3959 Comm: fbdev Tainted: G U
RIP: 0010:__list
On Wed, Mar 16, 2022 at 11:26:12AM +0900, Byungchul Park wrote:
> I'm gonna re-add RFC for a while at Ted's request. But hard testing is
> needed to find false alarms for now that there's no false alarm with my
> system. I'm gonna look for other systems that might produce false
> alarms. And it'd b
Felix Kuehling writes:
> On 2022-03-11 04:16, David Hildenbrand wrote:
>> On 10.03.22 18:26, Alex Sierra wrote:
>>> DEVICE_COHERENT pages introduce a subtle distinction in the way
>>> "normal" pages can be used by various callers throughout the kernel.
>>> They behave like normal pages for purpos
Felix Kuehling writes:
> Am 2022-03-10 um 14:25 schrieb Matthew Wilcox:
>> On Thu, Mar 10, 2022 at 11:26:31AM -0600, Alex Sierra wrote:
>>> @@ -606,7 +606,7 @@ static void print_bad_pte(struct vm_area_struct *vma,
>>> unsigned long addr,
>>>* PFNMAP mappings in order to support COWable mappi
Using "size of" instead of "end of" to fix the description for 'size' tag.
Signed-off-by: Cai Huoqing
---
drivers/gpu/drm/drm_mm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mm.c b/drivers/gpu/drm/drm_mm.c
index 8257f9d4f619..c2eedfd264f8 100644
---
>
> Use proper amdgpu_gem_prime_import function to handle all kinds of
> imports. Remember the dmabuf reference to enable proper multi-GPU
> attachment to multiple VMs without erroneously re-exporting the underlying
> BO multiple times.
>
> Signed-off-by: Felix Kuehling
> ---
> .../gpu/drm/a
Hi Dmitry
I have reviewed the series , some patches completely , some of them
especially the plane to sspp mapping is something i still need to check.
But I had one question on the design.
I thought we were going to have a boot param to control whether driver
will internally use both rectang
On 3/15/22 01:42, Dmitry Osipenko wrote:
> DRM API requires the DRM's driver to be backed with the device that can
> be used for generic DMA operations. The VirtIO-GPU device can't perform
> DMA operations if it uses PCI transport because PCI device driver creates
> a virtual VirtIO-GPU device that
From: Rob Clark
In the cause of using the GPU via virtgpu, the host side process is
really a sort of proxy, and not terribly interesting from the PoV of
crash/fault logging. Add a way to override these per process so that
we can see the guest process's name.
Signed-off-by: Rob Clark
---
drive
From: Rob Clark
Deduplicate this from fault_worker and recover_worker.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gpu.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
From: Rob Clark
The 64b value field is already suffient to hold a pointer instead of
immediate, but we also need a length field.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 12 ++--
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 4 ++--
drivers/gpu/drm/msm/msm_dr
From: Rob Clark
Add a way to override comm/cmdline per-drm_file. This is useful for
VM scenarios where the host process is just a proxy for the actual
guest process.
Rob Clark (3):
drm/msm: Add support for pointer params
drm/msm: Split out helper to get comm/cmdline
drm/msm: Add a way to
On Wed, Mar 16, 2022 at 04:45:38PM -0700, Lucas De Marchi wrote:
> From: Matthew Brost
>
> Add logical mapping for VDBOXs. This mapping is required for
> split-frame workloads, which otherwise fail with
>
> -F8C53528: [GUC] 0441-INVALID_ENGINE_SUBMIT_MASK
>
> ... if the applicatio
The KFD API is quite inflexible in that it allows only mapping entire BOs
at the same virtual address on all GPUs. This is incompatible with newer
CUDA memory management APIs.
(see https://docs.nvidia.com/cuda/cuda-driver-api/group__CUDA__VA.html)
Instead of inventing more KFD APIs to fix this, th
This is needed to correctly handle BOs imported into the GEM API, which
would otherwise get added twice to the same VM.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 26 +++
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers
When restoring after an eviction, use amdgpu_vm_handle_moved to update
BO VA mappings in KFD VMs that are not managed through the KFD API. This
should allow using the render node API to create more flexible memory
mappings in KFD VMs.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/
Instead of attaching the eviction fence when a KFD BO is first mapped,
attach it when it is allocated or imported. This in preparation to allow
KFD BOs to be mapped using the render node API.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 62 +--
Let amdgpu_vm_handle_moved update all BO VA mappings of BOs reserved by
the caller. This will be useful for handling extra BO VA mappings in
KFD VMs that are managed through the render node API.
TODO: This may also allow simplification of amdgpu_cs_vm_handling. See
the TODO comment in the code.
S
Exports a DMA buf fd of a given KFD buffer handle. This is intended for
the new upstreamable RDMA solution coming to UCX and libfabric.
The corresponding user mode change (Thunk API and kfdtest) is here:
https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/commits/fxkamd/dmabuf
Signed-off-by
Use proper amdgpu_gem_prime_import function to handle all kinds of
imports. Remember the dmabuf reference to enable proper multi-GPU
attachment to multiple VMs without erroneously re-exporting the
underlying BO multiple times.
Signed-off-by: Felix Kuehling
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkf
On 3/16/22 23:00, Rob Clark wrote:
> On Mon, Mar 14, 2022 at 3:44 PM Dmitry Osipenko
> wrote:
>>
>> Introduce a common DRM SHMEM shrinker. It allows to reduce code
>> duplication among DRM drivers, it also handles complicated lockings
>> for the drivers. This is initial version of the shrinker tha
Earlier versions of commit a5b7ef27da60 ("drm/i915: Add struct to hold
IP version") named "ver" as "arch" and then when it was renamed it
missed the rename on MEDIA_VER_FULL() since it it's currently not used.
Fixes: a5b7ef27da60 ("drm/i915: Add struct to hold IP version")
Cc: José Roberto de Souz
From: Matthew Brost
Add logical mapping for VDBOXs. This mapping is required for
split-frame workloads, which otherwise fail with
-F8C53528: [GUC] 0441-INVALID_ENGINE_SUBMIT_MASK
... if the application is using the logical id to reorder the engines and
then using it for the batc
From: Matthew Brost
PVC has non-standard logical mapping for the VDBOXs, add support for the
correct mapping.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engi
Earlier versions of commit a5b7ef27da60 ("drm/i915: Add struct to hold
IP version") named "ver" as "arch" and then when it was renamed it
missed the rename on MEDIA_VER_FULL() since it it's currently not used.
Fixes: a5b7ef27da60 ("drm/i915: Add struct to hold IP version")
Signed-off-by: Lucas De
Logical to physical mapping for VCS was in place for XEHPSDV and PVC,
but not for any other platform with media version 12. According to
BSpec 48028, for all such platforms, there should be the mapping
0 -> 0, 1 -> 2. This was reported by media team as a failure on ATS-M
and when checking for the o
Auto-generated diff between origin/internal..internal
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index bbaf1caca607f..ddbde96311eb
Hi Doug,
Quoting Doug Anderson (2022-03-10 23:10:20)
> Hi,
>
> On Thu, Mar 10, 2022 at 7:22 AM Kieran Bingham
> wrote:
> >
> > From: Laurent Pinchart
> >
> > Implement the bridge connector-related .get_edid() operation, and report
> > the related bridge capabilities and type.
> >
> > Signed-off
On 3/16/22 18:04, Steven Price wrote:
> On 14/03/2022 22:42, Dmitry Osipenko wrote:
>> Replace Panfrost's memory shrinker with a generic DRM memory shrinker.
>>
>> Signed-off-by: Dmitry Osipenko
>> ---
> I gave this a spin on my Firefly-RK3288 board and everything seems to
> work. So feel free t
On 3/16/22 18:04, Steven Price wrote:
> On 14/03/2022 22:42, Dmitry Osipenko wrote:
>> Introduce a common DRM SHMEM shrinker. It allows to reduce code
>> duplication among DRM drivers, it also handles complicated lockings
>> for the drivers. This is initial version of the shrinker that covers
>> ba
Newer platforms have DSS that aren't necessarily available for both
geometry and compute, two queries will need to exist. This introduces
the first, when passing a valid engine class and engine instance in the
flags returns a topology describing geometry.
v2: fix white space errors
v3: change flag
On Tue, Mar 8, 2022 at 11:40 PM Shashank Sharma
wrote:
>
> From: Shashank Sharma
>
> This patch adds a new sysfs event, which will indicate
> the userland about a GPU reset, and can also provide
> some information like:
> - process ID of the process involved with the GPU reset
> - process name of
On Tue, Mar 15, 2022 at 09:45:59AM +0100, Thomas Zimmermann wrote:
> Fix a number of undefined references to drm_kms_helper.ko in
> drm_dp_helper.ko:
>
> arm-suse-linux-gnueabi-ld: drivers/gpu/drm/dp/drm_dp_mst_topology.o: in
> function `drm_dp_mst_duplicate_state':
> drm_dp_mst_topology.c:(.
On Wed, Mar 16, 2022 at 8:31 PM Thomas Zimmermann wrote:
> Am 16.03.22 um 20:12 schrieb Thomas Zimmermann:
> >>
> >> Adding a dependency in all drivers that select DRM_MIPI_DBI avoids
> >> the problem for now, adding the dependency in DRM_MIPI_DBI as well
> >> should help make it easier to figure
Reviewed-by: Lyude Paul
Will push to drm-misc-next in just a moment
On Tue, 2022-03-15 at 22:19 +, Colin Ian King wrote:
> There is a spelling mistake in a nvdev_error error message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 2 +-
On Wed, 2022-03-16 at 13:01 +0200, Ville Syrjälä wrote:
> On Mon, Mar 14, 2022 at 06:16:36PM -0400, Lyude Paul wrote:
> > Hi! First a little bit of background: I've recently been trying to get rid
> > of
> > all of the non-atomic payload bandwidth management code in the MST helpers
> > in
> > order
On Mon, Mar 14, 2022 at 3:44 PM Dmitry Osipenko
wrote:
>
> Introduce a common DRM SHMEM shrinker. It allows to reduce code
> duplication among DRM drivers, it also handles complicated lockings
> for the drivers. This is initial version of the shrinker that covers
> basic needs of GPU drivers.
>
>
ttm_range_man_alloc would try to ttm_resource_fini the res pointer
before it is allocated.
Fixes: de3688e469b0 (drm/ttm: add ttm_resource_fini v2)
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/ttm/ttm_range_manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/driver
The 2022 X.Org Foundation elections are rapidly approaching. We will be
forwarding the election schedule and nominating process to the
membership shortly.
Please note that only current members can vote in the upcoming election,
and that the deadline for new memberships or renewals to vote in the
u
The Board consists of directors elected from the membership. Each year, an
election is held to bring the total number of directors to eight. The four
members receiving the highest vote totals will serve as directors for two year
terms.
The directors who received two year terms starting in 2021 we
Am 16.03.22 um 20:12 schrieb Thomas Zimmermann:
Hi
Am 16.03.22 um 19:36 schrieb Arnd Bergmann:
From: Arnd Bergmann
The driver fails to build when the KMS helpers are disabled:
ld.lld: error: undefined symbol: drm_gem_fb_get_obj
referenced by drm_mipi_dbi.c
gpu/drm/drm_mipi_
Hi
Am 16.03.22 um 17:45 schrieb Patrik Jakobsson:
On Tue, Mar 8, 2022 at 8:52 PM Thomas Zimmermann wrote:
Refactor and simplify various parts of the memory management. This
includes locking, initialization and finalizer functions, and code
organization.
Tested on Atom N2800 hardware.
v2:
Hi
Am 16.03.22 um 19:36 schrieb Arnd Bergmann:
From: Arnd Bergmann
The driver fails to build when the KMS helpers are disabled:
ld.lld: error: undefined symbol: drm_gem_fb_get_obj
referenced by drm_mipi_dbi.c
gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive
drivers/built
For vendors drivers which pass an already allocated and
initialized encoder especially for cases where the encoder
hardware is shared OR the writeback encoder shares the resources
with the rest of the display pipeline introduce a new API,
drm_writeback_connector_init_with_encoder() which expects
an
vc4 driver currently embeds the drm_encoder into struct vc4_txp
and later on uses container_of to retrieve the vc4_txp from
the drm_encoder.
Since drm_encoder has now been made a pointer inside
drm_writeback_connector, make vc4 driver use the new API
so that the embedded encoder model can be retai
For some vendor driver implementations, display hardware can
be shared between the encoder used for writeback and the physical
display.
In addition resources such as clocks and interrupts can
also be shared between writeback and the real encoder.
To accommodate such vendor drivers and hardware, a
There are some vendor drivers for which the writeback encoder shares
hardware resources such as clocks and interrupts with the rest of the
display pipeline. In addition, there can be use-cases where the
writeback encoder could be a shared encoder between the physical display
path and the writeback
From: Arnd Bergmann
The use of the old-style SET_RUNTIME_PM_OPS() and
SET_SYSTEM_SLEEP_PM_OPS() macros requires function definitions
to be hidden to avoid
drivers/gpu/drm/tegra/vic.c:326:12: error: 'vic_runtime_suspend' defined but
not used [-Werror=unused-function]
326 | static int vic_runti
From: Arnd Bergmann
The driver fails to build when the KMS helpers are disabled:
ld.lld: error: undefined symbol: drm_gem_fb_get_obj
>>> referenced by drm_mipi_dbi.c
>>> gpu/drm/drm_mipi_dbi.o:(mipi_dbi_buf_copy) in archive
>>> drivers/built-in.a
>>> referenced by drm_mipi_dbi.c
>
>> diff --git a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
>> b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
>> index 1c82caf525c3..0ec4986e4805 100644
>> --- a/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
>> +++ b/drivers/gpu/drm/i915/gt/gen2_engine_cs.c
>> @@ -37,6 +37,9 @@ int gen2_emit_flush(struct i915
Some eDP sinks or platform boards will not support hpd.
This patch adds support for those cases.
Signed-off-by: Sankeerth Billakanti
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_catalog.c
b/drivers/gp
The panel-edp driver modes needs to be validated differently from DP
because the link capabilities are not available for EDP by that time.
Signed-off-by: Sankeerth Billakanti
---
drivers/gpu/drm/msm/dp/dp_display.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/msm/dp/
The panel-edp enables the eDP panel power during probe, get_modes
and enable. The eDP connect and disconnect interrupts for the eDP/DP
controller are directly dependent on panel power. As eDP display can be
assumed as always connected, the controller driver can skip the eDP
connect and disc
The source device should ensure the sink is ready before
proceeding to read the sink capability or performing any aux transactions.
The sink will indicate its readiness by asserting the HPD line.
The eDP sink requires power from the source and its HPD line will
be asserted only aft
This patch adds support for generic eDP sink through aux_bus.
The eDP/DP controller driver should support aux transactions originating
from the panel-edp driver and hence should be initialized and ready.
The panel bridge supporting the panel should be ready before
the bridge connec
Add panel identification entry for the sharp LQ140M1JW46 eDP panel
with power sequencing delay information.
Signed-off-by: Sankeerth Billakanti
---
drivers/gpu/drm/panel/panel-edp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/pan
Enable backlight support for eDP panel on CRD platform for sc7280.
Signed-off-by: Sankeerth Billakanti
---
Changes in v5:
- Separate out backlight nodes
arch/arm64/boot/dts/qcom/sc7280-crd.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc
Enable support for eDP interface via aux_bus on CRD platform.
Signed-off-by: Sankeerth Billakanti
---
Changes in v5:
- Change the order of patches
- Remove the backlight nodes
- Remove the bias setting
- Fix compilation issue
- Model VREG_EDP_BP for backlight power
Changes in v4:
-
Rename the edp_out label in the sc7280 platform to mdss_edp_out
so that the nodes related to mdss are all grouped together in
the board specific files.
Signed-off-by: Sankeerth Billakanti
---
Changes in v5:
- Change the order of patches
- Modify commit text
arch/arm64/boot/dts/qcom/sc7280.
This series adds support for eDP on sc7280 CRD platform.
These changes are dependent on the following series in order:
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=620127&state=*
https://patchwork.kernel.org/project/linux-arm-msm/list/?series=616587&state=*
https://patchwork.ker
On 3/16/2022 12:31 AM, Dmitry Baryshkov wrote:
On 16/03/2022 03:28, Abhinav Kumar wrote:
On 3/3/2022 7:21 PM, Dmitry Baryshkov wrote:
MSM DRM driver already allows one to compile out the DP or DSI support.
Add support for disabling other features like MDP4/MDP5/DPU drivers or
direct HDMI o
It's obvious that we don't and shouldn't modify buffer that
is about to be dumped. Constify parameter in fbtft_dbg_hex()
to make it clear.
Fixes: c296d5f9957c ("staging: fbtft: core support")
Signed-off-by: Andy Shevchenko
---
v2: new patch to fix a warning (Greg)
drivers/staging/fbtft/fbtft-cor
In the fbtft_init_display() the init sequence is printed for
the debug purposes. Unfortunately the current code doesn't take
into account that values in the buffer are of the s16 type.
Consider that and replace the printing code with fbtft_par_dbg_hex()
call.
Fixes: b97014a9 ("staging/fbtft:
On Mon, Mar 14, 2022 at 06:28:41PM +0100, Greg Kroah-Hartman wrote:
> On Fri, Mar 04, 2022 at 09:34:14PM +0200, Andy Shevchenko wrote:
...
> Any reason you didn't test build this?
My test build doesn't include the WERROR for this driver, so I missed the
warning. Sorry for that. Now fixed.
> dri
On Tue, Mar 8, 2022 at 8:52 PM Thomas Zimmermann wrote:
>
> Refactor and simplify various parts of the memory management. This
> includes locking, initialization and finalizer functions, and code
> organization.
>
> Tested on Atom N2800 hardware.
>
> v2:
> * put common code in psb_gtt_{ini
> Subject: Re: [RFC PATCH v2 4/5] drm/msm/dp: replace dp_connector with
> drm_bridge_connector
> Date: Wed, 23 Feb 2022 16:40:56 -0800
> From: Kuogee Hsieh
> To: Stephen Boyd , Dmitry Baryshkov
>
> CC: Abhinav Kumar , Bjorn Andersson
> , Rob Clark , Sean Paul
> , David Airlie , Daniel Vetter
> ,
> Subject: [RFC PATCH v2 5/5] drm/msm/dp: remove extra wrappers and
> public functions
> Date: Sat, 12 Feb 2022 01:40:06 +0300
> From: Dmitry Baryshkov
> To: Bjorn Andersson , Rob Clark
> , Sean Paul , Abhinav Kumar
> , Kuogee Hsieh
> CC: Stephen Boyd , David Airlie ,
> Daniel Vetter , linux-arm-
On Wed, Mar 16, 2022 at 8:48 AM Alex Deucher wrote:
>
> On Wed, Mar 16, 2022 at 11:35 AM Rob Clark wrote:
> >
> > On Wed, Mar 16, 2022 at 7:12 AM Alex Deucher wrote:
> > >
> > > On Wed, Mar 16, 2022 at 4:48 AM Pekka Paalanen
> > > wrote:
> > > >
> > [snip]
> > > > With new UAPI comes the deman
Hi Dmitry
On 3/16/2022 12:40 AM, Dmitry Baryshkov wrote:
Hi Abhinav,
On 16/03/2022 02:11, Abhinav Kumar wrote:
There are some vendor drivers for which the writeback encoder shares
hardware resources such as clocks and interrupts with the rest of the
display pipeline. In addition, there can be
On Wed, Mar 16, 2022 at 11:35 AM Rob Clark wrote:
>
> On Wed, Mar 16, 2022 at 7:12 AM Alex Deucher wrote:
> >
> > On Wed, Mar 16, 2022 at 4:48 AM Pekka Paalanen wrote:
> > >
> [snip]
> > > With new UAPI comes the demand of userspace proof, not hand-waving. You
> > > would not be proposing this n
On Wed, Mar 16, 2022 at 7:12 AM Alex Deucher wrote:
>
> On Wed, Mar 16, 2022 at 4:48 AM Pekka Paalanen wrote:
> >
[snip]
> > With new UAPI comes the demand of userspace proof, not hand-waving. You
> > would not be proposing this new interface if you didn't have use cases
> > in mind, even just on
On 16/03/2022 14:39, Christian König wrote:
Am 16.03.22 um 15:26 schrieb Robert Beckett:
[SNIP]
this is where I replace an existing range check via drm_mm with the
range check I added in this patch.
Mhm, I still don't get the use case from the code, but I don't think it
matters any more.
On 16/03/2022 12:51, Rex-BC Chen wrote:
> Add aal binding for MT8183.
>
> Signed-off-by: Rex-BC Chen
> ---
> .../devicetree/bindings/display/mediatek/mediatek,aal.yaml| 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git
> a/Documentation/devicetree/bindings/display/med
On 3/15/22 10:18, Javier Martinez Canillas wrote:
> Hello YueHaibing,
>
> Thanks for the patch.
>
> On 3/12/22 07:34, YueHaibing wrote:
>> WARNING: unmet direct dependencies detected for DRM_GEM_SHMEM_HELPER
>> Depends on [n]: HAS_IOMEM [=y] && DRM [=m] && MMU [=n]
>> Selected by [m]:
>> -
Hi, Angelo:
AngeloGioacchino Del Regno 於
2022年3月16日 週三 下午6:40寫道：
>
> Il 25/01/22 17:36, Chun-Kuang Hu ha scritto:
> > Hi, AngeloGioacchino:
> >
> > AngeloGioacchino Del Regno 於
> > 2022年1月18日 週二 下午9:38寫道：
> >>
> >> There is no need to zero out the newly allocated memory because we are
> >> dupli
On 14/03/2022 22:42, Dmitry Osipenko wrote:
> Replace Panfrost's memory shrinker with a generic DRM memory shrinker.
>
> Signed-off-by: Dmitry Osipenko
> ---
I gave this a spin on my Firefly-RK3288 board and everything seems to
work. So feel free to add a:
Tested-by: Steven Price
As Alyssa ha
On 14/03/2022 22:42, Dmitry Osipenko wrote:
> Introduce a common DRM SHMEM shrinker. It allows to reduce code
> duplication among DRM drivers, it also handles complicated lockings
> for the drivers. This is initial version of the shrinker that covers
> basic needs of GPU drivers.
>
> This patch is
Am 16.03.22 um 15:26 schrieb Robert Beckett:
[SNIP]
this is where I replace an existing range check via drm_mm with the
range check I added in this patch.
Mhm, I still don't get the use case from the code, but I don't think it
matters any more.
I suppose we could add another drm_mm range t
On Wed, Mar 16, 2022 at 04:01:49PM +0300, Dmitry Osipenko wrote:
> On 3/16/22 12:12, Sascha Hauer wrote:
> > On Mon, Mar 14, 2022 at 08:54:27PM +0300, Dmitry Osipenko wrote:
> >> On 3/14/22 11:18, Sascha Hauer wrote:
> >>> On Sun, Mar 13, 2022 at 12:07:56AM +0300, Dmitry Osipenko wrote:
> On 3
On 16/03/2022 13:43, Christian König wrote:
Am 16.03.22 um 14:19 schrieb Robert Beckett:
On 16/03/2022 09:54, Christian König wrote:
Am 15.03.22 um 19:04 schrieb Robert Beckett:
RFC: do we want this to become a generic interface in
ttm_resource_manager_func?
RFC: would we prefer a differ
On 3/15/22 15:43, Emil Velikov wrote:
> Greetings everyone,
>
> Food for thought: Would it make sense to have the madvise ioctl as
> generic DRM one?
> Looking around - i915, msm & panfrost already have one and the virtio
> implementation [below] seems as generic as it gets.
>
> On Mon, 14 Mar 20
On Wed, Mar 16, 2022 at 4:48 AM Pekka Paalanen wrote:
>
> On Tue, 15 Mar 2022 10:54:38 -0400
> Alex Deucher wrote:
>
> > On Mon, Mar 14, 2022 at 11:26 AM Pekka Paalanen wrote:
> > >
> > > On Mon, 14 Mar 2022 10:23:27 -0400
> > > Alex Deucher wrote:
> > >
> > > > On Fri, Mar 11, 2022 at 3:30 AM
On 3/16/22 16:55, Robin Murphy wrote:
>> To me that NIU quirk should be internal to the clk h/w module, so it
>> doesn't feel nice to mix the clk h/w description with the HDMI h/w
>> description.
>>
>> On the other hand, making clk driver to handle this case indeed will
>> take some effort as I see
On 2022-03-16 13:01, Dmitry Osipenko wrote:
On 3/16/22 12:12, Sascha Hauer wrote:
On Mon, Mar 14, 2022 at 08:54:27PM +0300, Dmitry Osipenko wrote:
On 3/14/22 11:18, Sascha Hauer wrote:
On Sun, Mar 13, 2022 at 12:07:56AM +0300, Dmitry Osipenko wrote:
On 3/11/22 11:33, Sascha Hauer wrote:
The
On 3/16/22 15:41, Robin Murphy wrote:
> On 2022-03-14 22:42, Dmitry Osipenko wrote:
>> DRM API requires the DRM's driver to be backed with the device that can
>> be used for generic DMA operations. The VirtIO-GPU device can't perform
>> DMA operations if it uses PCI transport because PCI device d
Am 16.03.22 um 14:19 schrieb Robert Beckett:
On 16/03/2022 09:54, Christian König wrote:
Am 15.03.22 um 19:04 schrieb Robert Beckett:
RFC: do we want this to become a generic interface in
ttm_resource_manager_func?
RFC: would we prefer a different interface? e.g.
for_each_resource_in_range o
On Fri, Feb 18, 2022 at 11:15 PM Guillaume Ranquet
wrote:
>
> From: Jitao Shi
>
> DP 1.4a Section 2.8.7.1.5.6.1:
> A DP Source device shall retry at least seven times upon receiving
> AUX_DEFER before giving up the AUX transaction.
>
> Aux should retry to send msg whether how many bytes.
>
> Sign
On 16/03/2022 07:37, Kasireddy, Vivek wrote:
Hi Tvrtko,
On 15/03/2022 07:28, Kasireddy, Vivek wrote:
Hi Tvrtko, Daniel,
On 11/03/2022 09:39, Daniel Vetter wrote:
On Mon, 7 Mar 2022 at 21:38, Vivek Kasireddy wrote:
On platforms capable of allowing 8K (7680 x 4320) modes, pinning 2 or
On 16/03/2022 09:54, Christian König wrote:
Am 15.03.22 um 19:04 schrieb Robert Beckett:
RFC: do we want this to become a generic interface in
ttm_resource_manager_func?
RFC: would we prefer a different interface? e.g.
for_each_resource_in_range or for_each_bo_in_range
Well completely NAK
On Fri, Feb 18, 2022 at 11:04 AM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> struct drm_display_mode embeds a list head, so overwriting
> the full struct with another one will corrupt the list
> (if the destination mode is on a list). Use drm_mode_copy()
> instead which explicitly preserves
The LCD controller is composed of Frame Compression Processor (FCPVD),
Video Signal Processor (VSPD), and Display Unit (DU).
It has DPI/DSI interfaces and supports a maximum resolution of 1080p
along with 2 RPFs to support blending of two picture layers and
raster operations (ROPs).
The DU part i
RZ/G2L SoC's does not have group/plane registers compared to RCar, hence it
needs a different CRTC implementation. Factorise rcar_du_{atomic_check,
modeset_init} by adding struct rcar_du_crtc_helper_funcs to struct
rcar_du_device_info, so that it can support RZ/G2L SoC without any code
changes.
Si
RZ/G2L SoC's does not have group/plane registers compared to RCar, hence
it needs a different CRTC implementation. Factorise rcar_du_vsp{complete,
enable,plane_atomic_check} so that it can support RZ/G2L SoC without any
code changes.
Signed-off-by: Biju Das
---
v1->v2:
* No change
RFC->v1:
* Ne
RZ/G2L SoC's does not have group/plane registers compared to RCar, hence it
needs a different CRTC implementation.
Move rcar_du_output_name() to a new common file rcar_du_common.c, So that
the same function can be reused by RZ/G2L SoC later.
Signed-off-by: Biju Das
---
v1->v2:
* No change
RFC->
There are some differences related to max frame size supported by different
R-Car/RZ-G family of SoC's
Max frame size supported by R-Car Gen1 & R-Car Gen2 is 4095x2047
Max frame size supported by R-Car Gen3 is 8190x8190
Max frame size supported by RZ/G2L is 1920x1080
Add max_width and max_height
Number of RPF's VSP is different on R-Car and RZ/G2L
R-Car Gen3 -> 5 RPFs
R-Car Gen2 -> 4 RPFs
RZ/G2L -> 2 RPFs
Add num_rpf to struct rcar_du_device_info to support later
SoC without any code changes.
Signed-off-by: Biju Das
---
v1->v2:
* No change
RFC->v1:
* Fixed the comment for num_rpf s
Extend the Renesas DU display bindings to support the r9a07g044l
DU module found on RZ/G2L LCDC.
Signed-off-by: Biju Das
---
v1->v2:
* Updated commit description.
* Removed LCDC references
* Changed clock name from du.0->aclk
* Changed reset name from du.0->du
RFC->v1:
* Changed minItems->m
RZ/G2L LCD controller composed of Frame compression Processor(FCPVD),
Video signal processor (VSPD) and Display unit(DU). The output of LCDC is
connected to Display parallel interface and MIPI link video interface.
This patch series aims to add basic display support on RZ/G2L SMARC EVK
platform. T
On 3/16/22 12:12, Sascha Hauer wrote:
> On Mon, Mar 14, 2022 at 08:54:27PM +0300, Dmitry Osipenko wrote:
>> On 3/14/22 11:18, Sascha Hauer wrote:
>>> On Sun, Mar 13, 2022 at 12:07:56AM +0300, Dmitry Osipenko wrote:
On 3/11/22 11:33, Sascha Hauer wrote:
> The rk3568 HDMI has an additional c
1 - 100 of 131 matches
Mail list logo
