Micha Nelissen wrote:
>
> Alexandre Bounine wrote:
> > + /* Attempt to acquire device lock */
> > + rio_mport_write_config_32(port, destid,
> > + hopcount,
> > +
RIO_HOST_DID_LOCK_CSR,
> > +
port->host_deviceid);
> > + rio_mport_read_config_32(port, destid,
hopcount,
> > + RIO_HOST_DID_LOCK_CSR, &result);
> > + while (result != port->host_deviceid) {
>
> It's better to abstract the locking of a device into a new function,
> rio_lock_device / rio_unlock_device.
>
> Then you can use those in rio_get_route_entry and rio_add_route_entry.
Agree. Plus, adding a "lock" parameter to
rio_get_route_entry/rio_add_route_entry to avoid excessive locking
requests when scanning entire table. I will do it in next version or as
additional patch: I have to address locking anyway for future changes.
>
> > @@ -1027,6 +1090,13 @@ int __devinit rio_disc_mport(struct rio_
> > +
> > + /* Read DestID assigned by enumerator */
> > + rio_local_read_config_32(mport, RIO_DID_CSR,
> > + &mport->host_deviceid);
> > + mport->host_deviceid = RIO_GET_DID(mport->sys_size,
> > +
mport->host_deviceid);
> > +
>
> This fixes something else, should be a separate patch.
This sets an ID used for locking during discovery. On a startup only
enumerator's ID is set to the specified value. All discovering agents
have this ID set to -1. After enumeration is completed it is safe to
initialize host_deviceid for agents as well.
Alex.
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
