[PATCH] I2C: Add support for 64bit system.
Currently I2C_MPC supports 32bit system only, then this modification makes it support 32bit and 64bit system both. Signed-off-by: Xulei --- drivers/i2c/busses/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 9c6170c..3392f4b 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -422,7 +422,7 @@ config I2C_IXP2000 config I2C_MPC tristate "MPC107/824x/85xx/512x/52xx/83xx/86xx" - depends on PPC32 + depends on PPC32 || PPC64 help If you say yes to this option, support will be included for the built-in I2C interface on the MPC107, Tsi107, MPC512x, MPC52xx, -- 1.7.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] I2C: Add support for 64bit system.
On Mon, Dec 20, 2010 at 03:37:34PM +0800, Xulei wrote: > Currently I2C_MPC supports 32bit system only, then this > modification makes it support 32bit and 64bit system both. > > Signed-off-by: Xulei This been build or run tested? > --- > drivers/i2c/busses/Kconfig |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > index 9c6170c..3392f4b 100644 > --- a/drivers/i2c/busses/Kconfig > +++ b/drivers/i2c/busses/Kconfig > @@ -422,7 +422,7 @@ config I2C_IXP2000 > > config I2C_MPC > tristate "MPC107/824x/85xx/512x/52xx/83xx/86xx" > - depends on PPC32 > + depends on PPC32 || PPC64 > help > If you say yes to this option, support will be included for the > built-in I2C interface on the MPC107, Tsi107, MPC512x, MPC52xx, > -- > 1.7.0.4 > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Ben Dooks, b...@fluff.org, http://www.fluff.org/ben/ Large Hadron Colada: A large Pina Colada that makes the universe disappear. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
P2020 with BCM53115
I am trying to bring up a P2020 board which uses the Broadcom BCM53115 switch in unmanaged mode. The board is patterned after the P2020RDB, except the Vitesse switch has been replaced with a BCM53115. There is no MDIO connection to the switch, but there is an SPI connection available if needed. When running Uboot, the BCM53115 works just fine, as I am able to download the Linux Kernel and P2020RDB.dtb across the network without issue. But as Linux is booting up, I get the message: mdio_bus m...@ffe24520: error probing PHY at address 0 mdio_bus m...@ffe24520: error probing PHY at address 1 I expect these errors occur because the P2020RDB.dts file has these entries. I'm not sure what to try next to get Linux to use the BCM53115 switch in unmanaged mode. Any help is appreciated, Thanks, Craig This message is intended only for the designated recipient(s) and may contain confidential or proprietary information of Mercury Computer Systems, Inc. This message is solely intended to facilitate business discussions and does not constitute an express or implied offer to sell or purchase any products, services, or support. Any commitments must be made in writing and signed by duly authorized representatives of each party. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: P2020 with BCM53115
On Mon, 20 Dec 2010 13:08:55 -0500 "Dry, Craig" wrote: > I am trying to bring up a P2020 board which uses the Broadcom BCM53115 switch > in unmanaged mode. The board is patterned after the P2020RDB, except the > Vitesse switch has been replaced with a BCM53115. There is no MDIO connection > to the switch, but there is an SPI connection available if needed. > > When running Uboot, the BCM53115 works just fine, as I am able to download > the Linux Kernel and P2020RDB.dtb across the network without issue. But as > Linux is booting up, I get the message: > > mdio_bus m...@ffe24520: error probing PHY at address 0 > mdio_bus m...@ffe24520: error probing PHY at address 1 > > I expect these errors occur because the P2020RDB.dts file has these entries. > > I'm not sure what to try next to get Linux to use the BCM53115 switch in > unmanaged mode. See the fixed-link property in Documentation/powerpc/dts-bindings/fsl/tsec.txt -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Oops in trace_hardirqs_on (powerpc)
On Sun, 2010-12-19 at 14:27 +0100, Jörg Sommer wrote: > Hi Steven, > > Steven Rostedt hat am Mon 27. Sep, 21:58 (-0400) geschrieben: > > On Mon, 2010-09-27 at 14:50 +0200, Jörg Sommer wrote: > > > Hello Steven, > > > > > > Steven Rostedt hat am Wed 22. Sep, 15:44 (-0400) geschrieben: > > > > Sorry for the late reply, but I was on vacation when you sent this, and > > > > I missed it while going through email. > > > > > > > > Do you still have this issue? > > > > > > No. I've rebuild my kernel without TRACE_IRQFLAGS and the problem > > > vanished, as expected. The problem is, that in some cases the stack is > > > only two frames deep, which causes the macro CALLER_ADDR1 makes an > > > invalid access. Someone told me, there a workaround for the problem on > > > i386, too. > > > > > > % sed -n 2p arch/x86/lib/thunk_32.S > > > * Trampoline to trace irqs off. (otherwise CALLER_ADDR1 might crash) > > > > Yes, I remember that problem. When I get back from Tokyo, I'll tried to > > remember to fix it. > > Did you've fixed this problem? The bug report is still marked as open. > https://bugzilla.kernel.org/show_bug.cgi?id=16573 > Ah, this email got lost in the hundreds I had when I got back from Tokyo, sorry about that again :-( Anyway, it looks like this only affects 32 bit PPC as I can't reproduce it with my 64 bit one. And also, unfortunately, my 32bit ppc got taken from me by my kids, so I can't test it on that either. I'll look to see if I can write up a patch. Perhaps you could test it for me. Thanks, -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Oops in trace_hardirqs_on (powerpc)
On Mon, 2010-12-20 at 15:43 -0500, Steven Rostedt wrote: > Anyway, it looks like this only affects 32 bit PPC as I can't reproduce > it with my 64 bit one. And also, unfortunately, my 32bit ppc got taken > from me by my kids, so I can't test it on that either. Spoke too soon, I just triggered it on 64bit. I'll look into it. Thanks! -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 1/2] eSPI: change the read behavior of the SPIRF
The user must read N bytes of SPIRF (1 <= N <= 4) that do not exceed the
amount of data in the receive FIFO, so read the SPIRF byte by byte when
the data in receive FIFO is less than 4 bytes.
On Simics, when read N bytes that exceed the amout of data in receive
FIFO, we can't read the data out, that is we can't clear the rx FIFO,
then the CPU will loop on the espi rx interrupt.
Signed-off-by: Mingkai Hu
---
The patch 2/2 is againsted on this patch, so I resent this patch again
for convience which sent several weeks ago.
drivers/spi/spi_fsl_espi.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/spi/spi_fsl_espi.c b/drivers/spi/spi_fsl_espi.c
index e3b4f64..ae78926 100644
--- a/drivers/spi/spi_fsl_espi.c
+++ b/drivers/spi/spi_fsl_espi.c
@@ -507,16 +507,29 @@ void fsl_espi_cpu_irq(struct mpc8xxx_spi *mspi, u32
events)
/* We need handle RX first */
if (events & SPIE_NE) {
- u32 rx_data;
+ u32 rx_data, tmp;
+ u8 rx_data_8;
/* Spin until RX is done */
while (SPIE_RXCNT(events) < min(4, mspi->len)) {
cpu_relax();
events = mpc8xxx_spi_read_reg(®_base->event);
}
- mspi->len -= 4;
- rx_data = mpc8xxx_spi_read_reg(®_base->receive);
+ if (mspi->len >= 4) {
+ rx_data = mpc8xxx_spi_read_reg(®_base->receive);
+ } else {
+ tmp = mspi->len;
+ rx_data = 0;
+ while (tmp--) {
+ rx_data_8 = in_8((u8 *)®_base->receive);
+ rx_data |= (rx_data_8 << (tmp * 8));
+ }
+
+ rx_data <<= (4 - mspi->len) * 8;
+ }
+
+ mspi->len -= 4;
if (mspi->rx)
mspi->get_rx(rx_data, mspi);
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] eSPI: fix wrong setting of the address in the command buffer
Or else we cann't operate on the right address when the trans length
is greater than 65535.
Signed-off-by: Mingkai Hu
---
drivers/spi/spi_fsl_espi.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/spi/spi_fsl_espi.c b/drivers/spi/spi_fsl_espi.c
index ae78926..a99e233 100644
--- a/drivers/spi/spi_fsl_espi.c
+++ b/drivers/spi/spi_fsl_espi.c
@@ -258,18 +258,18 @@ static int fsl_espi_bufs(struct spi_device *spi, struct
spi_transfer *t)
return mpc8xxx_spi->count;
}
-static void fsl_espi_addr2cmd(unsigned int addr, u8 *cmd)
+static inline void fsl_espi_addr2cmd(unsigned int addr, u8 *cmd)
{
- if (cmd[1] && cmd[2] && cmd[3]) {
+ if (cmd) {
cmd[1] = (u8)(addr >> 16);
cmd[2] = (u8)(addr >> 8);
cmd[3] = (u8)(addr >> 0);
}
}
-static unsigned int fsl_espi_cmd2addr(u8 *cmd)
+static inline unsigned int fsl_espi_cmd2addr(u8 *cmd)
{
- if (cmd[1] && cmd[2] && cmd[3])
+ if (cmd)
return cmd[1] << 16 | cmd[2] << 8 | cmd[3] << 0;
return 0;
@@ -395,9 +395,11 @@ static void fsl_espi_rw_trans(struct spi_message *m,
}
}
- addr = fsl_espi_cmd2addr(local_buf);
- addr += pos;
- fsl_espi_addr2cmd(addr, local_buf);
+ if (pos > 0) {
+ addr = fsl_espi_cmd2addr(local_buf);
+ addr += pos;
+ fsl_espi_addr2cmd(addr, local_buf);
+ }
espi_trans->n_tx = n_tx;
espi_trans->n_rx = trans_len;
--
1.6.4
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] I2C: Add support for 64bit system.
yes, it has been built and could access the RTC well. On 一, 2010-12-20 at 14:59 +, Ben Dooks wrote: > On Mon, Dec 20, 2010 at 03:37:34PM +0800, Xulei wrote: > > Currently I2C_MPC supports 32bit system only, then this > > modification makes it support 32bit and 64bit system both. > > > > Signed-off-by: Xulei > > This been build or run tested? > > > --- > > drivers/i2c/busses/Kconfig |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig > > index 9c6170c..3392f4b 100644 > > --- a/drivers/i2c/busses/Kconfig > > +++ b/drivers/i2c/busses/Kconfig > > @@ -422,7 +422,7 @@ config I2C_IXP2000 > > > > config I2C_MPC > > tristate "MPC107/824x/85xx/512x/52xx/83xx/86xx" > > - depends on PPC32 > > + depends on PPC32 || PPC64 > > help > > If you say yes to this option, support will be included for the > > built-in I2C interface on the MPC107, Tsi107, MPC512x, MPC52xx, > > -- > > 1.7.0.4 > > > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-i2c" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
