From: Jan Glauber <jan.glauber@caviumnetworks.com>
To: Paul Burton <paul.burton@imgtec.com>
Cc: linux-i2c@vger.kernel.org, linux-mips@linux-mips.org,
David Daney <david.daney@cavium.com>,
Peter Swain <pswain@cavium.com>, Wolfram Sang <wsa@the-dreams.de>,
"Steven J. Hill" <Steven.Hill@cavium.com>
Subject: Re: [PATCH 2/2] i2c: octeon: Fix waiting for operation completion
Date: Wed, 9 Nov 2016 15:38:04 +0100 [thread overview]
Message-ID: <20161109143804.GE2960@hardcore> (raw)
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
WARNING: multiple messages have this Message-ID (diff)
From: Jan Glauber <jan.glauber@caviumnetworks.com>
To: Paul Burton <paul.burton@imgtec.com>
Cc: <linux-i2c@vger.kernel.org>, <linux-mips@linux-mips.org>,
David Daney <david.daney@cavium.com>,
Peter Swain <pswain@cavium.com>, Wolfram Sang <wsa@the-dreams.de>,
"Steven J. Hill" <Steven.Hill@cavium.com>
Subject: Re: [PATCH 2/2] i2c: octeon: Fix waiting for operation completion
Date: Wed, 9 Nov 2016 15:38:04 +0100 [thread overview]
Message-ID: <20161109143804.GE2960@hardcore> (raw)
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
next prev parent reply other threads:[~2016-11-09 14:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-07 20:09 [PATCH 1/2] i2c: octeon: Fix register access Paul Burton
2016-11-07 20:09 ` Paul Burton
2016-11-07 20:09 ` [PATCH 2/2] i2c: octeon: Fix waiting for operation completion Paul Burton
2016-11-07 20:09 ` Paul Burton
2016-11-08 9:20 ` Jan Glauber
2016-11-08 9:20 ` Jan Glauber
2016-11-09 13:41 ` Jan Glauber
2016-11-09 13:41 ` Jan Glauber
2016-11-09 14:07 ` Paul Burton
2016-11-09 14:07 ` Paul Burton
2016-11-09 14:38 ` Jan Glauber [this message]
2016-11-09 14:38 ` Jan Glauber
2016-11-11 8:57 ` Jan Glauber
2016-11-11 8:57 ` Jan Glauber
2016-11-11 8:57 ` Jan Glauber
2016-11-11 20:51 ` Steven J. Hill
2016-11-11 20:51 ` Steven J. Hill
2016-11-11 22:11 ` David Daney
2016-11-11 22:11 ` David Daney
2016-11-08 7:13 ` [PATCH 1/2] i2c: octeon: Fix register access Jan Glauber
2016-11-08 7:13 ` Jan Glauber
2016-11-09 14:09 ` Paul Burton
2016-11-09 14:09 ` Paul Burton
2016-11-09 14:43 ` Jan Glauber
2016-11-09 14:43 ` Jan Glauber
2016-11-10 20:17 ` Wolfram Sang
2016-11-11 7:00 ` Jan Glauber
2016-11-11 7:00 ` Jan Glauber
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161109143804.GE2960@hardcore \
--to=jan.glauber@caviumnetworks.com \
--cc=Steven.Hill@cavium.com \
--cc=david.daney@cavium.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=paul.burton@imgtec.com \
--cc=pswain@cavium.com \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.