* [PATCH v2] [media] mtk-vcodec: fix more type mismatches
@ 2016-07-13 8:47 Arnd Bergmann
2016-07-13 10:52 ` pochun lin
0 siblings, 1 reply; 4+ messages in thread
From: Arnd Bergmann @ 2016-07-13 8:47 UTC (permalink / raw)
To: Hans Verkuil
Cc: Arnd Bergmann, Mauro Carvalho Chehab, Matthias Brugger,
PoChun Lin, Tiffany Lin, linux-media, linux-arm-kernel,
linux-mediatek, linux-kernel
The newly added mtk-vcodec driver produces a number of warnings in an ARM
allmodconfig build, mainly since it assumes that dma_addr_t is 32-bit wide:
mtk-vcodec/venc/venc_vp8_if.c: In function 'vp8_enc_alloc_work_buf':
mtk-vcodec/venc/venc_vp8_if.c:212:191: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
mtk-vcodec/venc/venc_h264_if.c: In function 'h264_enc_alloc_work_buf':
mtk-vcodec/venc/venc_h264_if.c:297:190: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
This rearranges the format strings and type casts to what they should have been
in order to avoid the warnings. e0f80d8d62f5 ("[media] mtk-vcodec: fix two compiler
warnings") fixed some of the problems that were introduced at the same time, but
missed two others.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c | 4 ++--
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
index f4e18bb44cb9..9a600525b3c1 100644
--- a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
@@ -295,9 +295,9 @@ static int h264_enc_alloc_work_buf(struct venc_h264_inst *inst)
wb[i].iova = inst->work_bufs[i].dma_addr;
mtk_vcodec_debug(inst,
- "work_buf[%d] va=0x%p iova=0x%p size=%zu",
+ "work_buf[%d] va=0x%p iova=%pad size=%zu",
i, inst->work_bufs[i].va,
- (void *)inst->work_bufs[i].dma_addr,
+ &inst->work_bufs[i].dma_addr,
inst->work_bufs[i].size);
}
diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
index 5b4ef0f1740c..60bbcd2a0510 100644
--- a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
@@ -210,9 +210,9 @@ static int vp8_enc_alloc_work_buf(struct venc_vp8_inst *inst)
wb[i].iova = inst->work_bufs[i].dma_addr;
mtk_vcodec_debug(inst,
- "work_bufs[%d] va=0x%p,iova=0x%p,size=%zu",
+ "work_bufs[%d] va=0x%p,iova=%pad,size=%zu",
i, inst->work_bufs[i].va,
- (void *)inst->work_bufs[i].dma_addr,
+ &inst->work_bufs[i].dma_addr,
inst->work_bufs[i].size);
}
--
2.9.0
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: [PATCH v2] [media] mtk-vcodec: fix more type mismatches
2016-07-13 8:47 [PATCH v2] [media] mtk-vcodec: fix more type mismatches Arnd Bergmann
@ 2016-07-13 10:52 ` pochun lin
2016-07-13 13:17 ` Arnd Bergmann
0 siblings, 1 reply; 4+ messages in thread
From: pochun lin @ 2016-07-13 10:52 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Hans Verkuil, Mauro Carvalho Chehab, Matthias Brugger,
Tiffany Lin, linux-media, linux-arm-kernel, linux-mediatek,
linux-kernel
Hi Arnd,
On Wed, 2016-07-13 at 10:47 +0200, Arnd Bergmann wrote:
> The newly added mtk-vcodec driver produces a number of warnings in an ARM
> allmodconfig build, mainly since it assumes that dma_addr_t is 32-bit wide:
>
> mtk-vcodec/venc/venc_vp8_if.c: In function 'vp8_enc_alloc_work_buf':
> mtk-vcodec/venc/venc_vp8_if.c:212:191: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
> mtk-vcodec/venc/venc_h264_if.c: In function 'h264_enc_alloc_work_buf':
> mtk-vcodec/venc/venc_h264_if.c:297:190: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
>
> This rearranges the format strings and type casts to what they should have been
> in order to avoid the warnings. e0f80d8d62f5 ("[media] mtk-vcodec: fix two compiler
> warnings") fixed some of the problems that were introduced at the same time, but
> missed two others.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c | 4 ++--
> drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> index f4e18bb44cb9..9a600525b3c1 100644
> --- a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> +++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> @@ -295,9 +295,9 @@ static int h264_enc_alloc_work_buf(struct venc_h264_inst *inst)
> wb[i].iova = inst->work_bufs[i].dma_addr;
>
> mtk_vcodec_debug(inst,
> - "work_buf[%d] va=0x%p iova=0x%p size=%zu",
> + "work_buf[%d] va=0x%p iova=%pad size=%zu",
> i, inst->work_bufs[i].va,
> - (void *)inst->work_bufs[i].dma_addr,
> + &inst->work_bufs[i].dma_addr,
> inst->work_bufs[i].size);
> }
>
This modified will dump dma_addr's address, not dma_addr value.
In actually, we need to dump dma_addr value.
Thanks.
> diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> index 5b4ef0f1740c..60bbcd2a0510 100644
> --- a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> +++ b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> @@ -210,9 +210,9 @@ static int vp8_enc_alloc_work_buf(struct venc_vp8_inst *inst)
> wb[i].iova = inst->work_bufs[i].dma_addr;
>
> mtk_vcodec_debug(inst,
> - "work_bufs[%d] va=0x%p,iova=0x%p,size=%zu",
> + "work_bufs[%d] va=0x%p,iova=%pad,size=%zu",
> i, inst->work_bufs[i].va,
> - (void *)inst->work_bufs[i].dma_addr,
> + &inst->work_bufs[i].dma_addr,
> inst->work_bufs[i].size);
> }
>
The same as above.
Best Regards
PoChun
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [PATCH v2] [media] mtk-vcodec: fix more type mismatches
2016-07-13 10:52 ` pochun lin
@ 2016-07-13 13:17 ` Arnd Bergmann
2016-07-13 13:22 ` pochun lin
0 siblings, 1 reply; 4+ messages in thread
From: Arnd Bergmann @ 2016-07-13 13:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: pochun lin, Tiffany Lin, linux-kernel, Hans Verkuil,
Matthias Brugger, linux-mediatek, Mauro Carvalho Chehab,
linux-media
On Wednesday, July 13, 2016 6:52:43 PM CEST pochun lin wrote:
> > diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> > index f4e18bb44cb9..9a600525b3c1 100644
> > --- a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> > +++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> > @@ -295,9 +295,9 @@ static int h264_enc_alloc_work_buf(struct venc_h264_inst *inst)
> > wb[i].iova = inst->work_bufs[i].dma_addr;
> >
> > mtk_vcodec_debug(inst,
> > - "work_buf[%d] va=0x%p iova=0x%p size=%zu",
> > + "work_buf[%d] va=0x%p iova=%pad size=%zu",
> > i, inst->work_bufs[i].va,
> > - (void *)inst->work_bufs[i].dma_addr,
> > + &inst->work_bufs[i].dma_addr,
> > inst->work_bufs[i].size);
> > }
> >
>
> This modified will dump dma_addr's address, not dma_addr value.
> In actually, we need to dump dma_addr value.
According to Documentation/printk-formats.txt, it gets passed by
reference:
| DMA addresses types dma_addr_t:
|
| %pad 0x01234567 or 0x0123456789abcdef
|
| For printing a dma_addr_t type which can vary based on build options,
| regardless of the width of the CPU data path. Passed by reference.
The whole point of the %pad/%pr/%pM/... format strings is to print
something that cannot be passed by value because the type is not
a fixed-size integer.
Arnd
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v2] [media] mtk-vcodec: fix more type mismatches
2016-07-13 13:17 ` Arnd Bergmann
@ 2016-07-13 13:22 ` pochun lin
0 siblings, 0 replies; 4+ messages in thread
From: pochun lin @ 2016-07-13 13:22 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, Tiffany Lin, linux-kernel, Hans Verkuil,
Matthias Brugger, linux-mediatek, Mauro Carvalho Chehab,
linux-media
Hi Arnd,
On Wed, 2016-07-13 at 15:17 +0200, Arnd Bergmann wrote:
> On Wednesday, July 13, 2016 6:52:43 PM CEST pochun lin wrote:
> > > diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> > > index f4e18bb44cb9..9a600525b3c1 100644
> > > --- a/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> > > +++ b/drivers/media/platform/mtk-vcodec/venc/venc_h264_if.c
> > > @@ -295,9 +295,9 @@ static int h264_enc_alloc_work_buf(struct venc_h264_inst *inst)
> > > wb[i].iova = inst->work_bufs[i].dma_addr;
> > >
> > > mtk_vcodec_debug(inst,
> > > - "work_buf[%d] va=0x%p iova=0x%p size=%zu",
> > > + "work_buf[%d] va=0x%p iova=%pad size=%zu",
> > > i, inst->work_bufs[i].va,
> > > - (void *)inst->work_bufs[i].dma_addr,
> > > + &inst->work_bufs[i].dma_addr,
> > > inst->work_bufs[i].size);
> > > }
> > >
> >
> > This modified will dump dma_addr's address, not dma_addr value.
> > In actually, we need to dump dma_addr value.
>
> According to Documentation/printk-formats.txt, it gets passed by
> reference:
>
> | DMA addresses types dma_addr_t:
> |
> | %pad 0x01234567 or 0x0123456789abcdef
> |
> | For printing a dma_addr_t type which can vary based on build options,
> | regardless of the width of the CPU data path. Passed by reference.
>
> The whole point of the %pad/%pr/%pM/... format strings is to print
> something that cannot be passed by value because the type is not
> a fixed-size integer.
>
> Arnd
Got it. And sorry I was wrong.
Thanks your explain clearly.
Best Regards
PoChun
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-07-13 13:23 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-13 8:47 [PATCH v2] [media] mtk-vcodec: fix more type mismatches Arnd Bergmann
2016-07-13 10:52 ` pochun lin
2016-07-13 13:17 ` Arnd Bergmann
2016-07-13 13:22 ` pochun lin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).