Re: [PATCH 2/2] i2c: octeon: Fix waiting for operation completion

[Paul Burton <paul.burton@imgtec.com>]

[-- 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 --]