On 12.10.2021 22:47, Guido Günther wrote:
Hi Laurent,
On Tue, Oct 12, 2021 at 11:17:07PM +0300, Laurent Pinchart wrote:
Hi Guido,
Thank you for the patch.
On Tue, Oct 12, 2021 at 09:58:58PM +0200, Guido Günther wrote:
Otherwise logs are filled with
[drm:drm_bridge_attach] *ERROR* failed t
Hi,
On Tue, Oct 12, 2021 at 10:47:14PM +0200, Guido Günther wrote:
> Hi Laurent,
> On Tue, Oct 12, 2021 at 11:17:07PM +0300, Laurent Pinchart wrote:
> > Hi Guido,
> >
> > Thank you for the patch.
> >
> > On Tue, Oct 12, 2021 at 09:58:58PM +0200, Guido Günther wrote:
> > > Otherwise logs are fille
Hi Matt and Paulo,
> The first step of interrupt handling is to read a tile0 register that
> tells us in which tile the interrupt happened; we can then we read the
... we can then read the...
Andi
On Tue, 2021-10-12 at 20:57 +0200, Thomas Hellström wrote:
> > +void vmw_sys_man_fini(struct vmw_private *dev_priv)
> > +{
> > + struct ttm_resource_manager *man =
> > ttm_manager_type(&dev_priv->bdev,
> > +
> > VMW_PL_SYSTEM);
> > +
>
Hi Tvrtko and Matt,
[...]
> -#define I915_MAX_TILES 4
> - struct intel_gt *gts[I915_MAX_TILES];
> +#define I915_MAX_GTS 4
> + struct intel_gt *gts[I915_MAX_GTS];
let's call it MAX_GTS already in patch 5 so that we can avoid a
rename.
BTW, out of the scope of this patch but if we can rea
coccicheck complains about the use of snprintf() in sysfs show functions.
Fix the coccicheck warning:
WARNING: use scnprintf or sprintf.
Use sysfs_emit instead of scnprintf or sprintf makes more sense.
Signed-off-by: Qing Wang
---
drivers/video/fbdev/omap2/omapfb/dss/display-sysfs.c | 14 +
coccicheck complains about the use of snprintf() in sysfs show functions.
Fix the coccicheck warning:
WARNING: use scnprintf or sprintf.
Use sysfs_emit instead of scnprintf or sprintf makes more sense.
Signed-off-by: Qing Wang
---
drivers/video/fbdev/core/fbsysfs.c | 14 +++---
1 file
tree: git://people.freedesktop.org/~airlied/linux.git
drm-intel-display-refactor
head: cb45bcc9cf97016e5d4edb7a4196f0847437460e
commit: 678661f2ff1ba755fc652011d3edb2977165f508 [12/19] drm/i915/display: move
display dump/verify code to a separate file
config: i386-randconfig-a003-20211012
On Mon, Oct 11, 2021 at 04:32:03PM -0700, John Harrison wrote:
> On 10/4/2021 15:06, Matthew Brost wrote:
> > For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
> > mid BB. To safely enable preemption at the BB boundary, a handshake
> > between to parent and child is needed. Th
Hi Ezequiel,
Thanks for your feedback,
The driver can work well now according to your advice with
of_platform_populate interface.
In order to separate parent node with children node, parent node is
master device, children node is component device.
The master and component are registered platfor
Hi Andrzej,
On Tue, 2021-10-12 at 16:27 +0200, Andrzej Pietrasiewicz wrote:
> Hi Yunfei Dong,
>
> W dniu 11.10.2021 o 09:02, Yunfei Dong pisze:
> > This series adds support for multi hardware decode into mtk-vcodec,
> > by first
> > adding use of_platform_populate to manage each hardware
> > in
In preparation for GuC pmu stats, add a name to the execlists stats
structure so that it can be differentiated from the GuC stats.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 14 +++---
drivers/gpu/drm/i915/gt/intel_engine_stats.h | 33 +++--
d
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 all engines using shared memory. For each engine, this
info contains:
- to
From: Alex Deucher
[ Upstream commit 4702b34d1de9582df9dfa0e583ea28fff7de29df ]
Depends on DRM_AMDGPU_SI and DRM_AMD_DC
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff -
From: Yifan Zhang
[ Upstream commit 714d9e4574d54596973ee3b0624ee4a16264d700 ]
This patch is to fix clinfo failure in Raven/Picasso:
Number of platforms: 1
Platform Profile: FULL_PROFILE
Platform Version: OpenCL 2.2 AMD-APP (3364.0)
Platform Name: AMD Accelerated Parallel Processing
Pla
From: Alex Deucher
[ Upstream commit 4702b34d1de9582df9dfa0e583ea28fff7de29df ]
Depends on DRM_AMDGPU_SI and DRM_AMD_DC
Reviewed-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/amd/display/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff -
On Tue, Oct 12, 2021 at 02:22:41PM -0700, John Harrison wrote:
> On 10/4/2021 15:06, Matthew Brost wrote:
> > Allow multiple batch buffers to be submitted in a single execbuf IOCTL
> > after a context has been configured with the 'set_parallel' extension.
> > The number batches is implicit based on
On Tue, Oct 12, 2021 at 03:08:05PM -0700, John Harrison wrote:
> On 10/4/2021 15:06, Matthew Brost wrote:
> > If an object in the excl or shared slot is a composite fence from a
> > parallel submit and the current request in the conflict tracking is from
> > the same parallel context there is no ne
On Tue, Oct 12, 2021 at 02:56:36PM -0700, John Harrison wrote:
> On 10/4/2021 15:06, Matthew Brost wrote:
> > If an error occurs in the front end when multi-lrc requests are getting
> > generated we need to skip these in the backend but we still need to
> > emit the breadcrumbs seqno. An issues ari
Hello Guangming, Christian,
On Tue, 12 Oct 2021, 14:09 , wrote:
> From: Guangming Cao
>
> > Am 09.10.21 um 07:55 schrieb guangming@mediatek.com:
> > From: Guangming Cao
> > >
> > > If dma-buf don't want userspace users to touch the dmabuf buffer,
> > > it seems we should add this restric
On 2021-10-12 16:38, Bjorn Andersson wrote:
On Tue 12 Oct 16:03 PDT 2021, abhin...@codeaurora.org wrote:
On 2021-10-09 20:04, Bjorn Andersson wrote:
> The debugfs code is provided an array of a single drm_connector. Then to
> access the connector, the list of all connectors of the DRM device is
On Tue 12 Oct 16:03 PDT 2021, abhin...@codeaurora.org wrote:
> On 2021-10-09 20:04, Bjorn Andersson wrote:
> > The debugfs code is provided an array of a single drm_connector. Then to
> > access the connector, the list of all connectors of the DRM device is
> > traversed and all non-DisplayPort co
Am 2021-10-12 um 3:03 p.m. schrieb Andrew Morton:
> On Tue, 12 Oct 2021 15:56:29 -0300 Jason Gunthorpe wrote:
>
>>> To what other uses will this infrastructure be put?
>>>
>>> Because I must ask: if this feature is for one single computer which
>>> presumably has a custom kernel, why add it to mai
On 2021-10-09 20:04, Bjorn Andersson wrote:
The debugfs code is provided an array of a single drm_connector. Then
to
access the connector, the list of all connectors of the DRM device is
traversed and all non-DisplayPort connectors are skipped, to find the
one and only DisplayPort connector.
Bu
On 10/12/21 10:05 PM, Sam Ravnborg wrote:
[...]
diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c
index 37c34146eea8..a9217bc18e8f 100644
--- a/drivers/gpu/drm/drm_of.c
+++ b/drivers/gpu/drm/drm_of.c
@@ -402,3 +402,36 @@ int drm_of_lvds_get_dual_link_pixel_order(const struct
dev
Add helper function to convert DT "data-mapping" property string value
into media bus format value, and deduplicate the code in panel-lvds.c
and lvds-codec.c .
Signed-off-by: Marek Vasut
Cc: Laurent Pinchart
Cc: Sam Ravnborg
To: dri-devel@lists.freedesktop.org
---
V2: Drop bogus semicolon
V3: A
The I915_TILING_* values in our uapi header are intended solely for use
with the old get_tiling/set_tiling ioctls that operate on hardware
de-tiling fences; all other uapi communication about tiling types is
done via framebuffer modifiers rather than with these old values.
On newer Intel platforms
No problem, thanks for the patches! Will take a look at this tomorrow
On Tue, 2021-10-12 at 22:02 +, Lakha, Bhawanpreet wrote:
> [AMD Official Use Only]
>
> Hi Lyude,
>
> Jerry is busy these few weeks so I will be taking a look at this. I added
> the start/total slots to the mst_state and am
On 10/4/2021 15:06, Matthew Brost wrote:
If an object in the excl or shared slot is a composite fence from a
parallel submit and the current request in the conflict tracking is from
the same parallel context there is no need to enforce ordering as the
ordering already implicit. Make the request c
On Wed, 13 Oct 2021 at 03:58, Rafael J. Wysocki wrote:
>
> From: Rafael J. Wysocki
>
> The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
> macro and the ACPI handle produced by the former comes from the
> ACPI device object produced by the latter, so it is way more
> straightforward
On Tue, 12 Oct 2021 at 23:33, Karol Herbst wrote:
>
> Fixes a compilation issue introduced because I forgot to test with WERROR
> enabled.
>
> Cc: Stephen Rothwell
> Cc: DRI
> Cc: nouv...@lists.freedesktop.org
> Fixes: 404046cf4805 ("drm/nouveau/mmu/gp100-: drop unneeded assignment in the
> if
[AMD Official Use Only]
Hi Lyude,
Jerry is busy these few weeks so I will be taking a look at this. I added the
start/total slots to the mst_state and am updating them in atomic_check.
Also ignore the V2 "* Remove get_mst_link_encoding_cap" I got a bit lost in
trying to figure out the patch l
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission sta
On 10/4/2021 15:06, Matthew Brost wrote:
If an error occurs in the front end when multi-lrc requests are getting
generated we need to skip these in the backend but we still need to
emit the breadcrumbs seqno. An issues arises because with multi-lrc
breadcrumbs there is a handshake between the par
lib/stackdepot.c:150:1: warning: symbol 'stack_depot_init_mutex' was not
declared. Should it be static?
Reported-by: kernel test robot
Signed-off-by: kernel test robot
---
stackdepot.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/stackdepot.c b/lib/stackdepot.c
in
Hi Vlastimil,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on linux/master linus/master v5.15-rc5]
[cannot apply to hnaz-mm/master next-20211012]
[If your patch is applied to the wrong git tree, kindly drop us a
On Fri, Oct 08, 2021 at 12:49:57PM +0300, Ville Syrjälä wrote:
> On Thu, Sep 30, 2021 at 05:58:16PM -0700, Matt Roper wrote:
> > The I915_TILING_* definitions in the uapi header are intended solely for
> > tiling modes that are visible to the old de-tiling fence ioctls. Since
> > modern hardware d
On 10/4/2021 15:06, Matthew Brost wrote:
Allow multiple batch buffers to be submitted in a single execbuf IOCTL
after a context has been configured with the 'set_parallel' extension.
The number batches is implicit based on the contexts configuration.
This is implemented with a series of loops. F
OK - got sidetracked by an issue at work but I just resumed working on this
today, should hopefully have it done at the start of next week at the latest
(hooray for having time to do things upstream again! :).
On Tue, 2021-09-14 at 08:46 +, Lin, Wayne wrote:
> [Public]
>
> > -Original Mes
> -Original Message-
> From: Pekka Paalanen
> Sent: Tuesday, October 12, 2021 5:20 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> harry.wentl...@amd.com; ville.syrj...@linux.intel.com; brian.star...@arm.com;
> sebast...@sebastianwick.net
> -Original Message-
> From: Pekka Paalanen
> Sent: Tuesday, October 12, 2021 5:25 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> harry.wentl...@amd.com; ville.syrj...@linux.intel.com; brian.star...@arm.com;
> sebast...@sebastianwick.net
> -Original Message-
> From: Pekka Paalanen
> Sent: Tuesday, October 12, 2021 4:01 PM
> To: Shankar, Uma
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> harry.wentl...@amd.com; ville.syrj...@linux.intel.com;
> brian.star...@arm.com; sebast...@sebastianwick.ne
Hi Laurent,
On Tue, Oct 12, 2021 at 11:17:07PM +0300, Laurent Pinchart wrote:
> Hi Guido,
>
> Thank you for the patch.
>
> On Tue, Oct 12, 2021 at 09:58:58PM +0200, Guido Günther wrote:
> > Otherwise logs are filled with
> >
> > [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> > /soc
Hi,
On Tue, Oct 5, 2021 at 7:41 PM Lyude Paul wrote:
>
> @@ -1859,8 +1859,7 @@ drm_dp_sink_can_do_video_without_timing_msa(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> static inline bool
> drm_edp_backlight_supported(const u8 edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE])
> {
> - return (edp_dpcd[1] &
On Tue, Oct 12, 2021 at 04:24:25PM -0400, Felix Kuehling wrote:
>
> Am 2021-10-12 um 3:11 p.m. schrieb Matthew Wilcox:
> > On Tue, Oct 12, 2021 at 11:39:57AM -0700, Andrew Morton wrote:
> >> Because I must ask: if this feature is for one single computer which
> >> presumably has a custom kernel, w
Hi,
On Tue, Oct 12, 2021 at 10:08:28PM +0200, Sam Ravnborg wrote:
> Hi Guido,
>
> On Tue, Oct 12, 2021 at 09:58:58PM +0200, Guido Günther wrote:
> > Otherwise logs are filled with
> >
> > [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> > /soc@0/bus@3080/mipi-dsi@30a0 to enco
Am 2021-10-12 um 3:11 p.m. schrieb Matthew Wilcox:
> On Tue, Oct 12, 2021 at 11:39:57AM -0700, Andrew Morton wrote:
>> Because I must ask: if this feature is for one single computer which
>> presumably has a custom kernel, why add it to mainline Linux?
> I think in particular patch 2 deserves to
Hi Guido,
Thank you for the patch.
On Tue, Oct 12, 2021 at 09:58:58PM +0200, Guido Günther wrote:
> Otherwise logs are filled with
>
> [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> /soc@0/bus@3080/mipi-dsi@30a0 to encoder None-34: -517
>
> when the bridge isn't ready yet
Hi Guido,
On Tue, Oct 12, 2021 at 09:58:58PM +0200, Guido Günther wrote:
> Otherwise logs are filled with
>
> [drm:drm_bridge_attach] *ERROR* failed to attach bridge
> /soc@0/bus@3080/mipi-dsi@30a0 to encoder None-34: -517
>
> when the bridge isn't ready yet.
>
> Fixes: fb8d617f8fd6
Hi Marek,
On Mon, Oct 11, 2021 at 01:21:33PM +0200, Marek Vasut wrote:
> Add helper function to convert DT "data-mapping" property string value
> into media bus format value, and deduplicate the code in panel-lvds.c
> and lvds-codec.c .
>
> Signed-off-by: Marek Vasut
> Cc: Laurent Pinchart
> Cc
Otherwise logs are filled with
[drm:drm_bridge_attach] *ERROR* failed to attach bridge
/soc@0/bus@3080/mipi-dsi@30a0 to encoder None-34: -517
when the bridge isn't ready yet.
Fixes: fb8d617f8fd6 ("drm/bridge: Centralize error message when bridge attach
fails")
Signed-off-by: Guido G
Hi,
With Linux 5.14 kernel series, I often get this warning:
okt 12 16:36:05 piranha kernel: [ cut here ]
okt 12 16:36:05 piranha kernel: WARNING: CPU: 11 PID: 1 at
drivers/gpu/drm/ttm/ttm_bo.c:409 ttm_bo_release+0x2d1/0x300 [ttm]
okt 12 16:36:05 piranha kernel: Modules l
Hi Vegard,
On Tue, Oct 12, 2021 at 01:52:42PM +0200, Vegard Nossum wrote:
> Fix the following build/link error by adding a dependency on the CRC32
> routines:
>
> ld: drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.o: in function
> `lcd_olinuxino_probe':
> panel-olimex-lcd-olinuxino.c:(.tex
Hi Nirmoy,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on tegra/for-next drm-tip/drm-tip linus/master v5.15-rc5
next-20211012]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On Tue, Oct 12, 2021 at 11:39:57AM -0700, Andrew Morton wrote:
> Because I must ask: if this feature is for one single computer which
> presumably has a custom kernel, why add it to mainline Linux?
I think in particular patch 2 deserves to be merged because it removes
a ton of cruft from every cal
> -Original Message-
> From: Pekka Paalanen
> Sent: Tuesday, October 12, 2021 5:30 PM
> To: Simon Ser
> Cc: Shankar, Uma ; intel-...@lists.freedesktop.org;
> dri-
> de...@lists.freedesktop.org; harry.wentl...@amd.com;
> ville.syrj...@linux.intel.com; brian.star...@arm.com;
> sebast...
On Tue, 12 Oct 2021 15:56:29 -0300 Jason Gunthorpe wrote:
> > To what other uses will this infrastructure be put?
> >
> > Because I must ask: if this feature is for one single computer which
> > presumably has a custom kernel, why add it to mainline Linux?
>
> Well, it certainly isn't just "one
Am 2021-10-12 um 2:39 p.m. schrieb Andrew Morton:
> On Tue, 12 Oct 2021 12:12:35 -0500 Alex Sierra wrote:
>
>> This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
>> owned by a device that can be mapped into CPU page tables like
>> MEMORY_DEVICE_GENERIC and can also be migrated l
On 10/8/21 19:31, Zack Rusin wrote:
For larger (bigger than a page) and noncontiguous mobs we have
to create page tables that allow the host to find the memory.
Those page tables just used regular system memory. Unfortunately
in TTM those BO's are not allowed to be busy thus can't be
fenced and
On Tue, Oct 12, 2021 at 11:39:57AM -0700, Andrew Morton wrote:
> On Tue, 12 Oct 2021 12:12:35 -0500 Alex Sierra wrote:
>
> > This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
> > owned by a device that can be mapped into CPU page tables like
> > MEMORY_DEVICE_GENERIC and can a
On Tue, 12 Oct 2021 12:12:35 -0500 Alex Sierra wrote:
> This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
> owned by a device that can be mapped into CPU page tables like
> MEMORY_DEVICE_GENERIC and can also be migrated like MEMORY_DEVICE_PRIVATE.
> With MEMORY_DEVICE_COHERENT
On Tue, 12 Oct 2021 17:33:18 +, you wrote:
>Yes, this is expected behavior, even if it's not intuitive. For more
>details, see:
>
>https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110
Thanks - as noted in that discussion the behaviour is a bit unhelpful
but just knowing that it is exp
On Tue, Oct 12, 2021 at 08:53:25AM +0100, Tvrtko Ursulin wrote:
>
> On 04/10/2021 23:06, Matthew Brost wrote:
> > Parallel submission create composite fences (dma_fence_array) for excl /
> > shared slots in objects. The I915_GEM_BUSY IOCTL checks these slots to
> > determine the busyness of the ob
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a deregister context H2G is in flight. To do this must
issue the deregister H2G from a worker as context can be destroyed from
an atomic context and taking GT PM ref blows up. Previously we took a
runtime PM from th
From: Rafael J. Wysocki
The ACPI_HANDLE() macro is a wrapper arond the ACPI_COMPANION()
macro and the ACPI handle produced by the former comes from the
ACPI device object produced by the latter, so it is way more
straightforward to evaluate the latter directly instead of passing
the handle produc
Quoting Bjorn Andersson (2021-10-09 20:04:35)
> The debugfs code is provided an array of a single drm_connector. Then to
> access the connector, the list of all connectors of the DRM device is
> traversed and all non-DisplayPort connectors are skipped, to find the
> one and only DisplayPort connect
On Tue, 2021-10-12 at 11:10 +0200, Thomas Hellström wrote:
> On Tue, 2021-10-12 at 10:27 +0200, Christian König wrote:
> > Am 11.10.21 um 14:04 schrieb Thomas Hellström:
> >
> > > >
>
> > > So now if this is going to be changed, I think we need to
> > > understand
> > > why and think this throug
Yes, this is expected behavior, even if it's not intuitive. For more
details, see:
https://gitlab.freedesktop.org/mesa/drm/-/merge_requests/110
Quoting Marijn Suijten (2021-10-11 13:16:40)
> div_u64_rem provides the result of the division and additionally the
> remainder; don't use this function to solely calculate the remainder
> while calculating the division again with div_u64.
>
> A similar improvement was applied earlier to the 10nm p
Test cases such as migrate_fault and migrate_multiple,
were modified to explicit migrate from device to sys memory
without the need of page faults, when using device coherent
type.
Snapshot test case updated to read memory device type
first and based on that, get the proper returned results
migrat
Add two more parameters to set spm_addr_dev0 & spm_addr_dev1
addresses. These two parameters configure the start SP
addresses for each device in test_hmm driver.
Consequently, this configures zone device type as coherent.
Signed-off-by: Alex Sierra
---
tools/testing/selftests/vm/test_hmm.sh | 20
Ref counter from device pages is init to zero during memmap init zone.
The first time a new device page is allocated to migrate data into it,
its ref counter needs to be initialized to one.
Signed-off-by: Alex Sierra
---
drivers/gpu/drm/amd/amdkfd/kfd_migrate.c | 3 ++-
1 file changed, 2 inserti
Device Coherent type uses device memory that is coherently accesible by
the CPU. This could be shown as SP (special purpose) memory range
at the BIOS-e820 memory enumeration. If no SP memory is supported in
system, this could be faked by setting CONFIG_EFI_FAKE_MEMMAP.
Currently, test_hmm only sup
In order to configure device coherent in test_hmm, two module parameters
should be passed, which correspond to the SP start address of each
device (2) spm_addr_dev0 & spm_addr_dev1. If no parameters are passed,
private device type is configured.
Signed-off-by: Alex Sierra
---
lib/test_hmm.c
new ioctl cmd added to query zone device type. This will be
used once the test_hmm adds zone device coherent type.
Signed-off-by: Alex Sierra
---
lib/test_hmm.c | 15 ++-
lib/test_hmm_uapi.h | 7 +++
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/lib/test_hm
Coherent device type memory on VRAM to RAM migration, has similar access
as System RAM from the CPU. This flag sets the source from the sender.
Which in Coherent type case, should be set as
MIGRATE_VMA_SELECT_DEVICE_COHERENT.
Signed-off-by: Alex Sierra
Reviewed-by: Felix Kuehling
---
drivers/gp
Device memory that is cache coherent from device and CPU point of view.
This is use on platform that have an advance system bus (like CAPI or
CCIX). Any page of a process can be migrated to such memory. However,
no one should be allow to pin such memory so that it can always be
evicted.
Signed-off
When CPU is connected throug XGMI, it has coherent
access to VRAM resource. In this case that resource
is taken from a table in the device gmc aperture base.
This resource is used along with the device type, which could
be DEVICE_PRIVATE or DEVICE_COHERENT to create the device
page map region.
Sig
This case is used to migrate pages from device memory, back to system
memory. Device coherent type memory is cache coherent from device and CPU
point of view.
Signed-off-by: Alex Sierra
---
v2:
condition added when migrations from device coherent pages.
---
include/linux/migrate.h | 1 +
mm/migr
From: Ralph Campbell
ZONE_DEVICE struct pages have an extra reference count that complicates the
code for put_page() and several places in the kernel that need to check the
reference count to see that a page is not being used (gup, compaction,
migration, etc.). Clean up the code so the reference
From: Ralph Campbell
There are several places where ZONE_DEVICE struct pages assume a reference
count == 1 means the page is idle and free. Instead of open coding this,
add a helper function to hide this detail.
Signed-off-by: Ralph Campbell
Signed-off-by: Alex Sierra
Reviewed-by: Christoph He
This patch series introduces MEMORY_DEVICE_COHERENT, a type of memory
owned by a device that can be mapped into CPU page tables like
MEMORY_DEVICE_GENERIC and can also be migrated like MEMORY_DEVICE_PRIVATE.
With MEMORY_DEVICE_COHERENT, we isolate the new memory type from other
subsystems as far as
On 12.10.2021 18:16, Jani Nikula wrote:
> On Mon, 11 Oct 2021, Matthew Brost wrote:
>> On Mon, Oct 11, 2021 at 08:51:03PM +0530, Thanneeru Srinivasulu wrote:
>>> Replace DRM_ERROR with CT_PROBE_ERROR to report early CTB failures.
>>>
>>> Signed-off-by: Thanneeru Srinivasulu
>>
>> Reviewed-by:
On Tue, 12 Oct 2021, Jani Nikula wrote:
> On Mon, 11 Oct 2021, Matthew Brost wrote:
>> On Mon, Oct 11, 2021 at 08:51:03PM +0530, Thanneeru Srinivasulu wrote:
>>> Replace DRM_ERROR with CT_PROBE_ERROR to report early CTB failures.
>>>
>>> Signed-off-by: Thanneeru Srinivasulu
>>
>> Reviewed-by: M
On Mon, 11 Oct 2021, Matthew Brost wrote:
> On Mon, Oct 11, 2021 at 08:51:03PM +0530, Thanneeru Srinivasulu wrote:
>> Replace DRM_ERROR with CT_PROBE_ERROR to report early CTB failures.
>>
>> Signed-off-by: Thanneeru Srinivasulu
>
> Reviewed-by: Matthew Brost
>
>> ---
>> drivers/gpu/drm/i915/g
On Sun, Oct 10, 2021 at 7:07 AM Christophe JAILLET
wrote:
>
> 'destroy_workqueue()' already drains the queue before destroying it, so
> there is no need to flush it explicitly.
>
> Remove the redundant 'flush_workqueue()' calls.
>
> This was generated with coccinelle:
>
> @@
> expression E;
> @@
>
On Tue, Oct 12, 2021 at 6:40 PM Uwe Kleine-König
wrote:
>
> fbtft_remove_common() is only called with a non-NULL fb_info. (All
> callers are in remove callbacks and the matching probe callbacks set
> driver data accordingly.) So fbtft_remove_common() always returns zero.
> Make it return void inst
On 12/10/2021 15:38, Tomi Valkeinen wrote:
> On 12/10/2021 16:23, Neil Armstrong wrote:
>
+ struct drm_private_obj glob_obj;
+
struct drm_fb_helper *fbdev;
struct workqueue_struct *wq;
@@ -88,5 +105,9 @@ struct omap_drm_private {
void omap_de
Hello,
this is v2 of my quest to make spi remove callbacks return void. Today
they return an int, but the only result of returning a non-zero value is
a warning message. So it's a bad idea to return an error code in the
expectation that not freeing some resources is ok then. The same holds
true fo
fbtft_remove_common() is only called with a non-NULL fb_info. (All
callers are in remove callbacks and the matching probe callbacks set
driver data accordingly.) So fbtft_remove_common() always returns zero.
Make it return void instead which makes it easier to see in the callers
that there is no er
Up to now s6e63m0_remove() returns zero unconditionally. Make it return
void instead which makes it easier to see in the callers that there is
no error to handle.
Also the return value of spi remove callbacks is ignored anyway.
Signed-off-by: Uwe Kleine-König
---
drivers/gpu/drm/panel/panel-sam
On 11.10.2021 20:00, Matthew Brost wrote:
> On Mon, Oct 11, 2021 at 08:51:06PM +0530, Thanneeru Srinivasulu wrote:
>> Inject probe errors -ENXIO, -EBUSY for CT send.
>>
>> Signed-off-by: Thanneeru Srinivasulu
>> ---
>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8
>> 1 file changed,
On Tue, Oct 12, 2021 at 04:47:24PM +0200, Thomas Hellström wrote:
> Hi,
>
> On 10/12/21 15:25, Colin King wrote:
> > From: Colin Ian King
> >
> > The assignment of pointer backup_bo dereferences pointer backup before
> > backup is null checked, this could lead to a null pointer dereference
> > i
Hi,
On 10/12/21 15:25, Colin King wrote:
From: Colin Ian King
The assignment of pointer backup_bo dereferences pointer backup before
backup is null checked, this could lead to a null pointer dereference
issue. Fix this by only assigning backup_bo after backup has been null
checked.
Addresses-
On 12/10/2021 15:34, Tomi Valkeinen wrote:
> On 23/09/2021 10:06, Neil Armstrong wrote:
>> From: Benoit Parrot
>>
>> (re)assign the hw overlays to planes based on required caps, and to
>> handle situations where we could not modify an in-use plane.
>>
>> This means all planes advertise the superse
Use the new link training delay helpers, fixing the delays for
128b/132b.
For existing 8b/10b functionality, this will cause additional 1-byte
DPCD reads for LTTPR delays instead of using the cached values. It's
just too complicated to combine generic helpers with local caching in a
sensible way.
The link training delays are different and/or available in different
DPCD offsets depending on:
- Clock recovery vs. channel equalization
- DPRX vs. LTTPR
- 128b/132b vs. 8b/10b
- DPCD 1.4+ vs. earlier
Add helpers to get the correct delays in us, reading DPCD if
necessary. This is more straightfo
Hi Yunfei Dong,
W dniu 11.10.2021 o 09:02, Yunfei Dong pisze:
This series adds support for multi hardware decode into mtk-vcodec, by first
adding use of_platform_populate to manage each hardware information: interrupt,
clock, register bases and power. Secondly add core thread to deal with core
h
On 2021-10-10 16:59, Christophe JAILLET wrote:
'destroy_workqueue()' already drains the queue before destroying it, so
there is no need to flush it explicitly.
Remove the redundant 'flush_workqueue()' calls.
This was generated with coccinelle:
@@
expression E;
@@
- flush_workqueue(E);
On Tue, Oct 5, 2021 at 10:11 AM Thomas Zimmermann wrote:
>
> struct gtt_range represents a GEM object and should not be used for GTT
> setup. Change psb_gtt_insert() and psb_gtt_remove() to receive all
> necessary parameters from their caller. This also eliminates possible
> failure from psb_gtt_i
1 - 100 of 157 matches
Mail list logo
