This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
dma_addr_t might then be 64-bit:
drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
Signed-off-by: Olof Johansson <[email protected]>
---
drivers/dma/imx-dma.c | 20 ++++++++++----------
drivers/dma/imx-sdma.c | 8 ++++----
drivers/dma/ipu/ipu_idmac.c | 6 ++++--
3 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index 78f8ca5..fcc8a12 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -576,9 +576,9 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
imx_dmav1_writel(imxdma, d->len, DMA_CNTR(imxdmac->channel));
- dev_dbg(imxdma->dev, "%s channel: %d dest=0x%08x src=0x%08x "
+ dev_dbg(imxdma->dev, "%s channel: %d dest=%pa src=%pa "
"dma_length=%d\n", __func__, imxdmac->channel,
- d->dest, d->src, d->len);
+ &d->dest, &d->src, d->len);
break;
/* Cyclic transfer is the same as slave_sg with special sg configuration. */
@@ -591,9 +591,9 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
DMA_CCR(imxdmac->channel));
dev_dbg(imxdma->dev, "%s channel: %d sg=%p sgcount=%d "
- "total length=%d dev_addr=0x%08x (dev2mem)\n",
+ "total length=%d dev_addr=%pa (dev2mem)\n",
__func__, imxdmac->channel, d->sg, d->sgcount,
- d->len, imxdmac->per_address);
+ d->len, &imxdmac->per_address);
} else if (d->direction == DMA_MEM_TO_DEV) {
imx_dmav1_writel(imxdma, imxdmac->per_address,
DMA_DAR(imxdmac->channel));
@@ -601,9 +601,9 @@ static int imxdma_xfer_desc(struct imxdma_desc *d)
DMA_CCR(imxdmac->channel));
dev_dbg(imxdma->dev, "%s channel: %d sg=%p sgcount=%d "
- "total length=%d dev_addr=0x%08x (mem2dev)\n",
+ "total length=%d dev_addr=%pa (mem2dev)\n",
__func__, imxdmac->channel, d->sg, d->sgcount,
- d->len, imxdmac->per_address);
+ d->len, &imxdmac->per_address);
} else {
dev_err(imxdma->dev, "%s channel: %d bad dma mode\n",
__func__, imxdmac->channel);
@@ -927,8 +927,8 @@ static struct dma_async_tx_descriptor *imxdma_prep_dma_memcpy(
struct imxdma_engine *imxdma = imxdmac->imxdma;
struct imxdma_desc *desc;
- dev_dbg(imxdma->dev, "%s channel: %d src=0x%x dst=0x%x len=%d\n",
- __func__, imxdmac->channel, src, dest, len);
+ dev_dbg(imxdma->dev, "%s channel: %d src=%pa dst=%pa len=%d\n",
+ __func__, imxdmac->channel, &src, &dest, len);
if (list_empty(&imxdmac->ld_free) ||
imxdma_chan_is_doing_cyclic(imxdmac))
@@ -957,9 +957,9 @@ static struct dma_async_tx_descriptor *imxdma_prep_dma_interleaved(
struct imxdma_engine *imxdma = imxdmac->imxdma;
struct imxdma_desc *desc;
- dev_dbg(imxdma->dev, "%s channel: %d src_start=0x%x dst_start=0x%x\n"
+ dev_dbg(imxdma->dev, "%s channel: %d src_start=%pa dst_start=%pa\n"
" src_sgl=%s dst_sgl=%s numf=%d frame_size=%d\n", __func__,
- imxdmac->channel, xt->src_start, xt->dst_start,
+ imxdmac->channel, &xt->src_start, &xt->dst_start,
xt->src_sgl ? "true" : "false", xt->dst_sgl ? "true" : "false",
xt->numf, xt->frame_size);
diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
index fc43603..b6946c5 100644
--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c
@@ -1089,8 +1089,8 @@ static struct dma_async_tx_descriptor *sdma_prep_slave_sg(
param &= ~BD_CONT;
}
- dev_dbg(sdma->dev, "entry %d: count: %d dma: 0x%08x %s%s\n",
- i, count, sg->dma_address,
+ dev_dbg(sdma->dev, "entry %d: count: %d dma: %pa %s%s\n",
+ i, count, &sg->dma_address,
param & BD_WRAP ? "wrap" : "",
param & BD_INTR ? " intr" : "");
@@ -1163,8 +1163,8 @@ static struct dma_async_tx_descriptor *sdma_prep_dma_cyclic(
if (i + 1 == num_periods)
param |= BD_WRAP;
- dev_dbg(sdma->dev, "entry %d: count: %d dma: 0x%08x %s%s\n",
- i, period_len, dma_addr,
+ dev_dbg(sdma->dev, "entry %d: count: %d dma: %pa %s%s\n",
+ i, period_len, &dma_addr,
param & BD_WRAP ? "wrap" : "",
param & BD_INTR ? " intr" : "");
diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
index cb9c0bc..7d893c0 100644
--- a/drivers/dma/ipu/ipu_idmac.c
+++ b/drivers/dma/ipu/ipu_idmac.c
@@ -1232,8 +1232,10 @@ static irqreturn_t idmac_interrupt(int irq, void *dev_id)
desc = list_entry(ichan->queue.next, struct idmac_tx_desc, list);
descnew = desc;
- dev_dbg(dev, "IDMAC irq %d, dma 0x%08x, next dma 0x%08x, current %d, curbuf 0x%08x\n",
- irq, sg_dma_address(*sg), sgnext ? sg_dma_address(sgnext) : 0, ichan->active_buffer, curbuf);
+ dev_dbg(dev, "IDMAC irq %d, dma %pa, next dma %pa, current %d, curbuf 0x%08x\n",
+ irq, &sg_dma_address(*sg),
+ sgnext ? &sg_dma_address(sgnext) : NULL, ichan->active_buffer,
+ curbuf);
/* Find the descriptor of sgnext */
sgnew = idmac_sg_next(ichan, &descnew, *sg);
--
1.7.10.4
On 09/11/13 21:38, Olof Johansson wrote:
> This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
> dma_addr_t might then be 64-bit:
>
> drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
> drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
> drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
> drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
> drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
> drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
I've been tempted to make similar patches, but CONFIG_PHYS_ADDR_T_64BIT
and CONFIG_ARCH_DMA_ADDR_T_64BIT are independent AFAICT,
and %pa is for physical addresses, not necessarily DMA addresses.
Am I confused?
--
~Randy
On Thu, Sep 12, 2013 at 10:05 AM, Randy Dunlap <[email protected]> wrote:
> On 09/11/13 21:38, Olof Johansson wrote:
>> This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
>> dma_addr_t might then be 64-bit:
>>
>> drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>> drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
>
>
> I've been tempted to make similar patches, but CONFIG_PHYS_ADDR_T_64BIT
> and CONFIG_ARCH_DMA_ADDR_T_64BIT are independent AFAICT,
> and %pa is for physical addresses, not necessarily DMA addresses.
>
> Am I confused?
So, I prepared just that (allocating %pA for dma_addr_t) last night,
but after looking around a bit more, it was unclear to me if it's ever
meaningful to separate the two of them at different word sizes.
Any >32bit-addressable machine will likely want 64-bit dma_addr_t as
well. The only architecture that doesn't seem to set
ARCH_DMA_ADDR_T_64BIT based on PHYS_ADDR_T size is ARM, and I think
that should just be changed there as well.
-Olof
On Thu, 2013-09-12 at 10:05 -0700, Randy Dunlap wrote:
> On 09/11/13 21:38, Olof Johansson wrote:
> > This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
> > dma_addr_t might then be 64-bit:
> >
> > drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> > drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> > drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> > drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
> > drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
> > drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
> > drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> > drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
> > drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
> > drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
> > drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
>
>
> I've been tempted to make similar patches, but CONFIG_PHYS_ADDR_T_64BIT
> and CONFIG_ARCH_DMA_ADDR_T_64BIT are independent AFAICT,
> and %pa is for physical addresses, not necessarily DMA addresses.
>
> Am I confused?
No.
https://lkml.org/lkml/2013/6/1/202
No. If a dma_addr_t is really needed, then maybe
something like this:
---
Documentation/printk-formats.txt | 11 +++++++++--
lib/vsprintf.c | 33 +++++++++++++++++++++++++++------
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 445ad74..6f4eb32 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -55,14 +55,21 @@ Struct Resources:
For printing struct resources. The 'R' and 'r' specifiers result in a
printed resource with ('R') or without ('r') a decoded flags member.
-Physical addresses:
+Physical addresses types phys_addr_t:
- %pa 0x01234567 or 0x0123456789abcdef
+ %pa[p] 0x01234567 or 0x0123456789abcdef
For printing a phys_addr_t type (and its derivatives, such as
resource_size_t) which can vary based on build options, regardless of
the width of the CPU data path. 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.
+
Raw buffer as a hex string:
%*ph 00 01 02 ... 3f
%*phC 00:01:02: ... :3f
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 43c2ea0..4df18bc 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1154,6 +1154,30 @@ char *netdev_feature_string(char *buf, char *end, const u8 *addr,
return number(buf, end, *(const netdev_features_t *)addr, spec);
}
+static noinline_for_stack
+char *address_val(char *buf, char *end, const void *addr,
+ struct printf_spec spec, const char *fmt)
+{
+ unsigned long long num;
+
+ spec.flags |= SPECIAL | SMALL | ZEROPAD;
+ spec.base = 16;
+
+ switch (fmt[1]) {
+ case 'd':
+ num = *(const dma_addr_t *)addr;
+ spec.field_width = sizeof(dma_addr_t) * 2 + 2;
+ break;
+ case 'p':
+ default:
+ num = *(const phys_addr_t *)addr;
+ spec.field_width = sizeof(phys_addr_t) * 2 + 2;
+ break;
+ }
+
+ return number(buf, end, num, spec);
+}
+
int kptr_restrict __read_mostly;
/*
@@ -1217,7 +1241,8 @@ int kptr_restrict __read_mostly;
* N no separator
* The maximum supported length is 64 bytes of the input. Consider
* to use print_hex_dump() for the larger input.
- * - 'a' For a phys_addr_t type and its derivative types (passed by reference)
+ * - 'a[pd]' For address types phys_addr_t, dma_addr_t and derivatives
+ * (default assumed to be phys_addr_t, passed by reference)
*
* Note: The difference between 'S' and 'F' is that on ia64 and ppc64
* function pointers are really function descriptors, which contain a
@@ -1324,11 +1349,7 @@ char *pointer(const char *fmt, char *buf, char *end, void *ptr,
}
break;
case 'a':
- spec.flags |= SPECIAL | SMALL | ZEROPAD;
- spec.field_width = sizeof(phys_addr_t) * 2 + 2;
- spec.base = 16;
- return number(buf, end,
- (unsigned long long) *((phys_addr_t *)ptr), spec);
+ return address_val(buf, end, ptr, spec, fmt);
case 'd':
return dentry_name(buf, end, ptr, spec, fmt);
case 'D':
On Thu, Sep 12, 2013 at 10:11:44AM -0700, Olof Johansson wrote:
> Any >32bit-addressable machine will likely want 64-bit dma_addr_t as
> well. The only architecture that doesn't seem to set
> ARCH_DMA_ADDR_T_64BIT based on PHYS_ADDR_T size is ARM, and I think
> that should just be changed there as well.
Do we actually have any 64-bit DMA controllers out there? As far as
I'm aware, all our DMA controllers are all 32-bit address only. That
makes a 64-bit dma_addr_t rather silly.
Remember that dma_addr_t is the value you program into the DMA
controller, and _not_ the actual physical address.
On Thu, Sep 12, 2013 at 10:11 AM, Olof Johansson <[email protected]> wrote:
> On Thu, Sep 12, 2013 at 10:05 AM, Randy Dunlap <[email protected]> wrote:
>> On 09/11/13 21:38, Olof Johansson wrote:
>>> This resolves some warnings seen when building with CONFIG_ARM_LPAE=y, since
>>> dma_addr_t might then be 64-bit:
>>>
>>> drivers/dma/imx-sdma.c:1092:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>> drivers/dma/imx-sdma.c:1166:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>> drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>> drivers/dma/imx-dma.c:579:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>>> drivers/dma/imx-dma.c:593:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>>> drivers/dma/imx-dma.c:603:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t' [-Wformat=]
>>> drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>> drivers/dma/imx-dma.c:930:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>>> drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t' [-Wformat=]
>>> drivers/dma/imx-dma.c:960:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t' [-Wformat=]
>>> drivers/dma/ipu/ipu_idmac.c:1235:2: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'dma_addr_t' [-Wformat=]
>>
>>
>> I've been tempted to make similar patches, but CONFIG_PHYS_ADDR_T_64BIT
>> and CONFIG_ARCH_DMA_ADDR_T_64BIT are independent AFAICT,
>> and %pa is for physical addresses, not necessarily DMA addresses.
>>
>> Am I confused?
>
> So, I prepared just that (allocating %pA for dma_addr_t) last night,
> but after looking around a bit more, it was unclear to me if it's ever
> meaningful to separate the two of them at different word sizes.
>
> Any >32bit-addressable machine will likely want 64-bit dma_addr_t as
> well. The only architecture that doesn't seem to set
> ARCH_DMA_ADDR_T_64BIT based on PHYS_ADDR_T size is ARM, and I think
> that should just be changed there as well.
>
Xen also plays games here and has a 32-bit physical address with
64-bit dma. So I think we need something like Joe's patch.
--
Dan
On Thu, Sep 12, 2013 at 10:35 AM, Russell King - ARM Linux
<[email protected]> wrote:
> On Thu, Sep 12, 2013 at 10:11:44AM -0700, Olof Johansson wrote:
>> Any >32bit-addressable machine will likely want 64-bit dma_addr_t as
>> well. The only architecture that doesn't seem to set
>> ARCH_DMA_ADDR_T_64BIT based on PHYS_ADDR_T size is ARM, and I think
>> that should just be changed there as well.
The thread Joe linked to refers to a comment that is now deleted;
sparc64 apparantly has 32-bit dma_addr_t at least, so there are
platforms where the two differ permanently. Adding a new printk format
is probably needed here after all.
> Do we actually have any 64-bit DMA controllers out there? As far as
> I'm aware, all our DMA controllers are all 32-bit address only. That
> makes a 64-bit dma_addr_t rather silly.
PCI/PCI-e is the large unknown here, I'm not actually sure if any of
the current implementation of host controllers support it, but it
would seem likely that server-class hardware does.
-Olof