On Tue, 03 Jun 2014 11:21:10 +0200, Arnd Bergmann wrote:
> On Tuesday 03 June 2014 09:44:59 Grant Likely wrote:
> > > The reason I think allow an ECAM makes sense in ranges is because it
> > > allows for a direct IO read/write to CFG space (w/o any mapping) similar
> > > to what one would do for
On Tuesday 03 June 2014 09:44:59 Grant Likely wrote:
> > The reason I think allow an ECAM makes sense in ranges is because it allows
> > for a direct IO read/write to CFG space (w/o any mapping) similar to what
> > one would do for MEM space or IO.
>
> I don't think that's right. PCI addresses a
On Mon, 2 Jun 2014 13:09:08 -0500, Kumar Gala wrote:
>
> On Jun 2, 2014, at 11:23 AM, Grant Likely wrote:
>
> > On Mon, 2 Jun 2014 10:40:30 -0500, Kumar Gala wrote:
> >>
> >> On Jun 2, 2014, at 10:09 AM, Grant Likely wrote:
> >>
> >>> On Sat, 31 May 2014 20:41:04 +0200, Arnd Bergmann wrote
On Monday 02 June 2014 15:43:02 Kumar Gala wrote:
> Its imx6 and exynos, havent looked to see if dw-pcie is handling
> the parsing or not for them.
Ok, so they are both dw-pcie variants.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
On Jun 2, 2014, at 2:15 PM, Arnd Bergmann wrote:
> On Monday 02 June 2014 13:09:08 Kumar Gala wrote:
>>> However, what do we do with the 2 cases that exist in upstream that
are using ranges for cfg space?
>>>
>>> Ignore them in the core code? Make the specific host controller handle
>>> th
On Monday 02 June 2014 13:09:08 Kumar Gala wrote:
> > However, what do we do with the 2 cases that exist in upstream that
> >> are using ranges for cfg space?
> >
> > Ignore them in the core code? Make the specific host controller handle
> > them I would think.
>
> I just meant, should we ‘break’
On Jun 2, 2014, at 11:23 AM, Grant Likely wrote:
> On Mon, 2 Jun 2014 10:40:30 -0500, Kumar Gala wrote:
>>
>> On Jun 2, 2014, at 10:09 AM, Grant Likely wrote:
>>
>>> On Sat, 31 May 2014 20:41:04 +0200, Arnd Bergmann wrote:
On Saturday 31 May 2014 01:36:40 Liviu Dudau wrote:
> We wo
On Mon, 2 Jun 2014 10:40:30 -0500, Kumar Gala wrote:
>
> On Jun 2, 2014, at 10:09 AM, Grant Likely wrote:
>
> > On Sat, 31 May 2014 20:41:04 +0200, Arnd Bergmann wrote:
> >> On Saturday 31 May 2014 01:36:40 Liviu Dudau wrote:
> >>> We would like to be able to describe PCIe ECAM resources as
>
On Jun 2, 2014, at 10:09 AM, Grant Likely wrote:
> On Sat, 31 May 2014 20:41:04 +0200, Arnd Bergmann wrote:
>> On Saturday 31 May 2014 01:36:40 Liviu Dudau wrote:
>>> We would like to be able to describe PCIe ECAM resources as
>>> IORESOURCE_MEM blocks while distinguish them from standard
>>> m
On Sat, 31 May 2014 20:41:04 +0200, Arnd Bergmann wrote:
> On Saturday 31 May 2014 01:36:40 Liviu Dudau wrote:
> > We would like to be able to describe PCIe ECAM resources as
> > IORESOURCE_MEM blocks while distinguish them from standard
> > memory resources. Add an IORESOURCE_BIT entry for this c
On Sat, May 31, 2014 at 08:41:04PM +0200, Arnd Bergmann wrote:
> On Saturday 31 May 2014 01:36:40 Liviu Dudau wrote:
> > We would like to be able to describe PCIe ECAM resources as
> > IORESOURCE_MEM blocks while distinguish them from standard
> > memory resources. Add an IORESOURCE_BIT entry for t
On Saturday 31 May 2014 01:36:40 Liviu Dudau wrote:
> We would like to be able to describe PCIe ECAM resources as
> IORESOURCE_MEM blocks while distinguish them from standard
> memory resources. Add an IORESOURCE_BIT entry for this case.
>
> Signed-off-by: Liviu Dudau
I still don't see any value
We would like to be able to describe PCIe ECAM resources as
IORESOURCE_MEM blocks while distinguish them from standard
memory resources. Add an IORESOURCE_BIT entry for this case.
Signed-off-by: Liviu Dudau
---
include/linux/ioport.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/li
13 matches
Mail list logo
