* Re: [PATCH v2 1/1] counter: cros_ec: Add synchronization sensor
From: Lee Jones @ 2019-09-02 9:40 UTC (permalink / raw)
To: Fabien Lahoudere
Cc: gwendal, egranata, kernel, William Breathitt Gray,
Jonathan Corbet, Benson Leung, Enric Balletbo i Serra,
Guenter Roeck, Jonathan Cameron, Hartmut Knaack,
Lars-Peter Clausen, Peter Meerwald-Stadler, Mauro Carvalho Chehab,
David S. Miller, Greg Kroah-Hartman, Nicolas Ferre, Nick Vaccaro,
linux-iio, linux-doc, linux-kernel
In-Reply-To: <d985a8a811996148e8cda78b9fe47bb87b884b56.1566563833.git.fabien.lahoudere@collabora.com>
On Fri, 23 Aug 2019, Fabien Lahoudere wrote:
> From: Gwendal Grignou <gwendal@chromium.org>
>
> EC returns a counter when there is an event on camera vsync.
> This patch comes from chromeos kernel 4.4
>
> Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
> Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
>
> CROS EC sync sensor was originally designed as an IIO device.
> Now that the counter subsystem will replace IIO_COUNTER, we
> have to implement a new way to get sync count.
>
> Signed-off-by: Fabien Lahoudere <fabien.lahoudere@collabora.com>
> ---
> Documentation/driver-api/generic-counter.rst | 3 +
> MAINTAINERS | 7 +
> drivers/counter/Kconfig | 9 +
> drivers/counter/Makefile | 1 +
> drivers/counter/counter.c | 2 +
> drivers/counter/cros_ec_sensors_sync.c | 208 ++++++++++++++++++
> .../cros_ec_sensors/cros_ec_sensors_core.c | 1 +
> drivers/mfd/cros_ec_dev.c | 3 +
I can't see any reason for this change to be squashed into this patch.
Please separate it out.
> include/linux/counter.h | 1 +
> 9 files changed, 235 insertions(+)
> create mode 100644 drivers/counter/cros_ec_sensors_sync.c
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] doc: kvm: fix return description of KVM_SET_MSRS
From: Xiaoyao Li @ 2019-09-02 10:12 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář
Cc: Xiaoyao Li, Jonathan Corbet, kvm, linux-doc, linux-kernel
Signed-off-by: Xiaoyao Li <xiaoyao.li@intel.com>
---
Documentation/virt/kvm/api.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/virt/kvm/api.txt b/Documentation/virt/kvm/api.txt
index 2d067767b617..a2efc19e0f4e 100644
--- a/Documentation/virt/kvm/api.txt
+++ b/Documentation/virt/kvm/api.txt
@@ -586,7 +586,7 @@ Capability: basic
Architectures: x86
Type: vcpu ioctl
Parameters: struct kvm_msrs (in)
-Returns: 0 on success, -1 on error
+Returns: number of msrs successfully set, -1 on error
Writes model-specific registers to the vcpu. See KVM_GET_MSRS for the
data structures.
--
2.19.1
^ permalink raw reply related
* [PATCH 1/5] drm/ttm: add drm_gem_ttm_print_info()
From: Gerd Hoffmann @ 2019-09-02 12:41 UTC (permalink / raw)
To: dri-devel
Cc: Gerd Hoffmann, David Airlie, Daniel Vetter, Maarten Lankhorst,
Maxime Ripard, Sean Paul, Jonathan Corbet,
open list:DOCUMENTATION, open list
In-Reply-To: <20190902124126.7700-1-kraxel@redhat.com>
Now with ttm_buffer_object being a subclass of drm_gem_object we can
easily lookup ttm_buffer_object for a given drm_gem_object, which in
turm allows to create common helper functions.
This patch starts off with a drm_gem_ttm_print_info() helper function
which prints adds some ttm specific lines to the debug output.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
include/drm/drm_gem_ttm_helper.h | 19 ++++++++
drivers/gpu/drm/drm_gem_ttm_helper.c | 67 ++++++++++++++++++++++++++++
Documentation/gpu/drm-mm.rst | 12 +++++
drivers/gpu/drm/Kconfig | 7 +++
drivers/gpu/drm/Makefile | 3 ++
5 files changed, 108 insertions(+)
create mode 100644 include/drm/drm_gem_ttm_helper.h
create mode 100644 drivers/gpu/drm/drm_gem_ttm_helper.c
diff --git a/include/drm/drm_gem_ttm_helper.h b/include/drm/drm_gem_ttm_helper.h
new file mode 100644
index 000000000000..6268f89c5a48
--- /dev/null
+++ b/include/drm/drm_gem_ttm_helper.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#ifndef DRM_GEM_TTM_HELPER_H
+#define DRM_GEM_TTM_HELPER_H
+
+#include <linux/kernel.h>
+
+#include <drm/drm_gem.h>
+#include <drm/drm_device.h>
+#include <drm/ttm/ttm_bo_api.h>
+#include <drm/ttm/ttm_bo_driver.h>
+
+#define drm_gem_ttm_of_gem(gem_obj) \
+ container_of(gem_obj, struct ttm_buffer_object, base)
+
+void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent,
+ const struct drm_gem_object *gem);
+
+#endif
diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c b/drivers/gpu/drm/drm_gem_ttm_helper.c
new file mode 100644
index 000000000000..cd6ac2cc8fdd
--- /dev/null
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include <linux/module.h>
+
+#include <drm/drm_gem_ttm_helper.h>
+
+/**
+ * DOC: overview
+ *
+ * This library provides helper functions for gem objects backed by
+ * ttm.
+ */
+
+/**
+ * drm_gem_ttm_print_info() - Print &ttm_buffer_object info for debugfs
+ * @p: DRM printer
+ * @indent: Tab indentation level
+ * @gem: GEM object
+ *
+ * This function can be used as the &drm_driver->gem_print_info callback.
+ */
+void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent,
+ const struct drm_gem_object *gem)
+{
+ static const char *plname[] = {
+ [ TTM_PL_SYSTEM ] = "system",
+ [ TTM_PL_TT ] = "tt",
+ [ TTM_PL_VRAM ] = "vram",
+ [ TTM_PL_PRIV ] = "priv",
+
+ [ 16 ] = "cached",
+ [ 17 ] = "uncached",
+ [ 18 ] = "wc",
+ [ 19 ] = "contig",
+
+ [ 21 ] = "pinned", /* NO_EVICT */
+ [ 22 ] = "topdown",
+ };
+ const struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+ bool first = true;
+ unsigned int i;
+
+ for (i = 0; i < ARRAY_SIZE(plname); i++) {
+ if (!(bo->mem.placement & (1 << i)))
+ continue;
+ if (!plname[i])
+ continue;
+ if (first) {
+ first = false;
+ drm_printf_indent(p, indent, "placement=%s", plname[i]);
+ } else
+ drm_printf(p, ",%s", plname[i]);
+ }
+ if (!first)
+ drm_printf(p, "\n");
+
+ if (bo->mem.bus.is_iomem) {
+ drm_printf_indent(p, indent, "bus.base=%lx\n",
+ (unsigned long)bo->mem.bus.base);
+ drm_printf_indent(p, indent, "bus.offset=%lx\n",
+ (unsigned long)bo->mem.bus.offset);
+ }
+}
+EXPORT_SYMBOL(drm_gem_ttm_print_info);
+
+MODULE_DESCRIPTION("DRM gem ttm helpers");
+MODULE_LICENSE("GPL");
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index b664f054c259..a70a1d9f30ec 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -412,6 +412,18 @@ VRAM MM Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_vram_mm_helper.c
:export:
+GEM TTM Helper Functions Reference
+-----------------------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/drm_gem_ttm_helper.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
+ :export:
+
VMA Offset Manager
==================
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index e6f40fb54c9a..f7b25519f95c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -172,6 +172,13 @@ config DRM_VRAM_HELPER
help
Helpers for VRAM memory management
+config DRM_TTM_HELPER
+ tristate
+ depends on DRM
+ select DRM_TTM
+ help
+ Helpers for ttm-based gem objects
+
config DRM_GEM_CMA_HELPER
bool
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 10f8329a8b71..545c61d6528b 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -37,6 +37,9 @@ drm_vram_helper-y := drm_gem_vram_helper.o \
drm_vram_mm_helper.o
obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
+drm_ttm_helper-y := drm_gem_ttm_helper.o
+obj-$(CONFIG_DRM_TTM_HELPER) += drm_ttm_helper.o
+
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
--
2.18.1
^ permalink raw reply related
* Re: [PATCH v4 01/10] KVM: arm64: Document PV-time interface
From: Andrew Jones @ 2019-09-02 12:52 UTC (permalink / raw)
To: Steven Price
Cc: Mark Rutland, kvm, Radim Krčmář, Marc Zyngier,
Suzuki K Pouloze, linux-doc, Russell King, linux-kernel,
James Morse, Julien Thierry, Catalin Marinas, Paolo Bonzini,
Will Deacon, kvmarm, linux-arm-kernel
In-Reply-To: <7f459290-9c39-cfba-c514-a07469ff120f@arm.com>
On Fri, Aug 30, 2019 at 04:25:08PM +0100, Steven Price wrote:
> On 30/08/2019 15:47, Andrew Jones wrote:
> > On Fri, Aug 30, 2019 at 09:42:46AM +0100, Steven Price wrote:
> >> Introduce a paravirtualization interface for KVM/arm64 based on the
> >> "Arm Paravirtualized Time for Arm-Base Systems" specification DEN 0057A.
> >>
> >> This only adds the details about "Stolen Time" as the details of "Live
> >> Physical Time" have not been fully agreed.
> >>
> >> User space can specify a reserved area of memory for the guest and
> >> inform KVM to populate the memory with information on time that the host
> >> kernel has stolen from the guest.
> >>
> >> A hypercall interface is provided for the guest to interrogate the
> >> hypervisor's support for this interface and the location of the shared
> >> memory structures.
> >>
> >> Signed-off-by: Steven Price <steven.price@arm.com>
> >> ---
> >> Documentation/virt/kvm/arm/pvtime.txt | 64 +++++++++++++++++++++++++
> >> Documentation/virt/kvm/devices/vcpu.txt | 14 ++++++
> >> 2 files changed, 78 insertions(+)
> >> create mode 100644 Documentation/virt/kvm/arm/pvtime.txt
> >>
> >> diff --git a/Documentation/virt/kvm/arm/pvtime.txt b/Documentation/virt/kvm/arm/pvtime.txt
> >> new file mode 100644
> >> index 000000000000..dda3f0f855b9
> >> --- /dev/null
> >> +++ b/Documentation/virt/kvm/arm/pvtime.txt
> >> @@ -0,0 +1,64 @@
> >> +Paravirtualized time support for arm64
> >> +======================================
> >> +
> >> +Arm specification DEN0057/A defined a standard for paravirtualised time
> >> +support for AArch64 guests:
> >> +
> >> +https://developer.arm.com/docs/den0057/a
> >> +
> >> +KVM/arm64 implements the stolen time part of this specification by providing
> >> +some hypervisor service calls to support a paravirtualized guest obtaining a
> >> +view of the amount of time stolen from its execution.
> >> +
> >> +Two new SMCCC compatible hypercalls are defined:
> >> +
> >> +PV_FEATURES 0xC5000020
> >> +PV_TIME_ST 0xC5000022
> >> +
> >> +These are only available in the SMC64/HVC64 calling convention as
> >> +paravirtualized time is not available to 32 bit Arm guests. The existence of
> >> +the PV_FEATURES hypercall should be probed using the SMCCC 1.1 ARCH_FEATURES
> >> +mechanism before calling it.
> >> +
> >> +PV_FEATURES
> >> + Function ID: (uint32) : 0xC5000020
> >> + PV_func_id: (uint32) : Either PV_TIME_LPT or PV_TIME_ST
> >
> > PV_TIME_LPT doesn't exist
>
> Thanks, will remove.
>
> >> + Return value: (int32) : NOT_SUPPORTED (-1) or SUCCESS (0) if the relevant
> >> + PV-time feature is supported by the hypervisor.
> >> +
> >> +PV_TIME_ST
> >> + Function ID: (uint32) : 0xC5000022
> >> + Return value: (int64) : IPA of the stolen time data structure for this
> >> + VCPU. On failure:
> >> + NOT_SUPPORTED (-1)
> >> +
> >> +The IPA returned by PV_TIME_ST should be mapped by the guest as normal memory
> >> +with inner and outer write back caching attributes, in the inner shareable
> >> +domain. A total of 16 bytes from the IPA returned are guaranteed to be
> >> +meaningfully filled by the hypervisor (see structure below).
> >> +
> >> +PV_TIME_ST returns the structure for the calling VCPU.
> >> +
> >> +Stolen Time
> >> +-----------
> >> +
> >> +The structure pointed to by the PV_TIME_ST hypercall is as follows:
> >> +
> >> + Field | Byte Length | Byte Offset | Description
> >> + ----------- | ----------- | ----------- | --------------------------
> >> + Revision | 4 | 0 | Must be 0 for version 0.1
> >> + Attributes | 4 | 4 | Must be 0
> >
> > The above fields don't appear to be exposed to userspace in anyway. How
> > will we handle migration from one KVM with one version of the structure
> > to another?
>
> Interesting question. User space does have access to them now it is
> providing the memory, but it's not exactly an easy method. In particular
> user space has no (simple) way of probing the kernel's supported version.
>
> I guess one solution would be to add an extra attribute on the VCPU
> which would provide the revision information. The current kernel would
> then reject any revision other than 0, but this could then be extended
> to support other revision numbers in the future.
>
> Although there's some logic in saying we could add the extra attribute
> when(/if) there is a new version. Future kernels would then be expected
> to use the current version unless user space explicitly set the new
> attribute.
>
> Do you feel this is something that needs to be addressed now, or can it
> be deferred until another version is proposed?
Assuming we'll want userspace to have the option of choosing version=0,
and that we're fine with version=0 being the implicit choice, when nothing
is selected, then I guess it can be left as is for now. If, OTOH, we just
want migration to fail when attempting to migrate to another host with
an incompatible stolen-time structure (i.e. version=0 is not selectable
on hosts that implement later versions), then we should expose the version
in some way now. Perhaps a VCPU's "PV config" should be described in a
set of pseudo registers?
>
> >> + Stolen time | 8 | 8 | Stolen time in unsigned
> >> + | | | nanoseconds indicating how
> >> + | | | much time this VCPU thread
> >> + | | | was involuntarily not
> >> + | | | running on a physical CPU.
> >> +
> >> +The structure will be updated by the hypervisor prior to scheduling a VCPU. It
> >> +will be present within a reserved region of the normal memory given to the
> >> +guest. The guest should not attempt to write into this memory. There is a
> >> +structure per VCPU of the guest.
> >
> > Should we provide a recommendation as to how that reserved memory is
> > provided? One memslot divided into NR_VCPUS subregions? Should the
> > reserved region be described to the guest kernel with DT/ACPI? Or
> > should userspace ensure the region is not within any DT/ACPI described
> > regions?
>
> I'm open to providing a recommendation, but I'm not entirely sure I know
> enough here to provide one.
>
> There is an obvious efficiency argument for minimizing memslots with the
> current code. But if someone has a reason for using multiple memslots
> then that's probably a good argument for implementing a memslot-caching
> kvm_put_user() rather than to be dis-recommended.
Actually even if a single memslot is used for all the PV structures for
all VCPUs, but it's separate from the slot(s) used for main memory, then
we'll likely see performance issues with memslot searches (even though
it's a binary search). This is because memslots already have caching. The
last used slot is stored in the memslots' lru_slot member (the "lru" name
is confusing, but it means "last used" somehow). This means we could get
thrashing on that slot cache if we're searching for the PV structure
memslot on each vcpu load after searching for the main memory slot on each
page fault.
>
> My assumption (and testing) has been with a single memslot divided into
> NR_VCPUS (or more accurately the number of VCPUs in the VM) subregions.
>
> For testing DT I've tested both methods: an explicit reserved region or
> just ensuring it's not in any DT described region. Both seem reasonable,
> but it might be easier to integrate into existing migration mechanisms
> if it's simply a reserved region (then the memory block of the guest is
> just as it always was).
>
> For ACPI the situation should be similar, but my testing has been with DT.
I also can't think of any reason why we'd have to describe it in DT/ACPI,
but I get this feeling that if we don't, then we'll hit some issue that
will make us wish we had...
Thanks,
drew
^ permalink raw reply
* Re: [PATCH v4 02/10] KVM: arm/arm64: Factor out hypercall handling from PSCI code
From: kbuild test robot @ 2019-09-02 13:07 UTC (permalink / raw)
To: Steven Price
Cc: kbuild-all, Marc Zyngier, Will Deacon, linux-arm-kernel, kvmarm,
Steven Price, Catalin Marinas, Paolo Bonzini,
Radim =?unknown-8bit?B?S3LEjW3DocWZ?=, Russell King, James Morse,
Julien Thierry, Suzuki K Pouloze, Mark Rutland, kvm, linux-doc,
linux-kernel, Christoffer Dall
In-Reply-To: <20190830084255.55113-3-steven.price@arm.com>
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
Hi Steven,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3-rc6 next-20190830]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Steven-Price/arm64-Stolen-time-support/20190901-185152
config: c6x-allyesconfig (attached as .config)
compiler: c6x-elf-gcc (GCC) 7.4.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=c6x
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
In file included from <command-line>:0:0:
>> include/kvm/arm_hypercalls.h:7:10: fatal error: asm/kvm_emulate.h: No such file or directory
#include <asm/kvm_emulate.h>
^~~~~~~~~~~~~~~~~~~
compilation terminated.
vim +7 include/kvm/arm_hypercalls.h
6
> 7 #include <asm/kvm_emulate.h>
8
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 49715 bytes --]
^ permalink raw reply
* Re: [PATCH v2] docs: ftrace: clarify when tracing is disabled by the trace file
From: Jonathan Corbet @ 2019-09-02 13:14 UTC (permalink / raw)
To: Steven Rostedt
Cc: Peter Wu, Ingo Molnar, linux-doc, linux-kernel,
Alexei Starovoitov
In-Reply-To: <20190831115835.0a03b914@oasis.local.home>
On Sat, 31 Aug 2019 11:58:35 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
>
> Jon care to take this in your tree?
Will do.
jon
^ permalink raw reply
* Re: [PATCH v2] dma-mapping: Fix filename references
From: Andy Shevchenko @ 2019-09-02 13:22 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Thomas Gleixner, Ingo Molnar, Borislav Petkov, x86,
H. Peter Anvin, Tony Luck, Fenghua Yu, Konrad Rzeszutek Wilk,
linux-doc, Bjorn Helgaas
In-Reply-To: <20190813144536.GA7961@lst.de>
On Tue, Aug 13, 2019 at 04:45:36PM +0200, Christoph Hellwig wrote:
> On Tue, Aug 13, 2019 at 05:42:22PM +0300, Andy Shevchenko wrote:
> > On Wed, Jun 19, 2019 at 05:19:55PM +0300, Andy Shevchenko wrote:
> > > After the commit cf65a0f6f6ff
> > >
> > > ("dma-mapping: move all DMA mapping code to kernel/dma")
> > >
> > > some of the files are referring to outdated information, i.e. old file names
> > > of DMA mapping sources.
> > >
> > > Fix it here.
> > >
> > > Note, the lines with "Glue code for..." have been removed completely.
> >
> > Any comment on this?
>
> Fine with me, and I also agree with the glue code comment.
Are you going to apply this?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/5] drm/ttm: add drm_gem_ttm_print_info()
From: Thomas Zimmermann @ 2019-09-02 14:19 UTC (permalink / raw)
To: Gerd Hoffmann, dri-devel
Cc: Jonathan Corbet, David Airlie, open list:DOCUMENTATION, open list,
Maxime Ripard, Sean Paul
In-Reply-To: <20190902124126.7700-2-kraxel@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 6274 bytes --]
Hi
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
But please see below.
Am 02.09.19 um 14:41 schrieb Gerd Hoffmann:
> Now with ttm_buffer_object being a subclass of drm_gem_object we can
> easily lookup ttm_buffer_object for a given drm_gem_object, which in
> turm allows to create common helper functions.
s/trum/trun
>
> This patch starts off with a drm_gem_ttm_print_info() helper function
> which prints adds some ttm specific lines to the debug output.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
> include/drm/drm_gem_ttm_helper.h | 19 ++++++++
> drivers/gpu/drm/drm_gem_ttm_helper.c | 67 ++++++++++++++++++++++++++++
> Documentation/gpu/drm-mm.rst | 12 +++++
> drivers/gpu/drm/Kconfig | 7 +++
> drivers/gpu/drm/Makefile | 3 ++
> 5 files changed, 108 insertions(+)
> create mode 100644 include/drm/drm_gem_ttm_helper.h
> create mode 100644 drivers/gpu/drm/drm_gem_ttm_helper.c
>
> diff --git a/include/drm/drm_gem_ttm_helper.h b/include/drm/drm_gem_ttm_helper.h
> new file mode 100644
> index 000000000000..6268f89c5a48
> --- /dev/null
> +++ b/include/drm/drm_gem_ttm_helper.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
> +#ifndef DRM_GEM_TTM_HELPER_H
> +#define DRM_GEM_TTM_HELPER_H
> +
> +#include <linux/kernel.h>
> +
> +#include <drm/drm_gem.h>
> +#include <drm/drm_device.h>
> +#include <drm/ttm/ttm_bo_api.h>
> +#include <drm/ttm/ttm_bo_driver.h>
> +
> +#define drm_gem_ttm_of_gem(gem_obj) \
> + container_of(gem_obj, struct ttm_buffer_object, base)
> +
> +void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent,
> + const struct drm_gem_object *gem);
> +
> +#endif
> diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c b/drivers/gpu/drm/drm_gem_ttm_helper.c
> new file mode 100644
> index 000000000000..cd6ac2cc8fdd
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
> @@ -0,0 +1,67 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +#include <linux/module.h>
> +
> +#include <drm/drm_gem_ttm_helper.h>
> +
> +/**
> + * DOC: overview
> + *
> + * This library provides helper functions for gem objects backed by
> + * ttm.
> + */
> +
> +/**
> + * drm_gem_ttm_print_info() - Print &ttm_buffer_object info for debugfs
> + * @p: DRM printer
> + * @indent: Tab indentation level
> + * @gem: GEM object
> + *
> + * This function can be used as the &drm_driver->gem_print_info callback.
> + */
> +void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent,
> + const struct drm_gem_object *gem)
> +{
> + static const char *plname[] = {
The array and the strings should be declared const. IIRC something like
static const char * const plname[] = {
> + [ TTM_PL_SYSTEM ] = "system",
> + [ TTM_PL_TT ] = "tt",
> + [ TTM_PL_VRAM ] = "vram",
> + [ TTM_PL_PRIV ] = "priv",
> +
This 'gap' in the array seems to be a problem for drivers that use these
bits. Could the print logic be moved into s separate function that also
takes the array as an argument?
Best regards
Thomas
> + [ 16 ] = "cached",
> + [ 17 ] = "uncached",
> + [ 18 ] = "wc",
> + [ 19 ] = "contig",
> +
> + [ 21 ] = "pinned", /* NO_EVICT */
> + [ 22 ] = "topdown",
> + };
> + const struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
> + bool first = true;
> + unsigned int i;
> +
> + for (i = 0; i < ARRAY_SIZE(plname); i++) {
> + if (!(bo->mem.placement & (1 << i)))
> + continue;
> + if (!plname[i])
> + continue;
> + if (first) {
> + first = false;
> + drm_printf_indent(p, indent, "placement=%s", plname[i]);
> + } else
> + drm_printf(p, ",%s", plname[i]);
> + }
> + if (!first)
> + drm_printf(p, "\n");
> +
> + if (bo->mem.bus.is_iomem) {
> + drm_printf_indent(p, indent, "bus.base=%lx\n",
> + (unsigned long)bo->mem.bus.base);
> + drm_printf_indent(p, indent, "bus.offset=%lx\n",
> + (unsigned long)bo->mem.bus.offset);
> + }
> +}
> +EXPORT_SYMBOL(drm_gem_ttm_print_info);
> +
> +MODULE_DESCRIPTION("DRM gem ttm helpers");
> +MODULE_LICENSE("GPL");
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index b664f054c259..a70a1d9f30ec 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -412,6 +412,18 @@ VRAM MM Helper Functions Reference
> .. kernel-doc:: drivers/gpu/drm/drm_vram_mm_helper.c
> :export:
>
> +GEM TTM Helper Functions Reference
> +-----------------------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
> + :doc: overview
> +
> +.. kernel-doc:: include/drm/drm_gem_ttm_helper.h
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
> + :export:
> +
> VMA Offset Manager
> ==================
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index e6f40fb54c9a..f7b25519f95c 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -172,6 +172,13 @@ config DRM_VRAM_HELPER
> help
> Helpers for VRAM memory management
>
> +config DRM_TTM_HELPER
> + tristate
> + depends on DRM
> + select DRM_TTM
> + help
> + Helpers for ttm-based gem objects
> +
> config DRM_GEM_CMA_HELPER
> bool
> depends on DRM
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 10f8329a8b71..545c61d6528b 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -37,6 +37,9 @@ drm_vram_helper-y := drm_gem_vram_helper.o \
> drm_vram_mm_helper.o
> obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
>
> +drm_ttm_helper-y := drm_gem_ttm_helper.o
> +obj-$(CONFIG_DRM_TTM_HELPER) += drm_ttm_helper.o
> +
> drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany
GF: Felix Imendörffer, Mary Higgins, Sri Rasiah
HRB 21284 (AG Nürnberg)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 484 bytes --]
^ permalink raw reply
* Re: [PATCH] doc:lock: remove reference to clever use of read-write lock
From: Ingo Molnar @ 2019-09-02 18:10 UTC (permalink / raw)
To: Federico Vaga
Cc: Jonathan Corbet, Peter Zijlstra, Ingo Molnar, Will Deacon,
linux-kernel, linux-doc
In-Reply-To: <2216492.xyESGPMPG3@pcbe13614>
* Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> On Saturday, August 31, 2019 4:43:44 PM CEST Jonathan Corbet wrote:
> > On Sat, 31 Aug 2019 15:41:16 +0200
> >
> > Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> > > several CPU's and you want to use spinlocks you can potentially use
> > >
> > > -cheaper versions of the spinlocks. IFF you know that the spinlocks are
> > > +cheaper versions of the spinlocks. If you know that the spinlocks are
> > >
> > > never used in interrupt handlers, you can use the non-irq versions::
> > I suspect that was not actually a typo; "iff" is a way for the
> > mathematically inclined to say "if and only if".
> >
> > jon
>
> I learned something new today :)
>
> I am not used to the mathematical English jargon. It make sense, but then I
> would replace it with "If and only if": for clarity.
While it's used in a number of places and it's pretty common wording
overall in the literature, I agree that we should probably change this in
locking API user facing documentation.
If you change it, please do it in both places it's used.
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] doc:lock: remove reference to clever use of read-write lock
From: Federico Vaga @ 2019-09-02 19:19 UTC (permalink / raw)
To: Ingo Molnar
Cc: Jonathan Corbet, Peter Zijlstra, Ingo Molnar, Will Deacon,
linux-kernel, linux-doc
In-Reply-To: <20190902181010.GA35858@gmail.com>
On Monday, September 2, 2019 8:10:10 PM CEST Ingo Molnar wrote:
> * Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> > On Saturday, August 31, 2019 4:43:44 PM CEST Jonathan Corbet wrote:
> > > On Sat, 31 Aug 2019 15:41:16 +0200
> > >
> > > Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> > > > several CPU's and you want to use spinlocks you can potentially use
> > > >
> > > > -cheaper versions of the spinlocks. IFF you know that the spinlocks
> > > > are
> > > > +cheaper versions of the spinlocks. If you know that the spinlocks are
> > > >
> > > > never used in interrupt handlers, you can use the non-irq versions::
> > > I suspect that was not actually a typo; "iff" is a way for the
> > > mathematically inclined to say "if and only if".
> > >
> > > jon
> >
> > I learned something new today :)
> >
> > I am not used to the mathematical English jargon. It make sense, but then
> > I
> > would replace it with "If and only if": for clarity.
>
> While it's used in a number of places and it's pretty common wording
> overall in the literature, I agree that we should probably change this in
> locking API user facing documentation.
I would say not only in locking/. The argument is valid for the entire
Documentation/. I wait for Jon's opinion before proceeding.
> If you change it, please do it in both places it's used.
>
> Thanks,
>
> Ingo
^ permalink raw reply
* Re: [PATCH] doc:lock: remove reference to clever use of read-write lock
From: Jonathan Corbet @ 2019-09-02 20:21 UTC (permalink / raw)
To: Federico Vaga
Cc: Ingo Molnar, Peter Zijlstra, Ingo Molnar, Will Deacon,
linux-kernel, linux-doc
In-Reply-To: <4627860.yBeiQmOknq@harkonnen>
On Mon, 02 Sep 2019 21:19:24 +0200
Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> > > I am not used to the mathematical English jargon. It make sense, but then
> > > I
> > > would replace it with "If and only if": for clarity.
> >
> > While it's used in a number of places and it's pretty common wording
> > overall in the literature, I agree that we should probably change this in
> > locking API user facing documentation.
>
> I would say not only in locking/. The argument is valid for the entire
> Documentation/. I wait for Jon's opinion before proceeding.
I don't really have a problem with "iff"; it doesn't seem like *that*
obscure a term to me. But if you want spell it out, I guess I don't have
a problem with that. We can change it - iff you send a patch to do it :)
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] doc:lock: remove reference to clever use of read-write lock
From: Federico Vaga @ 2019-09-02 21:07 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Ingo Molnar, Peter Zijlstra, Ingo Molnar, Will Deacon,
linux-kernel, linux-doc
In-Reply-To: <20190902142133.37e106af@lwn.net>
On Monday, September 2, 2019 10:21:33 PM CEST Jonathan Corbet wrote:
> On Mon, 02 Sep 2019 21:19:24 +0200
>
> Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> > > > I am not used to the mathematical English jargon. It make sense, but
> > > > then
> > > > I
> > > > would replace it with "If and only if": for clarity.
> > >
> > > While it's used in a number of places and it's pretty common wording
> > > overall in the literature, I agree that we should probably change this
> > > in
> > > locking API user facing documentation.
> >
> > I would say not only in locking/. The argument is valid for the entire
> > Documentation/. I wait for Jon's opinion before proceeding.
>
> I don't really have a problem with "iff"; it doesn't seem like *that*
> obscure a term to me. But if you want spell it out, I guess I don't have
> a problem with that. We can change it - iff you send a patch to do it :)
I do not mind too, once I got the meaning of IFF to *me* is clear and
translatable to SSE (i will not).
My opinion is that abbreviations should not be used in general. But it is a
weak opinion. I can do, and send, a patch
>
> Thanks,
>
> jon
^ permalink raw reply
* Re: [PATCH] doc:lock: remove reference to clever use of read-write lock
From: Matthew Wilcox @ 2019-09-03 2:38 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Federico Vaga, Ingo Molnar, Peter Zijlstra, Ingo Molnar,
Will Deacon, linux-kernel, linux-doc
In-Reply-To: <20190902142133.37e106af@lwn.net>
On Mon, Sep 02, 2019 at 02:21:33PM -0600, Jonathan Corbet wrote:
> On Mon, 02 Sep 2019 21:19:24 +0200
> Federico Vaga <federico.vaga@vaga.pv.it> wrote:
>
> > > > I am not used to the mathematical English jargon. It make sense, but then
> > > > I
> > > > would replace it with "If and only if": for clarity.
> > >
> > > While it's used in a number of places and it's pretty common wording
> > > overall in the literature, I agree that we should probably change this in
> > > locking API user facing documentation.
> >
> > I would say not only in locking/. The argument is valid for the entire
> > Documentation/. I wait for Jon's opinion before proceeding.
>
> I don't really have a problem with "iff"; it doesn't seem like *that*
> obscure a term to me. But if you want spell it out, I guess I don't have
> a problem with that. We can change it - iff you send a patch to do it :)
$ git grep -iwc iff Documentation
Documentation/admin-guide/cgroup-v1/blkio-controller.rst:1
Documentation/admin-guide/cgroup-v1/cgroups.rst:1
Documentation/admin-guide/cgroup-v1/freezer-subsystem.rst:2
Documentation/admin-guide/cgroup-v2.rst:1
Documentation/devicetree/bindings/media/st-rc.txt:2
Documentation/devicetree/bindings/net/ibm,emac.txt:5
Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt:1
Documentation/driver-api/libata.rst:1
Documentation/features/scripts/features-refresh.sh:1
Documentation/filesystems/directory-locking:1
Documentation/i2c/i2c-topology:3
Documentation/ioctl/hdio.rst:1
Documentation/locking/spinlocks.rst:1
Documentation/locking/ww-mutex-design.rst:1
Documentation/scsi/scsi_eh.txt:2
Documentation/spi/spidev:2
Documentation/trace/ring-buffer-design.txt:1
Documentation/virt/kvm/api.txt:1
Documentation/virt/kvm/halt-polling.txt:1
(29 total)
Of course that doesn't count any in kernel-doc.
^ permalink raw reply
* [PATCH] doc: arm64: fix grammar dtb placed in no attributes region
From: lixianfa @ 2019-09-03 3:07 UTC (permalink / raw)
To: harryxiyou, alex.shi
Cc: corbet, robh, mchehab+samsung, linux-doc, linux-kernel
Fix grammar dtb placed in no attributes region.
This makes Chinese translation smooth to read.
Signed-off-by: lixinafa <lixinafa.official@gmail.com>
---
Documentation/translations/zh_CN/arm64/booting.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/translations/zh_CN/arm64/booting.txt b/Documentation/translations/zh_CN/arm64/booting.txt
index 4e373d1..5b01641 100644
--- a/Documentation/translations/zh_CN/arm64/booting.txt
+++ b/Documentation/translations/zh_CN/arm64/booting.txt
@@ -67,8 +67,8 @@ RAM，或可能使用对这个设备已知的 RAM 信息，还可能是引导装
必要性: 强制
设备树数据块（dtb）必须 8 字节对齐，且大小不能超过 2MB。由于设备树
-数据块将在使能缓存的情况下以 2MB 粒度被映射，故其不能被置于带任意
-特定属性被映射的 2MB 区域内。
+数据块将在使能缓存的情况下以 2MB 粒度被映射，故其不能被置于必须以特定
+属性映射的2M区域内。
注： v4.2 之前的版本同时要求设备树数据块被置于从内核映像以下
text_offset 字节处算起第一个 512MB 内。
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3 2/2] kbuild: rename KBUILD_ENABLE_EXTRA_GCC_CHECKS to KBUILD_EXTRA_WARN
From: Nathan Chancellor @ 2019-09-03 5:37 UTC (permalink / raw)
To: Masahiro Yamada
Cc: linux-kbuild, Nick Desaulniers, Sedat Dilek, Jonathan Corbet,
Michal Marek, clang-built-linux, linux-doc, linux-kernel
In-Reply-To: <20190831162555.31887-2-yamada.masahiro@socionext.com>
On Sun, Sep 01, 2019 at 01:25:55AM +0900, Masahiro Yamada wrote:
> KBUILD_ENABLE_EXTRA_GCC_CHECKS started as a switch to add extra warning
> options for GCC, but now it is a historical misnomer since we use it
> also for Clang, DTC, and even kernel-doc.
>
> Rename it to more sensible, and shorter KBUILD_EXTRA_WARN.
>
> For the backward compatibility, KBUILD_ENABLE_EXTRA_GCC_CHECKS is still
> supported (but not advertised in the documentation).
>
> I also fixed up 'make help', and updated the documentation.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/5] drm/ttm: add drm_gem_ttm_print_info()
From: Gerd Hoffmann @ 2019-09-03 6:15 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: dri-devel, Jonathan Corbet, David Airlie, open list:DOCUMENTATION,
open list, Maxime Ripard, Sean Paul
In-Reply-To: <199bbf8d-68bc-ea99-723e-3b88045970c4@suse.de>
Hi,
> > + [ TTM_PL_SYSTEM ] = "system",
> > + [ TTM_PL_TT ] = "tt",
> > + [ TTM_PL_VRAM ] = "vram",
> > + [ TTM_PL_PRIV ] = "priv",
> > +
>
> This 'gap' in the array seems to be a problem for drivers that use these
> bits. Could the print logic be moved into s separate function that also
> takes the array as an argument?
Are there any drivers which actually use these bits and which therefore
might want to use a different array?
Also note they should not cause any problems (other than not being
printed). There is an explicit check here ...
> > + if (!plname[i])
> > + continue;
.. to skip unknown bits.
cheers,
Gerd
^ permalink raw reply
* Re: [PATCH v2] dma-mapping: Fix filename references
From: Christoph Hellwig @ 2019-09-03 6:37 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Christoph Hellwig, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
x86, H. Peter Anvin, Tony Luck, Fenghua Yu, Konrad Rzeszutek Wilk,
linux-doc, Bjorn Helgaas
In-Reply-To: <20190902132250.GM2680@smile.fi.intel.com>
On Mon, Sep 02, 2019 at 04:22:50PM +0300, Andy Shevchenko wrote:
> > > Any comment on this?
> >
> > Fine with me, and I also agree with the glue code comment.
>
> Are you going to apply this?
Thanks, applied to the dma-mapping tree for 5.4.
^ permalink raw reply
* Re: [PATCH v4 00/10] arm64: Stolen time support
From: Andrew Jones @ 2019-09-03 8:03 UTC (permalink / raw)
To: Steven Price
Cc: Marc Zyngier, Will Deacon, linux-arm-kernel, kvmarm,
Catalin Marinas, Paolo Bonzini, Radim Krčmář,
Russell King, James Morse, Julien Thierry, Suzuki K Pouloze,
Mark Rutland, kvm, linux-doc, linux-kernel
In-Reply-To: <20190830084255.55113-1-steven.price@arm.com>
On Fri, Aug 30, 2019 at 09:42:45AM +0100, Steven Price wrote:
> This series add support for paravirtualized time for arm64 guests and
> KVM hosts following the specification in Arm's document DEN 0057A:
>
> https://developer.arm.com/docs/den0057/a
>
> It implements support for stolen time, allowing the guest to
> identify time when it is forcibly not executing.
>
> It doesn't implement support for Live Physical Time (LPT) as there are
> some concerns about the overheads and approach in the above
> specification, and I expect an updated version of the specification to
> be released soon with just the stolen time parts.
>
> NOTE: Patches 8 and 9 will conflict with Mark Rutland's series[1] cleaning
> up the SMCCC conduit. I do feel that the addition of an _invoke() call
> makes a number of call sites cleaner and it should be possible to
> integrate both this and Mark's other cleanups.
>
> [1] https://lore.kernel.org/linux-arm-kernel/20190809132245.43505-1-mark.rutland@arm.com/
>
> Also available as a git tree:
> git://linux-arm.org/linux-sp.git stolen_time/v4
>
> Changes from v3:
> https://lore.kernel.org/lkml/20190821153656.33429-1-steven.price@arm.com/
> * There's no longer a PV_TIME device, instead there are attributes on
> the VCPU. This allows the stolen time structures to be places
> arbitrarily by user space (subject to 64 byte alignment).
> * Split documentation between information on the hypercalls and the
> attributes on the VCPU
> * Fixed the type of SMCCC functions to return long not int
>
> Changes from v2:
> https://lore.kernel.org/lkml/20190819140436.12207-1-steven.price@arm.com/
> * Switched from using gfn_to_hva_cache to a new macro kvm_put_guest()
> that can provide the single-copy atomicity required (on arm64). This
> macro is added in patch 4.
> * Tidied up the locking for kvm_update_stolen_time().
> pagefault_disable() was unnecessary and the caller didn't need to
> take kvm->srcu as the function does it itself.
> * Removed struct kvm_arch_pvtime from the arm implementation, replaced
> instead with inline static functions which are empty for arm.
> * Fixed a few checkpatch --strict warnings.
>
> Changes from v1:
> https://lore.kernel.org/lkml/20190802145017.42543-1-steven.price@arm.com/
> * Host kernel no longer allocates the stolen time structure, instead it
> is allocated by user space. This means the save/restore functionality
> can be removed.
> * Refactored the code so arm has stub implementations and to avoid
> initcall
> * Rebased to pick up Documentation/{virt->virtual} change
> * Bunch of typo fixes
>
> Christoffer Dall (1):
> KVM: arm/arm64: Factor out hypercall handling from PSCI code
>
> Steven Price (9):
> KVM: arm64: Document PV-time interface
> KVM: arm64: Implement PV_FEATURES call
> KVM: Implement kvm_put_guest()
> KVM: arm64: Support stolen time reporting via shared structure
> KVM: Allow kvm_device_ops to be const
> KVM: arm64: Provide VCPU attributes for stolen time
> arm/arm64: Provide a wrapper for SMCCC 1.1 calls
> arm/arm64: Make use of the SMCCC 1.1 wrapper
> arm64: Retrieve stolen time as paravirtualized guest
>
> Documentation/virt/kvm/arm/pvtime.txt | 64 ++++++++++
> Documentation/virt/kvm/devices/vcpu.txt | 14 +++
> arch/arm/include/asm/kvm_host.h | 26 +++++
> arch/arm/kvm/Makefile | 2 +-
> arch/arm/kvm/handle_exit.c | 2 +-
> arch/arm/mm/proc-v7-bugs.c | 13 +--
> arch/arm64/include/asm/kvm_host.h | 30 ++++-
> arch/arm64/include/asm/paravirt.h | 9 +-
> arch/arm64/include/asm/pvclock-abi.h | 17 +++
> arch/arm64/include/uapi/asm/kvm.h | 2 +
> arch/arm64/kernel/cpu_errata.c | 80 +++++--------
> arch/arm64/kernel/paravirt.c | 148 ++++++++++++++++++++++++
> arch/arm64/kernel/time.c | 3 +
> arch/arm64/kvm/Kconfig | 1 +
> arch/arm64/kvm/Makefile | 2 +
> arch/arm64/kvm/guest.c | 9 ++
> arch/arm64/kvm/handle_exit.c | 4 +-
> include/kvm/arm_hypercalls.h | 43 +++++++
> include/kvm/arm_psci.h | 2 +-
> include/linux/arm-smccc.h | 58 ++++++++++
> include/linux/cpuhotplug.h | 1 +
> include/linux/kvm_host.h | 26 ++++-
> include/linux/kvm_types.h | 2 +
> include/uapi/linux/kvm.h | 2 +
> virt/kvm/arm/arm.c | 11 ++
> virt/kvm/arm/hypercalls.c | 68 +++++++++++
> virt/kvm/arm/psci.c | 84 +-------------
> virt/kvm/arm/pvtime.c | 124 ++++++++++++++++++++
> virt/kvm/kvm_main.c | 6 +-
> 29 files changed, 699 insertions(+), 154 deletions(-)
> create mode 100644 Documentation/virt/kvm/arm/pvtime.txt
> create mode 100644 arch/arm64/include/asm/pvclock-abi.h
> create mode 100644 include/kvm/arm_hypercalls.h
> create mode 100644 virt/kvm/arm/hypercalls.c
> create mode 100644 virt/kvm/arm/pvtime.c
>
> --
> 2.20.1
>
Hi Steven,
I had some fun testing this series with the KVM selftests framework. It
looks like it works to me, so you may add
Tested-by: Andrew Jones <drjones@redhat.com>
if you like. And below is the test I came up with.
Thanks,
drew
From: Andrew Jones <drjones@redhat.com>
Date: Tue, 3 Sep 2019 03:45:08 -0400
Subject: [PATCH] selftests: kvm: aarch64 stolen-time test
Signed-off-by: Andrew Jones <drjones@redhat.com>
---
tools/testing/selftests/kvm/Makefile | 1 +
.../selftests/kvm/aarch64/stolen-time.c | 208 ++++++++++++++++++
2 files changed, 209 insertions(+)
create mode 100644 tools/testing/selftests/kvm/aarch64/stolen-time.c
diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
index ba7849751989..3151264039ad 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -28,6 +28,7 @@ TEST_GEN_PROGS_x86_64 += clear_dirty_log_test
TEST_GEN_PROGS_x86_64 += dirty_log_test
TEST_GEN_PROGS_x86_64 += kvm_create_max_vcpus
+TEST_GEN_PROGS_aarch64 += aarch64/stolen-time
TEST_GEN_PROGS_aarch64 += clear_dirty_log_test
TEST_GEN_PROGS_aarch64 += dirty_log_test
TEST_GEN_PROGS_aarch64 += kvm_create_max_vcpus
diff --git a/tools/testing/selftests/kvm/aarch64/stolen-time.c b/tools/testing/selftests/kvm/aarch64/stolen-time.c
new file mode 100644
index 000000000000..36df2f6baa17
--- /dev/null
+++ b/tools/testing/selftests/kvm/aarch64/stolen-time.c
@@ -0,0 +1,208 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AArch64 PV stolen time test
+ *
+ * Copyright (C) 2019, Red Hat, Inc.
+ */
+#define _GNU_SOURCE
+#include <stdio.h>
+#include <time.h>
+#include <sched.h>
+#include <pthread.h>
+#include <sys/syscall.h>
+#include "kvm_util.h"
+
+#define ST_IPA_BASE (1 << 30)
+#define MIN_STOLEN_TIME 200000
+
+struct st_time {
+ uint32_t rev;
+ uint32_t attr;
+ uint64_t st_time;
+};
+
+static uint64_t st_ipa_offset[4];
+static uint64_t guest_stolen_time[4];
+
+static void guest_code(void)
+{
+ struct st_time *st_time;
+ uint64_t cpu;
+ int64_t ipa;
+ int32_t ret;
+
+ asm volatile("mrs %0, mpidr_el1" : "=r" (cpu));
+ cpu &= 0x3;
+
+ asm volatile(
+ "mov x0, %1\n"
+ "mov x1, %2\n"
+ "hvc #0\n"
+ "mov %0, x0\n"
+ : "=r" (ret) : "r" (0x80000001), "r" (0xc5000020) :
+ "x0", "x1", "x2", "x3");
+
+ GUEST_ASSERT(ret == 0);
+
+ asm volatile(
+ "mov x0, %1\n"
+ "mov x1, %2\n"
+ "hvc #0\n"
+ "mov %0, x0\n"
+ : "=r" (ret) : "r" (0xc5000020), "r" (0xc5000022) :
+ "x0", "x1", "x2", "x3");
+
+ GUEST_ASSERT(ret == 0);
+
+ asm volatile(
+ "mov x0, %1\n"
+ "hvc #0\n"
+ "mov %0, x0\n"
+ : "=r" (ipa) : "r" (0xc5000022) :
+ "x0", "x1", "x2", "x3");
+
+ GUEST_ASSERT(ipa == ST_IPA_BASE + st_ipa_offset[cpu]);
+
+ st_time = (struct st_time *)ipa;
+ GUEST_ASSERT(st_time->rev == 0);
+ GUEST_ASSERT(st_time->attr == 0);
+
+ guest_stolen_time[cpu] = st_time->st_time;
+ GUEST_SYNC(0);
+
+ guest_stolen_time[cpu] = st_time->st_time;
+ GUEST_DONE();
+}
+
+static long get_run_delay(void)
+{
+ char path[64];
+ long val[2];
+ FILE *fp;
+
+ sprintf(path, "/proc/%ld/schedstat", syscall(SYS_gettid));
+ fp = fopen(path, "r");
+ fscanf(fp, "%ld %ld ", &val[0], &val[1]);
+ fclose(fp);
+
+ return val[1];
+}
+
+static void *steal_time(void *arg)
+{
+ uint64_t nsecs_per_sec = 1000000000ul;
+ uint64_t sec, nsec;
+ struct timespec ts;
+
+ clock_gettime(CLOCK_MONOTONIC, &ts);
+ sec = ts.tv_sec;
+ nsec = ts.tv_nsec + MIN_STOLEN_TIME;
+ if (nsec > nsecs_per_sec) {
+ sec += 1;
+ nsec -= nsecs_per_sec;
+ }
+
+ while (1) {
+ clock_gettime(CLOCK_MONOTONIC, &ts);
+ if (ts.tv_sec > sec || (ts.tv_sec == sec && ts.tv_nsec >= nsec))
+ break;
+ }
+
+ return NULL;
+}
+
+static void run_vcpu(struct kvm_vm *vm, uint32_t vcpuid)
+{
+ struct ucall uc;
+
+ vcpu_ioctl(vm, vcpuid, KVM_RUN, NULL);
+
+ switch (get_ucall(vm, vcpuid, &uc)) {
+ case UCALL_SYNC:
+ case UCALL_DONE:
+ break;
+ case UCALL_ABORT:
+ TEST_ASSERT(false, "%s at %s:%d", (const char *)uc.args[0],
+ __FILE__, uc.args[1]);
+ default:
+ TEST_ASSERT(false, "Unexpected exit: %s",
+ exit_reason_str(vcpu_state(vm, vcpuid)->exit_reason));
+ }
+}
+
+int main(int ac, char **av)
+{
+ struct kvm_device_attr dev = {
+ .group = KVM_ARM_VCPU_PVTIME_CTRL,
+ .attr = KVM_ARM_VCPU_PVTIME_SET_IPA,
+ };
+ uint64_t pvtime_memslot_size;
+ struct kvm_vm *vm;
+ pthread_attr_t attr;
+ pthread_t thread;
+ cpu_set_t cpuset;
+ long stolen_time;
+ int i;
+
+ CPU_ZERO(&cpuset);
+ CPU_SET(0, &cpuset);
+ pthread_attr_init(&attr);
+ pthread_attr_setaffinity_np(&attr, sizeof(cpu_set_t), &cpuset);
+ pthread_setaffinity_np(pthread_self(), sizeof(cpu_set_t), &cpuset);
+
+ pvtime_memslot_size = 64 * 1024; /* one maximum-sized host page */
+
+ /* create a one-vcpu guest and the pvtime memslot */
+ vm = vm_create_default(0, 0, guest_code);
+ vm_userspace_mem_region_add(vm, VM_MEM_SRC_ANONYMOUS, ST_IPA_BASE, 1,
+ 16 /* vm uses 4k pages */, 0);
+ virt_map(vm, ST_IPA_BASE, ST_IPA_BASE, pvtime_memslot_size, 0);
+ ucall_init(vm, UCALL_MMIO, NULL);
+
+ /* add 3 more vcpus */
+ for (i = 1; i < 4; ++i) {
+ vm_vcpu_add_default(vm, i, guest_code);
+ st_ipa_offset[i] = i * 64;
+ sync_global_to_guest(vm, st_ipa_offset[i]);
+ }
+
+ /* add pvtime to each vcpu */
+ for (i = 0; i < 4; ++i) {
+ uint64_t st_ipa = ST_IPA_BASE + st_ipa_offset[i];
+ dev.addr = (uint64_t)&st_ipa;
+ vcpu_ioctl(vm, i, KVM_HAS_DEVICE_ATTR, &dev);
+ vcpu_ioctl(vm, i, KVM_SET_DEVICE_ATTR, &dev);
+ }
+
+ /* run the tests on each vcpu */
+ for (i = 0; i < 4; ++i) {
+ /* first vcpu run */
+ run_vcpu(vm, i);
+ sync_global_from_guest(vm, guest_stolen_time[i]);
+ TEST_ASSERT(guest_stolen_time[i] == 0, "Expected stolen_time = 0");
+
+ /* steal time from the vcpu */
+ stolen_time = get_run_delay();
+ pthread_create(&thread, &attr, steal_time, NULL);
+ pthread_yield();
+ pthread_join(thread, NULL);
+ stolen_time = get_run_delay() - stolen_time;
+ TEST_ASSERT(stolen_time >= MIN_STOLEN_TIME,
+ "Expected stolen time >= %ld, got %ld",
+ MIN_STOLEN_TIME, stolen_time);
+
+ /* run vcpu again and check the stolen time */
+ run_vcpu(vm, i);
+ sync_global_from_guest(vm, guest_stolen_time[i]);
+ TEST_ASSERT(guest_stolen_time[i] >= stolen_time,
+ "Expected stolen_time >= %ld, got %ld",
+ stolen_time, guest_stolen_time[i]);
+
+ printf("CPU%d: %ld", i, guest_stolen_time[i]);
+ if (stolen_time == guest_stolen_time[i])
+ printf(" (BONUS: guest stolen_time even exactly matches run_delay)");
+ printf("\n");
+ }
+
+ return 0;
+}
--
2.18.1
^ permalink raw reply related
* Re: [PATCH v4 10/10] arm64: Retrieve stolen time as paravirtualized guest
From: Andrew Jones @ 2019-09-03 8:47 UTC (permalink / raw)
To: Steven Price
Cc: Marc Zyngier, Will Deacon, linux-arm-kernel, kvmarm,
Catalin Marinas, Paolo Bonzini, Radim Krčmář,
Russell King, James Morse, Julien Thierry, Suzuki K Pouloze,
Mark Rutland, kvm, linux-doc, linux-kernel
In-Reply-To: <20190830084255.55113-11-steven.price@arm.com>
On Fri, Aug 30, 2019 at 09:42:55AM +0100, Steven Price wrote:
> Enable paravirtualization features when running under a hypervisor
> supporting the PV_TIME_ST hypercall.
>
> For each (v)CPU, we ask the hypervisor for the location of a shared
> page which the hypervisor will use to report stolen time to us. We set
> pv_time_ops to the stolen time function which simply reads the stolen
> value from the shared page for a VCPU. We guarantee single-copy
> atomicity using READ_ONCE which means we can also read the stolen
> time for another VCPU than the currently running one while it is
> potentially being updated by the hypervisor.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
> ---
> arch/arm64/include/asm/paravirt.h | 9 +-
> arch/arm64/kernel/paravirt.c | 148 ++++++++++++++++++++++++++++++
> arch/arm64/kernel/time.c | 3 +
> include/linux/cpuhotplug.h | 1 +
> 4 files changed, 160 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/paravirt.h b/arch/arm64/include/asm/paravirt.h
> index 799d9dd6f7cc..125c26c42902 100644
> --- a/arch/arm64/include/asm/paravirt.h
> +++ b/arch/arm64/include/asm/paravirt.h
> @@ -21,6 +21,13 @@ static inline u64 paravirt_steal_clock(int cpu)
> {
> return pv_ops.time.steal_clock(cpu);
> }
> -#endif
> +
> +int __init kvm_guest_init(void);
> +
> +#else
> +
> +#define kvm_guest_init()
> +
> +#endif // CONFIG_PARAVIRT
>
> #endif
> diff --git a/arch/arm64/kernel/paravirt.c b/arch/arm64/kernel/paravirt.c
> index 4cfed91fe256..5bf3be7ccf7e 100644
> --- a/arch/arm64/kernel/paravirt.c
> +++ b/arch/arm64/kernel/paravirt.c
> @@ -6,13 +6,161 @@
> * Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> */
>
> +#define pr_fmt(fmt) "kvmarm-pv: " fmt
> +
> +#include <linux/arm-smccc.h>
> +#include <linux/cpuhotplug.h>
> #include <linux/export.h>
> +#include <linux/io.h>
> #include <linux/jump_label.h>
> +#include <linux/printk.h>
> +#include <linux/psci.h>
> +#include <linux/reboot.h>
> +#include <linux/slab.h>
> #include <linux/types.h>
> +
> #include <asm/paravirt.h>
> +#include <asm/pvclock-abi.h>
> +#include <asm/smp_plat.h>
>
> struct static_key paravirt_steal_enabled;
> struct static_key paravirt_steal_rq_enabled;
>
> struct paravirt_patch_template pv_ops;
> EXPORT_SYMBOL_GPL(pv_ops);
> +
> +struct kvmarm_stolen_time_region {
> + struct pvclock_vcpu_stolen_time *kaddr;
> +};
> +
> +static DEFINE_PER_CPU(struct kvmarm_stolen_time_region, stolen_time_region);
> +
> +static bool steal_acc = true;
> +static int __init parse_no_stealacc(char *arg)
> +{
> + steal_acc = false;
> + return 0;
> +}
> +
> +early_param("no-steal-acc", parse_no_stealacc);
Need to also add an 'ARM64' to the
Documentation/admin-guide/kernel-parameters.txt entry for this.
Thanks,
drew
^ permalink raw reply
* Re: [PATCH v4 00/10] arm64: Stolen time support
From: Andrew Jones @ 2019-09-03 8:49 UTC (permalink / raw)
To: Steven Price
Cc: Marc Zyngier, Will Deacon, linux-arm-kernel, kvmarm,
Catalin Marinas, Paolo Bonzini, Radim Krčmář,
Russell King, James Morse, Julien Thierry, Suzuki K Pouloze,
Mark Rutland, kvm, linux-doc, linux-kernel
In-Reply-To: <20190903080348.5whavgrjki7zrtmd@kamzik.brq.redhat.com>
On Tue, Sep 03, 2019 at 10:03:48AM +0200, Andrew Jones wrote:
> Hi Steven,
>
> I had some fun testing this series with the KVM selftests framework. It
> looks like it works to me, so you may add
>
> Tested-by: Andrew Jones <drjones@redhat.com>
>
Actually, I probably shouldn't be quite so generous with this tag yet,
because I haven't yet tested the guest-side changes. To do that I'll
need to start prototyping something for QEMU. I need to finish some other
stuff first, but then I can do that.
Thanks,
drew
^ permalink raw reply
* Re: [PATCH v5 04/17] MIPS: PCI: refactor ioc3 special handling
From: Paul Burton @ 2019-09-03 9:10 UTC (permalink / raw)
To: Thomas Bogendoerfer
Cc: Jonathan Corbet, Ralf Baechle, Paul Burton, James Hogan,
Dmitry Torokhov, Lee Jones, David S. Miller, Srinivas Kandagatla,
Alessandro Zummo, Alexandre Belloni, Greg Kroah-Hartman,
Jiri Slaby, Evgeniy Polyakov, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
linux-input@vger.kernel.org, netdev@vger.kernel.org,
linux-rtc@vger.kernel.org, linux-serial@vger.kernel.org,
linux-mips@vger.kernel.org
In-Reply-To: <20190819163144.3478-5-tbogendoerfer@suse.de>
Hello,
Thomas Bogendoerfer wrote:
> Refactored code to only have one ioc3 special handling for read
> access and one for write access.
Applied to mips-next.
> commit 813cafc4109c
> https://git.kernel.org/mips/c/813cafc4109c
>
> Signed-off-by: Thomas Bogendoerfer <tbogendoerfer@suse.de>
> Signed-off-by: Paul Burton <paul.burton@mips.com>
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.burton@mips.com to report it. ]
^ permalink raw reply
* Re: [PATCH v4 05/10] KVM: arm64: Support stolen time reporting via shared structure
From: Zenghui Yu @ 2019-09-03 9:14 UTC (permalink / raw)
To: Steven Price, Marc Zyngier, Will Deacon, linux-arm-kernel, kvmarm
Cc: linux-kernel, kvm, Catalin Marinas, linux-doc, Russell King,
Paolo Bonzini
In-Reply-To: <20190830084255.55113-6-steven.price@arm.com>
On 2019/8/30 16:42, Steven Price wrote:
> Implement the service call for configuring a shared structure between a
> VCPU and the hypervisor in which the hypervisor can write the time
> stolen from the VCPU's execution time by other tasks on the host.
>
> The hypervisor allocates memory which is placed at an IPA chosen by user
> space.
It seems that no allocation happens in the hypervisor code. User space
will do it instead?
> The hypervisor then updates the shared structure using
> kvm_put_guest() to ensure single copy atomicity of the 64-bit value
> reporting the stolen time in nanoseconds.
>
> Whenever stolen time is enabled by the guest, the stolen time counter is
> reset.
>
> The stolen time itself is retrieved from the sched_info structure
> maintained by the Linux scheduler code. We enable SCHEDSTATS when
> selecting KVM Kconfig to ensure this value is meaningful.
>
> Signed-off-by: Steven Price <steven.price@arm.com>
Thanks,
zenghui
^ permalink raw reply
* [PATCH v2 2/6] drm/ttm: add drm gem ttm helpers, starting with drm_gem_ttm_print_info()
From: Gerd Hoffmann @ 2019-09-03 10:12 UTC (permalink / raw)
To: dri-devel
Cc: Gerd Hoffmann, David Airlie, Daniel Vetter, Maarten Lankhorst,
Maxime Ripard, Sean Paul, Jonathan Corbet,
open list:DOCUMENTATION, open list
In-Reply-To: <20190903101248.12879-1-kraxel@redhat.com>
Now with ttm_buffer_object being a subclass of drm_gem_object we can
easily lookup ttm_buffer_object for a given drm_gem_object, which in
turn allows to create common helper functions.
This patch starts off with a drm_gem_ttm_print_info() helper function
which prints adds some ttm specific lines to the debug output.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
---
include/drm/drm_gem_ttm_helper.h | 19 ++++++++++
drivers/gpu/drm/drm_gem_ttm_helper.c | 53 ++++++++++++++++++++++++++++
Documentation/gpu/drm-mm.rst | 12 +++++++
drivers/gpu/drm/Kconfig | 7 ++++
drivers/gpu/drm/Makefile | 3 ++
5 files changed, 94 insertions(+)
create mode 100644 include/drm/drm_gem_ttm_helper.h
create mode 100644 drivers/gpu/drm/drm_gem_ttm_helper.c
diff --git a/include/drm/drm_gem_ttm_helper.h b/include/drm/drm_gem_ttm_helper.h
new file mode 100644
index 000000000000..6268f89c5a48
--- /dev/null
+++ b/include/drm/drm_gem_ttm_helper.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0-or-later */
+
+#ifndef DRM_GEM_TTM_HELPER_H
+#define DRM_GEM_TTM_HELPER_H
+
+#include <linux/kernel.h>
+
+#include <drm/drm_gem.h>
+#include <drm/drm_device.h>
+#include <drm/ttm/ttm_bo_api.h>
+#include <drm/ttm/ttm_bo_driver.h>
+
+#define drm_gem_ttm_of_gem(gem_obj) \
+ container_of(gem_obj, struct ttm_buffer_object, base)
+
+void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent,
+ const struct drm_gem_object *gem);
+
+#endif
diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c b/drivers/gpu/drm/drm_gem_ttm_helper.c
new file mode 100644
index 000000000000..5a19a7e130c4
--- /dev/null
+++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+
+#include <linux/module.h>
+
+#include <drm/drm_gem_ttm_helper.h>
+
+/**
+ * DOC: overview
+ *
+ * This library provides helper functions for gem objects backed by
+ * ttm.
+ */
+
+/**
+ * drm_gem_ttm_print_info() - Print &ttm_buffer_object info for debugfs
+ * @p: DRM printer
+ * @indent: Tab indentation level
+ * @gem: GEM object
+ *
+ * This function can be used as the &drm_driver->gem_print_info callback.
+ */
+void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent,
+ const struct drm_gem_object *gem)
+{
+ static const char const *plname[] = {
+ [ TTM_PL_SYSTEM ] = "system",
+ [ TTM_PL_TT ] = "tt",
+ [ TTM_PL_VRAM ] = "vram",
+ [ TTM_PL_PRIV ] = "priv",
+
+ [ 16 ] = "cached",
+ [ 17 ] = "uncached",
+ [ 18 ] = "wc",
+ [ 19 ] = "contig",
+
+ [ 21 ] = "pinned", /* NO_EVICT */
+ [ 22 ] = "topdown",
+ };
+ const struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
+
+ drm_print_bits(p, indent, "placement", bo->mem.placement,
+ plname, ARRAY_SIZE(plname));
+ if (bo->mem.bus.is_iomem) {
+ drm_printf_indent(p, indent, "bus.base=%lx\n",
+ (unsigned long)bo->mem.bus.base);
+ drm_printf_indent(p, indent, "bus.offset=%lx\n",
+ (unsigned long)bo->mem.bus.offset);
+ }
+}
+EXPORT_SYMBOL(drm_gem_ttm_print_info);
+
+MODULE_DESCRIPTION("DRM gem ttm helpers");
+MODULE_LICENSE("GPL");
diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index b664f054c259..a70a1d9f30ec 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -412,6 +412,18 @@ VRAM MM Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_vram_mm_helper.c
:export:
+GEM TTM Helper Functions Reference
+-----------------------------------
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/drm_gem_ttm_helper.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
+ :export:
+
VMA Offset Manager
==================
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index e6f40fb54c9a..f7b25519f95c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -172,6 +172,13 @@ config DRM_VRAM_HELPER
help
Helpers for VRAM memory management
+config DRM_TTM_HELPER
+ tristate
+ depends on DRM
+ select DRM_TTM
+ help
+ Helpers for ttm-based gem objects
+
config DRM_GEM_CMA_HELPER
bool
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 10f8329a8b71..545c61d6528b 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -37,6 +37,9 @@ drm_vram_helper-y := drm_gem_vram_helper.o \
drm_vram_mm_helper.o
obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
+drm_ttm_helper-y := drm_gem_ttm_helper.o
+obj-$(CONFIG_DRM_TTM_HELPER) += drm_ttm_helper.o
+
drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
--
2.18.1
^ permalink raw reply related
* Re: [PATCH v2 2/6] drm/ttm: add drm gem ttm helpers, starting with drm_gem_ttm_print_info()
From: Daniel Vetter @ 2019-09-03 10:56 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: dri-devel, David Airlie, Daniel Vetter, Maarten Lankhorst,
Maxime Ripard, Sean Paul, Jonathan Corbet,
open list:DOCUMENTATION, open list
In-Reply-To: <20190903101248.12879-3-kraxel@redhat.com>
On Tue, Sep 03, 2019 at 12:12:44PM +0200, Gerd Hoffmann wrote:
> Now with ttm_buffer_object being a subclass of drm_gem_object we can
> easily lookup ttm_buffer_object for a given drm_gem_object, which in
> turn allows to create common helper functions.
>
> This patch starts off with a drm_gem_ttm_print_info() helper function
> which prints adds some ttm specific lines to the debug output.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
> include/drm/drm_gem_ttm_helper.h | 19 ++++++++++
> drivers/gpu/drm/drm_gem_ttm_helper.c | 53 ++++++++++++++++++++++++++++
> Documentation/gpu/drm-mm.rst | 12 +++++++
> drivers/gpu/drm/Kconfig | 7 ++++
> drivers/gpu/drm/Makefile | 3 ++
> 5 files changed, 94 insertions(+)
> create mode 100644 include/drm/drm_gem_ttm_helper.h
> create mode 100644 drivers/gpu/drm/drm_gem_ttm_helper.c
>
> diff --git a/include/drm/drm_gem_ttm_helper.h b/include/drm/drm_gem_ttm_helper.h
> new file mode 100644
> index 000000000000..6268f89c5a48
> --- /dev/null
> +++ b/include/drm/drm_gem_ttm_helper.h
> @@ -0,0 +1,19 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +
> +#ifndef DRM_GEM_TTM_HELPER_H
> +#define DRM_GEM_TTM_HELPER_H
> +
> +#include <linux/kernel.h>
> +
> +#include <drm/drm_gem.h>
> +#include <drm/drm_device.h>
> +#include <drm/ttm/ttm_bo_api.h>
> +#include <drm/ttm/ttm_bo_driver.h>
> +
> +#define drm_gem_ttm_of_gem(gem_obj) \
> + container_of(gem_obj, struct ttm_buffer_object, base)
> +
> +void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent,
> + const struct drm_gem_object *gem);
> +
> +#endif
> diff --git a/drivers/gpu/drm/drm_gem_ttm_helper.c b/drivers/gpu/drm/drm_gem_ttm_helper.c
> new file mode 100644
> index 000000000000..5a19a7e130c4
> --- /dev/null
> +++ b/drivers/gpu/drm/drm_gem_ttm_helper.c
> @@ -0,0 +1,53 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +#include <linux/module.h>
> +
> +#include <drm/drm_gem_ttm_helper.h>
> +
> +/**
> + * DOC: overview
> + *
> + * This library provides helper functions for gem objects backed by
> + * ttm.
> + */
> +
> +/**
> + * drm_gem_ttm_print_info() - Print &ttm_buffer_object info for debugfs
> + * @p: DRM printer
> + * @indent: Tab indentation level
> + * @gem: GEM object
> + *
> + * This function can be used as the &drm_driver->gem_print_info callback.
&drm_gem_object_funcs.print_info is the new thing. Also I think you need
the . for kerneldoc to parse this correctly and make it a link.
> + */
> +void drm_gem_ttm_print_info(struct drm_printer *p, unsigned int indent,
> + const struct drm_gem_object *gem)
> +{
> + static const char const *plname[] = {
> + [ TTM_PL_SYSTEM ] = "system",
> + [ TTM_PL_TT ] = "tt",
> + [ TTM_PL_VRAM ] = "vram",
> + [ TTM_PL_PRIV ] = "priv",
> +
> + [ 16 ] = "cached",
> + [ 17 ] = "uncached",
> + [ 18 ] = "wc",
> + [ 19 ] = "contig",
> +
> + [ 21 ] = "pinned", /* NO_EVICT */
> + [ 22 ] = "topdown",
> + };
> + const struct ttm_buffer_object *bo = drm_gem_ttm_of_gem(gem);
> +
> + drm_print_bits(p, indent, "placement", bo->mem.placement,
> + plname, ARRAY_SIZE(plname));
> + if (bo->mem.bus.is_iomem) {
> + drm_printf_indent(p, indent, "bus.base=%lx\n",
> + (unsigned long)bo->mem.bus.base);
> + drm_printf_indent(p, indent, "bus.offset=%lx\n",
> + (unsigned long)bo->mem.bus.offset);
> + }
> +}
> +EXPORT_SYMBOL(drm_gem_ttm_print_info);
> +
> +MODULE_DESCRIPTION("DRM gem ttm helpers");
> +MODULE_LICENSE("GPL");
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index b664f054c259..a70a1d9f30ec 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -412,6 +412,18 @@ VRAM MM Helper Functions Reference
> .. kernel-doc:: drivers/gpu/drm/drm_vram_mm_helper.c
> :export:
>
> +GEM TTM Helper Functions Reference
> +-----------------------------------
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
> + :doc: overview
> +
> +.. kernel-doc:: include/drm/drm_gem_ttm_helper.h
> + :internal:
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_gem_ttm_helper.c
> + :export:
> +
> VMA Offset Manager
> ==================
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index e6f40fb54c9a..f7b25519f95c 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -172,6 +172,13 @@ config DRM_VRAM_HELPER
> help
> Helpers for VRAM memory management
>
> +config DRM_TTM_HELPER
> + tristate
> + depends on DRM
> + select DRM_TTM
> + help
> + Helpers for ttm-based gem objects
> +
> config DRM_GEM_CMA_HELPER
> bool
> depends on DRM
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 10f8329a8b71..545c61d6528b 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -37,6 +37,9 @@ drm_vram_helper-y := drm_gem_vram_helper.o \
> drm_vram_mm_helper.o
> obj-$(CONFIG_DRM_VRAM_HELPER) += drm_vram_helper.o
>
> +drm_ttm_helper-y := drm_gem_ttm_helper.o
> +obj-$(CONFIG_DRM_TTM_HELPER) += drm_ttm_helper.o
> +
> drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_dsc.o drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> drm_kms_helper_common.o drm_dp_dual_mode_helper.o \
Nice! With the kerneldoc bikeshed fixed:
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> --
> 2.18.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 0/2] trace-vmscan-postprocess: fix parsing and output
From: Florian Schmidt @ 2019-09-03 11:14 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Andrew Morton, Daniel Jordan, Kirill Tkhai,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Florian Schmidt
This patch series updates trace-vmscan-postprocess.pl to work without
throwing warnings and errors which stem from updates to several trace
points.
3481c37ffa1d ("mm/vmscan: drop may_writepage and classzone_idx from
direct reclaim begin template") removed "may_writepage" from
mm_vmscan_direct_reclaim_begin, and 3b775998eca7
("include/trace/events/vmscan.h: drop zone id from kswapd tracepoints")
removed "zid" from mm_vmscan_wakeup_kswapd. The output of
mm_vmscan_lru_isolate and mm_vmscan_lru_shrink_active seems to never
have matched the format of the trace point output since they were
created, or at least for as long as I can tell. Patch 1 aligns the
format parsing of the perl script with the current output of the trace
points.
In addition, the tables that are printed by the script were not properly
aligned any more, so patch 2 fixes the spacing.
A side remark: parsing the trace output for mm_vmscan_lru_shrink_active
has been in the script ever since it was created in 2010, but at no
point the parsed output was ever used for anything. I updated the
parsing code now, but I wonder if we could just get rid of that part...
Florian Schmidt (2):
trace-vmscan-postprocess: sync with tracepoints updates
trace-vmscan-postprocess: fix output table spacing
.../postprocess/trace-vmscan-postprocess.pl | 29 +++++++++----------
1 file changed, 14 insertions(+), 15 deletions(-)
--
2.23.0.rc1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox