* Re: [PATCH v4 00/14] ARM: dts: r8a779x: use demuxer for I2C
From: Simon Horman @ 2016-11-10 10:06 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Wolfram Sang, linux-renesas-soc, linux-i2c
In-Reply-To: <20161109085954.GA1807@katana>
Hi Wolfram,
On Wed, Nov 09, 2016 at 09:59:54AM +0100, Wolfram Sang wrote:
> Hi Simon,
>
> > I have tested these patches on alt, gose, lager and koelsch.
>
> Wow, that was quick. Thank you!
>
> > The switching part seems to work fine, in so far as my test script
> > succeeds. However, it seems that some IP blocks are not able to handle
> > this switching. In particular I needed to disable VIDEO_RCAR_VIN and
> > REGULATOR_DA9210 to avoid errors shown in the logs below.
>
> Yes. Probably we should activate the shiny new DEBUG_TEST_DRIVER_REMOVE
> and if that passes, we should be safe.
>
> > My suggestion is to drop the following patches until those problems
> > can be sorted out, most likely via driver updates.
> >
> > ARM: dts: alt: use demuxer for I2C1
> > ARM: dts: gose: use demuxer for I2C2
> > ARM: dts: lager: use demuxer for IIC2/I2C2
> > ARM: dts: lager: use demuxer for IIC3/I2C3
> > ARM: dts: koelsch: use demuxer for I2C2
>
> OK. I'll try to have a look at those drivers nonetheless, because
> rebasing these patches is a bit of a hazzle once new i2c slaves were
> added to the busses. But I'll juest resend the patches along with my
> fixes if I really can find the time.
>
> > I am not in a position to test silk or porter at this time.
> > But by the same reasoning above I wonder if the following should
> > be dropped for now.
> >
> > ARM: dts: gose: use demuxer for I2C2
>
> I assume you mean 'porter' here.
>
> > ARM: dts: silk: use demuxer for I2C1
As per our discussion on IRC this morning I have queued up the following.
We can revisit the remaining patches once the issues described above
are resolved one way or another.
ARM: dts: alt: use demuxer for I2C4
ARM: dts: gose: use demuxer for I2C4
ARM: dts: koelsch: use demuxer for I2C4
ARM: dts: koelsch: use demuxer for I2C1
ARM: dts: lager: use demuxer for IIC1/I2C1
ARM: dts: lager: rename and reindex i2cexio
^ permalink raw reply
* Re: [PATCH v4 00/14] ARM: dts: r8a779x: use demuxer for I2C
From: Magnus Damm @ 2016-11-10 8:12 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Simon Horman, Wolfram Sang, Linux-Renesas, Linux-I2C
In-Reply-To: <20161110075719.GA1436@katana>
Hi Wolfram,
On Thu, Nov 10, 2016 at 4:57 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> I think postponing merge of patches is one thing but I don't think
>> dropping them forever is a long term solution. I think we should have
>
> Just to make sure because you wrote 'them': I talked about one patch of
> the series, not the whole series, namely DVFS. Because Lager is the only
> board we have where you can multiplex DVFS between IIC and I2C, no GPIO
> option here. All other SoCs have dedicated pins for DVFS which you can't
> mux to anything else at all.
Sorry I meant "one patch". As a workaround it is fine, but dropping
one patch still does not change the way the hardware is designed.
Being able to change the I2C master controller between the on-chip I2C
device and the on-chip IIC device is still something that the hardware
supports but we cannot seem to do without further software
development.
Thanks,
/ magnus
^ permalink raw reply
* Re: [PATCH v4 00/14] ARM: dts: r8a779x: use demuxer for I2C
From: Wolfram Sang @ 2016-11-10 7:57 UTC (permalink / raw)
To: Magnus Damm; +Cc: Simon Horman, Wolfram Sang, Linux-Renesas, Linux-I2C
In-Reply-To: <CANqRtoRwSh602rjbHA2qo=XHyimpyyi_T=0sh2A4NOfzzVB+oQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 462 bytes --]
> I think postponing merge of patches is one thing but I don't think
> dropping them forever is a long term solution. I think we should have
Just to make sure because you wrote 'them': I talked about one patch of
the series, not the whole series, namely DVFS. Because Lager is the only
board we have where you can multiplex DVFS between IIC and I2C, no GPIO
option here. All other SoCs have dedicated pins for DVFS which you can't
mux to anything else at all.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v4 00/14] ARM: dts: r8a779x: use demuxer for I2C
From: Magnus Damm @ 2016-11-10 3:56 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Simon Horman, Wolfram Sang, Linux-Renesas, Linux-I2C
In-Reply-To: <20161109172813.GA1545@katana>
Hi Wolfram,
On Thu, Nov 10, 2016 at 2:28 AM, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> ARM: dts: lager: use demuxer for IIC3/I2C3
>
> I think the sanest solution is to drop this patch forever. The WARN from
> the regulator core is sparse in describing the problem yet it is
> correct: The regulator is needed, by the CPU! :) And this will probably
> be the smallest problem when trying to demux the bus which is used to
> handle all DVFS operations. Let's stick to IIC3 here, I'd say. Gen3 even
> has this one IIC instance for exactly the DVFS purpose.
I think postponing merge of patches is one thing but I don't think
dropping them forever is a long term solution. I think we should have
a plan how to describe the hardware as-is in DT and work towards
having software support for it.
My hope has always been that it would be possible to switch I2C master
during run time without deregister/register of all the slave devices.
I do realise much work will be needed to make it happen, but from
hardware point of view it must be possible to switch I2C master
transparently between the messages on the bus.
Thanks,
/ magnus
^ permalink raw reply
* [PATCH v4] i2c: designware: Implement support for SMBus block read and write
From: tnhuynh @ 2016-11-10 2:56 UTC (permalink / raw)
To: Jarkko Nikula, Andy Shevchenko, Mika Westerberg, Wolfram Sang,
linux-i2c, linux-kernel
Cc: Loc Ho, Thang Nguyen, Phong Vo, patches, Tin Huynh
From: Tin Huynh <tnhuynh@apm.com>
Free and Open IPMI use SMBUS BLOCK Read/Write to support SSIF protocol.
However, I2C Designware Core Driver doesn't handle the case at the moment.
The below patch supports this feature.
Signed-off-by: Tin Huynh <tnhuynh@apm.com>
---
Change from V3:
- Correct coding conventions
- Make clean
Change from V2:
- Change subject of email
- Add a helper function to handle
length byte receiving
Change from V1:
- Remove empty lines
- Add flags variable to make clean code
- Change DW_DEFAULT_FUNCTIONALITY
in i2c-designware-pcidrv.c
---
drivers/i2c/busses/i2c-designware-core.c | 46 +++++++++++++++++++++++++--
drivers/i2c/busses/i2c-designware-pcidrv.c | 1 +
drivers/i2c/busses/i2c-designware-platdrv.c | 1 +
3 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c b/drivers/i2c/busses/i2c-designware-core.c
index 1fe93c4..c91d1b4 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -543,6 +543,8 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
intr_mask = DW_IC_INTR_DEFAULT_MASK;
for (; dev->msg_write_idx < dev->msgs_num; dev->msg_write_idx++) {
+ u32 flags = msgs[dev->msg_write_idx].flags;
+
/*
* if target address has changed, we need to
* reprogram the target address in the i2c
@@ -588,8 +590,15 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
* detected from the registers so we set it always
* when writing/reading the last byte.
*/
+
+ /*
+ * i2c-core.c always sets the buffer length of
+ * I2C_FUNC_SMBUS_BLOCK_DATA to 1. The length will
+ * be adjusted when receiving the first byte.
+ * Thus we can't stop the transaction here.
+ */
if (dev->msg_write_idx == dev->msgs_num - 1 &&
- buf_len == 1)
+ buf_len == 1 && !(flags & I2C_M_RECV_LEN))
cmd |= BIT(9);
if (need_restart) {
@@ -614,7 +623,12 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
dev->tx_buf = buf;
dev->tx_buf_len = buf_len;
- if (buf_len > 0) {
+ /*
+ * Because we don't know the buffer length in the
+ * I2C_FUNC_SMBUS_BLOCK_DATA case, we can't stop
+ * the transaction here.
+ */
+ if (buf_len > 0 || flags & I2C_M_RECV_LEN) {
/* more bytes to be written */
dev->status |= STATUS_WRITE_IN_PROGRESS;
break;
@@ -635,6 +649,24 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
dw_writel(dev, intr_mask, DW_IC_INTR_MASK);
}
+static u8
+i2c_dw_recv_len(struct dw_i2c_dev *dev, u8 len)
+{
+ struct i2c_msg *msgs = dev->msgs;
+ u32 flags = msgs[dev->msg_read_idx].flags;
+
+ /*
+ * Adjust the buffer length and mask the flag
+ * after receiving the first byte.
+ */
+ len += (flags & I2C_CLIENT_PEC) ? 2 : 1;
+ dev->tx_buf_len = len - min_t(u8, len, dev->rx_outstanding);
+ msgs[dev->msg_read_idx].len = len;
+ msgs[dev->msg_read_idx].flags &= ~I2C_M_RECV_LEN;
+
+ return len;
+}
+
static void
i2c_dw_read(struct dw_i2c_dev *dev)
{
@@ -659,7 +691,15 @@ static void i2c_dw_xfer_init(struct dw_i2c_dev *dev)
rx_valid = dw_readl(dev, DW_IC_RXFLR);
for (; len > 0 && rx_valid > 0; len--, rx_valid--) {
- *buf++ = dw_readl(dev, DW_IC_DATA_CMD);
+ u32 flags = msgs[dev->msg_read_idx].flags;
+
+ *buf = dw_readl(dev, DW_IC_DATA_CMD);
+ /* Ensure length byte is a valid value */
+ if (flags & I2C_M_RECV_LEN &&
+ *buf <= I2C_SMBUS_BLOCK_MAX && *buf > 0) {
+ len = i2c_dw_recv_len(dev, *buf);
+ }
+ buf++;
dev->rx_outstanding--;
}
diff --git a/drivers/i2c/busses/i2c-designware-pcidrv.c b/drivers/i2c/busses/i2c-designware-pcidrv.c
index 96f8230..8ffe2da 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
@@ -75,6 +75,7 @@ struct dw_pci_controller {
I2C_FUNC_SMBUS_BYTE | \
I2C_FUNC_SMBUS_BYTE_DATA | \
I2C_FUNC_SMBUS_WORD_DATA | \
+ I2C_FUNC_SMBUS_BLOCK_DATA | \
I2C_FUNC_SMBUS_I2C_BLOCK)
/* Merrifield HCNT/LCNT/SDA hold time */
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 0b42a12..886fb62 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -220,6 +220,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
I2C_FUNC_SMBUS_BYTE |
I2C_FUNC_SMBUS_BYTE_DATA |
I2C_FUNC_SMBUS_WORD_DATA |
+ I2C_FUNC_SMBUS_BLOCK_DATA |
I2C_FUNC_SMBUS_I2C_BLOCK;
dev->master_cfg = DW_IC_CON_MASTER | DW_IC_CON_SLAVE_DISABLE |
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v4 00/14] ARM: dts: r8a779x: use demuxer for I2C
From: Geert Uytterhoeven @ 2016-11-09 19:00 UTC (permalink / raw)
To: Simon Horman; +Cc: Wolfram Sang, Wolfram Sang, Linux-Renesas, Linux I2C
In-Reply-To: <20161109143508.GA19184@verge.net.au>
On Wed, Nov 9, 2016 at 3:35 PM, Simon Horman <horms@verge.net.au> wrote:
>> Will you get access to these boards in the foreseeable future?
>
> As mentioned by Geert, there is a porter in Magnus's board farm.
> Unforunately I have never had much luck in getting it to boot.
>From the point of view of the kernel, there's not much difference between
Koelsch/Lager and Porter. The U-Boot is newer than the one on Lager,
though, so no need for the "dtb" keyword in the bootz command.
I use:
setenv ethaddr 2e:01:02:03:04:05
tftp 41000000 porter/zImage
tftp 40f00000 porter/r8a7791-porter.dtb
bootz 41000000 - 40f00000
Perhaps you didn't have the MAC address set?
BTW, for blanche, I had to add "setenv fdt_high 41000000".
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v4 00/14] ARM: dts: r8a779x: use demuxer for I2C
From: Wolfram Sang @ 2016-11-09 17:28 UTC (permalink / raw)
To: Simon Horman; +Cc: Wolfram Sang, linux-renesas-soc, linux-i2c
In-Reply-To: <20161109084406.GA22213@verge.net.au>
[-- Attachment #1: Type: text/plain, Size: 457 bytes --]
> ARM: dts: lager: use demuxer for IIC3/I2C3
I think the sanest solution is to drop this patch forever. The WARN from
the regulator core is sparse in describing the problem yet it is
correct: The regulator is needed, by the CPU! :) And this will probably
be the smallest problem when trying to demux the bus which is used to
handle all DVFS operations. Let's stick to IIC3 here, I'd say. Gen3 even
has this one IIC instance for exactly the DVFS purpose.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] i2c: octeon: Fix register access
From: Jan Glauber @ 2016-11-09 14:43 UTC (permalink / raw)
To: Paul Burton; +Cc: linux-i2c, linux-mips, David Daney, Wolfram Sang, stable
In-Reply-To: <10136944.jCslgNClvG@np-p-burton>
On Wed, Nov 09, 2016 at 02:09:38PM +0000, Paul Burton wrote:
> On Tuesday, 8 November 2016 08:13:37 GMT Jan Glauber wrote:
> > On Mon, Nov 07, 2016 at 08:09:20PM +0000, Paul Burton wrote:
> > > Commit 70121f7f3725 ("i2c: octeon: thunderx: Limit register access
> > > retries") attempted to replace potentially infinite loops with ones
> > > which will time out using readq_poll_timeout, but in doing so it
> > > inverted the condition for exiting this loop.
> > >
> > > Tested on a Rhino Labs UTM-8 with Octeon CN7130.
> > >
> > > Signed-off-by: Paul Burton <paul.burton@imgtec.com>
> > > Cc: Jan Glauber <jglauber@cavium.com>
> > > Cc: David Daney <david.daney@cavium.com>
> > > Cc: Wolfram Sang <wsa@the-dreams.de>
> > > Cc: linux-i2c@vger.kernel.org
> > >
> > > ---
> >
> > Acked-by: Jan Glauber <jglauber@cavium.com>
> >
> > Thanks for spotting this. I think this should go into stable too for
> > 4.8, so adding Cc: stable@vger.kernel.org.
>
> Hi Jan,
>
> ...but the bad patch was only merged for v4.9-rc1?
true, I've misread it.
> Thanks,
> Paul
>
> >
> > > drivers/i2c/busses/i2c-octeon-core.h | 7 ++++---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/i2c/busses/i2c-octeon-core.h
> > > b/drivers/i2c/busses/i2c-octeon-core.h index 1db7c83..d980406 100644
> > > --- a/drivers/i2c/busses/i2c-octeon-core.h
> > > +++ b/drivers/i2c/busses/i2c-octeon-core.h
> > > @@ -146,8 +146,9 @@ static inline void octeon_i2c_reg_write(struct
> > > octeon_i2c *i2c, u64 eop_reg, u8>
> > > __raw_writeq(SW_TWSI_V | eop_reg | data, i2c->twsi_base +
> SW_TWSI(i2c));
> > >
> > > - readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp, tmp &
> SW_TWSI_V,
> > > - I2C_OCTEON_EVENT_WAIT, i2c->adap.timeout);
> > > + readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp,
> > > + !(tmp & SW_TWSI_V), I2C_OCTEON_EVENT_WAIT,
> > > + i2c->adap.timeout);
> > >
> > > }
> > >
> > > #define octeon_i2c_ctl_write(i2c, val) \
> > >
> > > @@ -173,7 +174,7 @@ static inline int octeon_i2c_reg_read(struct
> > > octeon_i2c *i2c, u64 eop_reg,>
> > > __raw_writeq(SW_TWSI_V | eop_reg | SW_TWSI_R, i2c->twsi_base +
> > > SW_TWSI(i2c));
> > >
> > > ret = readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp,
> > >
> > > - tmp & SW_TWSI_V, I2C_OCTEON_EVENT_WAIT,
> > > + !(tmp & SW_TWSI_V), I2C_OCTEON_EVENT_WAIT,
> > >
> > > i2c->adap.timeout);
> > >
> > > if (error)
> > >
> > > *error = ret;
>
^ permalink raw reply
* Re: [PATCH 2/2] i2c: octeon: Fix waiting for operation completion
From: Jan Glauber @ 2016-11-09 14:38 UTC (permalink / raw)
To: Paul Burton
Cc: linux-i2c, linux-mips, David Daney, Peter Swain, Wolfram Sang,
Steven J. Hill
In-Reply-To: <1595446.2T31j1Ekg5@np-p-burton>
On Wed, Nov 09, 2016 at 02:07:58PM +0000, Paul Burton wrote:
> On Wednesday, 9 November 2016 14:41:03 GMT Jan Glauber wrote:
> > Hi Paul,
> >
> > I think we should revert commit "70121f7 i2c: octeon: thunderx: Limit
> > register access retries". With debugging enabled I'm getting:
> >
> > <snip>
> >
> > This is not caused by the usleep inside the wait_event but by
> > readq_poll_timeout(). Could you try if it works for you if you only revert
> > this patch?
> >
> > Thanks,
> > Jan
>
> Hi Jan,
>
> If I drop both my patches & just revert 70121f7f3725 ("i2c: octeon: thunderx:
> Limit register access retries") sadly it doesn't fix my system. A boot of a
> cavium_octeon_defconfig kernel with initcall_debug ends with:
>
> calling octeon_mgmt_mod_init+0x0/0x28 @ 1
> initcall octeon_mgmt_mod_init+0x0/0x28 returned 0 after 67 usecs
> calling ds1307_driver_init+0x0/0x10 @ 1
> initcall ds1307_driver_init+0x0/0x10 returned 0 after 19 usecs
> calling octeon_i2c_driver_init+0x0/0x10 @ 1
> ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> ata1.00: ATA-9: SanDisk SDSSDA240G, Z22000RL, max UDMA/133
> ata1.00: 468862128 sectors, multi 1: LBA48 NCQ (depth 31/32)
> ata1.00: configured for UDMA/133
> scsi 0:0:0:0: Direct-Access ATA SanDisk SDSSDA24 00RL PQ: 0 ANSI: 5
> sd 0:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 GiB)
> sd 0:0:0:0: [sda] Write Protect is off
> sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA
> sda: sda1 sda2 sda3 sda4
> sd 0:0:0:0: [sda] Attached SCSI disk
> ata2: SATA link down (SStatus 0 SControl 300)
> random: crng init done
>
> As you can see octeon_i2c_driver_init never returns. Are you able to test on
> one of your MIPS-based systems?
CC'ing Steven who might be able to test on MIPS.
> Thanks,
> Paul
^ permalink raw reply
* Re: [PATCH v4 00/14] ARM: dts: r8a779x: use demuxer for I2C
From: Simon Horman @ 2016-11-09 14:35 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Wolfram Sang, linux-renesas-soc, linux-i2c
In-Reply-To: <20161109085954.GA1807@katana>
On Wed, Nov 09, 2016 at 09:59:54AM +0100, Wolfram Sang wrote:
> Hi Simon,
>
> > I have tested these patches on alt, gose, lager and koelsch.
>
> Wow, that was quick. Thank you!
>
> > The switching part seems to work fine, in so far as my test script
> > succeeds. However, it seems that some IP blocks are not able to handle
> > this switching. In particular I needed to disable VIDEO_RCAR_VIN and
> > REGULATOR_DA9210 to avoid errors shown in the logs below.
>
> Yes. Probably we should activate the shiny new DEBUG_TEST_DRIVER_REMOVE
> and if that passes, we should be safe.
>
> > My suggestion is to drop the following patches until those problems
> > can be sorted out, most likely via driver updates.
> >
> > ARM: dts: alt: use demuxer for I2C1
> > ARM: dts: gose: use demuxer for I2C2
> > ARM: dts: lager: use demuxer for IIC2/I2C2
> > ARM: dts: lager: use demuxer for IIC3/I2C3
> > ARM: dts: koelsch: use demuxer for I2C2
>
> OK. I'll try to have a look at those drivers nonetheless, because
> rebasing these patches is a bit of a hazzle once new i2c slaves were
> added to the busses. But I'll juest resend the patches along with my
> fixes if I really can find the time.
>
> > I am not in a position to test silk or porter at this time.
> > But by the same reasoning above I wonder if the following should
> > be dropped for now.
> >
> > ARM: dts: gose: use demuxer for I2C2
>
> I assume you mean 'porter' here.
Yes, I meant porter.
> > ARM: dts: silk: use demuxer for I2C1
>
> Will you get access to these boards in the foreseeable future?
As mentioned by Geert, there is a porter in Magnus's board farm.
Unforunately I have never had much luck in getting it to boot.
With regards to silk, I'm not aware of any plans at this time.
^ permalink raw reply
* Re: [PATCH 1/2] i2c: octeon: Fix register access
From: Paul Burton @ 2016-11-09 14:09 UTC (permalink / raw)
To: Jan Glauber; +Cc: linux-i2c, linux-mips, David Daney, Wolfram Sang, stable
In-Reply-To: <20161108071337.GA4601@hardcore>
[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]
On Tuesday, 8 November 2016 08:13:37 GMT Jan Glauber wrote:
> On Mon, Nov 07, 2016 at 08:09:20PM +0000, Paul Burton wrote:
> > Commit 70121f7f3725 ("i2c: octeon: thunderx: Limit register access
> > retries") attempted to replace potentially infinite loops with ones
> > which will time out using readq_poll_timeout, but in doing so it
> > inverted the condition for exiting this loop.
> >
> > Tested on a Rhino Labs UTM-8 with Octeon CN7130.
> >
> > Signed-off-by: Paul Burton <paul.burton@imgtec.com>
> > Cc: Jan Glauber <jglauber@cavium.com>
> > Cc: David Daney <david.daney@cavium.com>
> > Cc: Wolfram Sang <wsa@the-dreams.de>
> > Cc: linux-i2c@vger.kernel.org
> >
> > ---
>
> Acked-by: Jan Glauber <jglauber@cavium.com>
>
> Thanks for spotting this. I think this should go into stable too for
> 4.8, so adding Cc: stable@vger.kernel.org.
Hi Jan,
...but the bad patch was only merged for v4.9-rc1?
Thanks,
Paul
>
> > drivers/i2c/busses/i2c-octeon-core.h | 7 ++++---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-octeon-core.h
> > b/drivers/i2c/busses/i2c-octeon-core.h index 1db7c83..d980406 100644
> > --- a/drivers/i2c/busses/i2c-octeon-core.h
> > +++ b/drivers/i2c/busses/i2c-octeon-core.h
> > @@ -146,8 +146,9 @@ static inline void octeon_i2c_reg_write(struct
> > octeon_i2c *i2c, u64 eop_reg, u8>
> > __raw_writeq(SW_TWSI_V | eop_reg | data, i2c->twsi_base +
SW_TWSI(i2c));
> >
> > - readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp, tmp &
SW_TWSI_V,
> > - I2C_OCTEON_EVENT_WAIT, i2c->adap.timeout);
> > + readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp,
> > + !(tmp & SW_TWSI_V), I2C_OCTEON_EVENT_WAIT,
> > + i2c->adap.timeout);
> >
> > }
> >
> > #define octeon_i2c_ctl_write(i2c, val) \
> >
> > @@ -173,7 +174,7 @@ static inline int octeon_i2c_reg_read(struct
> > octeon_i2c *i2c, u64 eop_reg,>
> > __raw_writeq(SW_TWSI_V | eop_reg | SW_TWSI_R, i2c->twsi_base +
> > SW_TWSI(i2c));
> >
> > ret = readq_poll_timeout(i2c->twsi_base + SW_TWSI(i2c), tmp,
> >
> > - tmp & SW_TWSI_V, I2C_OCTEON_EVENT_WAIT,
> > + !(tmp & SW_TWSI_V), I2C_OCTEON_EVENT_WAIT,
> >
> > i2c->adap.timeout);
> >
> > if (error)
> >
> > *error = ret;
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] i2c: octeon: Fix waiting for operation completion
From: Paul Burton @ 2016-11-09 14:07 UTC (permalink / raw)
To: Jan Glauber; +Cc: linux-i2c, linux-mips, David Daney, Peter Swain, Wolfram Sang
In-Reply-To: <20161109134103.GC2960@hardcore>
[-- Attachment #1: Type: text/plain, Size: 1708 bytes --]
On Wednesday, 9 November 2016 14:41:03 GMT Jan Glauber wrote:
> Hi Paul,
>
> I think we should revert commit "70121f7 i2c: octeon: thunderx: Limit
> register access retries". With debugging enabled I'm getting:
>
> <snip>
>
> This is not caused by the usleep inside the wait_event but by
> readq_poll_timeout(). Could you try if it works for you if you only revert
> this patch?
>
> Thanks,
> Jan
Hi Jan,
If I drop both my patches & just revert 70121f7f3725 ("i2c: octeon: thunderx:
Limit register access retries") sadly it doesn't fix my system. A boot of a
cavium_octeon_defconfig kernel with initcall_debug ends with:
calling octeon_mgmt_mod_init+0x0/0x28 @ 1
initcall octeon_mgmt_mod_init+0x0/0x28 returned 0 after 67 usecs
calling ds1307_driver_init+0x0/0x10 @ 1
initcall ds1307_driver_init+0x0/0x10 returned 0 after 19 usecs
calling octeon_i2c_driver_init+0x0/0x10 @ 1
ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
ata1.00: ATA-9: SanDisk SDSSDA240G, Z22000RL, max UDMA/133
ata1.00: 468862128 sectors, multi 1: LBA48 NCQ (depth 31/32)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA SanDisk SDSSDA24 00RL PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 468862128 512-byte logical blocks: (240 GB/224 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support
DPO or FUA
sda: sda1 sda2 sda3 sda4
sd 0:0:0:0: [sda] Attached SCSI disk
ata2: SATA link down (SStatus 0 SControl 300)
random: crng init done
As you can see octeon_i2c_driver_init never returns. Are you able to test on
one of your MIPS-based systems?
Thanks,
Paul
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: amd756 driver error introduced with kernel-4.9.0-0.rc1.git0.2.fc26
From: Jean Delvare @ 2016-11-09 13:54 UTC (permalink / raw)
To: Johnny Bieren; +Cc: linux-i2c
In-Reply-To: <58221469.50005@redhat.com>
On Tue, 8 Nov 2016 13:07:37 -0500, Johnny Bieren wrote:
> No, that option is not enabled.
>
> cat /boot/config-4.9.0-0.rc1.git0.2.fc26.x86_64 | grep DEBUG_TEST
> # CONFIG_DEBUG_TEST_DRIVER_REMOVE is not set
Then I don't know. I can't see how the only recent change to the
i2c-amd756 driver (ea734404f3daf1f6b5103171d848c9d4641fd96b) could
cause this. The warning comes from:
WARN_ON(!list_empty(&dev->devres_head));
which was added a decade ago so nothing new here.
I'm out of ideas. The only way to move forward is to bisect it to find
out the exact commit which triggered the warning.
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* Re: [PATCH 2/2] i2c: octeon: Fix waiting for operation completion
From: Jan Glauber @ 2016-11-09 13:41 UTC (permalink / raw)
To: Paul Burton; +Cc: linux-i2c, linux-mips, David Daney, Peter Swain, Wolfram Sang
In-Reply-To: <20161107200921.30284-2-paul.burton@imgtec.com>
Hi Paul,
I think we should revert commit "70121f7 i2c: octeon: thunderx: Limit
register access retries". With debugging enabled I'm getting:
[ 78.871568] ipmi_ssif: Trying hotmod-specified SSIF interface at i2c address 0x12, adapter Cavium ThunderX i2c adapter at 0000:01:09.4, slave address 0x0
[ 78.886107] do not call blocking ops when !TASK_RUNNING; state=2 set at [<fffffc00080e0088>] prepare_to_wait_event+0x58/0x10c
[ 78.897436] ------------[ cut here ]------------
[ 78.902050] WARNING: CPU: 6 PID: 2235 at kernel/sched/core.c:7718 __might_sleep+0x80/0x88
[ 78.910218] Modules linked in: ipmi_ssif i2c_thunderx i2c_smbus nicvf nicpf thunder_bgx thunder_xcv mdio_thunder
[ 78.921916] CPU: 6 PID: 2235 Comm: bash Tainted: G W 4.9.0-rc3-jang+ #17
[ 78.929737] Hardware name: www.cavium.com ThunderX CRB-1S/ThunderX CRB-1S, BIOS 0.3 Aug 24 2016
[ 78.938426] task: fffffe1fdd554500 task.stack: fffffe1fe384c000
[ 78.944338] PC is at __might_sleep+0x80/0x88
[ 78.948601] LR is at __might_sleep+0x80/0x88
[ 78.952863] pc : [<fffffc00080c3aac>] lr : [<fffffc00080c3aac>] pstate: 80000145
[ 78.960250] sp : fffffe1fe384f600
[ 78.963557] x29: fffffe1fe384f600 x28: fffffe1fe384f860
[ 78.968875] x27: fffffe1fd07fa018 x26: fffffe1fe384f968
[ 78.974193] x25: fffffc0009a2b000 x24: 00000000ffff26d6
[ 78.979510] x23: fffffe1fe384f860 x22: fffffe1fe384f860
[ 78.984827] x21: 0000000000000000 x20: 00000000000000b1
[ 78.990144] x19: fffffc0000e330b8 x18: 0000000000005bb0
[ 78.995461] x17: fffffc0009669ca8 x16: 0000000000000000
[ 79.000779] x15: 0000000000000539 x14: 66663c5b20746120
[ 79.006097] x13: 74657320323d6574 x12: 617473203b474e49
[ 79.011415] x11: 4e4e55525f4b5341 x10: 5421206e65687720
[ 79.016732] x9 : 73706f20676e696b x8 : 0000000000000000
[ 79.022049] x7 : fffffc00080f5740 x6 : fffffc00080f5740
[ 79.027367] x5 : ffffffffffffff80 x4 : 0000000000000060
[ 79.032684] x3 : 0000000000000000 x2 : 0000000000000001
[ 79.038001] x1 : 0000000000000000 x0 : 0000000000000071
[ 79.044803] ---[ end trace d8af6005f683d444 ]---
[ 79.049413] Call trace:
[ 79.051853] Exception stack(0xfffffe1fe384f420 to 0xfffffe1fe384f550)
[ 79.058287] f420: fffffc0000e330b8 0000040000000000 fffffe1fe384f600 fffffc00080c3aac
[ 79.066109] f440: 0000000080000145 000000000000003d 0000000000000000 fffffc0008853920
[ 79.073931] f460: 0000040000000000 0000000100000001 fffffe1fe384f520 fffffc00080f60d8
[ 79.081752] f480: fffffc0000e330b8 00000000000000b1 0000000000000000 fffffe1fe384f860
[ 79.089574] f4a0: fffffe1fe384f860 00000000ffff26d6 fffffc0009a2b000 fffffe1fe384f968
[ 79.097396] f4c0: fffffe1fd07fa018 fffffe1fe384f860 0000000000000071 0000000000000000
[ 79.105218] f4e0: 0000000000000001 0000000000000000 0000000000000060 ffffffffffffff80
[ 79.113040] f500: fffffc00080f5740 fffffc00080f5740 0000000000000000 73706f20676e696b
[ 79.120861] f520: 5421206e65687720 4e4e55525f4b5341 617473203b474e49 74657320323d6574
[ 79.128683] f540: 66663c5b20746120 0000000000000539
[ 79.133553] [<fffffc00080c3aac>] __might_sleep+0x80/0x88
[ 79.138862] [<fffffc0000e30138>] octeon_i2c_test_iflg+0x4c/0xbc [i2c_thunderx]
[ 79.146077] [<fffffc0000e30958>] octeon_i2c_test_ready+0x18/0x70 [i2c_thunderx]
[ 79.153379] [<fffffc0000e30b04>] octeon_i2c_wait+0x154/0x1a4 [i2c_thunderx]
[ 79.160334] [<fffffc0000e310bc>] octeon_i2c_xfer+0xf4/0xf60 [i2c_thunderx]
This is not caused by the usleep inside the wait_event but by readq_poll_timeout().
Could you try if it works for you if you only revert this patch?
Thanks,
Jan
^ permalink raw reply
* [PATCH v4 2/3] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Romain Perier @ 2016-11-09 11:57 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, linux-arm-kernel, Thomas Petazzoni, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas <mw>
In-Reply-To: <20161109115715.2557-1-romain.perier@free-electrons.com>
The Armada 3700 has two i2c bus interface units, this commit adds the
definitions of the corresponding device nodes. It also enables the node
on the development board for this SoC.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6..16d84af 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -62,6 +62,10 @@
};
};
+&i2c0 {
+ status = "okay";
+};
+
/* CON3 */
&sata {
status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index c476253..bf2d73d 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -98,6 +98,24 @@
/* 32M internal register @ 0xd000_0000 */
ranges = <0x0 0x0 0xd0000000 0x2000000>;
+ i2c0: i2c@11000 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11000 0x24>;
+ clocks = <&nb_perih_clk 10>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
+ i2c1: i2c@11080 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11080 0x24>;
+ clocks = <&nb_perih_clk 9>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
uart0: serial@12000 {
compatible = "marvell,armada-3700-uart";
reg = <0x12000 0x400>;
--
2.9.3
^ permalink raw reply related
* [PATCH v4 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-11-09 11:57 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161109115715.2557-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-11-09 11:57 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161109115715.2557-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The Armada 3700 has two I2C controllers that is compliant with the I2C
Bus Specificiation 2.1, supports multi-master and different bus speed:
Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
High speed mode (up to 3.4 Mhz).
This IP block has a lot of similarity with the PXA, except some register
offsets and bitfield. This commits adds a basic support for this I2C
unit.
Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Tested-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
Changes in v4:
- Replaced the type of hs_mask and fm_mask by u32, instead of
unsigned int, As writel() take an u32 as first argument...
Changes in v3:
- Replaced the type of hs_mask and fm_mask by unsigned int,
instead of unsigned long.
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 25 +++++++++++++++++++++++--
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d252276..2f56a26 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -763,7 +763,7 @@ config I2C_PUV3
config I2C_PXA
tristate "Intel PXA2XX I2C adapter"
- depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
+ depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
help
If you have devices in the PXA I2C bus, say yes to this option.
This driver can also be built as a module. If so, the module
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index e28b825..09b4705 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -55,6 +55,7 @@ enum pxa_i2c_types {
REGS_PXA3XX,
REGS_CE4100,
REGS_PXA910,
+ REGS_A3700,
};
/*
@@ -91,6 +92,13 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
.ilcr = 0x28,
.iwcr = 0x30,
},
+ [REGS_A3700] = {
+ .ibmr = 0x00,
+ .idbr = 0x04,
+ .icr = 0x08,
+ .isr = 0x0c,
+ .isar = 0x10,
+ },
};
static const struct platform_device_id i2c_pxa_id_table[] = {
@@ -98,6 +106,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa3xx-pwri2c", REGS_PXA3XX },
{ "ce4100-i2c", REGS_CE4100 },
{ "pxa910-i2c", REGS_PXA910 },
+ { "armada-3700-i2c", REGS_A3700 },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -122,7 +131,9 @@ MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
#define ICR_SADIE (1 << 13) /* slave address detected int enable */
#define ICR_UR (1 << 14) /* unit reset */
#define ICR_FM (1 << 15) /* fast mode */
+#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
#define ICR_HS (1 << 16) /* High Speed mode */
+#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
#define ICR_GPIOEN (1 << 19) /* enable GPIO mode for SCL in HS */
#define ISR_RWM (1 << 0) /* read/write mode */
@@ -193,6 +204,8 @@ struct pxa_i2c {
unsigned char master_code;
unsigned long rate;
bool highmode_enter;
+ u32 fm_mask;
+ u32 hs_mask;
};
#define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -503,8 +516,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
writel(i2c->slave_addr, _ISAR(i2c));
/* set control register values */
- writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
- writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
+ writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
+ writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(&i2c->adap.dev, "Enabling slave mode\n");
@@ -1137,6 +1150,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
+ { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
{}
};
MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
@@ -1158,6 +1172,13 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
i2c->use_pio = 1;
if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
i2c->fast_mode = 1;
+ if (of_device_is_compatible(np, "marvell,armada-3700-i2c")) {
+ i2c->fm_mask = ICR_BUSMODE_FM;
+ i2c->hs_mask = ICR_BUSMODE_HS;
+ } else {
+ i2c->fm_mask = ICR_FM;
+ i2c->hs_mask = ICR_HS;
+ }
*i2c_types = (enum pxa_i2c_types)(of_id->data);
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v4 0/3] Add basic support for the I2C units of the Armada 3700
From: Romain Perier @ 2016-11-09 11:57 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
This series add basic support for the I2C bus interface units present
in the Armada 3700 to the pxa-i2c driver. It also add the definitions of
the device nodes to the devicetree at the SoC level and for its official
development board: the Armada 3720 DB.
Romain Perier (3):
i2c: pxa: Add support for the I2C units found in Armada 3700
arm64: dts: marvell: Add I2C definitions for the Armada 3700
dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 25 +++++++++++++++++++++--
5 files changed, 47 insertions(+), 3 deletions(-)
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* 35911 linux-i2c
From: lcrumly @ 2016-11-09 10:45 UTC (permalink / raw)
To: linux-i2c
[-- Attachment #1: MESSAGE_551535988129_linux-i2c.zip --]
[-- Type: application/zip, Size: 3915 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Gregory CLEMENT @ 2016-11-09 10:21 UTC (permalink / raw)
To: Romain Perier
Cc: Mark Rutland, devicetree, Yahuda Yitschak, Omri Itach,
Jason Cooper, Pawel Moll, Ian Campbell, Igal Liberman, Hanna Hawa,
Wolfram Sang, Neta Zur Hershkovits, Nadav Haklai, Rob Herring,
Andrew Lunn, linux-i2c, Kumar Gala, Shadi Ammouri, Marcin Wojtas,
Thomas Petazzoni, linux-arm-kernel, Sebastian Hesselbarth
In-Reply-To: <20161109101349.18722-2-romain.perier@free-electrons.com>
Hi Romain,
You was too fast I didn't have time to commnent about Baruch suggestion.
On mer., nov. 09 2016, Romain Perier <romain.perier@free-electrons.com> wrote:
> The Armada 3700 has two I2C controllers that is compliant with the I2C
> Bus Specificiation 2.1, supports multi-master and different bus speed:
> Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
> High speed mode (up to 3.4 Mhz).
>
> This IP block has a lot of similarity with the PXA, except some register
> offsets and bitfield. This commits adds a basic support for this I2C
> unit.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
>
> Changes in v3:
> - Replaced the type of hm_mask and fm_mask by unsigned int,
> instead of unsigned long.
[...]
> #define ISR_RWM (1 << 0) /* read/write mode */
> @@ -193,6 +204,8 @@ struct pxa_i2c {
> unsigned char master_code;
> unsigned long rate;
> bool highmode_enter;
> + unsigned int fm_mask;
> + unsigned int hs_mask;
These masks are used with writel and readl which use an u32. So the
better is to use this type.
Gregory
> };
>
> #define _IBMR(i2c) ((i2c)->reg_ibmr)
> @@ -503,8 +516,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
> writel(i2c->slave_addr, _ISAR(i2c));
>
> /* set control register values */
> - writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
> - writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
> + writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
> + writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v3 0/3] Add basic support for the I2C units of the Armada 3700
From: Romain Perier @ 2016-11-09 10:13 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, linux-arm-kernel, Thomas Petazzoni, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas <mw>
This series add basic support for the I2C bus interface units present
in the Armada 3700 to the pxa-i2c driver. It also add the definitions of
the device nodes to the devicetree at the SoC level and for its official
development board: the Armada 3720 DB.
Romain Perier (3):
i2c: pxa: Add support for the I2C units found in Armada 3700
arm64: dts: marvell: Add I2C definitions for the Armada 3700
dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 25 +++++++++++++++++++++--
5 files changed, 47 insertions(+), 3 deletions(-)
--
2.9.3
^ permalink raw reply
* [PATCH v3 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-11-09 10:13 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, linux-arm-kernel, Thomas Petazzoni, Nadav Haklai,
Omri Itach, Shadi Ammouri, Yahuda Yitschak, Hanna Hawa,
Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas <mw>
In-Reply-To: <20161109101349.18722-1-romain.perier@free-electrons.com>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Changes in v2:
- Fixed wrong compatible string, it should be "marvell,armada-3700-i2c"
and not "marvell,armada-3700".
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..d30f0b1 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700-i2c".
Recommended properties :
--
2.9.3
^ permalink raw reply related
* [PATCH v3 2/3] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Romain Perier @ 2016-11-09 10:13 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161109101349.18722-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The Armada 3700 has two i2c bus interface units, this commit adds the
definitions of the corresponding device nodes. It also enables the node
on the development board for this SoC.
Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6..16d84af 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -62,6 +62,10 @@
};
};
+&i2c0 {
+ status = "okay";
+};
+
/* CON3 */
&sata {
status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index c476253..bf2d73d 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -98,6 +98,24 @@
/* 32M internal register @ 0xd000_0000 */
ranges = <0x0 0x0 0xd0000000 0x2000000>;
+ i2c0: i2c@11000 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11000 0x24>;
+ clocks = <&nb_perih_clk 10>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
+ i2c1: i2c@11080 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11080 0x24>;
+ clocks = <&nb_perih_clk 9>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
uart0: serial@12000 {
compatible = "marvell,armada-3700-uart";
reg = <0x12000 0x400>;
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v3 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-11-09 10:13 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits, Igal Liberman,
Marcin Wojtas <mw>
In-Reply-To: <20161109101349.18722-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The Armada 3700 has two I2C controllers that is compliant with the I2C
Bus Specificiation 2.1, supports multi-master and different bus speed:
Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
High speed mode (up to 3.4 Mhz).
This IP block has a lot of similarity with the PXA, except some register
offsets and bitfield. This commits adds a basic support for this I2C
unit.
Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Tested-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
Changes in v3:
- Replaced the type of hm_mask and fm_mask by unsigned int,
instead of unsigned long.
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 25 +++++++++++++++++++++++--
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d252276..2f56a26 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -763,7 +763,7 @@ config I2C_PUV3
config I2C_PXA
tristate "Intel PXA2XX I2C adapter"
- depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
+ depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
help
If you have devices in the PXA I2C bus, say yes to this option.
This driver can also be built as a module. If so, the module
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index e28b825..09619db 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -55,6 +55,7 @@ enum pxa_i2c_types {
REGS_PXA3XX,
REGS_CE4100,
REGS_PXA910,
+ REGS_A3700,
};
/*
@@ -91,6 +92,13 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
.ilcr = 0x28,
.iwcr = 0x30,
},
+ [REGS_A3700] = {
+ .ibmr = 0x00,
+ .idbr = 0x04,
+ .icr = 0x08,
+ .isr = 0x0c,
+ .isar = 0x10,
+ },
};
static const struct platform_device_id i2c_pxa_id_table[] = {
@@ -98,6 +106,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa3xx-pwri2c", REGS_PXA3XX },
{ "ce4100-i2c", REGS_CE4100 },
{ "pxa910-i2c", REGS_PXA910 },
+ { "armada-3700-i2c", REGS_A3700 },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -122,7 +131,9 @@ MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
#define ICR_SADIE (1 << 13) /* slave address detected int enable */
#define ICR_UR (1 << 14) /* unit reset */
#define ICR_FM (1 << 15) /* fast mode */
+#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
#define ICR_HS (1 << 16) /* High Speed mode */
+#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
#define ICR_GPIOEN (1 << 19) /* enable GPIO mode for SCL in HS */
#define ISR_RWM (1 << 0) /* read/write mode */
@@ -193,6 +204,8 @@ struct pxa_i2c {
unsigned char master_code;
unsigned long rate;
bool highmode_enter;
+ unsigned int fm_mask;
+ unsigned int hs_mask;
};
#define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -503,8 +516,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
writel(i2c->slave_addr, _ISAR(i2c));
/* set control register values */
- writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
- writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
+ writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
+ writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(&i2c->adap.dev, "Enabling slave mode\n");
@@ -1137,6 +1150,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
+ { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
{}
};
MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
@@ -1158,6 +1172,13 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
i2c->use_pio = 1;
if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
i2c->fast_mode = 1;
+ if (of_device_is_compatible(np, "marvell,armada-3700-i2c")) {
+ i2c->fm_mask = ICR_BUSMODE_FM;
+ i2c->hs_mask = ICR_BUSMODE_HS;
+ } else {
+ i2c->fm_mask = ICR_FM;
+ i2c->hs_mask = ICR_HS;
+ }
*i2c_types = (enum pxa_i2c_types)(of_id->data);
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-11-09 9:55 UTC (permalink / raw)
To: Baruch Siach
Cc: Mark Rutland, Andrew Lunn, Wolfram Sang, Hanna Hawa, Nadav Haklai,
Neta Zur Hershkovits, linux-i2c, Yahuda Yitschak,
linux-arm-kernel, Sebastian Hesselbarth, devicetree, Jason Cooper,
Pawel Moll, Ian Campbell, Omri Itach, Rob Herring,
Gregory Clement, Marcin Wojtas, Igal Liberman, Thomas Petazzoni,
Shadi Ammouri, Kumar Gala
In-Reply-To: <20161109085946.cmd4ltaxpiojq7il@tarshish>
Hi Baruch
Le 09/11/2016 à 09:59, Baruch Siach a écrit :
>> @@ -193,6 +204,8 @@ struct pxa_i2c {
>> unsigned char master_code;
>> unsigned long rate;
>> bool highmode_enter;
>> + unsigned long fm_mask;
>> + unsigned long hs_mask;
>
> Do you really need 64bit for that?
>
> baruch
Mhhh, good point. No I think that I can use an unsigned int.
I will fix it.
Thanks,
Romain
--
Romain Perier, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox