> On Sep 12, 2021, at 2:49 PM, Tobias Nygren <t...@netbsd.org> wrote:
>
> On Sun, 12 Sep 2021 12:30:14 -0700
> Jason Thorpe <thor...@me.com> wrote:
>
>> Ok, sparc64 should be good do go now. I made a bunch of fake fixup entries
>> for the Qemu machine and, after a couple of additional fixes, verified that
>> the machinery is working as expected.
>
> Gets further but hits another problem.
> bus mutex uninitialized or points at wrong data?
>
> iic0 at pcfiic0: I2C bus
> cpu0: data fault: pc=105f440 rpc=143e594 addr=1afc000
> kernel trap 6c: +fast data access protection
> Stopped in pid 0.0 (system) at netbsd:_lock_cas: casxa 0x80,
> %o1, %o2
> db{0}> bt
> iic_acquire_bus(1afd088, 8, 2003dac, 1af0400, 1afd098, 10) at
> netbsd:iic_acquire_bus+0x94
> spdmem_i2c_match(1075dfa80, 1c66f00, 2004710, 1aecc00, 73, 1c60b98) at
> netbsd:spdmem_i2c_match+0xa4
> config_match(1075dfa80, 1c66f00, 2004710, 2004710, 20, 0) at
> netbsd:config_match+0x38
> [rest of trace omitted]
Ok, I'm a little confused by this one. pcfiic_attach() allocates a single
channel structure if the ebus front-end did not already do so. And then for
either case, it then enumerates the channels and calls
iic_tag_init(&ch->ch_i2c) for the tag on each one, which initializes the bus
mutex.
Hm, but I spotted another bug ... I didn't update pcfiic_i2c_exec() for the
channel split. That could be clobbering something. I just pushed an update to
dev/ic/pcf8584.c -- can you give it a spin?
-- thorpej