Re: [PATCH v2] Documentation: gpu: Mention the requirements for new properties
Hi Maxime, Thank you for the patch. On Thu, May 20, 2021 at 04:24:35PM +0200, Maxime Ripard wrote: > New KMS properties come with a bunch of requirements to avoid each > driver from running their own, inconsistent, set of properties, > eventually leading to issues like property conflicts, inconsistencies > between drivers and semantics, etc. > > Let's document what we expect. > > Cc: Alexandre Belloni > Cc: Alexandre Torgue > Cc: Alex Deucher > Cc: Alison Wang > Cc: Alyssa Rosenzweig > Cc: Andrew Jeffery > Cc: Andrzej Hajda > Cc: Anitha Chrisanthus > Cc: Benjamin Gaignard > Cc: Ben Skeggs > Cc: Boris Brezillon > Cc: Brian Starkey > Cc: Chen Feng > Cc: Chen-Yu Tsai > Cc: Christian Gmeiner > Cc: "Christian König" > Cc: Chun-Kuang Hu > Cc: Edmund Dea > Cc: Eric Anholt > Cc: Fabio Estevam > Cc: Gerd Hoffmann > Cc: Haneen Mohammed > Cc: Hans de Goede > Cc: "Heiko Stübner" > Cc: Huang Rui > Cc: Hyun Kwon > Cc: Inki Dae > Cc: Jani Nikula > Cc: Jernej Skrabec > Cc: Jerome Brunet > Cc: Joel Stanley > Cc: John Stultz > Cc: Jonas Karlman > Cc: Jonathan Hunter > Cc: Joonas Lahtinen > Cc: Joonyoung Shim > Cc: Jyri Sarha > Cc: Kevin Hilman > Cc: Kieran Bingham > Cc: Krzysztof Kozlowski > Cc: Kyungmin Park > Cc: Laurent Pinchart > Cc: Linus Walleij > Cc: Liviu Dudau > Cc: Lucas Stach > Cc: Ludovic Desroches > Cc: Marek Vasut > Cc: Martin Blumenstingl > Cc: Matthias Brugger > Cc: Maxime Coquelin > Cc: Maxime Ripard > Cc: Melissa Wen > Cc: Neil Armstrong > Cc: Nicolas Ferre > Cc: "Noralf Trønnes" > Cc: NXP Linux Team > Cc: Oleksandr Andrushchenko > Cc: Patrik Jakobsson > Cc: Paul Cercueil > Cc: Pengutronix Kernel Team > Cc: Philippe Cornu > Cc: Philipp Zabel > Cc: Qiang Yu > Cc: Rob Clark > Cc: Robert Foss > Cc: Rob Herring > Cc: Rodrigo Siqueira > Cc: Rodrigo Vivi > Cc: Roland Scheidegger > Cc: Russell King > Cc: Sam Ravnborg > Cc: Sandy Huang > Cc: Sascha Hauer > Cc: Sean Paul > Cc: Seung-Woo Kim > Cc: Shawn Guo > Cc: Stefan Agner > Cc: Steven Price > Cc: Sumit Semwal > Cc: Thierry Reding > Cc: Tian Tao > Cc: Tomeu Vizoso > Cc: Tomi Valkeinen > Cc: VMware Graphics > Cc: Xinliang Liu > Cc: Xinwei Kong > Cc: Yannick Fertre > Cc: Zack Rusin > Reviewed-by: Daniel Vetter > Signed-off-by: Maxime Ripard > > --- > > Changes from v2: > - Typos and wording reported by Daniel and Alex > --- > Documentation/gpu/drm-kms.rst | 19 +++ > 1 file changed, 19 insertions(+) > > diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst > index 87e5023e3f55..c28b464dd397 100644 > --- a/Documentation/gpu/drm-kms.rst > +++ b/Documentation/gpu/drm-kms.rst > @@ -463,6 +463,25 @@ KMS Properties > This section of the documentation is primarily aimed at user-space > developers. > For the driver APIs, see the other sections. > > +Requirements > + > + > +KMS drivers might need to add extra properties to support new features. > +Each new property introduced in a driver need to meet a few s/need/needs/ > +requirements, in addition to the one mentioned above.: s/above./above/ > + > +- It must be standardized, with some documentation to describe how the > + property can be used. > + > +- It must provide a generic helper in the core code to register that > + property on the object it attaches to. > + > +- Its content must be decoded by the core and provided in the object's > + associated state structure. That includes anything drivers might want to > + precompute, like :c:type:`struct drm_clip_rect ` for planes. Does this effectively mean that we completely forbid driver-specific properties ? While I agree that we should strive for standardization, there are two issues that worry me. The first one is simple, we may need to control features that would be very device-specific, and standardizing properties doesn't seem to make much sense in that case. The second issue relates to properties that could be applicable to multiple devices, but for which we have a single driver. Designing a standard with a single data point usually leads to a bad design. I'm not sure how to handle this correctly though, as we certainly don't want this to be taken as an excuse to create driver-specific properties when generic properties would make sense. > +- An IGT test must be submitted where reasonable. > + > Property Types and Blob Property Support > > -- Regards, Laurent Pinchart
Re: i915 gvt broke drm-tip; Fix ASAP
On 2021.05.22 21:19:38 +0200, Thomas Zimmermann wrote: > Hi, > > after creating drm-tip today as part of [1], building drm-tip is now broken > with the error message shown below. > > Some register constants appear to be missing from the GVT code. Please fix > ASAP. > Thanks, Thomas. Looks DMC rename missed gvt part. We need to ask CI to have at least build test with gvt. signature.asc Description: PGP signature
dma-resv ongoing discussion
I'd like to try and summarise where I feel we are all at with respect to the dma-buf discussions. I think I've gotten a fairly good idea of how things stand but I'm not sure we are really getting to the how to move things forward stage, where is probably when I need to step in. Thanks for keeping this as respectful as it has been I understand it can be difficult. I also think we are starting to find we moved the knob on driver development happening in company siloes too far with acceleration features and hopefully with this and TTM work etc we can start to push back to upstream first designs. I think Jason[1] summed up my feelings on this the best. We have a dma-buf inter-driver contract that has a design issue. We didn't fix that initially, now we have amdgpu as the outlier in a world where everyone else agreed to the contract. a) Christian wants to try and move forward with fixing the world of dma-buf design across all drivers, but hasn't come up with a plan for doing so apart from amdgpu/i915. I think one strength Daniel has here is that he's good at coming up with plans that change the ecosystem. I'd really like to see some concrete effort to work out how much work fixing this across the ecosystem is and whether it is possible. I expect Daniel's big huge monster commit message summary of the current drivers is a great place to start for this. That is if we can agree dma-buf is broken and what dma-buf should look like tomorrow. b) Daniel is coming from the side of let's bring amdgpu into the fold first, then if the problem exists we can move everything forward together. He intends on pointing out how alone amdgpu is here, and wants to try and create a uapi that at least mitigates the biggest problems with moving amdgpu to the common model first. I'd like to know if this is at least a possibility as an alternate route. I understand AMD have some goals to reach here but I think we've dug a massive hole here and paying off the tech debt is going to have to delay those goals if we are to keep upstream sane. I'm slowly paging all of the technical details as I go, I'd like to see more thought around Daniel's idea of fixing the amdgpu oversync with TLB flushing, as it really doesn't make much sense to be that TLB flushing on process teardown is going to stall out other processes using the shared buffer, that it should only stall out moving the pages. If that then allows aligning amdgpu for now and we can work out how to fix (a) then that would rock. Please correct me where I'm wrong here and definitely if I've misrepresented anyone's positions. Dave. [1] https://lore.kernel.org/dri-devel/a1925038-5c3c-0193-1870-27488caa2...@gmail.com/T/#md800f00476ca1869a81b02a28cb2fabc1028c6be
Re: EPOLL for drm_syncfile (was Re: [PATCH 4/4] RFC: dma-buf: Add an API for importing sync files (v6))
Hi Christian, On Sun, 23 May 2021 at 18:16, Christian König wrote: > Am 22.05.21 um 22:05 schrieb Daniel Stone: > > Anyway, the problem with syncobj is that the ioctl to wait for a > > sync_file to materialise for a given timeline point only allows us to > > block with a timeout; this is a non-starter, because we need something > > which fits into epoll. The most optimal case is returning a new > > eventfd or similar which signals when a given timeline point becomes > > available or signaled, but in extremis a syncobj FD becoming readable > > when any activity which would change the result of any zero-timeout > > wait on that syncobj is more or less workable. > > I think the tricky part is to epoll for a certain value. > > Not sure how eventfd is supposed to work, but IIRC we don't have the > functionality to poll for a certain value/offset etc to become available. > > We could of course create a separate fd for each requested value to poll > for thought, but that sounds like a bit much overhead to me. Yeah, I understand the point; something like an eventfd is exactly what you think, that we would have to materialise a new FD for it. On the other hand, as soon as the sync point becomes available, the winsys will want to immediately extract a sync_file from it, so I don't think FD amplification is a big issue. If it looks like being a problem in practice, we could look at providing a FD which starts off inert, and only later becomes a sync_file after it polls readable, but that sounds like something we really want to avoid if we can. Cheers, Daniel
Re: [PATCH v5 0/3] Add option to mmap GEM buffers cached
Hi Thomas, Le dim., mai 23 2021 at 21:05:30 +0200, Thomas Zimmermann a écrit : Hi Am 23.05.21 um 19:04 schrieb Paul Cercueil: V5 of my patchset which adds the option for having GEM buffers backed by non-coherent memory. Changes from V4: - [2/3]: - Rename to drm_fb_cma_sync_non_coherent - Invert loops for better cache locality - Only sync BOs that have the non-coherent flag - Properly sort includes - Move to drm_fb_cma_helper.c to avoid circular dependency I'm pretty sure it's still not the right place. That would be something like drm_gem_cma_atomic_helper.c, but creating a new file just for a single function doesn't make sense. drm_fb_cma_sync_non_coherent calls drm_fb_cma_* functions, so it's a better match than its former location (which wasn't good as it created a circular dependency between drm.ko and drm-kms-helper.ko). Do you have a better idea? - [3/3]: - Fix drm_atomic_get_new_plane_state() used to retrieve the old state - Use custom drm_gem_fb_create() It's often a better choice to express such differences via different data structures (i.e., different instances of drm_mode_config_funcs) but it's not a big deal either. The different drm_mode_config_funcs instances already exist in drm_gem_framebuffer_helper.c but are static, and drm_gem_fb_create() and drm_gem_fb_create_with_dirty() are just tiny wrappers around drm_gem_fb_create_with_funcs() with the corresponding drm_mode_config_funcs instance. I didn't want to copy them to ingenic-drm-drv.c, but maybe I can export the symbols and use drm_gem_fb_create_with_funcs() directly? Please go ahaed and merge if no one objects. All patches: Acked-by: Thomas Zimmermann Thanks! Cheers, -Paul Best regards Thomas - Only check damage clips and sync DMA buffers if non-coherent buffers are used Cheers, -Paul Paul Cercueil (3): drm: Add support for GEM buffers backed by non-coherent memory drm: Add and export function drm_fb_cma_sync_non_coherent drm/ingenic: Add option to alloc cached GEM buffers drivers/gpu/drm/drm_fb_cma_helper.c | 46 ++ drivers/gpu/drm/drm_gem_cma_helper.c | 38 +++ drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 59 +-- drivers/gpu/drm/ingenic/ingenic-drm.h | 1 + drivers/gpu/drm/ingenic/ingenic-ipu.c | 21 ++-- include/drm/drm_fb_cma_helper.h | 4 ++ include/drm/drm_gem_cma_helper.h | 3 ++ 7 files changed, 156 insertions(+), 16 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Re: [PATCH v5 0/3] Add option to mmap GEM buffers cached
Hi Am 23.05.21 um 19:04 schrieb Paul Cercueil: V5 of my patchset which adds the option for having GEM buffers backed by non-coherent memory. Changes from V4: - [2/3]: - Rename to drm_fb_cma_sync_non_coherent - Invert loops for better cache locality - Only sync BOs that have the non-coherent flag - Properly sort includes - Move to drm_fb_cma_helper.c to avoid circular dependency I'm pretty sure it's still not the right place. That would be something like drm_gem_cma_atomic_helper.c, but creating a new file just for a single function doesn't make sense. - [3/3]: - Fix drm_atomic_get_new_plane_state() used to retrieve the old state - Use custom drm_gem_fb_create() It's often a better choice to express such differences via different data structures (i.e., different instances of drm_mode_config_funcs) but it's not a big deal either. Please go ahaed and merge if no one objects. All patches: Acked-by: Thomas Zimmermann Best regards Thomas - Only check damage clips and sync DMA buffers if non-coherent buffers are used Cheers, -Paul Paul Cercueil (3): drm: Add support for GEM buffers backed by non-coherent memory drm: Add and export function drm_fb_cma_sync_non_coherent drm/ingenic: Add option to alloc cached GEM buffers drivers/gpu/drm/drm_fb_cma_helper.c | 46 ++ drivers/gpu/drm/drm_gem_cma_helper.c | 38 +++ drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 59 +-- drivers/gpu/drm/ingenic/ingenic-drm.h | 1 + drivers/gpu/drm/ingenic/ingenic-ipu.c | 21 ++-- include/drm/drm_fb_cma_helper.h | 4 ++ include/drm/drm_gem_cma_helper.h | 3 ++ 7 files changed, 156 insertions(+), 16 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v5 2/3] drm: Add and export function drm_fb_cma_sync_non_coherent
Hi Paul, I love your patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v5.13-rc2 next-20210521] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch] url: https://github.com/0day-ci/linux/commits/Paul-Cercueil/Add-option-to-mmap-GEM-buffers-cached/20210524-010735 base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 4d7620341eda38573a73ab63c33423534fa38eb9 config: powerpc-randconfig-r013-20210524 (attached as .config) compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project b4fd512c36ca344a3ff69350219e8b0a67e9472a) reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # install powerpc cross compiling tool for clang build # apt-get install binutils-powerpc-linux-gnu # https://github.com/0day-ci/linux/commit/2dea3091811eb397337113498cf675a383412c59 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Paul-Cercueil/Add-option-to-mmap-GEM-buffers-cached/20210524-010735 git checkout 2dea3091811eb397337113498cf675a383412c59 # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=powerpc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All warnings (new ones prefixed by >>): In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:43:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insb, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :84:1: note: expanded from here __do_insb ^ arch/powerpc/include/asm/io.h:556:56: note: expanded from macro '__do_insb' #define __do_insb(p, b, n) readsb((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from drivers/gpu/drm/pl111/pl111_display.c:15: In file included from include/linux/dma-buf.h:16: In file included from include/linux/dma-buf-map.h:9: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:45:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insw, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :86:1: note: expanded from here __do_insw ^ arch/powerpc/include/asm/io.h:557:56: note: expanded from macro '__do_insw' #define __do_insw(p, b, n) readsw((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from drivers/gpu/drm/pl111/pl111_display.c:15: In file included from include/linux/dma-buf.h:16: In file included from include/linux/dma-buf-map.h:9: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:47:1: warning: performing pointer arithmetic on a null pointer has undefined behavior [-Wnull-pointer-arithmetic] DEF_PCI_AC_NORET(insl, (unsigned long p, void *b, unsigned long c), ^~~ arch/powerpc/include/asm/io.h:616:3: note: expanded from macro 'DEF_PCI_AC_NORET' __do_##name al; \ ^~ :88:1: note: expanded from here __do_insl ^ arch/powerpc/include/asm/io.h:558:56: note: expanded from macro '__do_insl' #define __do_insl(p, b, n) readsl((PCI_IO_ADDR)_IO_BASE+(p), (b), (n)) ~^ In file included from drivers/gpu/drm/pl111/pl111_display.c:15: In file included from include/linux/dma-buf.h:16: In file included from include/linux/dma-buf-map.h:9: In file included from include/linux/io.h:13: In file included from arch/powerpc/include/asm/io.h:619: arch/powerpc/include/asm/io-defs.h:49:1: warning: performing pointer arithmetic on a null pointer has
[PATCH v2] drm/i915/gem: Use list_entry to access list members
Use list_entry() instead of container_of() to access list members.
Also drop unnecessary and misleading NULL checks on the result of
list_entry().
Signed-off-by: Guenter Roeck
---
v2: Checkpatch fixes:
- Fix alignment
- Replace comparison against NULL with !
drivers/gpu/drm/i915/gvt/dmabuf.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
b/drivers/gpu/drm/i915/gvt/dmabuf.c
index d4f883f35b95..e3f488681484 100644
--- a/drivers/gpu/drm/i915/gvt/dmabuf.c
+++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
@@ -148,8 +148,7 @@ static void dmabuf_gem_object_free(struct kref *kref)
if (vgpu && vgpu->active && !list_empty(>dmabuf_obj_list_head)) {
list_for_each(pos, >dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos,
- struct intel_vgpu_dmabuf_obj, list);
+ dmabuf_obj = list_entry(pos, struct
intel_vgpu_dmabuf_obj, list);
if (dmabuf_obj == obj) {
list_del(pos);
intel_gvt_hypervisor_put_vfio_device(vgpu);
@@ -357,10 +356,8 @@ pick_dmabuf_by_info(struct intel_vgpu *vgpu,
struct intel_vgpu_dmabuf_obj *ret = NULL;
list_for_each(pos, >dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos, struct intel_vgpu_dmabuf_obj,
- list);
- if ((dmabuf_obj == NULL) ||
- (dmabuf_obj->info == NULL))
+ dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
+ if (!dmabuf_obj->info)
continue;
fb_info = (struct intel_vgpu_fb_info *)dmabuf_obj->info;
@@ -387,11 +384,7 @@ pick_dmabuf_by_num(struct intel_vgpu *vgpu, u32 id)
struct intel_vgpu_dmabuf_obj *ret = NULL;
list_for_each(pos, >dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos, struct intel_vgpu_dmabuf_obj,
- list);
- if (!dmabuf_obj)
- continue;
-
+ dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
if (dmabuf_obj->dmabuf_id == id) {
ret = dmabuf_obj;
break;
@@ -600,8 +593,7 @@ void intel_vgpu_dmabuf_cleanup(struct intel_vgpu *vgpu)
mutex_lock(>dmabuf_lock);
list_for_each_safe(pos, n, >dmabuf_obj_list_head) {
- dmabuf_obj = container_of(pos, struct intel_vgpu_dmabuf_obj,
- list);
+ dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
list);
dmabuf_obj->vgpu = NULL;
idr_remove(>object_idr, dmabuf_obj->dmabuf_id);
--
2.25.1
EPOLL for drm_syncfile (was Re: [PATCH 4/4] RFC: dma-buf: Add an API for importing sync files (v6))
Hi guys, separating that discussion out since Daniel had a rather interesting idea here. Am 22.05.21 um 22:05 schrieb Daniel Stone: [SNIP] Anyway, the problem with syncobj is that the ioctl to wait for a sync_file to materialise for a given timeline point only allows us to block with a timeout; this is a non-starter, because we need something which fits into epoll. The most optimal case is returning a new eventfd or similar which signals when a given timeline point becomes available or signaled, but in extremis a syncobj FD becoming readable when any activity which would change the result of any zero-timeout wait on that syncobj is more or less workable. I think the tricky part is to epoll for a certain value. Not sure how eventfd is supposed to work, but IIRC we don't have the functionality to poll for a certain value/offset etc to become available. We could of course create a separate fd for each requested value to poll for thought, but that sounds like a bit much overhead to me. Apart from that this is a really interesting idea. Regards, Christian.
[PATCH v5 2/3] drm: Add and export function drm_fb_cma_sync_non_coherent
This function can be used by drivers that use damage clips and have
CMA GEM objects backed by non-coherent memory. Calling this function
in a plane's .atomic_update ensures that all the data in the backing
memory have been written to RAM.
v3: - Only sync data if using GEM objects backed by non-coherent memory.
- Use a drm_device pointer instead of device pointer in prototype
v5: - Rename to drm_fb_cma_sync_non_coherent
- Invert loops for better cache locality
- Only sync BOs that have the non-coherent flag
- Move to drm_fb_cma_helper.c to avoid circular dependency
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/drm_fb_cma_helper.c | 46 +
include/drm/drm_fb_cma_helper.h | 4 +++
2 files changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index cb2349ad338d..69c57273b184 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -9,12 +9,14 @@
* Copyright (C) 2012 Red Hat
*/
+#include
#include
#include
#include
#include
#include
#include
+#include
#include
/**
@@ -97,3 +99,47 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
return paddr;
}
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
+
+/**
+ * drm_fb_cma_sync_non_coherent - Sync GEM object to non-coherent backing
+ * memory
+ * @drm: DRM device
+ * @old_state: Old plane state
+ * @state: New plane state
+ *
+ * This function can be used by drivers that use damage clips and have
+ * CMA GEM objects backed by non-coherent memory. Calling this function
+ * in a plane's .atomic_update ensures that all the data in the backing
+ * memory have been written to RAM.
+ */
+void drm_fb_cma_sync_non_coherent(struct drm_device *drm,
+ struct drm_plane_state *old_state,
+ struct drm_plane_state *state)
+{
+ const struct drm_format_info *finfo = state->fb->format;
+ struct drm_atomic_helper_damage_iter iter;
+ const struct drm_gem_cma_object *cma_obj;
+ unsigned int offset, i;
+ struct drm_rect clip;
+ dma_addr_t daddr;
+ size_t nb_bytes;
+
+ for (i = 0; i < finfo->num_planes; i++) {
+ cma_obj = drm_fb_cma_get_gem_obj(state->fb, i);
+ if (!cma_obj->map_noncoherent)
+ continue;
+
+ daddr = drm_fb_cma_get_gem_addr(state->fb, state, i);
+ drm_atomic_helper_damage_iter_init(, old_state, state);
+
+ drm_atomic_for_each_plane_damage(, ) {
+ /* Ignore x1/x2 values, invalidate complete lines */
+ offset = clip.y1 * state->fb->pitches[i];
+
+ nb_bytes = (clip.y2 - clip.y1) * state->fb->pitches[i];
+ dma_sync_single_for_device(drm->dev, daddr + offset,
+ nb_bytes, DMA_TO_DEVICE);
+ }
+ }
+}
+EXPORT_SYMBOL_GPL(drm_fb_cma_sync_non_coherent);
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/drm_fb_cma_helper.h
index 795aea1d0a25..3a177632b17e 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -14,5 +14,9 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer *fb,
struct drm_plane_state *state,
unsigned int plane);
+void drm_fb_cma_sync_non_coherent(struct drm_device *drm,
+ struct drm_plane_state *old_state,
+ struct drm_plane_state *state);
+
#endif
--
2.30.2
[PATCH v5 3/3] drm/ingenic: Add option to alloc cached GEM buffers
Alloc GEM buffers backed by noncoherent memory on SoCs where it is
actually faster than write-combine.
This dramatically speeds up software rendering on these SoCs, even for
tasks where write-combine memory should in theory be faster (e.g. simple
blits).
v3: The option is now selected per-SoC instead of being a module
parameter.
v5: - Fix drm_atomic_get_new_plane_state() used to retrieve the old
state
- Use custom drm_gem_fb_create()
- Only check damage clips and sync DMA buffers if non-coherent
buffers are used
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 59 +--
drivers/gpu/drm/ingenic/ingenic-drm.h | 1 +
drivers/gpu/drm/ingenic/ingenic-ipu.c | 21 ++--
3 files changed, 74 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
index 389cad59e090..5244f4763477 100644
--- a/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
+++ b/drivers/gpu/drm/ingenic/ingenic-drm-drv.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -23,6 +24,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -57,6 +59,7 @@ struct ingenic_dma_hwdescs {
struct jz_soc_info {
bool needs_dev_clk;
bool has_osd;
+ bool map_noncoherent;
unsigned int max_width, max_height;
const u32 *formats_f0, *formats_f1;
unsigned int num_formats_f0, num_formats_f1;
@@ -410,6 +413,9 @@ static int ingenic_drm_plane_atomic_check(struct drm_plane
*plane,
old_plane_state->fb->format->format !=
new_plane_state->fb->format->format))
crtc_state->mode_changed = true;
+ if (priv->soc_info->map_noncoherent)
+ drm_atomic_helper_check_plane_damage(state, new_plane_state);
+
return 0;
}
@@ -526,6 +532,13 @@ void ingenic_drm_plane_config(struct device *dev,
}
}
+bool ingenic_drm_map_noncoherent(const struct device *dev)
+{
+ const struct ingenic_drm *priv = dev_get_drvdata(dev);
+
+ return priv->soc_info->map_noncoherent;
+}
+
static void ingenic_drm_update_palette(struct ingenic_drm *priv,
const struct drm_color_lut *lut)
{
@@ -544,8 +557,8 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
struct drm_atomic_state *state)
{
struct ingenic_drm *priv = drm_device_get_priv(plane->dev);
- struct drm_plane_state *newstate = drm_atomic_get_new_plane_state(state,
-
plane);
+ struct drm_plane_state *newstate =
drm_atomic_get_new_plane_state(state, plane);
+ struct drm_plane_state *oldstate =
drm_atomic_get_old_plane_state(state, plane);
struct drm_crtc_state *crtc_state;
struct ingenic_dma_hwdesc *hwdesc;
unsigned int width, height, cpp, offset;
@@ -553,6 +566,9 @@ static void ingenic_drm_plane_atomic_update(struct
drm_plane *plane,
u32 fourcc;
if (newstate && newstate->fb) {
+ if (priv->soc_info->map_noncoherent)
+ drm_fb_cma_sync_non_coherent(>drm, oldstate,
newstate);
+
crtc_state = newstate->crtc->state;
addr = drm_fb_cma_get_gem_addr(newstate->fb, newstate, 0);
@@ -742,6 +758,33 @@ static void ingenic_drm_disable_vblank(struct drm_crtc
*crtc)
regmap_update_bits(priv->map, JZ_REG_LCD_CTRL, JZ_LCD_CTRL_EOF_IRQ, 0);
}
+static struct drm_framebuffer *
+ingenic_drm_gem_fb_create(struct drm_device *drm, struct drm_file *file,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ struct ingenic_drm *priv = drm_device_get_priv(drm);
+
+ if (priv->soc_info->map_noncoherent)
+ return drm_gem_fb_create_with_dirty(drm, file, mode_cmd);
+
+ return drm_gem_fb_create(drm, file, mode_cmd);
+}
+
+static struct drm_gem_object *
+ingenic_drm_gem_create_object(struct drm_device *drm, size_t size)
+{
+ struct ingenic_drm *priv = drm_device_get_priv(drm);
+ struct drm_gem_cma_object *obj;
+
+ obj = kzalloc(sizeof(*obj), GFP_KERNEL);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ obj->map_noncoherent = priv->soc_info->map_noncoherent;
+
+ return >base;
+}
+
DEFINE_DRM_GEM_CMA_FOPS(ingenic_drm_fops);
static const struct drm_driver ingenic_drm_driver_data = {
@@ -754,6 +797,7 @@ static const struct drm_driver ingenic_drm_driver_data = {
.patchlevel = 0,
.fops = _drm_fops,
+ .gem_create_object = ingenic_drm_gem_create_object,
DRM_GEM_CMA_DRIVER_OPS,
.irq_handler= ingenic_drm_irq_handler,
@@ -804,7 +848,7 @@ static const struct drm_encoder_helper_funcs
ingenic_drm_encoder_helper_funcs =
};
static const struct
[PATCH v5 1/3] drm: Add support for GEM buffers backed by non-coherent memory
Having GEM buffers backed by non-coherent memory is interesting in the
particular case where it is faster to render to a non-coherent buffer
then sync the data cache, than to render to a write-combine buffer, and
(by extension) much faster than using a shadow buffer. This is true for
instance on some Ingenic SoCs, where even simple blits (e.g. memcpy)
are about three times faster using this method.
Add a 'map_noncoherent' flag to the drm_gem_cma_object structure, which
can be set by the drivers when they create the dumb buffer.
Since this really only applies to software rendering, disable this flag
as soon as the CMA objects are exported via PRIME.
v3: New patch. Now uses a simple 'map_noncoherent' flag to control how
the objects are mapped, and use the new dma_mmap_pages function.
v4: Make sure map_noncoherent is always disabled when creating GEM
objects meant to be used with dma-buf.
Signed-off-by: Paul Cercueil
Acked-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_cma_helper.c | 38 +---
include/drm/drm_gem_cma_helper.h | 3 +++
2 files changed, 32 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
b/drivers/gpu/drm/drm_gem_cma_helper.c
index 7942cf05cd93..235c7a63da2b 100644
--- a/drivers/gpu/drm/drm_gem_cma_helper.c
+++ b/drivers/gpu/drm/drm_gem_cma_helper.c
@@ -46,6 +46,7 @@ static const struct drm_gem_object_funcs
drm_gem_cma_default_funcs = {
* __drm_gem_cma_create - Create a GEM CMA object without allocating memory
* @drm: DRM device
* @size: size of the object to allocate
+ * @private: true if used for internal purposes
*
* This function creates and initializes a GEM CMA object of the given size,
* but doesn't allocate any memory to back the object.
@@ -55,11 +56,11 @@ static const struct drm_gem_object_funcs
drm_gem_cma_default_funcs = {
* error code on failure.
*/
static struct drm_gem_cma_object *
-__drm_gem_cma_create(struct drm_device *drm, size_t size)
+__drm_gem_cma_create(struct drm_device *drm, size_t size, bool private)
{
struct drm_gem_cma_object *cma_obj;
struct drm_gem_object *gem_obj;
- int ret;
+ int ret = 0;
if (drm->driver->gem_create_object)
gem_obj = drm->driver->gem_create_object(drm, size);
@@ -73,7 +74,14 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size)
cma_obj = container_of(gem_obj, struct drm_gem_cma_object, base);
- ret = drm_gem_object_init(drm, gem_obj, size);
+ if (private) {
+ drm_gem_private_object_init(drm, gem_obj, size);
+
+ /* Always use writecombine for dma-buf mappings */
+ cma_obj->map_noncoherent = false;
+ } else {
+ ret = drm_gem_object_init(drm, gem_obj, size);
+ }
if (ret)
goto error;
@@ -111,12 +119,19 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
drm_device *drm,
size = round_up(size, PAGE_SIZE);
- cma_obj = __drm_gem_cma_create(drm, size);
+ cma_obj = __drm_gem_cma_create(drm, size, false);
if (IS_ERR(cma_obj))
return cma_obj;
- cma_obj->vaddr = dma_alloc_wc(drm->dev, size, _obj->paddr,
- GFP_KERNEL | __GFP_NOWARN);
+ if (cma_obj->map_noncoherent) {
+ cma_obj->vaddr = dma_alloc_noncoherent(drm->dev, size,
+ _obj->paddr,
+ DMA_TO_DEVICE,
+ GFP_KERNEL |
__GFP_NOWARN);
+ } else {
+ cma_obj->vaddr = dma_alloc_wc(drm->dev, size, _obj->paddr,
+ GFP_KERNEL | __GFP_NOWARN);
+ }
if (!cma_obj->vaddr) {
drm_dbg(drm, "failed to allocate buffer with size %zu\n",
size);
@@ -432,7 +447,7 @@ drm_gem_cma_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(-EINVAL);
/* Create a CMA GEM buffer. */
- cma_obj = __drm_gem_cma_create(dev, attach->dmabuf->size);
+ cma_obj = __drm_gem_cma_create(dev, attach->dmabuf->size, true);
if (IS_ERR(cma_obj))
return ERR_CAST(cma_obj);
@@ -499,8 +514,13 @@ int drm_gem_cma_mmap(struct drm_gem_object *obj, struct
vm_area_struct *vma)
cma_obj = to_drm_gem_cma_obj(obj);
- ret = dma_mmap_wc(cma_obj->base.dev->dev, vma, cma_obj->vaddr,
- cma_obj->paddr, vma->vm_end - vma->vm_start);
+ vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
+ if (!cma_obj->map_noncoherent)
+ vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
+
+ ret = dma_mmap_pages(cma_obj->base.dev->dev,
+vma, vma->vm_end - vma->vm_start,
+virt_to_page(cma_obj->vaddr));
if (ret)
[PATCH v5 0/3] Add option to mmap GEM buffers cached
V5 of my patchset which adds the option for having GEM buffers backed by non-coherent memory. Changes from V4: - [2/3]: - Rename to drm_fb_cma_sync_non_coherent - Invert loops for better cache locality - Only sync BOs that have the non-coherent flag - Properly sort includes - Move to drm_fb_cma_helper.c to avoid circular dependency - [3/3]: - Fix drm_atomic_get_new_plane_state() used to retrieve the old state - Use custom drm_gem_fb_create() - Only check damage clips and sync DMA buffers if non-coherent buffers are used Cheers, -Paul Paul Cercueil (3): drm: Add support for GEM buffers backed by non-coherent memory drm: Add and export function drm_fb_cma_sync_non_coherent drm/ingenic: Add option to alloc cached GEM buffers drivers/gpu/drm/drm_fb_cma_helper.c | 46 ++ drivers/gpu/drm/drm_gem_cma_helper.c | 38 +++ drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 59 +-- drivers/gpu/drm/ingenic/ingenic-drm.h | 1 + drivers/gpu/drm/ingenic/ingenic-ipu.c | 21 ++-- include/drm/drm_fb_cma_helper.h | 4 ++ include/drm/drm_gem_cma_helper.h | 3 ++ 7 files changed, 156 insertions(+), 16 deletions(-) -- 2.30.2
Re: [PATCH 06/11] drm/: drm_gem_plane_helper_prepare_fb is now the default
On Fri, May 21, 2021 at 11:10 AM Daniel Vetter wrote: > > No need to set it explicitly. > > Signed-off-by: Daniel Vetter > Cc: Laurentiu Palcu > Cc: Lucas Stach > Cc: Shawn Guo > Cc: Sascha Hauer > Cc: Pengutronix Kernel Team > Cc: Fabio Estevam > Cc: NXP Linux Team > Cc: Philipp Zabel > Cc: Paul Cercueil > Cc: Chun-Kuang Hu > Cc: Matthias Brugger > Cc: Neil Armstrong > Cc: Kevin Hilman > Cc: Jerome Brunet > Cc: Martin Blumenstingl > Cc: Marek Vasut > Cc: Stefan Agner > Cc: Sandy Huang > Cc: "Heiko Stübner" > Cc: Yannick Fertre > Cc: Philippe Cornu > Cc: Benjamin Gaignard > Cc: Maxime Coquelin > Cc: Alexandre Torgue > Cc: Maxime Ripard > Cc: Chen-Yu Tsai > Cc: Jernej Skrabec > Cc: Jyri Sarha > Cc: Tomi Valkeinen > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-m...@vger.kernel.org > Cc: linux-media...@lists.infradead.org > Cc: linux-amlo...@lists.infradead.org > Cc: linux-rockc...@lists.infradead.org > Cc: linux-st...@st-md-mailman.stormreply.com > Cc: linux-su...@lists.linux.dev > --- > drivers/gpu/drm/imx/dcss/dcss-plane.c | 1 - > drivers/gpu/drm/imx/ipuv3-plane.c | 1 - > drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 1 - > drivers/gpu/drm/ingenic/ingenic-ipu.c | 1 - > drivers/gpu/drm/mediatek/mtk_drm_plane.c| 1 - > drivers/gpu/drm/meson/meson_overlay.c | 1 - > drivers/gpu/drm/meson/meson_plane.c | 1 - For drivers/gpu/drm/meson/*: Acked-by: Martin Blumenstingl
Re: [PATCH RESEND] drm/hisilicon/kirin: Use the correct HiSilicon copyright
Hi Am 22.05.21 um 12:15 schrieb Hao Fang: s/Hisilicon/HiSilicon/. It should use capital S, according to https://www.hisilicon.com/en. Signed-off-by: Hao Fang Acked-by: Tian Tao It's been acked already. Tian can merge it for you. Best regards Thomas --- drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c| 2 +- drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h| 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c index 00e87c2..9b565a0 100644 --- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c +++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c @@ -3,7 +3,7 @@ * DesignWare MIPI DSI Host Controller v1.02 driver * * Copyright (c) 2016 Linaro Limited. - * Copyright (c) 2014-2016 Hisilicon Limited. + * Copyright (c) 2014-2016 HiSilicon Limited. * * Author: *Xinliang Liu diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h b/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h index 19e81ff..d79fc03 100644 --- a/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h +++ b/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h @@ -1,7 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-only */ /* * Copyright (c) 2016 Linaro Limited. - * Copyright (c) 2014-2016 Hisilicon Limited. + * Copyright (c) 2014-2016 HiSilicon Limited. */ #ifndef __DW_DSI_REG_H__ diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h index e2ac098..be9e789 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h @@ -1,7 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-only */ /* * Copyright (c) 2016 Linaro Limited. - * Copyright (c) 2014-2016 Hisilicon Limited. + * Copyright (c) 2014-2016 HiSilicon Limited. */ #ifndef __KIRIN_ADE_REG_H__ diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 6dcf9ec..1ab9462 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -3,7 +3,7 @@ * Hisilicon Hi6220 SoC ADE(Advanced Display Engine)'s crtc driver * * Copyright (c) 2016 Linaro Limited. - * Copyright (c) 2014-2016 Hisilicon Limited. + * Copyright (c) 2014-2016 HiSilicon Limited. * * Author: *Xinliang Liu diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c index 4349da3..e590e19 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c @@ -3,7 +3,7 @@ * Hisilicon Kirin SoCs drm master driver * * Copyright (c) 2016 Linaro Limited. - * Copyright (c) 2014-2016 Hisilicon Limited. + * Copyright (c) 2014-2016 HiSilicon Limited. * * Author: *Xinliang Liu diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h index 386d137..db0dc7b 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h @@ -1,7 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-only */ /* * Copyright (c) 2016 Linaro Limited. - * Copyright (c) 2014-2016 Hisilicon Limited. + * Copyright (c) 2014-2016 HiSilicon Limited. */ #ifndef __KIRIN_DRM_DRV_H__ -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer OpenPGP_signature Description: OpenPGP digital signature
[PATCH RESEND] drm/hisilicon/kirin: Use the correct HiSilicon copyright
s/Hisilicon/HiSilicon/. It should use capital S, according to https://www.hisilicon.com/en. Signed-off-by: Hao Fang Acked-by: Tian Tao --- drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c| 2 +- drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h| 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 2 +- drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 2 +- 6 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c index 00e87c2..9b565a0 100644 --- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c +++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c @@ -3,7 +3,7 @@ * DesignWare MIPI DSI Host Controller v1.02 driver * * Copyright (c) 2016 Linaro Limited. - * Copyright (c) 2014-2016 Hisilicon Limited. + * Copyright (c) 2014-2016 HiSilicon Limited. * * Author: * Xinliang Liu diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h b/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h index 19e81ff..d79fc03 100644 --- a/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h +++ b/drivers/gpu/drm/hisilicon/kirin/dw_dsi_reg.h @@ -1,7 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-only */ /* * Copyright (c) 2016 Linaro Limited. - * Copyright (c) 2014-2016 Hisilicon Limited. + * Copyright (c) 2014-2016 HiSilicon Limited. */ #ifndef __DW_DSI_REG_H__ diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h index e2ac098..be9e789 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_ade_reg.h @@ -1,7 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-only */ /* * Copyright (c) 2016 Linaro Limited. - * Copyright (c) 2014-2016 Hisilicon Limited. + * Copyright (c) 2014-2016 HiSilicon Limited. */ #ifndef __KIRIN_ADE_REG_H__ diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c index 6dcf9ec..1ab9462 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c @@ -3,7 +3,7 @@ * Hisilicon Hi6220 SoC ADE(Advanced Display Engine)'s crtc driver * * Copyright (c) 2016 Linaro Limited. - * Copyright (c) 2014-2016 Hisilicon Limited. + * Copyright (c) 2014-2016 HiSilicon Limited. * * Author: * Xinliang Liu diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c index 4349da3..e590e19 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c @@ -3,7 +3,7 @@ * Hisilicon Kirin SoCs drm master driver * * Copyright (c) 2016 Linaro Limited. - * Copyright (c) 2014-2016 Hisilicon Limited. + * Copyright (c) 2014-2016 HiSilicon Limited. * * Author: * Xinliang Liu diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h index 386d137..db0dc7b 100644 --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h @@ -1,7 +1,7 @@ /* SPDX-License-Identifier: GPL-2.0-only */ /* * Copyright (c) 2016 Linaro Limited. - * Copyright (c) 2014-2016 Hisilicon Limited. + * Copyright (c) 2014-2016 HiSilicon Limited. */ #ifndef __KIRIN_DRM_DRV_H__ -- 2.8.1
