| Message ID | 1480019716-14225-1-git-send-email-tushar.n.dave@oracle.com |
|---|---|
| State | Accepted |
| Delegated to: | David Miller |
| Headers | show |
On Thu, 24 Nov 2016 21:35:16 +0100, Tushar Dave wrote: > > dbri uses 'u32' for dma handle while invoking kernel DMA APIs, > instead of using dma_addr_t. This hasn't caused any 'incompatible > pointer type' warning on SPARC because until now dma_addr_t is of > type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit > DMA and therefore dma_addr_t became of type u64. This makes > 'incompatible pointer type' warnings inevitable. > > e.g. > sound/sparc/dbri.c: In function ‘snd_dbri_create’: > sound/sparc/dbri.c:2538: warning: passing argument 3 of ‘dma_zalloc_coherent’ from incompatible pointer type > ./include/linux/dma-mapping.h:608: note: expected ‘dma_addr_t *’ but argument is of type ‘u32 *’ > > For the record, dbri(sbus) driver never executes on sun4v. Therefore > even though 64bit DMA is enabled on SPARC, dbri continues to use > legacy iommu that guarantees DMA address is always in 32bit range. > > This patch resolves above compiler warning. > > Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> > Reviewed-by: thomas tai <thomas.tai@oracle.com> > --- > v2->v3: > - Use %pad to print dma_addr_t. Comment by Takashi Iwai. Applied now. Thanks! Takashi -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Takashi Iwai <tiwai@suse.de> Date: Fri, 25 Nov 2016 10:30:48 +0100 > On Thu, 24 Nov 2016 21:35:16 +0100, > Tushar Dave wrote: >> >> dbri uses 'u32' for dma handle while invoking kernel DMA APIs, >> instead of using dma_addr_t. This hasn't caused any 'incompatible >> pointer type' warning on SPARC because until now dma_addr_t is of >> type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit >> DMA and therefore dma_addr_t became of type u64. This makes >> 'incompatible pointer type' warnings inevitable. >> >> e.g. >> sound/sparc/dbri.c: In function ‘snd_dbri_create’: >> sound/sparc/dbri.c:2538: warning: passing argument 3 of ‘dma_zalloc_coherent’ from incompatible pointer type >> ./include/linux/dma-mapping.h:608: note: expected ‘dma_addr_t *’ but argument is of type ‘u32 *’ >> >> For the record, dbri(sbus) driver never executes on sun4v. Therefore >> even though 64bit DMA is enabled on SPARC, dbri continues to use >> legacy iommu that guarantees DMA address is always in 32bit range. >> >> This patch resolves above compiler warning. >> >> Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> >> Reviewed-by: thomas tai <thomas.tai@oracle.com> >> --- >> v2->v3: >> - Use %pad to print dma_addr_t. Comment by Takashi Iwai. > > Applied now. Thanks! This patch is absolutely not appropriate for your tree Takashi. It's for the sparc tree because that's where the dma_addr_t type was changed from 32-bit to 64-bit on sparc64, which is what caused this build warning. Dave, please only send sparc specific driver patches to sparclinux@vger.kernel.org in the future so we can avoid this kind of problem. The whole handling of the dma_addr_t type change on sparc64 has been a real mess, quite honestly.
On Fri, 25 Nov 2016 17:54:47 +0100, David Miller wrote: > > From: Takashi Iwai <tiwai@suse.de> > Date: Fri, 25 Nov 2016 10:30:48 +0100 > > > On Thu, 24 Nov 2016 21:35:16 +0100, > > Tushar Dave wrote: > >> > >> dbri uses 'u32' for dma handle while invoking kernel DMA APIs, > >> instead of using dma_addr_t. This hasn't caused any 'incompatible > >> pointer type' warning on SPARC because until now dma_addr_t is of > >> type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit > >> DMA and therefore dma_addr_t became of type u64. This makes > >> 'incompatible pointer type' warnings inevitable. > >> > >> e.g. > >> sound/sparc/dbri.c: In function ‘snd_dbri_create’: > >> sound/sparc/dbri.c:2538: warning: passing argument 3 of ‘dma_zalloc_coherent’ from incompatible pointer type > >> ./include/linux/dma-mapping.h:608: note: expected ‘dma_addr_t *’ but argument is of type ‘u32 *’ > >> > >> For the record, dbri(sbus) driver never executes on sun4v. Therefore > >> even though 64bit DMA is enabled on SPARC, dbri continues to use > >> legacy iommu that guarantees DMA address is always in 32bit range. > >> > >> This patch resolves above compiler warning. > >> > >> Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> > >> Reviewed-by: thomas tai <thomas.tai@oracle.com> > >> --- > >> v2->v3: > >> - Use %pad to print dma_addr_t. Comment by Takashi Iwai. > > > > Applied now. Thanks! > > This patch is absolutely not appropriate for your tree Takashi. > > It's for the sparc tree because that's where the dma_addr_t > type was changed from 32-bit to 64-bit on sparc64, which is > what caused this build warning. > > Dave, please only send sparc specific driver patches to > sparclinux@vger.kernel.org in the future so we can avoid > this kind of problem. The whole handling of the dma_addr_t > type change on sparc64 has been a real mess, quite honestly. Fair enough. Could you take it through your tree? Feel free to take my ack: Reviewed-by: Takashi Iwai <tiwai@suse.de> Thanks! Takashi -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Takashi Iwai <tiwai@suse.de> Date: Fri, 25 Nov 2016 17:58:21 +0100 > On Fri, 25 Nov 2016 17:54:47 +0100, > David Miller wrote: >> >> From: Takashi Iwai <tiwai@suse.de> >> Date: Fri, 25 Nov 2016 10:30:48 +0100 >> >> > On Thu, 24 Nov 2016 21:35:16 +0100, >> > Tushar Dave wrote: >> >> >> >> dbri uses 'u32' for dma handle while invoking kernel DMA APIs, >> >> instead of using dma_addr_t. This hasn't caused any 'incompatible >> >> pointer type' warning on SPARC because until now dma_addr_t is of >> >> type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit >> >> DMA and therefore dma_addr_t became of type u64. This makes >> >> 'incompatible pointer type' warnings inevitable. >> >> >> >> e.g. >> >> sound/sparc/dbri.c: In function ‘snd_dbri_create’: >> >> sound/sparc/dbri.c:2538: warning: passing argument 3 of ‘dma_zalloc_coherent’ from incompatible pointer type >> >> ./include/linux/dma-mapping.h:608: note: expected ‘dma_addr_t *’ but argument is of type ‘u32 *’ >> >> >> >> For the record, dbri(sbus) driver never executes on sun4v. Therefore >> >> even though 64bit DMA is enabled on SPARC, dbri continues to use >> >> legacy iommu that guarantees DMA address is always in 32bit range. >> >> >> >> This patch resolves above compiler warning. >> >> >> >> Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> >> >> Reviewed-by: thomas tai <thomas.tai@oracle.com> >> >> --- >> >> v2->v3: >> >> - Use %pad to print dma_addr_t. Comment by Takashi Iwai. >> > >> > Applied now. Thanks! >> >> This patch is absolutely not appropriate for your tree Takashi. >> >> It's for the sparc tree because that's where the dma_addr_t >> type was changed from 32-bit to 64-bit on sparc64, which is >> what caused this build warning. >> >> Dave, please only send sparc specific driver patches to >> sparclinux@vger.kernel.org in the future so we can avoid >> this kind of problem. The whole handling of the dma_addr_t >> type change on sparc64 has been a real mess, quite honestly. > > Fair enough. Could you take it through your tree? > Feel free to take my ack: > Reviewed-by: Takashi Iwai <tiwai@suse.de> I will, thank you.
On 11/25/2016 08:54 AM, David Miller wrote: > From: Takashi Iwai <tiwai@suse.de> > Date: Fri, 25 Nov 2016 10:30:48 +0100 > >> On Thu, 24 Nov 2016 21:35:16 +0100, >> Tushar Dave wrote: >>> >>> dbri uses 'u32' for dma handle while invoking kernel DMA APIs, >>> instead of using dma_addr_t. This hasn't caused any 'incompatible >>> pointer type' warning on SPARC because until now dma_addr_t is of >>> type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit >>> DMA and therefore dma_addr_t became of type u64. This makes >>> 'incompatible pointer type' warnings inevitable. >>> >>> e.g. >>> sound/sparc/dbri.c: In function ‘snd_dbri_create’: >>> sound/sparc/dbri.c:2538: warning: passing argument 3 of ‘dma_zalloc_coherent’ from incompatible pointer type >>> ./include/linux/dma-mapping.h:608: note: expected ‘dma_addr_t *’ but argument is of type ‘u32 *’ >>> >>> For the record, dbri(sbus) driver never executes on sun4v. Therefore >>> even though 64bit DMA is enabled on SPARC, dbri continues to use >>> legacy iommu that guarantees DMA address is always in 32bit range. >>> >>> This patch resolves above compiler warning. >>> >>> Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> >>> Reviewed-by: thomas tai <thomas.tai@oracle.com> >>> --- >>> v2->v3: >>> - Use %pad to print dma_addr_t. Comment by Takashi Iwai. >> >> Applied now. Thanks! > > This patch is absolutely not appropriate for your tree Takashi. > > It's for the sparc tree because that's where the dma_addr_t > type was changed from 32-bit to 64-bit on sparc64, which is > what caused this build warning. > > Dave, please only send sparc specific driver patches to > sparclinux@vger.kernel.org in the future so we can avoid > this kind of problem. The whole handling of the dma_addr_t > type change on sparc64 has been a real mess, quite honestly. I got your point. I will keep it in mind in future submission. Thanks. -Tushar > -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Tushar Dave <tushar.n.dave@oracle.com> Date: Thu, 24 Nov 2016 12:35:16 -0800 > dbri uses 'u32' for dma handle while invoking kernel DMA APIs, > instead of using dma_addr_t. This hasn't caused any 'incompatible > pointer type' warning on SPARC because until now dma_addr_t is of > type u32. However, recent changes in SPARC ATU (iommu) enabled 64bit > DMA and therefore dma_addr_t became of type u64. This makes > 'incompatible pointer type' warnings inevitable. > > e.g. > sound/sparc/dbri.c: In function ‘snd_dbri_create’: > sound/sparc/dbri.c:2538: warning: passing argument 3 of ‘dma_zalloc_coherent’ from incompatible pointer type > ./include/linux/dma-mapping.h:608: note: expected ‘dma_addr_t *’ but argument is of type ‘u32 *’ > > For the record, dbri(sbus) driver never executes on sun4v. Therefore > even though 64bit DMA is enabled on SPARC, dbri continues to use > legacy iommu that guarantees DMA address is always in 32bit range. > > This patch resolves above compiler warning. > > Signed-off-by: Tushar Dave <tushar.n.dave@oracle.com> > Reviewed-by: thomas tai <thomas.tai@oracle.com> Applied, thanks.
diff --git a/sound/sparc/dbri.c b/sound/sparc/dbri.c index 0190cb6..3fe4468 100644 --- a/sound/sparc/dbri.c +++ b/sound/sparc/dbri.c @@ -304,7 +304,7 @@ struct snd_dbri { spinlock_t lock; struct dbri_dma *dma; /* Pointer to our DMA block */ - u32 dma_dvma; /* DBRI visible DMA address */ + dma_addr_t dma_dvma; /* DBRI visible DMA address */ void __iomem *regs; /* dbri HW regs */ int dbri_irqp; /* intr queue pointer */ @@ -657,12 +657,14 @@ static void dbri_cmdwait(struct snd_dbri *dbri) */ static s32 *dbri_cmdlock(struct snd_dbri *dbri, int len) { + u32 dvma_addr = (u32)dbri->dma_dvma; + /* Space for 2 WAIT cmds (replaced later by 1 JUMP cmd) */ len += 2; spin_lock(&dbri->cmdlock); if (dbri->cmdptr - dbri->dma->cmd + len < DBRI_NO_CMDS - 2) return dbri->cmdptr + 2; - else if (len < sbus_readl(dbri->regs + REG8) - dbri->dma_dvma) + else if (len < sbus_readl(dbri->regs + REG8) - dvma_addr) return dbri->dma->cmd; else printk(KERN_ERR "DBRI: no space for commands."); @@ -680,6 +682,7 @@ static s32 *dbri_cmdlock(struct snd_dbri *dbri, int len) */ static void dbri_cmdsend(struct snd_dbri *dbri, s32 *cmd, int len) { + u32 dvma_addr = (u32)dbri->dma_dvma; s32 tmp, addr; static int wait_id = 0; @@ -689,7 +692,7 @@ static void dbri_cmdsend(struct snd_dbri *dbri, s32 *cmd, int len) *(cmd+1) = DBRI_CMD(D_WAIT, 1, wait_id); /* Replace the last command with JUMP */ - addr = dbri->dma_dvma + (cmd - len - dbri->dma->cmd) * sizeof(s32); + addr = dvma_addr + (cmd - len - dbri->dma->cmd) * sizeof(s32); *(dbri->cmdptr+1) = addr; *(dbri->cmdptr) = DBRI_CMD(D_JUMP, 0, 0); @@ -747,6 +750,7 @@ static void dbri_reset(struct snd_dbri *dbri) /* Lock must not be held before calling this */ static void dbri_initialize(struct snd_dbri *dbri) { + u32 dvma_addr = (u32)dbri->dma_dvma; s32 *cmd; u32 dma_addr; unsigned long flags; @@ -764,7 +768,7 @@ static void dbri_initialize(struct snd_dbri *dbri) /* * Initialize the interrupt ring buffer. */ - dma_addr = dbri->dma_dvma + dbri_dma_off(intr, 0); + dma_addr = dvma_addr + dbri_dma_off(intr, 0); dbri->dma->intr[0] = dma_addr; dbri->dbri_irqp = 1; /* @@ -778,7 +782,7 @@ static void dbri_initialize(struct snd_dbri *dbri) dbri->cmdptr = cmd; *(cmd++) = DBRI_CMD(D_WAIT, 1, 0); *(cmd++) = DBRI_CMD(D_WAIT, 1, 0); - dma_addr = dbri->dma_dvma + dbri_dma_off(cmd, 0); + dma_addr = dvma_addr + dbri_dma_off(cmd, 0); sbus_writel(dma_addr, dbri->regs + REG8); spin_unlock(&dbri->cmdlock); @@ -1077,6 +1081,7 @@ static void recv_fixed(struct snd_dbri *dbri, int pipe, volatile __u32 *ptr) static int setup_descs(struct snd_dbri *dbri, int streamno, unsigned int period) { struct dbri_streaminfo *info = &dbri->stream_info[streamno]; + u32 dvma_addr = (u32)dbri->dma_dvma; __u32 dvma_buffer; int desc; int len; @@ -1177,7 +1182,7 @@ static int setup_descs(struct snd_dbri *dbri, int streamno, unsigned int period) else { dbri->next_desc[last_desc] = desc; dbri->dma->desc[last_desc].nda = - dbri->dma_dvma + dbri_dma_off(desc, desc); + dvma_addr + dbri_dma_off(desc, desc); } last_desc = desc; @@ -1192,7 +1197,7 @@ static int setup_descs(struct snd_dbri *dbri, int streamno, unsigned int period) } dbri->dma->desc[last_desc].nda = - dbri->dma_dvma + dbri_dma_off(desc, first_desc); + dvma_addr + dbri_dma_off(desc, first_desc); dbri->next_desc[last_desc] = first_desc; dbri->pipes[info->pipe].first_desc = first_desc; dbri->pipes[info->pipe].desc = first_desc; @@ -1697,6 +1702,7 @@ calling dbri_process_interrupt_buffer(), which works even if the CPU's static void xmit_descs(struct snd_dbri *dbri) { struct dbri_streaminfo *info; + u32 dvma_addr = (u32)dbri->dma_dvma; s32 *cmd; unsigned long flags; int first_td; @@ -1718,7 +1724,7 @@ static void xmit_descs(struct snd_dbri *dbri) *(cmd++) = DBRI_CMD(D_SDP, 0, dbri->pipes[info->pipe].sdp | D_SDP_P | D_SDP_EVERY | D_SDP_C); - *(cmd++) = dbri->dma_dvma + + *(cmd++) = dvma_addr + dbri_dma_off(desc, first_td); dbri_cmdsend(dbri, cmd, 2); @@ -1740,7 +1746,7 @@ static void xmit_descs(struct snd_dbri *dbri) *(cmd++) = DBRI_CMD(D_SDP, 0, dbri->pipes[info->pipe].sdp | D_SDP_P | D_SDP_EVERY | D_SDP_C); - *(cmd++) = dbri->dma_dvma + + *(cmd++) = dvma_addr + dbri_dma_off(desc, first_td); dbri_cmdsend(dbri, cmd, 2); @@ -2539,7 +2545,7 @@ static int snd_dbri_create(struct snd_card *card, if (!dbri->dma) return -ENOMEM; - dprintk(D_GEN, "DMA Cmd Block 0x%p (0x%08x)\n", + dprintk(D_GEN, "DMA Cmd Block 0x%p (%pad)\n", dbri->dma, dbri->dma_dvma); /* Map the registers into memory. */