[<prev] [next>] [day] [month] [year] [list]
Message-ID: <0CE8B6BE3C4AD74AB97D9D29BD24E552A54EA1@CORPEXCH1.na.ads.idt.com>
Date: Thu, 25 Feb 2010 06:53:04 -0800
From: "Bounine, Alexandre" <Alexandre.Bounine@....com>
To: "Micha Nelissen" <micha@...i.hopto.org>
Cc: <mporter@...nel.crashing.org>, <linuxppc-dev@...ts.ozlabs.org>,
<linux-kernel@...r.kernel.org>, <thomas.moll@...go.com>,
<thomas.moll.ext@....com>, "Alexandre Bounine" <alexb@...dra.com>
Subject: RE: [PATCH 2/7] RapidIO: Add switch locking during discovery
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists