Re: [meta-xilinx] [linux-xlnx] uio as module fails to link
Hi JFD, On Tue, 2019-07-09 at 11:07:03 -0700, Jean-Francois Dagenais wrote: > > > > On Jul 9, 2019, at 12:59, Hyun Kwon wrote: > > > > > > The Kconfig takes care of it by selecting CONFIG_DMA_SHARED_BUFFER because > > I didn't want to add #ifdefs for downstream changes. > > Ok. But what if someone has no use for DMABUF and doesn't want the extra code > weight, but does want UIO? I.e. a dmabuf-less UIO module? I mean, UIO exists > without all these functions. Automatically adding all this code to the module, > although it would not bother me all that much, might upset some. > > Cheers! Yes, I understand points you made. But for that, I may end up adding another uio dmabuf config and adding several #ifdefs or even making it as a completely separate module. It seemed overkill to me for a couple of hundred lines of code. I wanted to keep it simple and less intrusive. Maybe I was being lazy. :-) Thanks, -hyun -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] [linux-xlnx] uio as module fails to link
Hi JFD,
Thanks for taking a look.
On Tue, 2019-07-09 at 05:26:43 -0700, Jean-Francois Dagenais wrote:
> Quick turn-around!
>
> > On Jul 8, 2019, at 14:51, Hyun Kwon wrote:
> >
> > Hi JFD,
> >
> > Thanks for reporting the issue.
> >
> > On Mon, 2019-07-08 at 09:01:03 -0700, Jean-Francois Dagenais wrote:
> >> Anyone tried that? I get:
> >>
> >> WARNING: modpost: missing MODULE_LICENSE() in drivers/uio/uio_dmabuf.o
> >> see include/linux/module.h for more information
> >> ERROR: "uio_dmabuf_map" [drivers/uio/uio.ko] undefined!
> >> ERROR: "uio_dmabuf_unmap" [drivers/uio/uio.ko] undefined!
> >> ERROR: "uio_dmabuf_cleanup" [drivers/uio/uio.ko] undefined!
> >>
> >> uio/Makefile shows:
> >> obj-$(CONFIG_UIO) += uio.o uio_dmabuf.o
> >>
> >> I got it to compile by hacking uio.c to #include uio_dmabuf.c instead of
> >> the .h but that's probably not the correct way to fix this.
> >>
> >
> > The easiest fix would be to merge uio_dmabuf.c into uio.c. Please see
> > the attached patch and let me know if you see any other better way.
>
> > Hehe, that was essentially what my #include "uio_dmabuf.c" was doing. This
> > patch
> > fixes the problem. See my suggestion below.
Indeed. :-) It doesn't seem to work by fixing the makefile.
> >
> > Thanks,
> > -hyun
> >
> > From 84cbe02cf2775dca911c2b734dded794150698a8 Mon Sep 17 00:00:00 2001
> > From: Hyun Kwon
> > Date: Mon, 8 Jul 2019 11:37:03 -0700
> > Subject: [PATCH 1/1] uio: dmabuf: Merge the dmabuf functions into uio.c
> >
> > With a separate uio_dmabuf.c, it's tricky to build the uio as
> > a separate kernel module.
> >
> > Reported-by: Jean-Francois Dagenais
> > Signed-off-by: Hyun Kwon
>
> Tested-by: Jean-Francois Dagenais
>
Thanks. I'll take this tag into this patch.
> > ---
> > drivers/uio/Makefile | 2 +-
> > drivers/uio/uio.c| 191 ++
> > drivers/uio/uio_dmabuf.c | 210
> > ---
> > 3 files changed, 192 insertions(+), 211 deletions(-)
> > delete mode 100644 drivers/uio/uio_dmabuf.c
> >
> > diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
> > index 7af888a..aea3e17 100644
> > --- a/drivers/uio/Makefile
> > +++ b/drivers/uio/Makefile
> > @@ -1,5 +1,5 @@
> > # SPDX-License-Identifier: GPL-2.0
> > -obj-$(CONFIG_UIO) += uio.o uio_dmabuf.o
> > +obj-$(CONFIG_UIO) += uio.o
> > obj-$(CONFIG_UIO_CIF) += uio_cif.o
> > obj-$(CONFIG_UIO_PDRV_GENIRQ) += uio_pdrv_genirq.o
> > obj-$(CONFIG_UIO_DMEM_GENIRQ) += uio_dmem_genirq.o
> > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
> > index e054fa7..175fb6b 100644
> > --- a/drivers/uio/uio.c
> > +++ b/drivers/uio/uio.c
> > @@ -26,6 +26,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > #include
> >
> > @@ -455,6 +456,196 @@ static irqreturn_t uio_interrupt(int irq, void
> > *dev_id)
> > return ret;
> > }
>
> Would it be better to put all this dmabuf inside a
> #ifdef CONFIG_DMA_SHARED_BUFFER
> maybe? (Or IS_REACHABLE(CONFIG_DMA_SHARED_BUFFER), not sure which formulation
> works for all cases...)
The Kconfig takes care of it by selecting CONFIG_DMA_SHARED_BUFFER because
I didn't want to add #ifdefs for downstream changes.
Thanks,
-hyun
>
> >
> > +struct uio_dmabuf_mem {
> > + int dbuf_fd;
> > + struct dma_buf *dbuf;
> > + struct dma_buf_attachment *dbuf_attach;
> > + struct sg_table *sgt;
> > + enum dma_data_direction dir;
> > + struct list_head list;
> > +};
> > +
> > +long uio_dmabuf_map(struct uio_device *dev, struct list_head *dbufs,
> > + struct mutex *dbufs_lock, void __user *user_args)
> > +{
> > + struct uio_dmabuf_args args;
> > + struct uio_dmabuf_mem *dbuf_mem;
> > + struct dma_buf *dbuf;
> > + struct dma_buf_attachment *dbuf_attach;
> > + enum dma_data_direction dir;
> > + struct sg_table *sgt;
> > + long ret;
> > +
> > + if (copy_from_user(&args, user_args, sizeof(args))) {
> > + ret = -EFAULT;
> > + dev_err(dev->dev.parent, "failed to copy from user\n");
> > + goto err;
> > + }
> > +
> > + dbuf = dma_buf_get(args.dbuf_fd);
> > + if (IS_ERR(dbuf)) {
> > + dev_err(dev->dev.parent, "failed to get dmabuf\n");
> > + return PTR_ERR(dbuf);
> > + }
> > +
> > + dbuf_attach = dma_buf_attach(dbuf, dev->dev.parent);
> > + if (IS_ERR(dbuf_attach)) {
> > + dev_err(dev->dev.parent, "failed to attach dmabuf\n");
> > + ret = PTR_ERR(dbuf_attach);
> > + goto err_put;
> > + }
> > +
> > [...]
>
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] [linux-xlnx] uio as module fails to link
Hi JFD,
Thanks for reporting the issue.
On Mon, 2019-07-08 at 09:01:03 -0700, Jean-Francois Dagenais wrote:
> Anyone tried that? I get:
>
> WARNING: modpost: missing MODULE_LICENSE() in drivers/uio/uio_dmabuf.o
> see include/linux/module.h for more information
> ERROR: "uio_dmabuf_map" [drivers/uio/uio.ko] undefined!
> ERROR: "uio_dmabuf_unmap" [drivers/uio/uio.ko] undefined!
> ERROR: "uio_dmabuf_cleanup" [drivers/uio/uio.ko] undefined!
>
> uio/Makefile shows:
> obj-$(CONFIG_UIO) += uio.o uio_dmabuf.o
>
> I got it to compile by hacking uio.c to #include uio_dmabuf.c instead of the
> .h but that's probably not the correct way to fix this.
>
The easiest fix would be to merge uio_dmabuf.c into uio.c. Please see
the attached patch and let me know if you see any other better way.
Thanks,
-hyun
>From 84cbe02cf2775dca911c2b734dded794150698a8 Mon Sep 17 00:00:00 2001
From: Hyun Kwon
Date: Mon, 8 Jul 2019 11:37:03 -0700
Subject: [PATCH 1/1] uio: dmabuf: Merge the dmabuf functions into uio.c
With a separate uio_dmabuf.c, it's tricky to build the uio as
a separate kernel module.
Reported-by: Jean-Francois Dagenais
Signed-off-by: Hyun Kwon
---
drivers/uio/Makefile | 2 +-
drivers/uio/uio.c| 191 ++
drivers/uio/uio_dmabuf.c | 210 ---
3 files changed, 192 insertions(+), 211 deletions(-)
delete mode 100644 drivers/uio/uio_dmabuf.c
diff --git a/drivers/uio/Makefile b/drivers/uio/Makefile
index 7af888a..aea3e17 100644
--- a/drivers/uio/Makefile
+++ b/drivers/uio/Makefile
@@ -1,5 +1,5 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_UIO) += uio.o uio_dmabuf.o
+obj-$(CONFIG_UIO) += uio.o
obj-$(CONFIG_UIO_CIF) += uio_cif.o
obj-$(CONFIG_UIO_PDRV_GENIRQ) += uio_pdrv_genirq.o
obj-$(CONFIG_UIO_DMEM_GENIRQ) += uio_dmem_genirq.o
diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c
index e054fa7..175fb6b 100644
--- a/drivers/uio/uio.c
+++ b/drivers/uio/uio.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
@@ -455,6 +456,196 @@ static irqreturn_t uio_interrupt(int irq, void *dev_id)
return ret;
}
+struct uio_dmabuf_mem {
+ int dbuf_fd;
+ struct dma_buf *dbuf;
+ struct dma_buf_attachment *dbuf_attach;
+ struct sg_table *sgt;
+ enum dma_data_direction dir;
+ struct list_head list;
+};
+
+long uio_dmabuf_map(struct uio_device *dev, struct list_head *dbufs,
+ struct mutex *dbufs_lock, void __user *user_args)
+{
+ struct uio_dmabuf_args args;
+ struct uio_dmabuf_mem *dbuf_mem;
+ struct dma_buf *dbuf;
+ struct dma_buf_attachment *dbuf_attach;
+ enum dma_data_direction dir;
+ struct sg_table *sgt;
+ long ret;
+
+ if (copy_from_user(&args, user_args, sizeof(args))) {
+ ret = -EFAULT;
+ dev_err(dev->dev.parent, "failed to copy from user\n");
+ goto err;
+ }
+
+ dbuf = dma_buf_get(args.dbuf_fd);
+ if (IS_ERR(dbuf)) {
+ dev_err(dev->dev.parent, "failed to get dmabuf\n");
+ return PTR_ERR(dbuf);
+ }
+
+ dbuf_attach = dma_buf_attach(dbuf, dev->dev.parent);
+ if (IS_ERR(dbuf_attach)) {
+ dev_err(dev->dev.parent, "failed to attach dmabuf\n");
+ ret = PTR_ERR(dbuf_attach);
+ goto err_put;
+ }
+
+ switch (args.dir) {
+ case UIO_DMABUF_DIR_BIDIR:
+ dir = DMA_BIDIRECTIONAL;
+ break;
+ case UIO_DMABUF_DIR_TO_DEV:
+ dir = DMA_TO_DEVICE;
+ break;
+ case UIO_DMABUF_DIR_FROM_DEV:
+ dir = DMA_FROM_DEVICE;
+ break;
+ default:
+ /* Not needed with check. Just here for any future change */
+ dev_err(dev->dev.parent, "invalid direction\n");
+ ret = -EINVAL;
+ goto err_detach;
+ }
+
+ sgt = dma_buf_map_attachment(dbuf_attach, dir);
+ if (IS_ERR(sgt)) {
+ dev_err(dev->dev.parent, "failed to get dmabuf scatterlist\n");
+ ret = PTR_ERR(sgt);
+ goto err_detach;
+ }
+
+ /* Accept only contiguous one */
+ if (sgt->nents != 1) {
+ dma_addr_t next_addr = sg_dma_address(sgt->sgl);
+ struct scatterlist *s;
+ unsigned int i;
+
+ for_each_sg(sgt->sgl, s, sgt->nents, i) {
+ if (!sg_dma_len(s))
+ continue;
+
+ if (sg_dma_address(s) != next_addr) {
+ dev_err(dev->dev.parent,
+ "dmabuf not contiguous\n");
+
Re: [meta-xilinx] [PATCH v2] kernel-module-mali: add patch to check dma_map_page error
Hi JFD, + Mads Thanks for the patch. > -Original Message- > From: Jean-Francois Dagenais [mailto:jeff.dagen...@gmail.com] > Sent: Tuesday, March 12, 2019 11:17 AM > To: meta-xil...@lists.yoctoproject.org > Cc: Hyun Kwon ; Jean-Francois Dagenais > > Subject: [PATCH v2] kernel-module-mali: add patch to check > dma_map_page error > > This fixes an error when using the module in a kernel configured with > the CONFIG_DMA_API_DEBUG flag. > > utgard fd4b.gpu: DMA-API: device driver failed to check map > error[device address=0x325b] [size=4096 bytes] [mapped as > page] > ... > [] check_unmap+0x44c/0x7e8 > [] debug_dma_unmap_page+0x60/0x68 > [] mali_mem_os_alloc_pages+0x230/0x498 [mali] > ... > > Acked-by: Hyun Kwon > Signed-off-by: Jean-Francois Dagenais > --- > .../recipes-graphics/mali/kernel-module-mali.bb | 1 + > .../0007-fix-driver-failed-to-check-map-error.patch | 17 > + > 2 files changed, 18 insertions(+) > create mode 100644 meta-xilinx-bsp/recipes-graphics/mali/kernel-module- > mali/0007-fix-driver-failed-to-check-map-error.patch > > diff --git a/meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali.bb > b/meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali.bb > index 0f44d25..5833239 100644 > --- a/meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali.bb > +++ b/meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali.bb > @@ -16,6 +16,7 @@ SRC_URI = " \ > file://0004-staging-mali-r8p0-01rel0-Don-t-include- > mali_read_phy.patch \ > file://0005-linux-mali_kernel_linux.c-Handle-clock-when-probed- > a.patch \ > file://0006-arm.c-global-variable-dma_ops-is-removed-from-the- > ke.patch \ > + file://0007-fix-driver-failed-to-check-map-error.patch \ > file://0010-common-mali_pm.c-Add-PM-runtime-barrier-after- > removi.patch \ > file://0011-linux-mali_kernel_linux.c-Enable-disable-clock-for- > r.patch\ > " I'm still not sure why this list looks different here, unless I'm missing something: https://github.com/Xilinx/meta-xilinx/blob/rel-v2018.3/meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali.bb https://github.com/Xilinx/meta-xilinx/blob/master-next/meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali.bb If that is the case, it'll probably fail to apply. Thanks, -hyun -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] [PATCH] kernel-module-mali: check and honour dma_unmap_page exit code
Hi JFD, On Fri, 2019-02-22 at 12:57:23 -0800, Manjukumar Harthikote Matha wrote: >Hi JFD, > > >Please send v2 with correction suggested by Hyun > > >Thanks, > >Manju > >From: meta-xilinx-boun...@yoctoproject.org >[mailto:meta-xilinx-boun...@yoctoproject.org] On Behalf Of >Jean-Francois Dagenais >Sent: Friday, February 22, 2019 5:04 AM >To: Hyun Kwon > Cc: meta-xil...@lists.yoctoproject.org; Hyun Kwon >Subject: Re: [meta-xilinx] [PATCH] kernel-module-mali: check and honour >dma_unmap_page exit code > > >Hi Hyun, > >On Feb 21, 2019, at 17:25, Hyun Kwon <[1]hyun.k...@xilinx.com> wrote: > > >Hi Jean-Francois, >Thanks for the patch. >On Tue, 2019-02-19 at 09:16:46 -0800, Jean-Francois Dagenais wrote: > > Sorry, the subject should be: > kernel-module-mali: check and honour dma_map_page exit code > instead of "dma_UNmap_page" > >Why using upper case, 'UN'? > >It was just emphasis on what the mistake on the commit headline was... >trying to remove the subtlety. > > On Feb 19, 2019, at 10:39, Jean-Francois Dagenais > <[2]jeff.dagen...@gmail.com> wrote: > This fixes an error when using the module in a kernel configured > with > the CONFIG_DMA_API_DEBUG flag. > utgard fd4b.gpu: DMA-API: device driver failed to check map > error[device address=0x325b] [size=4096 bytes] [mapped > as page] > ... > [] check_unmap+0x44c/0x7e8 > [] debug_dma_unmap_page+0x60/0x68 > [] mali_mem_os_alloc_pages+0x230/0x498 [mali] > ... > Signed-off-by: Jean-Francois Dagenais <[3]dagena...@sonatest.com> > >I believe the Yocto patch requires the upstreaming status. Please refer >to >other patches. You can mark it as pending. Our team can share this to >ARM >internally. > >noted. > > --- > .../recipes-graphics/mali/[4]https://linkprotect.cudasvc.com/url?a=h > ttps%3a%2f%2fkernel-module-mali.bb&c=E,1,7H1c4ml0nbgV5Y-a8ex5Nz-45BC > lZi0HAb8rSq_LVyywEvSS_hmK5Elx6jiQ69wE9_E1QeXVcbkuLM3wVzF94BmsSb6qcax > lV72Yhev6VOpD-Va8ik99UVY,&typo=1 | 1 + > .../0007-fix-driver-failed-to-check-map-error.patch | 16 > > 2 files changed, 17 insertions(+) > create mode 100644 > meta-xilinx-bsp/recipes-graphics/mali/kernel-module-mali/0007-fix-dr > iver-failed-to-check-map-error.patch > diff --git > a/meta-xilinx-bsp/recipes-graphics/mali/[5]https://linkprotect.cudas > vc.com/url?a=https%3a%2f%2fkernel-module-mali.bb&c=E,1,_43jl_v77hUeZ > 715j6nn3vef5fYyi5F8RndfWf7jFiMkSoYFNOFmaBY-eCWB04sK6Rs2xuAQXQQLPfB3D > R-4vTWdAeyhs1FG88HNCPpxRT4IBMFxfpo,&typo=1 > b/meta-xilinx-bsp/recipes-graphics/mali/[6]https://linkprotect.cudas > vc.com/url?a=https%3a%2f%2fkernel-module-mali.bb&c=E,1,JaZ3yJLlmgR_Q > e9c3t82B8aU2fH7lMmTxdGS2rEmZdyNWYlZXRBMelmmmJNcH07ltvr8DLau5iRr3aHww > _esitrJ74H-z6N3l499VbXohkosRapNSkht&typo=1 > index 0f44d25..5833239 100644 > --- > a/meta-xilinx-bsp/recipes-graphics/mali/[7]https://linkprotect.cudas > vc.com/url?a=https%3a%2f%2fkernel-module-mali.bb&c=E,1,JqkVEZw5PLC_a > cDxcaxe3EmRTDzQtpfOF0S4ihWN30-lP3msD4vK_acCQ9sKuS5qgR16izABptBPu3V1Z > iG5Asv_MlTX6zV8I0Sis_DkCyxAetfsx3tIR_xQvQ,,&typo=1 > +++ > b/meta-xilinx-bsp/recipes-graphics/mali/[8]https://linkprotect.cudas > vc.com/url?a=https%3a%2f%2fkernel-module-mali.bb&c=E,1,BrH3PiHKnMb_d > JfDtP8QdTfn_a_1u4u6-Op5vJEWvlZOpwm8o6Girdnwajqk5AnN4y9nDiNOQlDSJVCmn > VqNSjABPOdFOeXlvF-4gujGyfw,&typo=1 > @@ -16,6 +16,7 @@ SRC_URI = " \ > > [9]file://0004-staging-mali-r8p0-01rel0-Don-t-include-mali_read_phy. > patch \ > > [10]file://0005-linux-mali_kernel_linux.c-Handle-clock-when-probed-a > .patch \ > > [11]file://0006-arm.c-global-variable-dma_ops-is-removed-from-the-ke > .patch \ > + > [12]file://0007-fix-driver-failed-to-check-map-error.patch \ > >This list is different from what I see in the head. There's no empty >index >there. Then this can be 0012. Maybe we are looking at differnt >branches. Please >confirm. > > >You mean meta-xilinx/master? I will check and apply there with proper >sequence number. > > > [13]file://0010-common-mali_pm.c-Add-PM-runtime-barrier-after-removi > .patch \ > > [14]file://0011-linux-mali_kernel_linux.c-Enable-disable-clock-for-r > .patch
Re: [meta-xilinx] libmali EGLDeviceExt support
Hi Jean-Francois, The EGLDeviceEXT, which seems to require EGL 1.5, is not supported by the libMali, which supports EGL 1.4. I believe the requirement here is to be able to specify which fb device file to open. The change is relatively simple, but unfortunately it's not currently in our plan. And just for information, internally, we are enabling the mali drm backend to support wayland. We don't run eglfs kms on the mali with drm backend, so not sure if it works out of box or not. It may be worth trying though. If the support case is filed through Xilinx, we will be able to prioritize accordingly. Otherwise, only option that I can think of is to use X11, run multiple X11 instances and run Qt on corresponding instance. I understand this is not your preferred approach. Thanks, -hyun > -Original Message- > From: Jean-Francois Dagenais [mailto:jeff.dagen...@gmail.com] > Sent: Tuesday, July 17, 2018 11:57 AM > To: Madhurkiran Harikrishnan ; Manjukumar > Harthikote Matha ; meta- > xil...@lists.yoctoproject.org > Cc: Hyun Kwon ; Maxime Roussin-Bélanger > > Subject: libmali EGLDeviceExt support > > Hi all, > > We have a dual screen setup running on top of xilinx/linux/4.14's new XLNX > DRM (Thanks Hyun, great job with the refactor BTW). So far I can only set > the dual display through the native KMS modetest command line. > > Now we need to make Qt5 work. To make things clean, we thought we'd > use the modern APIs for this, namely something like this: > http://doc.qt.io/qt-5/embedded-linux.html#advanced-eglfs-kms-features in > order to setup the cloned screens on /dev/dri/card0. > > The problem is that the libMali provided binaries only use /dev/fb0 and the > corresponding EGL header files are too old such that EGLDeviceEXT is not > defined. Thus Qt's generic > qtbase/src/plugins/platforms/eglfs/deviceintegration/eglfs_kms_egldevice > will simply not work. > > Is there any way xilinx will provide a updated libmali package? Or is there > any other ways to use the MALI on top of EGLFS? We are trying, if possible, > to avoid larger window frameworks such as X11 and wayland. And we are > also under the impression, so far and perhaps falsely, that we cannot setup > our screen cloning using the currently provided libmali-xlnx stack. > > Thanks for any pointers. > /jfd > -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] [PATCH] kernel-module-mali: remove unused trace macros
Hi Yasir, Thanks for the patch. > -Original Message- > From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx- > boun...@yoctoproject.org] On Behalf Of Yasir Khan > Sent: Friday, November 04, 2016 7:04 AM > To: meta-xil...@lists.yoctoproject.org > Subject: [meta-xilinx] [PATCH] kernel-module-mali: remove unused trace > macros > > From: Yasir-Khan > > Based on > https://patchwork.kernel.org/patch/6150651/ > https://github.com/Xilinx/linux- > xlnx/commit/dadb5e41f28f9619debc9aae4ae543aa1dcd5be8 > > Signed-off-by: Yasir-Khan Reviewed-by: Hyun Kwon Thanks, -hyun This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] [PATCH] mali: fix a typo in using stringify macro
Hi Yasir,
Thanks for the patch.
> -Original Message-
> From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx-
> boun...@yoctoproject.org] On Behalf Of Yasir Khan
> Sent: Monday, October 31, 2016 7:44 AM
> To: meta-xil...@lists.yoctoproject.org
> Subject: [meta-xilinx] [PATCH] mali: fix a typo in using stringify macro
>
> From: Yasir-Khan
>
> When mali kernel module is built with tracing enabled, it throws compilation
> error due to a typo in stringify macro.
>
> Signed-off-by: Yasir-Khan
> ---
> recipes-graphics/mali/kernel-module-mali.bb| 1 +
> ...i_linux_trace-fix-typo-in-stringify-macro.patch | 29
> ++
> 2 files changed, 30 insertions(+)
> create mode 100644 recipes-graphics/mali/kernel-module-mali/0001-
> mali_linux_trace-fix-typo-in-stringify-macro.patch
>
> diff --git a/recipes-graphics/mali/kernel-module-mali.bb b/recipes-
> graphics/mali/kernel-module-mali.bb
> index c809243..128973d 100644
> --- a/recipes-graphics/mali/kernel-module-mali.bb
> +++ b/recipes-graphics/mali/kernel-module-mali.bb
> @@ -11,6 +11,7 @@ PV = "r5p1-01rel0"
> SRC_URI = " \
> http://malideveloper.arm.com/downloads/drivers/DX910/${PV}/DX910-
> SW-99002-${PV}.tgz \
> file://Makefile.patch \
> + file://0001-mali_linux_trace-fix-typo-in-stringify-macro.patch \
> "
> SRC_URI[md5sum] = "9c85c113e4d41ae992e45ba27287d1ab"
> SRC_URI[sha256sum] =
> "86209c99c36a7622402b016b6f764c212b738ccdec9cdc6d6f16758c013957a0"
> diff --git
> a/recipes-graphics/mali/kernel-module-mali/0001-mali_linux_trace-fix-
> typo-in-stringify-macro.patch b/recipes-graphics/mali/kernel-module-
> mali/0001-mali_linux_trace-fix-typo-in-stringify-macro.patch
> new file mode 100644
> index 000..5657442
> --- /dev/null
> +++ b/recipes-graphics/mali/kernel-module-mali/0001-mali_linux_trace-fix-
> typo-in-stringify-macro.patch
> @@ -0,0 +1,29 @@
> +From 69e3a37715600761358c58d71a777d292cb429dd Mon Sep 17 00:00:00
> 2001
> +From: Yasir-Khan
> +Date: Mon, 31 Oct 2016 16:45:46 +0500
> +Subject: [PATCH] mali_linux_trace: fix typo in stringify macro
> +
> +When mali kernel module is built with tracing enabled, we get
> +compilation error due to a typo in stringify macro.
> +
> +Signed-off-by: Yasir-Khan
> +---
> + driver/src/devicedrv/mali/linux/mali_linux_trace.h | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/driver/src/devicedrv/mali/linux/mali_linux_trace.h
> b/driver/src/devicedrv/mali/linux/mali_linux_trace.h
> +index c6cd2bf..7c27b92 100644
> +--- a/linux/mali_linux_trace.h
> b/linux/mali_linux_trace.h
> +@@ -18,7 +18,7 @@
> +
> + #undef TRACE_SYSTEM
> + #define TRACE_SYSTEM mali
> +-#define TRACE_SYSTEM_STRING __stringfy(TRACE_SYSTEM)
> ++#define TRACE_SYSTEM_STRING __stringify(TRACE_SYSTEM)
Wouldn't it make more sense to remove this macro from MALI driver? In recent
Linux kernel, all TRACE_SYSTEM_STRING have been removed: ex,
https://patchwork.kernel.org/patch/6150651/
Similar patch has been merged in Xilinx Linux tree:
https://github.com/Xilinx/linux-xlnx/commit/dadb5e41f28f9619debc9aae4ae543aa1dcd5be8
Thanks,
-hyun
This email and any attachments are intended for the sole use of the named
recipient(s) and contain(s) confidential information that may be proprietary,
privileged or copyrighted under applicable law. If you are not the intended
recipient, do not read, copy, or forward this email message or any attachments.
Delete this email message and any attachments immediately.
--
___
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
