[PATCH v3] powerpc/srio: Fix the compile errors when building with 64bit
For the file arch/powerpc/sysdev/fsl_rmu.c, there will be some compile
errors while using the corenet64_smp_defconfig:
.../fsl_rmu.c:315: error: cast from pointer to integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:320: error: cast to pointer from integer of different size
.../fsl_rmu.c:330: error: cast to pointer from integer of different size
.../fsl_rmu.c:332: error: cast to pointer from integer of different size
.../fsl_rmu.c:339: error: cast to pointer from integer of different size
.../fsl_rmu.c:340: error: cast to pointer from integer of different size
.../fsl_rmu.c:341: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:348: error: cast to pointer from integer of different size
.../fsl_rmu.c:659: error: cast from pointer to integer of different size
.../fsl_rmu.c:659: error: format '%8.8x' expects type 'unsigned int',
but argument 5 has type 'size_t'
.../fsl_rmu.c:985: error: cast from pointer to integer of different size
.../fsl_rmu.c:997: error: cast to pointer from integer of different size
Rewrote the corresponding code with the support of 64bit building.
Signed-off-by: Liu Gang gang@freescale.com
Signed-off-by: Shaohui Xie shaohui@freescale.com
Reported-by: Paul Gortmaker paul.gortma...@windriver.com
---
Changes in v2:
- Add the struct rio_dbell_msg to instead of some DBELL_* macros.
- Change the virt_buf to be void * type.
- Change Signed-off-by to Reported-by for Paul.
Changes in v3:
- Change the %8.8lx to be %p and remove the cast of the buffer
arch/powerpc/sysdev/fsl_rmu.c | 42 +---
1 files changed, 22 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_rmu.c b/arch/powerpc/sysdev/fsl_rmu.c
index 1548578..14bd522 100644
--- a/arch/powerpc/sysdev/fsl_rmu.c
+++ b/arch/powerpc/sysdev/fsl_rmu.c
@@ -100,14 +100,8 @@
#define DOORBELL_DSR_TE0x0080
#define DOORBELL_DSR_QFI 0x0010
#define DOORBELL_DSR_DIQI 0x0001
-#define DOORBELL_TID_OFFSET0x02
-#define DOORBELL_SID_OFFSET0x04
-#define DOORBELL_INFO_OFFSET 0x06
#define DOORBELL_MESSAGE_SIZE 0x08
-#define DBELL_SID(x) (*(u16 *)(x + DOORBELL_SID_OFFSET))
-#define DBELL_TID(x) (*(u16 *)(x + DOORBELL_TID_OFFSET))
-#define DBELL_INF(x) (*(u16 *)(x + DOORBELL_INFO_OFFSET))
struct rio_msg_regs {
u32 omr;
@@ -193,6 +187,13 @@ struct fsl_rmu {
int rxirq;
};
+struct rio_dbell_msg {
+ u16 pad1;
+ u16 tid;
+ u16 sid;
+ u16 info;
+};
+
/**
* fsl_rio_tx_handler - MPC85xx outbound message interrupt handler
* @irq: Linux interrupt number
@@ -311,8 +312,8 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
/* XXX Need to check/dispatch until queue empty */
if (dsr DOORBELL_DSR_DIQI) {
- u32 dmsg =
- (u32) fsl_dbell-dbell_ring.virt +
+ struct rio_dbell_msg *dmsg =
+ fsl_dbell-dbell_ring.virt +
(in_be32(fsl_dbell-dbell_regs-dqdpar) 0xfff);
struct rio_dbell *dbell;
int found = 0;
@@ -320,25 +321,25 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
pr_debug
(RIO: processing doorbell,
sid %2.2x tid %2.2x info %4.4x\n,
- DBELL_SID(dmsg), DBELL_TID(dmsg), DBELL_INF(dmsg));
+ dmsg-sid, dmsg-tid, dmsg-info);
for (i = 0; i MAX_PORT_NUM; i++) {
if (fsl_dbell-mport[i]) {
list_for_each_entry(dbell,
fsl_dbell-mport[i]-dbells, node) {
if ((dbell-res-start
- = DBELL_INF(dmsg))
+ = dmsg-info)
(dbell-res-end
- = DBELL_INF(dmsg))) {
+ = dmsg-info)) {
found = 1;
break;
}
}
if (found dbell-dinb) {
dbell-dinb(fsl_dbell-mport[i],
- dbell-dev_id, DBELL_SID(dmsg),
- DBELL_TID(dmsg),
- DBELL_INF(dmsg));
+
Re: [PATCH v2 0/9] DMA engine cookie handling cleanups
On Tue, Mar 06, 2012 at 10:33:21PM +, Russell King - ARM Linux wrote: ... drivers/dma/imx-sdma.c | 23 ++-- ... drivers/dma/mxs-dma.c| 23 ++-- Tested-by: Shawn Guo shawn@linaro.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc/44x: Fix PCI MSI support for Maui APM821xx SoC and Bluestone board
On Thu, Mar 8, 2012 at 10:35 PM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Fri, 2012-03-09 at 10:17 +0700, Mai La wrote: This patch consists of: - Enable PCI MSI as default for Bluestone board - Define number of MSI interrupt for Maui APM821xx SoC using in Bluestone board - Fix returning ENODEV as finding MSI node - Fix MSI physical high and low address - Keep MSI data logically Signed-off-by: Mai La m...@apm.com --- index 7b4df37..c86231e 100644 --- a/arch/powerpc/sysdev/Kconfig +++ b/arch/powerpc/sysdev/Kconfig @@ -20,6 +20,12 @@ config PPC_MSI_BITMAP default y if FSL_PCI default y if PPC4xx_MSI +config PPC4xx_NR_MSI_IRQS + int Number of PCI MSI interrupts + depends on PCI_MSI PPC4xx_MSI + default 4 if !APM821xx + default 8 if APM821xx + .../... +#define NR_MSI_IRQS CONFIG_PPC4xx_NR_MSI_IRQS ARGH. We asked to -NOT MAKE THIS A COMPILE TIME OPTION- Actually, I asked for basically exactly above. I was _wrong_ in asking, but it was asked for. CONFIG_foo is as bad as your previous ifdef, in fact you just added a useless config option here. Make that number dynamic. Count the entries in the device-tree (or add a property with the number in it, whatever you fancy the most) but make it something detected at RUNTIME ! My apologies Mai. Ben is correct here and I should have thought more about my suggestion before I made it. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: manual merge of the driver-core tree with the powerpc tree
On Fri, Mar 09, 2012 at 04:40:25PM +1100, Stephen Rothwell wrote: Hi Greg, Today's linux-next merge of the driver-core tree got a conflict in drivers/base/driver.c between commit fcd6f7620202 (driver-core: remove legacy iSeries hack) from the powerpc tree and commit 9875bb480cc8 (Eliminate get_driver() and put_driver()) from the driver-core tree. Just context changes. I fixed it up (see below) and can carry the fix as necessary. Looks good to me, thanks for doing this. greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: 3.3.0-rc6-next-20120308 boot failure on POWER7 blade
On Fri, 9 Mar 2012 14:46:45 +1100 Anton Blanchard an...@samba.org wrote: Hi Ben, Looks like something that got fixed but the new patches from Bjorn aren't in next yet. I'll fwd you the patch separately to apply on top of what you have see if that helps (to confirm that's indeed the issue). Thanks, confirmed that it fixes it. Patch below in case anyone else is hitting it. Anton -- On Sat, 2012-03-03 at 08:52 +1100, Benjamin Herrenschmidt wrote: Or give me a chance to dig :-) I'll have a look next week. This is indeed what bjorn suspected on irc, this patch fixes it: (Bjorn, please fold it in the original offending patch) Thanks guys; I'll push the fixes to -next when I get to a real network (at the airport now about to run out of battery with a crappy connection). Jesse ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: linux-next: manual merge of the powerpc tree with the arm tree
On 03/08/2012 09:13 PM, Benjamin Herrenschmidt wrote: On Fri, 2012-03-09 at 00:39 +, Russell King wrote: On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote: Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If I remove it, then I get Kconfig warnings: warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies (HAVE_GENERIC_HARDIRQS HAVE_SPARSE_IRQ) Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ? Nope, Grant patch didn't mention a dependency. My opinion is that SPARSE_IRQ shouldn't be user visible option, and the simple solution was to just make it hidden. It wasn't clear if this was desired or not for other arches at the time. There is a mixture of settings in powerpc defconfigs. SuperH selects it for 32-bit and leaves it user selectable for 64-bit. I'm happy to revert adding MAY_HAVE_SPARSE_IRQ and just make SPARSE_IRQ a hidden option. It really just needs the okay from SuperH folks. Rob ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
