| Message ID | 1378960909-15773-1-git-send-email-olof@lixom.net |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
On Wed, Sep 11, 2013 at 09:41:49PM -0700, Olof Johansson wrote: > This removes two warnings where dma_addr_t variables were printed using > %x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t: > > drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' > drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' Hi Olof, I can't reproduce this. Does this perhaps depend on some other patch? When I enable LPAE I do see similar warnings in drivers/iommu/tegra-*.c and those can indeed be fixed using an equivalent patch. Thierry
On Mon, Sep 16, 2013 at 8:17 AM, Thierry Reding <thierry.reding@gmail.com> wrote: > On Wed, Sep 11, 2013 at 09:41:49PM -0700, Olof Johansson wrote: >> This removes two warnings where dma_addr_t variables were printed using >> %x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t: >> >> drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' >> drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' > > Hi Olof, > > I can't reproduce this. Does this perhaps depend on some other patch? > When I enable LPAE I do see similar warnings in drivers/iommu/tegra-*.c > and those can indeed be fixed using an equivalent patch. You need to enable LPAE on a platform that also selects ARCH_DMA_ADDR_T_64BIT, I don't think tegra does. If you do it with multi_v7_defconfig you'll see them. However, see discussion on another of the emails in the series; I'll have to introduce a new format specifier instead. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2013-09-16 at 08:46 -0700, Olof Johansson wrote: > On Mon, Sep 16, 2013 at 8:17 AM, Thierry Reding > <thierry.reding@gmail.com> wrote: > > On Wed, Sep 11, 2013 at 09:41:49PM -0700, Olof Johansson wrote: > >> This removes two warnings where dma_addr_t variables were printed using > >> %x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t: > >> > >> drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' > >> drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' > > > > Hi Olof, > > > > I can't reproduce this. Does this perhaps depend on some other patch? > > When I enable LPAE I do see similar warnings in drivers/iommu/tegra-*.c > > and those can indeed be fixed using an equivalent patch. > > You need to enable LPAE on a platform that also selects > ARCH_DMA_ADDR_T_64BIT, I don't think tegra does. If you do it with > multi_v7_defconfig you'll see them. > > However, see discussion on another of the emails in the series; I'll > have to introduce a new format specifier instead. Or not. I don't know whether or not the dma_addr_t really needs a fixed 18 byte output length for 64 bit uses. I think always using a cast for dma_addr_t addresses like: printk("dma_addr_t: %#llx\n", (u64)addr); would probably work just fine. -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Sep 16, 2013 at 8:54 AM, Joe Perches <joe@perches.com> wrote: > On Mon, 2013-09-16 at 08:46 -0700, Olof Johansson wrote: >> On Mon, Sep 16, 2013 at 8:17 AM, Thierry Reding >> <thierry.reding@gmail.com> wrote: >> > On Wed, Sep 11, 2013 at 09:41:49PM -0700, Olof Johansson wrote: >> >> This removes two warnings where dma_addr_t variables were printed using >> >> %x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t: >> >> >> >> drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' >> >> drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' >> > >> > Hi Olof, >> > >> > I can't reproduce this. Does this perhaps depend on some other patch? >> > When I enable LPAE I do see similar warnings in drivers/iommu/tegra-*.c >> > and those can indeed be fixed using an equivalent patch. >> >> You need to enable LPAE on a platform that also selects >> ARCH_DMA_ADDR_T_64BIT, I don't think tegra does. If you do it with >> multi_v7_defconfig you'll see them. >> >> However, see discussion on another of the emails in the series; I'll >> have to introduce a new format specifier instead. > > Or not. > > I don't know whether or not the dma_addr_t really needs a > fixed 18 byte output length for 64 bit uses. > > I think always using a cast for dma_addr_t addresses like: > > printk("dma_addr_t: %#llx\n", (u64)addr); > > would probably work just fine. Sigh. Any color would do. I just want to get rid of the mostly-bogus warnings that makes it harder to spot real problems, I really don't care how they're resolved. None of the affected platforms today use 64-bit DMA anyway, so casting down to u32 is equally acceptable. I'll repost with that instead. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/16/13 17:06, Olof Johansson wrote: > On Mon, Sep 16, 2013 at 8:54 AM, Joe Perches <joe@perches.com> wrote: >> On Mon, 2013-09-16 at 08:46 -0700, Olof Johansson wrote: >>> On Mon, Sep 16, 2013 at 8:17 AM, Thierry Reding >>> <thierry.reding@gmail.com> wrote: >>>> On Wed, Sep 11, 2013 at 09:41:49PM -0700, Olof Johansson wrote: >>>>> This removes two warnings where dma_addr_t variables were printed using >>>>> %x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t: >>>>> >>>>> drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' >>>>> drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' >>>> >>>> Hi Olof, >>>> >>>> I can't reproduce this. Does this perhaps depend on some other patch? >>>> When I enable LPAE I do see similar warnings in drivers/iommu/tegra-*.c >>>> and those can indeed be fixed using an equivalent patch. >>> >>> You need to enable LPAE on a platform that also selects >>> ARCH_DMA_ADDR_T_64BIT, I don't think tegra does. If you do it with >>> multi_v7_defconfig you'll see them. >>> >>> However, see discussion on another of the emails in the series; I'll >>> have to introduce a new format specifier instead. >> >> Or not. >> >> I don't know whether or not the dma_addr_t really needs a >> fixed 18 byte output length for 64 bit uses. >> >> I think always using a cast for dma_addr_t addresses like: >> >> printk("dma_addr_t: %#llx\n", (u64)addr); >> >> would probably work just fine. > > Sigh. Any color would do. I just want to get rid of the mostly-bogus > warnings that makes it harder to spot real problems, I really don't > care how they're resolved. > > None of the affected platforms today use 64-bit DMA anyway, so casting > down to u32 is equally acceptable. I'll repost with that instead. Casting to u64 and using %llx is preferred for this throughout the kernel, not u32. That way you would never have to 'fix' those when those platforms use 64-bit DMA (this is where you say that they never will :).
diff --git a/drivers/gpu/host1x/hw/cdma_hw.c b/drivers/gpu/host1x/hw/cdma_hw.c index 2ee4ad5..3db3011 100644 --- a/drivers/gpu/host1x/hw/cdma_hw.c +++ b/drivers/gpu/host1x/hw/cdma_hw.c @@ -54,8 +54,8 @@ static void cdma_timeout_cpu_incr(struct host1x_cdma *cdma, u32 getptr, u32 *p = (u32 *)((u32)pb->mapped + getptr); *(p++) = HOST1X_OPCODE_NOP; *(p++) = HOST1X_OPCODE_NOP; - dev_dbg(host1x->dev, "%s: NOP at 0x%x\n", __func__, - pb->phys + getptr); + dev_dbg(host1x->dev, "%s: NOP at %pa+0x%x\n", __func__, + &pb->phys, getptr); getptr = (getptr + 8) & (pb->size_bytes - 1); } wmb(); diff --git a/drivers/gpu/host1x/hw/debug_hw.c b/drivers/gpu/host1x/hw/debug_hw.c index 334c038..346a54b 100644 --- a/drivers/gpu/host1x/hw/debug_hw.c +++ b/drivers/gpu/host1x/hw/debug_hw.c @@ -171,8 +171,8 @@ static void show_channel_gathers(struct output *o, struct host1x_cdma *cdma) continue; } - host1x_debug_output(o, " GATHER at %08x+%04x, %d words\n", - g->base, g->offset, g->words); + host1x_debug_output(o, " GATHER at %pa+%04x, %d words\n", + &g->base, g->offset, g->words); show_gather(o, g->base + g->offset, g->words, cdma, g->base, mapped);
This removes two warnings where dma_addr_t variables were printed using %x when built with CONFIG_ARM_LPAE=y, thus having 64-bit dma_addr_t: drivers/gpu/host1x/hw/cdma_hw.c:57:3: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' drivers/gpu/host1x/hw/debug_hw.c:175:10: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'dma_addr_t' Signed-off-by: Olof Johansson <olof@lixom.net> --- drivers/gpu/host1x/hw/cdma_hw.c | 4 ++-- drivers/gpu/host1x/hw/debug_hw.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)