On Wed, 19 Dec 2012 12:18:00 -0700, Jason Gunthorpe
wrote:
> On Wed, Dec 19, 2012 at 12:54:51PM +, Grant Likely wrote:
> > In both cases, the type of transfer is encoded by the BAR address and
> > does not get exposed to the child device. Exposing the PCI flags into
> > the child bus(es) real
On Wed, Dec 19, 2012 at 12:54:51PM +, Grant Likely wrote:
> Then it sounds like you really don't want PCI addressing in the
> children. It sounds like the children addresses need to be in the form
> [bar#] [offset-from-base-of-bar]. In that case, you need the
> appropriate
They should be int
On Fri, 14 Dec 2012 14:58:14 -0700, Jason Gunthorpe
wrote:
> On Fri, Dec 14, 2012 at 08:26:29PM +, Grant Likely wrote:
>
> > > > If the soc_devices are getting triggered on that and they shouldn't be,
> > > > then we need a mechanism in the soc_bridge node to kick out of that
> > > > behavoi
On Fri, Dec 14, 2012 at 08:26:29PM +, Grant Likely wrote:
> > > If the soc_devices are getting triggered on that and they shouldn't be,
> > > then we need a mechanism in the soc_bridge node to kick out of that
> > > behavoir for its children.
> >
> > Is this what you were thinking?
>
> Not r
On Mon, 10 Dec 2012 14:51:19 -0700, Jason Gunthorpe
wrote:
> The intended use for this feature is to let a PCI device declare
> itself a 'simple-bus' and then describe additional devices
> (such as GPIOs, I2C, etc) nested below itself.
>
> The devices nested below the PCI device will use 'reg' a
The intended use for this feature is to let a PCI device declare
itself a 'simple-bus' and then describe additional devices
(such as GPIOs, I2C, etc) nested below itself.
The devices nested below the PCI device will use 'reg' addressing
with the 5 dw format used by PCI.
This is for embedded cases
6 matches
Mail list logo
