[PATCH v2 03/20] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

On Thu, Apr 4, 2013 at 10:36 AM, Tejun Heo  wrote:
> Hello,
>
> On Sat, Mar 09, 2013 at 10:44:30PM -0800, Yinghai Lu wrote:
>> Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not
>> be used anymore.
>>
>> User should use arch_pfn_mapped or just 1UL<<(32-PAGE_SHIFT) instead.
>>
>> Only user is ACPI_INITRD_TABLE_OVERRIDE, and it should not use that,
>> as later accessing is using early_ioremap(). Change to try to 4G below
>> and then 4G above.
> ...
>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
>> index 586e7e9..c08cdb6 100644
>> --- a/drivers/acpi/osl.c
>> +++ b/drivers/acpi/osl.c
>> @@ -624,9 +624,13 @@ void __init acpi_initrd_override(void *data, size_t 
>> size)
>>   if (table_nr == 0)
>>   return;
>>
>> - acpi_tables_addr =
>> - memblock_find_in_range(0, max_low_pfn_mapped << PAGE_SHIFT,
>> -all_tables_size, PAGE_SIZE);
>> + /* under 4G at first, then above 4G */
>> + acpi_tables_addr = memblock_find_in_range(0, (1ULL<<32) - 1,
>> + all_tables_size, PAGE_SIZE);
>> + if (!acpi_tables_addr)
>> + acpi_tables_addr = memblock_find_in_range(0,
>> + ~(phys_addr_t)0,
>> + all_tables_size, PAGE_SIZE);
>
> So, it's changing the allocation from <=4G to <=4G first and then >4G.
> The only explanation given is "as later accessing is using
> early_ioremap()", but I can't see why that can be a reason for that.
> early_ioremap() doesn't care whether the given physaddr is under 4G or
> not, it unconditionally maps it into fixmap, so whether the allocated
> address is below or above 4G doesn't make any difference.
>
> Changing the allowed range of the allocation should be a separate
> patch.  It has some chance of its own breakage and the change itself
> isn't really related to this one.

Ok, will separate that  "try above 4G" to another patch.

>
> Please try to elaborate the reasoning behind "why", so that readers of
> the description don't have to deduce (oh well, guess) your intentions
> behind the changes.  As much as it would help the readers, it'd also
> help you even more as you would have had to explicitly write something
> like "the table is accessed with early_ioremap() so the address
> doesn't need to be restricted under 4G; however, to avoid unnecessary
> remappings, first try <= 4G and then > 4G."  Then, you would be
> compelled to check whether the statement you explicitly wrote is true,
> which isn't in this case and you would also realize that the change
> isn't trivial and doesn't really belong with this patch.  By not doing
> the due diligence, you're offloading what you should have done to
> others, which isn't very nice.
>
> I think the descriptions are better in this posting than the last time
> but it's still lacking, so, please putfff more effort into describing
> the changes and reasoning behind them.

ok.

Thanks a lot.

Yinghai

Re: [PATCH v2 03/20] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

On Thu, Apr 4, 2013 at 10:36 AM, Tejun Heo t...@kernel.org wrote:
 Hello,

 On Sat, Mar 09, 2013 at 10:44:30PM -0800, Yinghai Lu wrote:
 Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not
 be used anymore.

 User should use arch_pfn_mapped or just 1UL(32-PAGE_SHIFT) instead.

 Only user is ACPI_INITRD_TABLE_OVERRIDE, and it should not use that,
 as later accessing is using early_ioremap(). Change to try to 4G below
 and then 4G above.
 ...
 diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
 index 586e7e9..c08cdb6 100644
 --- a/drivers/acpi/osl.c
 +++ b/drivers/acpi/osl.c
 @@ -624,9 +624,13 @@ void __init acpi_initrd_override(void *data, size_t 
 size)
   if (table_nr == 0)
   return;

 - acpi_tables_addr =
 - memblock_find_in_range(0, max_low_pfn_mapped  PAGE_SHIFT,
 -all_tables_size, PAGE_SIZE);
 + /* under 4G at first, then above 4G */
 + acpi_tables_addr = memblock_find_in_range(0, (1ULL32) - 1,
 + all_tables_size, PAGE_SIZE);
 + if (!acpi_tables_addr)
 + acpi_tables_addr = memblock_find_in_range(0,
 + ~(phys_addr_t)0,
 + all_tables_size, PAGE_SIZE);

 So, it's changing the allocation from =4G to =4G first and then 4G.
 The only explanation given is as later accessing is using
 early_ioremap(), but I can't see why that can be a reason for that.
 early_ioremap() doesn't care whether the given physaddr is under 4G or
 not, it unconditionally maps it into fixmap, so whether the allocated
 address is below or above 4G doesn't make any difference.

 Changing the allowed range of the allocation should be a separate
 patch.  It has some chance of its own breakage and the change itself
 isn't really related to this one.

Ok, will separate that  try above 4G to another patch.


 Please try to elaborate the reasoning behind why, so that readers of
 the description don't have to deduce (oh well, guess) your intentions
 behind the changes.  As much as it would help the readers, it'd also
 help you even more as you would have had to explicitly write something
 like the table is accessed with early_ioremap() so the address
 doesn't need to be restricted under 4G; however, to avoid unnecessary
 remappings, first try = 4G and then  4G.  Then, you would be
 compelled to check whether the statement you explicitly wrote is true,
 which isn't in this case and you would also realize that the change
 isn't trivial and doesn't really belong with this patch.  By not doing
 the due diligence, you're offloading what you should have done to
 others, which isn't very nice.

 I think the descriptions are better in this posting than the last time
 but it's still lacking, so, please putfff more effort into describing
 the changes and reasoning behind them.

ok.

Thanks a lot.

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses

[Yinghai Lu]

On Tue, Mar 19, 2013 at 9:54 AM, Daniel Vetter  
wrote:

> I guess I should have phrased it more precisely, but that's exactly
> what I expect is happening on my machine: I don't have anything on
> irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
> the irq is completely disabled. Which obviously makes it impossible
> for me to reproduce the issue. To test that theory, is there a quick
> way to force-enable a given interrupt, short of just hacking up a 2nd
> dummy irq handler in my driver?

You may try to add another request_irq()
after i915_load_modeset_init==>drm_irq_install.
That could install one dummy action for ioapic irq for i915.

Also you may need to add one quirk that does not disable intx during
msi enabling like:
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,
0x2e22,
quirk_msi_intx_disable_bug);

Thanks

Yinghai

Re: gm45 intel gfx can generate non-MSI irq# in MSI mode (was Re: [PATCH] drm/i915: stop using GMBUS IRQs on Gen4 chips (was Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt respo

[Yinghai Lu]

On Tue, Mar 19, 2013 at 9:54 AM, Daniel Vetter daniel.vet...@ffwll.ch wrote:

 I guess I should have phrased it more precisely, but that's exactly
 what I expect is happening on my machine: I don't have anything on
 irq16 (i.e. in non-msi mode the gfx interrupt isn't shared) and hence
 the irq is completely disabled. Which obviously makes it impossible
 for me to reproduce the issue. To test that theory, is there a quick
 way to force-enable a given interrupt, short of just hacking up a 2nd
 dummy irq handler in my driver?

You may try to add another request_irq()
after i915_load_modeset_init==drm_irq_install.
That could install one dummy action for ioapic irq for i915.

Also you may need to add one quirk that does not disable intx during
msi enabling like:
DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL,
0x2e22,
quirk_msi_intx_disable_bug);

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Yinghai Lu]

On Mon, Mar 18, 2013 at 3:05 PM, Jiri Kosina  wrote:
> On Mon, 18 Mar 2013, Yinghai Lu wrote:
>
>> > Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
>> > interrupts go away.
>> >
>> > My understanding from the other mail is that DAniel Vetter already has an
>> > idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully
>> > this datapoint regarding MSI will fit into it.
>>
>> What is /proc/interrupts difference between with and without pci=nomsi ?
>>
>> drm is forced to share irq 16?
>
> Yup, IRQ 16 is being shared, and one of the owners is i915.

the vga report strange INTx status...

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA
controller])
Subsystem: Lenovo Device 20e4
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
SERR-  [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0100c  Data: 4142
Capabilities: [d0] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915
Kernel modules: i915

it should be INTx-, after we have set DisINTx+ in control.

So INTx can not be disabled after it get enabled before ?

the VGA on my T420 looks right.

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
00 [VGA controller])
Subsystem: Lenovo Device 21ce
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort-
SERR- 

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Yinghai Lu]

On Mon, Mar 18, 2013 at 2:12 AM, Jiri Kosina  wrote:
> On Fri, 15 Mar 2013, Yinghai Lu wrote:
>
>> > Just a datapoint -- I have put a trivial debugging patch in place, and it
>> > reveals that "nobody cared" for irq 16 happens long after last
>> >
>> > I915_WRITE(GMBUS4 + reg_offset, 0);
>> >
>> > has been performed in gmbus_wait_hw_status(). On the other hand, if I
>> > comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(),
>> > then it of course falls back to GPIO bit-banging, but the "nobody cared"
>> > for irq 16 is gone.
>> >
>> > So it seems like something gets severely confused by the I915_WRITE to
>> > GMBUS4 + reg_offset. So far this seems to have been reported solely on
>> > Lenovos as far as I can see (although a completely different types), so it
>> > might be some platform-specific quirk?
>> >
>> > Honestly, I still don't understand how all the GMBUS stuff relates to IRQ
>> > 16 at all.
>>
>> that device is using
>> i915 :00:02.0: irq 44 for MSI/MSI-X
>>
>> so can you try to boot with pci=nomsi?
>
> Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
> interrupts go away.
>
> My understanding from the other mail is that DAniel Vetter already has an
> idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully
> this datapoint regarding MSI will fit into it.

What is /proc/interrupts difference between with and without pci=nomsi ?

drm is forced to share irq 16?

Thanks

Yinghai

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Yinghai Lu]

On Mon, Mar 18, 2013 at 2:12 AM, Jiri Kosina jkos...@suse.cz wrote:
 On Fri, 15 Mar 2013, Yinghai Lu wrote:

  Just a datapoint -- I have put a trivial debugging patch in place, and it
  reveals that nobody cared for irq 16 happens long after last
 
  I915_WRITE(GMBUS4 + reg_offset, 0);
 
  has been performed in gmbus_wait_hw_status(). On the other hand, if I
  comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(),
  then it of course falls back to GPIO bit-banging, but the nobody cared
  for irq 16 is gone.
 
  So it seems like something gets severely confused by the I915_WRITE to
  GMBUS4 + reg_offset. So far this seems to have been reported solely on
  Lenovos as far as I can see (although a completely different types), so it
  might be some platform-specific quirk?
 
  Honestly, I still don't understand how all the GMBUS stuff relates to IRQ
  16 at all.

 that device is using
 i915 :00:02.0: irq 44 for MSI/MSI-X

 so can you try to boot with pci=nomsi?

 Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
 interrupts go away.

 My understanding from the other mail is that DAniel Vetter already has an
 idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully
 this datapoint regarding MSI will fit into it.

What is /proc/interrupts difference between with and without pci=nomsi ?

drm is forced to share irq 16?

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Yinghai Lu]

On Mon, Mar 18, 2013 at 3:05 PM, Jiri Kosina jkos...@suse.cz wrote:
 On Mon, 18 Mar 2013, Yinghai Lu wrote:

  Yes, switching from MSI to IO-APIC-fasteoi makes the report about lost
  interrupts go away.
 
  My understanding from the other mail is that DAniel Vetter already has an
  idea what might be going wrong with IRQ acking on GM45 chipsets; hopefully
  this datapoint regarding MSI will fit into it.

 What is /proc/interrupts difference between with and without pci=nomsi ?

 drm is forced to share irq 16?

 Yup, IRQ 16 is being shared, and one of the owners is i915.

the vga report strange INTx status...

00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA
controller])
Subsystem: Lenovo Device 20e4
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR- INTx+
Latency: 0
Interrupt: pin A routed to IRQ 44
Region 0: Memory at f200 (64-bit, non-prefetchable) [size=4M]
Region 2: Memory at d000 (64-bit, prefetchable) [size=256M]
Region 4: I/O ports at 1800 [size=8]
Expansion ROM at unassigned [disabled]
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0100c  Data: 4142
Capabilities: [d0] Power Management version 3
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: i915
Kernel modules: i915

it should be INTx-, after we have set DisINTx+ in control.

So INTx can not be disabled after it get enabled before ?

the VGA on my T420 looks right.

00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09) (prog-if
00 [VGA controller])
Subsystem: Lenovo Device 21ce
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast TAbort-
TAbort- MAbort- SERR- PERR- INTx-

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Yinghai Lu]

On Fri, Mar 15, 2013 at 8:14 AM, Jiri Kosina  wrote:

> Just a datapoint -- I have put a trivial debugging patch in place, and it
> reveals that "nobody cared" for irq 16 happens long after last
>
> I915_WRITE(GMBUS4 + reg_offset, 0);
>
> has been performed in gmbus_wait_hw_status(). On the other hand, if I
> comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(),
> then it of course falls back to GPIO bit-banging, but the "nobody cared"
> for irq 16 is gone.
>
> So it seems like something gets severely confused by the I915_WRITE to
> GMBUS4 + reg_offset. So far this seems to have been reported solely on
> Lenovos as far as I can see (although a completely different types), so it
> might be some platform-specific quirk?
>
> Honestly, I still don't understand how all the GMBUS stuff relates to IRQ
> 16 at all.

that device is using
i915 :00:02.0: irq 44 for MSI/MSI-X

so can you try to boot with pci=nomsi?

Re: [3.9-rc1] irq 16: nobody cared (was [3.9-rc1] very poor interrupt responses)

[Yinghai Lu]

On Fri, Mar 15, 2013 at 8:14 AM, Jiri Kosina jkos...@suse.cz wrote:

 Just a datapoint -- I have put a trivial debugging patch in place, and it
 reveals that nobody cared for irq 16 happens long after last

 I915_WRITE(GMBUS4 + reg_offset, 0);

 has been performed in gmbus_wait_hw_status(). On the other hand, if I
 comment out both GMBUS4 register offset writes in gmbus_wait_hw_status(),
 then it of course falls back to GPIO bit-banging, but the nobody cared
 for irq 16 is gone.

 So it seems like something gets severely confused by the I915_WRITE to
 GMBUS4 + reg_offset. So far this seems to have been reported solely on
 Lenovos as far as I can see (although a completely different types), so it
 might be some platform-specific quirk?

 Honestly, I still don't understand how all the GMBUS stuff relates to IRQ
 16 at all.

that device is using
i915 :00:02.0: irq 44 for MSI/MSI-X

so can you try to boot with pci=nomsi?
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 03/20] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not
be used anymore.

User should use arch_pfn_mapped or just 1UL<<(32-PAGE_SHIFT) instead.

Only user is ACPI_INITRD_TABLE_OVERRIDE, and it should not use that,
as later accessing is using early_ioremap(). Change to try to 4G below
and then 4G above.

-v2: Leave alone max_low_pfn_mapped in i915 code according to tj.

Suggested-by: H. Peter Anvin 
Signed-off-by: Yinghai Lu 
Cc: "Rafael J. Wysocki" 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Jacob Shin 
Cc: linux-acpi at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
---
 arch/x86/include/asm/page_types.h |1 -
 arch/x86/kernel/setup.c   |4 +---
 arch/x86/mm/init.c|4 
 drivers/acpi/osl.c|   10 +++---
 4 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/page_types.h 
b/arch/x86/include/asm/page_types.h
index 54c9787..b012b82 100644
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -43,7 +43,6 @@

 extern int devmem_is_allowed(unsigned long pagenr);

-extern unsigned long max_low_pfn_mapped;
 extern unsigned long max_pfn_mapped;

 static inline phys_addr_t get_max_mapped(void)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 1629577..e75c6e6 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -113,13 +113,11 @@
 #include 

 /*
- * max_low_pfn_mapped: highest direct mapped pfn under 4GB
- * max_pfn_mapped: highest direct mapped pfn over 4GB
+ * max_pfn_mapped: highest direct mapped pfn
  *
  * The direct mapping only covers E820_RAM regions, so the ranges and gaps are
  * represented by pfn_mapped
  */
-unsigned long max_low_pfn_mapped;
 unsigned long max_pfn_mapped;

 #ifdef CONFIG_DMI
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 59b7fc4..abcc241 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -313,10 +313,6 @@ static void add_pfn_range_mapped(unsigned long start_pfn, 
unsigned long end_pfn)
nr_pfn_mapped = clean_sort_range(pfn_mapped, E820_X_MAX);

max_pfn_mapped = max(max_pfn_mapped, end_pfn);
-
-   if (start_pfn < (1UL<<(32-PAGE_SHIFT)))
-   max_low_pfn_mapped = max(max_low_pfn_mapped,
-min(end_pfn, 1UL<<(32-PAGE_SHIFT)));
 }

 bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long end_pfn)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 586e7e9..c08cdb6 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -624,9 +624,13 @@ void __init acpi_initrd_override(void *data, size_t size)
if (table_nr == 0)
return;

-   acpi_tables_addr =
-   memblock_find_in_range(0, max_low_pfn_mapped << PAGE_SHIFT,
-  all_tables_size, PAGE_SIZE);
+   /* under 4G at first, then above 4G */
+   acpi_tables_addr = memblock_find_in_range(0, (1ULL<<32) - 1,
+   all_tables_size, PAGE_SIZE);
+   if (!acpi_tables_addr)
+   acpi_tables_addr = memblock_find_in_range(0,
+   ~(phys_addr_t)0,
+   all_tables_size, PAGE_SIZE);
if (!acpi_tables_addr) {
WARN_ON(1);
return;
-- 
1.7.10.4

[PATCH v2 03/20] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not
be used anymore.

User should use arch_pfn_mapped or just 1UL(32-PAGE_SHIFT) instead.

Only user is ACPI_INITRD_TABLE_OVERRIDE, and it should not use that,
as later accessing is using early_ioremap(). Change to try to 4G below
and then 4G above.

-v2: Leave alone max_low_pfn_mapped in i915 code according to tj.

Suggested-by: H. Peter Anvin h...@zytor.com
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: David Airlie airl...@linux.ie
Cc: Jacob Shin jacob.s...@amd.com
Cc: linux-a...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
 arch/x86/include/asm/page_types.h |1 -
 arch/x86/kernel/setup.c   |4 +---
 arch/x86/mm/init.c|4 
 drivers/acpi/osl.c|   10 +++---
 4 files changed, 8 insertions(+), 11 deletions(-)

diff --git a/arch/x86/include/asm/page_types.h 
b/arch/x86/include/asm/page_types.h
index 54c9787..b012b82 100644
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -43,7 +43,6 @@
 
 extern int devmem_is_allowed(unsigned long pagenr);
 
-extern unsigned long max_low_pfn_mapped;
 extern unsigned long max_pfn_mapped;
 
 static inline phys_addr_t get_max_mapped(void)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 1629577..e75c6e6 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -113,13 +113,11 @@
 #include asm/prom.h
 
 /*
- * max_low_pfn_mapped: highest direct mapped pfn under 4GB
- * max_pfn_mapped: highest direct mapped pfn over 4GB
+ * max_pfn_mapped: highest direct mapped pfn
  *
  * The direct mapping only covers E820_RAM regions, so the ranges and gaps are
  * represented by pfn_mapped
  */
-unsigned long max_low_pfn_mapped;
 unsigned long max_pfn_mapped;
 
 #ifdef CONFIG_DMI
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 59b7fc4..abcc241 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -313,10 +313,6 @@ static void add_pfn_range_mapped(unsigned long start_pfn, 
unsigned long end_pfn)
nr_pfn_mapped = clean_sort_range(pfn_mapped, E820_X_MAX);
 
max_pfn_mapped = max(max_pfn_mapped, end_pfn);
-
-   if (start_pfn  (1UL(32-PAGE_SHIFT)))
-   max_low_pfn_mapped = max(max_low_pfn_mapped,
-min(end_pfn, 1UL(32-PAGE_SHIFT)));
 }
 
 bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long end_pfn)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 586e7e9..c08cdb6 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -624,9 +624,13 @@ void __init acpi_initrd_override(void *data, size_t size)
if (table_nr == 0)
return;
 
-   acpi_tables_addr =
-   memblock_find_in_range(0, max_low_pfn_mapped  PAGE_SHIFT,
-  all_tables_size, PAGE_SIZE);
+   /* under 4G at first, then above 4G */
+   acpi_tables_addr = memblock_find_in_range(0, (1ULL32) - 1,
+   all_tables_size, PAGE_SIZE);
+   if (!acpi_tables_addr)
+   acpi_tables_addr = memblock_find_in_range(0,
+   ~(phys_addr_t)0,
+   all_tables_size, PAGE_SIZE);
if (!acpi_tables_addr) {
WARN_ON(1);
return;
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

On Thu, Mar 7, 2013 at 9:25 PM, Tejun Heo  wrote:
> On Thu, Mar 7, 2013 at 9:22 PM, Yinghai Lu  wrote:
>> On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo  wrote:
>>> On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
>>>> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
>>>> b/drivers/gpu/drm/i915/i915_gem_stolen.c
>>>> index 69d97cb..7f9380b 100644
>>>> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>>>> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>>>> @@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
>>>> drm_device *dev)
>>>>   base -= dev_priv->mm.gtt->stolen_size;
>>>>   } else {
>>>>   /* Stolen is immediately above Top of Memory */
>>>> - base = max_low_pfn_mapped << PAGE_SHIFT;
>>>> + base = __REMOVED_CRAZY__ << PAGE_SHIFT;
>>>
>>> Huh?
>>
>> Whole function:
>
> Yeah, but can't we still just do 1LLU << 32 like other places? Or at
> least explain what was there before? It's gonna confuse the hell out
> of future readers of the code.

They are not using memblock_find_in_range(), so 1ULL<< will not help.

Really hope i915 drm guys could clean that hacks.

Thanks

Yinghai

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo  wrote:
> On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
>> diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
>> b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> index 69d97cb..7f9380b 100644
>> --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
>> +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
>> @@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
>> drm_device *dev)
>>   base -= dev_priv->mm.gtt->stolen_size;
>>   } else {
>>   /* Stolen is immediately above Top of Memory */
>> - base = max_low_pfn_mapped << PAGE_SHIFT;
>> + base = __REMOVED_CRAZY__ << PAGE_SHIFT;
>
> Huh?

Whole function:

static unsigned long i915_stolen_to_physical(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct pci_dev *pdev = dev_priv->bridge_dev;
u32 base;

/* On the machines I have tested the Graphics Base of Stolen Memory
 * is unreliable, so on those compute the base by subtracting the
 * stolen memory from the Top of Low Usable DRAM which is where the
 * BIOS places the graphics stolen memory.
 *
 * On gen2, the layout is slightly different with the Graphics Segment
 * immediately following Top of Memory (or Top of Usable DRAM). Note
 * it appears that TOUD is only reported by 865g, so we just use the
 * top of memory as determined by the e820 probe.
 *
 * XXX gen2 requires an unavailable symbol and 945gm fails with
 * its value of TOLUD.
 */
base = 0;
if (INTEL_INFO(dev)->gen >= 6) {
/* Read Base Data of Stolen Memory Register (BDSM) directly.
 * Note that there is also a MCHBAR miror at 0x1080c0 or
 * we could use device 2:0x5c instead.
*/
pci_read_config_dword(pdev, 0xB0, );
base &= ~4095; /* lower bits used for locking register */
} else if (INTEL_INFO(dev)->gen > 3 || IS_G33(dev)) {
/* Read Graphics Base of Stolen Memory directly */
pci_read_config_dword(pdev, 0xA4, );
#if 0
} else if (IS_GEN3(dev)) {
u8 val;
/* Stolen is immediately below Top of Low Usable DRAM */
pci_read_config_byte(pdev, 0x9c, );
base = val >> 3 << 27;
base -= dev_priv->mm.gtt->stolen_size;
} else {
/* Stolen is immediately above Top of Memory */
base = __REMOVED_CRAZY__ << PAGE_SHIFT;
#endif
}

return base;
}

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not
be used anymore.

Only user is ACPI_OVERRIDE, and it should not use that, as later
accessing is using early_remap. Change to try to 4G below and
then 4G above.

Other user is in drm/i915, but it is commented out.

Should use arch_pfn_mapped or just 1<<(32-PAGE_SHIFT) instead.

Suggested-by: H. Peter Anvin 
Signed-off-by: Yinghai Lu 
Cc: Thomas Renninger 
Cc: "Rafael J. Wysocki" 
Cc: Daniel Vetter 
Cc: David Airlie 
Cc: Jacob Shin 
Cc: linux-acpi at vger.kernel.org
Cc: dri-devel at lists.freedesktop.org
---
 arch/x86/include/asm/page_types.h  |1 -
 arch/x86/kernel/setup.c|4 +---
 arch/x86/mm/init.c |4 
 drivers/acpi/osl.c |9 ++---
 drivers/gpu/drm/i915/i915_gem_stolen.c |2 +-
 5 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/page_types.h 
b/arch/x86/include/asm/page_types.h
index 54c9787..b012b82 100644
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -43,7 +43,6 @@

 extern int devmem_is_allowed(unsigned long pagenr);

-extern unsigned long max_low_pfn_mapped;
 extern unsigned long max_pfn_mapped;

 static inline phys_addr_t get_max_mapped(void)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 90d8cc9..4dcaae7 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -113,13 +113,11 @@
 #include 

 /*
- * max_low_pfn_mapped: highest direct mapped pfn under 4GB
- * max_pfn_mapped: highest direct mapped pfn over 4GB
+ * max_pfn_mapped: highest direct mapped pfn
  *
  * The direct mapping only covers E820_RAM regions, so the ranges and gaps are
  * represented by pfn_mapped
  */
-unsigned long max_low_pfn_mapped;
 unsigned long max_pfn_mapped;

 #ifdef CONFIG_DMI
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 59b7fc4..abcc241 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -313,10 +313,6 @@ static void add_pfn_range_mapped(unsigned long start_pfn, 
unsigned long end_pfn)
nr_pfn_mapped = clean_sort_range(pfn_mapped, E820_X_MAX);

max_pfn_mapped = max(max_pfn_mapped, end_pfn);
-
-   if (start_pfn < (1UL<<(32-PAGE_SHIFT)))
-   max_low_pfn_mapped = max(max_low_pfn_mapped,
-min(end_pfn, 1UL<<(32-PAGE_SHIFT)));
 }

 bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long end_pfn)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 586e7e9..c9e36d7 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -624,9 +624,12 @@ void __init acpi_initrd_override(void *data, size_t size)
if (table_nr == 0)
return;

-   acpi_tables_addr =
-   memblock_find_in_range(0, max_low_pfn_mapped << PAGE_SHIFT,
-  all_tables_size, PAGE_SIZE);
+   /* under 4G at first, then above 4G */
+   acpi_tables_addr = memblock_find_in_range(0, 1ULL<<32,
+   all_tables_size, PAGE_SIZE);
+   if (!acpi_tables_addr)
+   acpi_tables_addr = memblock_find_in_range(1ULL<<32, -1ULL,
+   all_tables_size, PAGE_SIZE);
if (!acpi_tables_addr) {
WARN_ON(1);
return;
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 69d97cb..7f9380b 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
drm_device *dev)
base -= dev_priv->mm.gtt->stolen_size;
} else {
/* Stolen is immediately above Top of Memory */
-   base = max_low_pfn_mapped << PAGE_SHIFT;
+   base = __REMOVED_CRAZY__ << PAGE_SHIFT;
 #endif
}

-- 
1.7.10.4

[PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

Now we have arch_pfn_mapped array, and max_low_pfn_mapped should not
be used anymore.

Only user is ACPI_OVERRIDE, and it should not use that, as later
accessing is using early_remap. Change to try to 4G below and
then 4G above.

Other user is in drm/i915, but it is commented out.

Should use arch_pfn_mapped or just 1(32-PAGE_SHIFT) instead.

Suggested-by: H. Peter Anvin h...@linux.intel.com
Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Thomas Renninger tr...@suse.de
Cc: Rafael J. Wysocki r...@sisk.pl
Cc: Daniel Vetter daniel.vet...@ffwll.ch
Cc: David Airlie airl...@linux.ie
Cc: Jacob Shin jacob.s...@amd.com
Cc: linux-a...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
---
 arch/x86/include/asm/page_types.h  |1 -
 arch/x86/kernel/setup.c|4 +---
 arch/x86/mm/init.c |4 
 drivers/acpi/osl.c |9 ++---
 drivers/gpu/drm/i915/i915_gem_stolen.c |2 +-
 5 files changed, 8 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/page_types.h 
b/arch/x86/include/asm/page_types.h
index 54c9787..b012b82 100644
--- a/arch/x86/include/asm/page_types.h
+++ b/arch/x86/include/asm/page_types.h
@@ -43,7 +43,6 @@
 
 extern int devmem_is_allowed(unsigned long pagenr);
 
-extern unsigned long max_low_pfn_mapped;
 extern unsigned long max_pfn_mapped;
 
 static inline phys_addr_t get_max_mapped(void)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 90d8cc9..4dcaae7 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -113,13 +113,11 @@
 #include asm/prom.h
 
 /*
- * max_low_pfn_mapped: highest direct mapped pfn under 4GB
- * max_pfn_mapped: highest direct mapped pfn over 4GB
+ * max_pfn_mapped: highest direct mapped pfn
  *
  * The direct mapping only covers E820_RAM regions, so the ranges and gaps are
  * represented by pfn_mapped
  */
-unsigned long max_low_pfn_mapped;
 unsigned long max_pfn_mapped;
 
 #ifdef CONFIG_DMI
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 59b7fc4..abcc241 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -313,10 +313,6 @@ static void add_pfn_range_mapped(unsigned long start_pfn, 
unsigned long end_pfn)
nr_pfn_mapped = clean_sort_range(pfn_mapped, E820_X_MAX);
 
max_pfn_mapped = max(max_pfn_mapped, end_pfn);
-
-   if (start_pfn  (1UL(32-PAGE_SHIFT)))
-   max_low_pfn_mapped = max(max_low_pfn_mapped,
-min(end_pfn, 1UL(32-PAGE_SHIFT)));
 }
 
 bool pfn_range_is_mapped(unsigned long start_pfn, unsigned long end_pfn)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 586e7e9..c9e36d7 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -624,9 +624,12 @@ void __init acpi_initrd_override(void *data, size_t size)
if (table_nr == 0)
return;
 
-   acpi_tables_addr =
-   memblock_find_in_range(0, max_low_pfn_mapped  PAGE_SHIFT,
-  all_tables_size, PAGE_SIZE);
+   /* under 4G at first, then above 4G */
+   acpi_tables_addr = memblock_find_in_range(0, 1ULL32,
+   all_tables_size, PAGE_SIZE);
+   if (!acpi_tables_addr)
+   acpi_tables_addr = memblock_find_in_range(1ULL32, -1ULL,
+   all_tables_size, PAGE_SIZE);
if (!acpi_tables_addr) {
WARN_ON(1);
return;
diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
b/drivers/gpu/drm/i915/i915_gem_stolen.c
index 69d97cb..7f9380b 100644
--- a/drivers/gpu/drm/i915/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
@@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
drm_device *dev)
base -= dev_priv-mm.gtt-stolen_size;
} else {
/* Stolen is immediately above Top of Memory */
-   base = max_low_pfn_mapped  PAGE_SHIFT;
+   base = __REMOVED_CRAZY__  PAGE_SHIFT;
 #endif
}
 
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo t...@kernel.org wrote:
 On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
 diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
 b/drivers/gpu/drm/i915/i915_gem_stolen.c
 index 69d97cb..7f9380b 100644
 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
 +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
 @@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
 drm_device *dev)
   base -= dev_priv-mm.gtt-stolen_size;
   } else {
   /* Stolen is immediately above Top of Memory */
 - base = max_low_pfn_mapped  PAGE_SHIFT;
 + base = __REMOVED_CRAZY__  PAGE_SHIFT;

 Huh?

Whole function:

static unsigned long i915_stolen_to_physical(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
struct pci_dev *pdev = dev_priv-bridge_dev;
u32 base;

/* On the machines I have tested the Graphics Base of Stolen Memory
 * is unreliable, so on those compute the base by subtracting the
 * stolen memory from the Top of Low Usable DRAM which is where the
 * BIOS places the graphics stolen memory.
 *
 * On gen2, the layout is slightly different with the Graphics Segment
 * immediately following Top of Memory (or Top of Usable DRAM). Note
 * it appears that TOUD is only reported by 865g, so we just use the
 * top of memory as determined by the e820 probe.
 *
 * XXX gen2 requires an unavailable symbol and 945gm fails with
 * its value of TOLUD.
 */
base = 0;
if (INTEL_INFO(dev)-gen = 6) {
/* Read Base Data of Stolen Memory Register (BDSM) directly.
 * Note that there is also a MCHBAR miror at 0x1080c0 or
 * we could use device 2:0x5c instead.
*/
pci_read_config_dword(pdev, 0xB0, base);
base = ~4095; /* lower bits used for locking register */
} else if (INTEL_INFO(dev)-gen  3 || IS_G33(dev)) {
/* Read Graphics Base of Stolen Memory directly */
pci_read_config_dword(pdev, 0xA4, base);
#if 0
} else if (IS_GEN3(dev)) {
u8 val;
/* Stolen is immediately below Top of Low Usable DRAM */
pci_read_config_byte(pdev, 0x9c, val);
base = val  3  27;
base -= dev_priv-mm.gtt-stolen_size;
} else {
/* Stolen is immediately above Top of Memory */
base = __REMOVED_CRAZY__  PAGE_SHIFT;
#endif
}

return base;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/14] x86, ACPI, mm: Kill max_low_pfn_mapped

[Yinghai Lu]

On Thu, Mar 7, 2013 at 9:25 PM, Tejun Heo t...@kernel.org wrote:
 On Thu, Mar 7, 2013 at 9:22 PM, Yinghai Lu ying...@kernel.org wrote:
 On Thu, Mar 7, 2013 at 9:10 PM, Tejun Heo t...@kernel.org wrote:
 On Thu, Mar 07, 2013 at 08:58:27PM -0800, Yinghai Lu wrote:
 diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c 
 b/drivers/gpu/drm/i915/i915_gem_stolen.c
 index 69d97cb..7f9380b 100644
 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c
 +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c
 @@ -81,7 +81,7 @@ static unsigned long i915_stolen_to_physical(struct 
 drm_device *dev)
   base -= dev_priv-mm.gtt-stolen_size;
   } else {
   /* Stolen is immediately above Top of Memory */
 - base = max_low_pfn_mapped  PAGE_SHIFT;
 + base = __REMOVED_CRAZY__  PAGE_SHIFT;

 Huh?

 Whole function:

 Yeah, but can't we still just do 1LLU  32 like other places? Or at
 least explain what was there before? It's gonna confuse the hell out
 of future readers of the code.

They are not using memblock_find_in_range(), so 1ULL will not help.

Really hope i915 drm guys could clean that hacks.

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 11/22] PCI, drm: Kill pci_root_buses in alpha hose setting

[Yinghai Lu]

On Sun, Jan 27, 2013 at 7:21 PM, Yijing Wang  wrote:
> On 2013/1/28 3:23, Yinghai Lu wrote:
>> Replace that with hotplug-safe version.
>>
>> Signed-off-by: Yinghai Lu 
>> Cc: David Airlie 
>> Cc: dri-devel at lists.freedesktop.org
>> ---
>>  drivers/gpu/drm/drm_fops.c |   10 +++---
>>  1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
>> index 133b413..b92a9cc 100644
>> --- a/drivers/gpu/drm/drm_fops.c
>> +++ b/drivers/gpu/drm/drm_fops.c
>> @@ -356,9 +356,13 @@ static int drm_open_helper(struct inode *inode, struct 
>> file *filp,
>>   pci_dev_put(pci_dev);
>>   }
>>   if (!dev->hose) {
>> - struct pci_bus *b = pci_bus_b(pci_root_buses.next);
>> - if (b)
>> - dev->hose = b->sysdata;
>> + struct pci_host_bridge *host_bridge;
>> +
>> + host_bridge = pci_next_host_bridge(NULL);
>
> pci_get_next_host_bridge() ?
>

Fixed.

Thanks.

[PATCH v3 22/22] PCI: Kill pci_root_buses

[Yinghai Lu]

No user now, remove it.

Signed-off-by: Yinghai Lu 
Cc: Mauro Carvalho Chehab 
Cc: Doug Thompson 
Cc: linux-edac at vger.kernel.org
Cc: x86 at kernel.org
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Cc: "David S. Miller" 
Cc: sparclinux at vger.kernel.org
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: linux-ia64 at vger.kernel.org
Cc: linux-altix at sgi.com
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: linux-alpha at vger.kernel.org
Cc: Russell King 
Cc: linux-arm-kernel at lists.infradead.org
Cc: David Howells 
Cc: Michal Simek 
Cc: microblaze-uclinux at itee.uq.edu.au
Cc: Koichi Yasutake 
Cc: linux-am33-list at redhat.com
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: linuxppc-dev at lists.ozlabs.org
---
 drivers/pci/probe.c |8 
 include/linux/pci.h |3 ---
 2 files changed, 11 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 04ecf0d..8420b9d 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -23,10 +23,6 @@ struct resource busn_resource = {
.flags  = IORESOURCE_BUS,
 };

-/* Ugh.  Need to stop exporting this to modules. */
-LIST_HEAD(pci_root_buses);
-EXPORT_SYMBOL(pci_root_buses);
-
 static LIST_HEAD(pci_domain_busn_res_list);

 struct pci_domain_busn_res {
@@ -1746,10 +1742,6 @@ struct pci_bus *pci_create_root_bus(struct device 
*parent, int bus,
dev_info(>dev, "root bus resource %pR%s\n", res, bus_addr);
}

-   down_write(_bus_sem);
-   list_add_tail(>node, _root_buses);
-   up_write(_bus_sem);
-
return b;

 class_dev_reg_err:
diff --git a/include/linux/pci.h b/include/linux/pci.h
index bb07db2..b42721b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -674,9 +674,6 @@ extern enum pcie_bus_config_types pcie_bus_config;
 extern struct bus_type pci_host_bridge_bus_type;
 extern struct bus_type pci_bus_type;

-/* Do NOT directly access these two variables, unless you are arch specific pci
- * code, or pci core code. */
-extern struct list_head pci_root_buses;/* list of all known PCI buses 
*/
 /* Some device drivers need know if pci is initiated */
 extern int no_pci_devices(void);

-- 
1.7.10.4

[PATCH v3 21/22] PCI: Kill pci_find_next_bus

[Yinghai Lu]

No user now, remove it.

That name is misleading as it only for root buses.

Signed-off-by: Yinghai Lu 
Cc: Mauro Carvalho Chehab 
Cc: Doug Thompson 
Cc: linux-edac at vger.kernel.org
Cc: x86 at kernel.org
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Cc: "David S. Miller" 
Cc: sparclinux at vger.kernel.org
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: linux-ia64 at vger.kernel.org
Cc: linux-altix at sgi.com
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: linux-alpha at vger.kernel.org
Cc: Russell King 
Cc: linux-arm-kernel at lists.infradead.org
Cc: David Howells 
Cc: Michal Simek 
Cc: microblaze-uclinux at itee.uq.edu.au
Cc: Koichi Yasutake 
Cc: linux-am33-list at redhat.com
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: linuxppc-dev at lists.ozlabs.org
---
 drivers/pci/search.c |   37 +++--
 include/linux/pci.h  |4 
 2 files changed, 7 insertions(+), 34 deletions(-)

diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index db0c3a9..329c533 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -79,44 +79,22 @@ static struct pci_bus *pci_do_find_bus(struct pci_bus *bus, 
unsigned char busnr)
  */
 struct pci_bus * pci_find_bus(int domain, int busnr)
 {
-   struct pci_bus *bus = NULL;
+   struct pci_host_bridge *host_bridge = NULL;
struct pci_bus *tmp_bus;

-   while ((bus = pci_find_next_bus(bus)) != NULL)  {
-   if (pci_domain_nr(bus) != domain)
+   for_each_pci_host_bridge(host_bridge) {
+   if (pci_domain_nr(host_bridge->bus) != domain)
continue;
-   tmp_bus = pci_do_find_bus(bus, busnr);
-   if (tmp_bus)
+   tmp_bus = pci_do_find_bus(host_bridge->bus, busnr);
+   if (tmp_bus) {
+   put_device(_bridge->dev);
return tmp_bus;
+   }
}
return NULL;
 }

 /**
- * pci_find_next_bus - begin or continue searching for a PCI bus
- * @from: Previous PCI bus found, or %NULL for new search.
- *
- * Iterates through the list of known PCI busses.  A new search is
- * initiated by passing %NULL as the @from argument.  Otherwise if
- * @from is not %NULL, searches continue from next device on the
- * global list.
- */
-struct pci_bus * 
-pci_find_next_bus(const struct pci_bus *from)
-{
-   struct list_head *n;
-   struct pci_bus *b = NULL;
-
-   WARN_ON(in_interrupt());
-   down_read(_bus_sem);
-   n = from ? from->node.next : pci_root_buses.next;
-   if (n != _root_buses)
-   b = pci_bus_b(n);
-   up_read(_bus_sem);
-   return b;
-}
-
-/**
  * pci_get_slot - locate PCI device for a given PCI slot
  * @bus: PCI bus on which desired PCI device resides
  * @devfn: encodes number of PCI slot in which the desired PCI 
@@ -356,7 +334,6 @@ EXPORT_SYMBOL(pci_dev_present);

 /* For boot time work */
 EXPORT_SYMBOL(pci_find_bus);
-EXPORT_SYMBOL(pci_find_next_bus);
 /* For everyone */
 EXPORT_SYMBOL(pci_get_device);
 EXPORT_SYMBOL(pci_get_subsys);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 67879cb..bb07db2 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -763,7 +763,6 @@ int pci_find_ext_capability(struct pci_dev *dev, int cap);
 int pci_find_next_ext_capability(struct pci_dev *dev, int pos, int cap);
 int pci_find_ht_capability(struct pci_dev *dev, int ht_cap);
 int pci_find_next_ht_capability(struct pci_dev *dev, int pos, int ht_cap);
-struct pci_bus *pci_find_next_bus(const struct pci_bus *from);

 struct pci_host_bridge *pci_get_next_host_bridge(struct pci_host_bridge *from);
 struct pci_dev *pci_get_device(unsigned int vendor, unsigned int device,
@@ -1404,9 +1403,6 @@ static inline int pci_block_cfg_access_in_atomic(struct 
pci_dev *dev)
 static inline void pci_unblock_cfg_access(struct pci_dev *dev)
 { }

-static inline struct pci_bus *pci_find_next_bus(const struct pci_bus *from)
-{ return NULL; }
-
 static inline struct pci_dev *pci_get_slot(struct pci_bus *bus,
unsigned int devfn)
 { return NULL; }
-- 
1.7.10.4

[PATCH v3 11/22] PCI, drm: Kill pci_root_buses in alpha hose setting

[Yinghai Lu]

Replace that with hotplug-safe version.

Signed-off-by: Yinghai Lu 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_fops.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 133b413..b92a9cc 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -356,9 +356,13 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
pci_dev_put(pci_dev);
}
if (!dev->hose) {
-   struct pci_bus *b = pci_bus_b(pci_root_buses.next);
-   if (b)
-   dev->hose = b->sysdata;
+   struct pci_host_bridge *host_bridge;
+
+   host_bridge = pci_next_host_bridge(NULL);
+   if (host_bridge) {
+   dev->hose = host_bridge->bus->sysdata;
+   put_device(_bridge->dev);
+   }
}
}
 #endif
-- 
1.7.10.4

[PATCH v3 05/22] PCI: Add for_each_pci_host_bridge() and pci_get_next_host_bridge

[Yinghai Lu]

Now we have pci_root_buses list, and there is lots of iteration with
list_of_each of it, that is not safe after we add pci root bus hotplug
support after booting stage.

Also pci_find_next_bus is pretty misleading name, and it is only finding
next root bus instead of regular pci bus.

Add pci_get_next_host_bridge and use bus_find_device in driver core to
iterate host bridge and the same time get root bus.

In folllowing patches will replace searching root bus with searching 
host_bridge.
after using with that host-bridge, will need to call put device to release
reference if break early from the loop.

After those replacing, we even could kill pci_root_buses list.

-v2: fixes compiling error when CONFIG_PCI is not defined that Fengguang Wu 
found.

Signed-off-by: Yinghai Lu 
Cc: Mauro Carvalho Chehab 
Cc: Doug Thompson 
Cc: linux-edac at vger.kernel.org
Cc: x86 at kernel.org
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Cc: "David S. Miller" 
Cc: sparclinux at vger.kernel.org
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: linux-ia64 at vger.kernel.org
Cc: linux-altix at sgi.com
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: linux-alpha at vger.kernel.org
Cc: Russell King 
Cc: linux-arm-kernel at lists.infradead.org
Cc: David Howells 
Cc: Michal Simek 
Cc: microblaze-uclinux at itee.uq.edu.au
Cc: Koichi Yasutake 
Cc: linux-am33-list at redhat.com
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: linuxppc-dev at lists.ozlabs.org
---
 drivers/pci/search.c |   24 
 include/linux/pci.h  |9 +
 2 files changed, 33 insertions(+)

diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index d0627fa..db0c3a9 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -178,6 +178,30 @@ struct pci_dev *pci_get_domain_bus_and_slot(int domain, 
unsigned int bus,
 }
 EXPORT_SYMBOL(pci_get_domain_bus_and_slot);

+static int match_pci_host_bridge(struct device *dev, void *data)
+{
+   return 1;
+}
+
+struct pci_host_bridge *pci_get_next_host_bridge(struct pci_host_bridge *from)
+{
+   struct device *dev;
+   struct device *dev_start = NULL;
+   struct pci_host_bridge *bridge = NULL;
+
+   WARN_ON(in_interrupt());
+   if (from)
+   dev_start = >dev;
+   dev = bus_find_device(_host_bridge_bus_type, dev_start, NULL,
+ match_pci_host_bridge);
+   if (dev)
+   bridge = to_pci_host_bridge(dev);
+   if (from)
+   put_device(>dev);
+   return bridge;
+}
+EXPORT_SYMBOL_GPL(pci_get_next_host_bridge);
+
 static int match_pci_dev_by_id(struct device *dev, void *data)
 {
struct pci_dev *pdev = to_pci_dev(dev);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 9da06ec..67879cb 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -375,6 +375,8 @@ struct pci_host_bridge {
 };

 #defineto_pci_host_bridge(n) container_of(n, struct pci_host_bridge, 
dev)
+#define for_each_pci_host_bridge(d) while ((d = pci_get_next_host_bridge(d)) 
!= NULL)
+
 void pci_set_host_bridge_release(struct pci_host_bridge *bridge,
 void (*release_fn)(struct pci_host_bridge *),
 void *release_data);
@@ -763,6 +765,7 @@ int pci_find_ht_capability(struct pci_dev *dev, int ht_cap);
 int pci_find_next_ht_capability(struct pci_dev *dev, int pos, int ht_cap);
 struct pci_bus *pci_find_next_bus(const struct pci_bus *from);

+struct pci_host_bridge *pci_get_next_host_bridge(struct pci_host_bridge *from);
 struct pci_dev *pci_get_device(unsigned int vendor, unsigned int device,
struct pci_dev *from);
 struct pci_dev *pci_get_subsys(unsigned int vendor, unsigned int device,
@@ -1418,6 +1421,12 @@ static inline int pci_domain_nr(struct pci_bus *bus)
 static inline struct pci_dev *pci_dev_get(struct pci_dev *dev)
 { return NULL; }

+static inline struct pci_host_bridge *pci_get_next_host_bridge(
+   struct pci_host_bridge *host_bridge)
+{
+   return NULL;
+}
+
 #define dev_is_pci(d) (false)
 #define dev_is_pf(d) (false)
 #define dev_num_vf(d) (0)
-- 
1.7.10.4

[PATCH v3 02/22] PCI: Add dummy bus_type for pci_host_bridge

[Yinghai Lu]

Need to use it for looping registered host_bridge, and kill
pci_root_buses list.

Signed-off-by: Yinghai Lu 
Cc: Mauro Carvalho Chehab 
Cc: Doug Thompson 
Cc: linux-edac at vger.kernel.org
Cc: x86 at kernel.org
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Cc: "David S. Miller" 
Cc: sparclinux at vger.kernel.org
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: linux-ia64 at vger.kernel.org
Cc: linux-altix at sgi.com
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: linux-alpha at vger.kernel.org
Cc: Russell King 
Cc: linux-arm-kernel at lists.infradead.org
Cc: David Howells 
Cc: Michal Simek 
Cc: microblaze-uclinux at itee.uq.edu.au
Cc: Koichi Yasutake 
Cc: linux-am33-list at redhat.com
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: linuxppc-dev at lists.ozlabs.org
---
 drivers/pci/pci-driver.c |   11 ++-
 drivers/pci/probe.c  |1 +
 include/linux/pci.h  |2 ++
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index acdcc3c..9fb004b 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1278,11 +1278,20 @@ struct bus_type pci_bus_type = {
.pm = PCI_PM_OPS_PTR,
 };

+struct bus_type pci_host_bridge_bus_type = {
+   .name   = "pci_host_bridge",
+};
+
+static int __init pci_host_bridge_driver_init(void)
+{
+   return bus_register(_host_bridge_bus_type);
+}
+postcore_initcall(pci_host_bridge_driver_init);
+
 static int __init pci_driver_init(void)
 {
return bus_register(_bus_type);
 }
-
 postcore_initcall(pci_driver_init);

 EXPORT_SYMBOL_GPL(pci_add_dynid);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ef50154..04ecf0d 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1692,6 +1692,7 @@ struct pci_bus *pci_create_root_bus(struct device 
*parent, int bus,
goto err_out;

bridge->dev.parent = parent;
+   bridge->dev.bus = _host_bridge_bus_type;
bridge->dev.release = pci_release_host_bridge_dev;
dev_set_name(>dev, "pci%04x:%02x", pci_domain_nr(b), bus);
error = pcibios_root_bridge_prepare(bridge);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 056d3d6..9da06ec 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -669,6 +669,7 @@ enum pcie_bus_config_types {

 extern enum pcie_bus_config_types pcie_bus_config;

+extern struct bus_type pci_host_bridge_bus_type;
 extern struct bus_type pci_bus_type;

 /* Do NOT directly access these two variables, unless you are arch specific pci
@@ -740,6 +741,7 @@ void pci_stop_root_bus(struct pci_bus *bus);
 void pci_remove_root_bus(struct pci_bus *bus);
 void pci_setup_cardbus(struct pci_bus *bus);
 extern void pci_sort_breadthfirst(void);
+#define dev_is_pci_host_bridge(d) ((d)->bus == _host_bridge_bus_type)
 #define dev_is_pci(d) ((d)->bus == _bus_type)
 #define dev_is_pf(d) ((dev_is_pci(d) ? to_pci_dev(d)->is_physfn : false))
 #define dev_num_vf(d) ((dev_is_pci(d) ? pci_num_vf(to_pci_dev(d)) : 0))
-- 
1.7.10.4

[PATCH v3 00/22] PCI: Iterate pci host bridge instead of pci root bus

[Yinghai Lu]

Now we have pci_root_buses list, and there is lots of iteration with
list_of_each of it, that is not safe after we add pci root bus hotplug
support after booting stage.

Add pci_get_next_host_bridge and use bus_find_device in driver core to
iterate host bridge and the same time get root bus.

We replace searching root bus with searching host_bridge,
as host_bridge->bus is the root bus.
After those replacing, we even could kill pci_root_buses list.

based on pci/next

could get from
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git 
for-pci-for-each-host-bridge

-v2: updated after pci_root_bus_hotplug get into pci/next
-v3: update changelog and add cc for pci core change for arch guys.

Cc: Mauro Carvalho Chehab 
Cc: Doug Thompson 
Cc: linux-edac at vger.kernel.org
Cc: x86 at kernel.org
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
Cc: "David S. Miller" 
Cc: sparclinux at vger.kernel.org
Cc: Tony Luck 
Cc: Fenghua Yu 
Cc: linux-ia64 at vger.kernel.org
Cc: linux-altix at sgi.com
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: linux-alpha at vger.kernel.org
Cc: Russell King 
Cc: linux-arm-kernel at lists.infradead.org
Cc: David Howells 
Cc: Michal Simek 
Cc: microblaze-uclinux at itee.uq.edu.au
Cc: Koichi Yasutake 
Cc: linux-am33-list at redhat.com
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: linuxppc-dev at lists.ozlabs.org


Yinghai Lu (22):
  PCI: Rename pci_release_bus_bridge_dev to pci_release_host_bridge_dev
  PCI: Add dummy bus_type for pci_host_bridge
  PCI, libata: remove find_bridge in acpi_bus_type
  PCI, ACPI: Update comments for find_bridge in acpi_bus_type
  PCI: Add for_each_pci_host_bridge() and pci_get_next_host_bridge
  PCI, hotplug: Kill pci_find_next_bus in sgi_hotplug
  PCI: Kill pci_find_next_bus in pci_sysfs
  PCI, edac: Kill pci_find_next_bus in edac
  PCI, x86: Kill pci_find_next_bus in pcibios_scan_root
  PCI, x86: Kill pci_root_buses in resources reservations
  PCI, drm: Kill pci_root_buses in alpha hose setting
  PCI: Kill pci_root_buses in setup-bus
  PCI, sparc: Kill pci_find_next_bus
  PCI, ia64: Kill pci_find_next_bus
  PCI, alpha: Kill pci_root_buses
  PCI, arm: Kill pci_root_buses
  PCI, frv: Kill pci_root_buses in resources reservations
  PCI, microblaze: Kill pci_root_buses in resources reservations
  PCI, mn10300: Kill pci_root_buses in resources reservations
  PCI, powerpc: Kill pci_root_buses in resources reservations
  PCI: Kill pci_find_next_bus
  PCI: Kill pci_root_buses

 arch/alpha/kernel/pci.c |6 +--
 arch/arm/kernel/bios32.c|9 ++---
 arch/frv/mb93090-mb00/pci-frv.c |   37 +-
 arch/ia64/hp/common/sba_iommu.c |7 ++--
 arch/ia64/sn/kernel/io_common.c |5 ++-
 arch/microblaze/pci/pci-common.c|   10 ++---
 arch/mn10300/unit-asb2305/pci-asb2305.c |   62 ---
 arch/powerpc/kernel/pci-common.c|   13 +++
 arch/powerpc/kernel/pci_64.c|8 ++--
 arch/sparc/kernel/pci.c |6 ++-
 arch/x86/pci/common.c   |9 +++--
 arch/x86/pci/i386.c |   20 +-
 drivers/ata/libata-acpi.c   |6 ---
 drivers/edac/i7core_edac.c  |6 +--
 drivers/gpu/drm/drm_fops.c  |   10 +++--
 drivers/pci/hotplug/sgi_hotplug.c   |6 ++-
 drivers/pci/pci-driver.c|   11 +-
 drivers/pci/pci-sysfs.c |6 +--
 drivers/pci/probe.c |   13 ++-
 drivers/pci/search.c|   61 +++---
 drivers/pci/setup-bus.c |   24 ++--
 include/acpi/acpi_bus.h |2 +-
 include/linux/pci.h |   18 +
 23 files changed, 187 insertions(+), 168 deletions(-)

-- 
1.7.10.4

[PATCH v3 11/22] PCI, drm: Kill pci_root_buses in alpha hose setting

[Yinghai Lu]

Replace that with hotplug-safe version.

Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/drm_fops.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 133b413..b92a9cc 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -356,9 +356,13 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
pci_dev_put(pci_dev);
}
if (!dev-hose) {
-   struct pci_bus *b = pci_bus_b(pci_root_buses.next);
-   if (b)
-   dev-hose = b-sysdata;
+   struct pci_host_bridge *host_bridge;
+
+   host_bridge = pci_next_host_bridge(NULL);
+   if (host_bridge) {
+   dev-hose = host_bridge-bus-sysdata;
+   put_device(host_bridge-dev);
+   }
}
}
 #endif
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 11/22] PCI, drm: Kill pci_root_buses in alpha hose setting

[Yinghai Lu]

On Sun, Jan 27, 2013 at 7:21 PM, Yijing Wang wangyij...@huawei.com wrote:
 On 2013/1/28 3:23, Yinghai Lu wrote:
 Replace that with hotplug-safe version.

 Signed-off-by: Yinghai Lu ying...@kernel.org
 Cc: David Airlie airl...@linux.ie
 Cc: dri-devel@lists.freedesktop.org
 ---
  drivers/gpu/drm/drm_fops.c |   10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
 index 133b413..b92a9cc 100644
 --- a/drivers/gpu/drm/drm_fops.c
 +++ b/drivers/gpu/drm/drm_fops.c
 @@ -356,9 +356,13 @@ static int drm_open_helper(struct inode *inode, struct 
 file *filp,
   pci_dev_put(pci_dev);
   }
   if (!dev-hose) {
 - struct pci_bus *b = pci_bus_b(pci_root_buses.next);
 - if (b)
 - dev-hose = b-sysdata;
 + struct pci_host_bridge *host_bridge;
 +
 + host_bridge = pci_next_host_bridge(NULL);

 pci_get_next_host_bridge() ?


Fixed.

Thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 02/22] PCI: Add dummy bus_type for pci_host_bridge

[Yinghai Lu]

Need to use it for looping registered host_bridge, and kill
pci_root_buses list.

Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Doug Thompson dougthomp...@xmission.com
Cc: linux-e...@vger.kernel.org
Cc: x...@kernel.org
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
Cc: David S. Miller da...@davemloft.net
Cc: sparcli...@vger.kernel.org
Cc: Tony Luck tony.l...@intel.com
Cc: Fenghua Yu fenghua...@intel.com
Cc: linux-i...@vger.kernel.org
Cc: linux-al...@sgi.com
Cc: Richard Henderson r...@twiddle.net
Cc: Ivan Kokshaysky i...@jurassic.park.msu.ru
Cc: Matt Turner matts...@gmail.com
Cc: linux-al...@vger.kernel.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Cc: David Howells dhowe...@redhat.com
Cc: Michal Simek mon...@monstr.eu
Cc: microblaze-ucli...@itee.uq.edu.au
Cc: Koichi Yasutake yasutake.koi...@jp.panasonic.com
Cc: linux-am33-l...@redhat.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-...@lists.ozlabs.org
---
 drivers/pci/pci-driver.c |   11 ++-
 drivers/pci/probe.c  |1 +
 include/linux/pci.h  |2 ++
 3 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index acdcc3c..9fb004b 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -1278,11 +1278,20 @@ struct bus_type pci_bus_type = {
.pm = PCI_PM_OPS_PTR,
 };
 
+struct bus_type pci_host_bridge_bus_type = {
+   .name   = pci_host_bridge,
+};
+
+static int __init pci_host_bridge_driver_init(void)
+{
+   return bus_register(pci_host_bridge_bus_type);
+}
+postcore_initcall(pci_host_bridge_driver_init);
+
 static int __init pci_driver_init(void)
 {
return bus_register(pci_bus_type);
 }
-
 postcore_initcall(pci_driver_init);
 
 EXPORT_SYMBOL_GPL(pci_add_dynid);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index ef50154..04ecf0d 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1692,6 +1692,7 @@ struct pci_bus *pci_create_root_bus(struct device 
*parent, int bus,
goto err_out;
 
bridge-dev.parent = parent;
+   bridge-dev.bus = pci_host_bridge_bus_type;
bridge-dev.release = pci_release_host_bridge_dev;
dev_set_name(bridge-dev, pci%04x:%02x, pci_domain_nr(b), bus);
error = pcibios_root_bridge_prepare(bridge);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 056d3d6..9da06ec 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -669,6 +669,7 @@ enum pcie_bus_config_types {
 
 extern enum pcie_bus_config_types pcie_bus_config;
 
+extern struct bus_type pci_host_bridge_bus_type;
 extern struct bus_type pci_bus_type;
 
 /* Do NOT directly access these two variables, unless you are arch specific pci
@@ -740,6 +741,7 @@ void pci_stop_root_bus(struct pci_bus *bus);
 void pci_remove_root_bus(struct pci_bus *bus);
 void pci_setup_cardbus(struct pci_bus *bus);
 extern void pci_sort_breadthfirst(void);
+#define dev_is_pci_host_bridge(d) ((d)-bus == pci_host_bridge_bus_type)
 #define dev_is_pci(d) ((d)-bus == pci_bus_type)
 #define dev_is_pf(d) ((dev_is_pci(d) ? to_pci_dev(d)-is_physfn : false))
 #define dev_num_vf(d) ((dev_is_pci(d) ? pci_num_vf(to_pci_dev(d)) : 0))
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 05/22] PCI: Add for_each_pci_host_bridge() and pci_get_next_host_bridge

[Yinghai Lu]

Now we have pci_root_buses list, and there is lots of iteration with
list_of_each of it, that is not safe after we add pci root bus hotplug
support after booting stage.

Also pci_find_next_bus is pretty misleading name, and it is only finding
next root bus instead of regular pci bus.

Add pci_get_next_host_bridge and use bus_find_device in driver core to
iterate host bridge and the same time get root bus.

In folllowing patches will replace searching root bus with searching 
host_bridge.
after using with that host-bridge, will need to call put device to release
reference if break early from the loop.

After those replacing, we even could kill pci_root_buses list.

-v2: fixes compiling error when CONFIG_PCI is not defined that Fengguang Wu 
found.

Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Doug Thompson dougthomp...@xmission.com
Cc: linux-e...@vger.kernel.org
Cc: x...@kernel.org
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
Cc: David S. Miller da...@davemloft.net
Cc: sparcli...@vger.kernel.org
Cc: Tony Luck tony.l...@intel.com
Cc: Fenghua Yu fenghua...@intel.com
Cc: linux-i...@vger.kernel.org
Cc: linux-al...@sgi.com
Cc: Richard Henderson r...@twiddle.net
Cc: Ivan Kokshaysky i...@jurassic.park.msu.ru
Cc: Matt Turner matts...@gmail.com
Cc: linux-al...@vger.kernel.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Cc: David Howells dhowe...@redhat.com
Cc: Michal Simek mon...@monstr.eu
Cc: microblaze-ucli...@itee.uq.edu.au
Cc: Koichi Yasutake yasutake.koi...@jp.panasonic.com
Cc: linux-am33-l...@redhat.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-...@lists.ozlabs.org
---
 drivers/pci/search.c |   24 
 include/linux/pci.h  |9 +
 2 files changed, 33 insertions(+)

diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index d0627fa..db0c3a9 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -178,6 +178,30 @@ struct pci_dev *pci_get_domain_bus_and_slot(int domain, 
unsigned int bus,
 }
 EXPORT_SYMBOL(pci_get_domain_bus_and_slot);
 
+static int match_pci_host_bridge(struct device *dev, void *data)
+{
+   return 1;
+}
+
+struct pci_host_bridge *pci_get_next_host_bridge(struct pci_host_bridge *from)
+{
+   struct device *dev;
+   struct device *dev_start = NULL;
+   struct pci_host_bridge *bridge = NULL;
+
+   WARN_ON(in_interrupt());
+   if (from)
+   dev_start = from-dev;
+   dev = bus_find_device(pci_host_bridge_bus_type, dev_start, NULL,
+ match_pci_host_bridge);
+   if (dev)
+   bridge = to_pci_host_bridge(dev);
+   if (from)
+   put_device(from-dev);
+   return bridge;
+}
+EXPORT_SYMBOL_GPL(pci_get_next_host_bridge);
+
 static int match_pci_dev_by_id(struct device *dev, void *data)
 {
struct pci_dev *pdev = to_pci_dev(dev);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 9da06ec..67879cb 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -375,6 +375,8 @@ struct pci_host_bridge {
 };
 
 #defineto_pci_host_bridge(n) container_of(n, struct pci_host_bridge, 
dev)
+#define for_each_pci_host_bridge(d) while ((d = pci_get_next_host_bridge(d)) 
!= NULL)
+
 void pci_set_host_bridge_release(struct pci_host_bridge *bridge,
 void (*release_fn)(struct pci_host_bridge *),
 void *release_data);
@@ -763,6 +765,7 @@ int pci_find_ht_capability(struct pci_dev *dev, int ht_cap);
 int pci_find_next_ht_capability(struct pci_dev *dev, int pos, int ht_cap);
 struct pci_bus *pci_find_next_bus(const struct pci_bus *from);
 
+struct pci_host_bridge *pci_get_next_host_bridge(struct pci_host_bridge *from);
 struct pci_dev *pci_get_device(unsigned int vendor, unsigned int device,
struct pci_dev *from);
 struct pci_dev *pci_get_subsys(unsigned int vendor, unsigned int device,
@@ -1418,6 +1421,12 @@ static inline int pci_domain_nr(struct pci_bus *bus)
 static inline struct pci_dev *pci_dev_get(struct pci_dev *dev)
 { return NULL; }
 
+static inline struct pci_host_bridge *pci_get_next_host_bridge(
+   struct pci_host_bridge *host_bridge)
+{
+   return NULL;
+}
+
 #define dev_is_pci(d) (false)
 #define dev_is_pf(d) (false)
 #define dev_num_vf(d) (0)
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 00/22] PCI: Iterate pci host bridge instead of pci root bus

[Yinghai Lu]

Now we have pci_root_buses list, and there is lots of iteration with
list_of_each of it, that is not safe after we add pci root bus hotplug
support after booting stage.

Add pci_get_next_host_bridge and use bus_find_device in driver core to
iterate host bridge and the same time get root bus.

We replace searching root bus with searching host_bridge,
as host_bridge-bus is the root bus.
After those replacing, we even could kill pci_root_buses list.

based on pci/next

could get from
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git 
for-pci-for-each-host-bridge

-v2: updated after pci_root_bus_hotplug get into pci/next
-v3: update changelog and add cc for pci core change for arch guys.

Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Doug Thompson dougthomp...@xmission.com
Cc: linux-e...@vger.kernel.org
Cc: x...@kernel.org
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
Cc: David S. Miller da...@davemloft.net
Cc: sparcli...@vger.kernel.org
Cc: Tony Luck tony.l...@intel.com
Cc: Fenghua Yu fenghua...@intel.com
Cc: linux-i...@vger.kernel.org
Cc: linux-al...@sgi.com
Cc: Richard Henderson r...@twiddle.net
Cc: Ivan Kokshaysky i...@jurassic.park.msu.ru
Cc: Matt Turner matts...@gmail.com
Cc: linux-al...@vger.kernel.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Cc: David Howells dhowe...@redhat.com
Cc: Michal Simek mon...@monstr.eu
Cc: microblaze-ucli...@itee.uq.edu.au
Cc: Koichi Yasutake yasutake.koi...@jp.panasonic.com
Cc: linux-am33-l...@redhat.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-...@lists.ozlabs.org


Yinghai Lu (22):
  PCI: Rename pci_release_bus_bridge_dev to pci_release_host_bridge_dev
  PCI: Add dummy bus_type for pci_host_bridge
  PCI, libata: remove find_bridge in acpi_bus_type
  PCI, ACPI: Update comments for find_bridge in acpi_bus_type
  PCI: Add for_each_pci_host_bridge() and pci_get_next_host_bridge
  PCI, hotplug: Kill pci_find_next_bus in sgi_hotplug
  PCI: Kill pci_find_next_bus in pci_sysfs
  PCI, edac: Kill pci_find_next_bus in edac
  PCI, x86: Kill pci_find_next_bus in pcibios_scan_root
  PCI, x86: Kill pci_root_buses in resources reservations
  PCI, drm: Kill pci_root_buses in alpha hose setting
  PCI: Kill pci_root_buses in setup-bus
  PCI, sparc: Kill pci_find_next_bus
  PCI, ia64: Kill pci_find_next_bus
  PCI, alpha: Kill pci_root_buses
  PCI, arm: Kill pci_root_buses
  PCI, frv: Kill pci_root_buses in resources reservations
  PCI, microblaze: Kill pci_root_buses in resources reservations
  PCI, mn10300: Kill pci_root_buses in resources reservations
  PCI, powerpc: Kill pci_root_buses in resources reservations
  PCI: Kill pci_find_next_bus
  PCI: Kill pci_root_buses

 arch/alpha/kernel/pci.c |6 +--
 arch/arm/kernel/bios32.c|9 ++---
 arch/frv/mb93090-mb00/pci-frv.c |   37 +-
 arch/ia64/hp/common/sba_iommu.c |7 ++--
 arch/ia64/sn/kernel/io_common.c |5 ++-
 arch/microblaze/pci/pci-common.c|   10 ++---
 arch/mn10300/unit-asb2305/pci-asb2305.c |   62 ---
 arch/powerpc/kernel/pci-common.c|   13 +++
 arch/powerpc/kernel/pci_64.c|8 ++--
 arch/sparc/kernel/pci.c |6 ++-
 arch/x86/pci/common.c   |9 +++--
 arch/x86/pci/i386.c |   20 +-
 drivers/ata/libata-acpi.c   |6 ---
 drivers/edac/i7core_edac.c  |6 +--
 drivers/gpu/drm/drm_fops.c  |   10 +++--
 drivers/pci/hotplug/sgi_hotplug.c   |6 ++-
 drivers/pci/pci-driver.c|   11 +-
 drivers/pci/pci-sysfs.c |6 +--
 drivers/pci/probe.c |   13 ++-
 drivers/pci/search.c|   61 +++---
 drivers/pci/setup-bus.c |   24 ++--
 include/acpi/acpi_bus.h |2 +-
 include/linux/pci.h |   18 +
 23 files changed, 187 insertions(+), 168 deletions(-)

-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 22/22] PCI: Kill pci_root_buses

[Yinghai Lu]

No user now, remove it.

Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Doug Thompson dougthomp...@xmission.com
Cc: linux-e...@vger.kernel.org
Cc: x...@kernel.org
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
Cc: David S. Miller da...@davemloft.net
Cc: sparcli...@vger.kernel.org
Cc: Tony Luck tony.l...@intel.com
Cc: Fenghua Yu fenghua...@intel.com
Cc: linux-i...@vger.kernel.org
Cc: linux-al...@sgi.com
Cc: Richard Henderson r...@twiddle.net
Cc: Ivan Kokshaysky i...@jurassic.park.msu.ru
Cc: Matt Turner matts...@gmail.com
Cc: linux-al...@vger.kernel.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Cc: David Howells dhowe...@redhat.com
Cc: Michal Simek mon...@monstr.eu
Cc: microblaze-ucli...@itee.uq.edu.au
Cc: Koichi Yasutake yasutake.koi...@jp.panasonic.com
Cc: linux-am33-l...@redhat.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-...@lists.ozlabs.org
---
 drivers/pci/probe.c |8 
 include/linux/pci.h |3 ---
 2 files changed, 11 deletions(-)

diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 04ecf0d..8420b9d 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -23,10 +23,6 @@ struct resource busn_resource = {
.flags  = IORESOURCE_BUS,
 };
 
-/* Ugh.  Need to stop exporting this to modules. */
-LIST_HEAD(pci_root_buses);
-EXPORT_SYMBOL(pci_root_buses);
-
 static LIST_HEAD(pci_domain_busn_res_list);
 
 struct pci_domain_busn_res {
@@ -1746,10 +1742,6 @@ struct pci_bus *pci_create_root_bus(struct device 
*parent, int bus,
dev_info(b-dev, root bus resource %pR%s\n, res, bus_addr);
}
 
-   down_write(pci_bus_sem);
-   list_add_tail(b-node, pci_root_buses);
-   up_write(pci_bus_sem);
-
return b;
 
 class_dev_reg_err:
diff --git a/include/linux/pci.h b/include/linux/pci.h
index bb07db2..b42721b 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -674,9 +674,6 @@ extern enum pcie_bus_config_types pcie_bus_config;
 extern struct bus_type pci_host_bridge_bus_type;
 extern struct bus_type pci_bus_type;
 
-/* Do NOT directly access these two variables, unless you are arch specific pci
- * code, or pci core code. */
-extern struct list_head pci_root_buses;/* list of all known PCI buses 
*/
 /* Some device drivers need know if pci is initiated */
 extern int no_pci_devices(void);
 
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 21/22] PCI: Kill pci_find_next_bus

[Yinghai Lu]

No user now, remove it.

That name is misleading as it only for root buses.

Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: Doug Thompson dougthomp...@xmission.com
Cc: linux-e...@vger.kernel.org
Cc: x...@kernel.org
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
Cc: David S. Miller da...@davemloft.net
Cc: sparcli...@vger.kernel.org
Cc: Tony Luck tony.l...@intel.com
Cc: Fenghua Yu fenghua...@intel.com
Cc: linux-i...@vger.kernel.org
Cc: linux-al...@sgi.com
Cc: Richard Henderson r...@twiddle.net
Cc: Ivan Kokshaysky i...@jurassic.park.msu.ru
Cc: Matt Turner matts...@gmail.com
Cc: linux-al...@vger.kernel.org
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-arm-ker...@lists.infradead.org
Cc: David Howells dhowe...@redhat.com
Cc: Michal Simek mon...@monstr.eu
Cc: microblaze-ucli...@itee.uq.edu.au
Cc: Koichi Yasutake yasutake.koi...@jp.panasonic.com
Cc: linux-am33-l...@redhat.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul Mackerras pau...@samba.org
Cc: linuxppc-...@lists.ozlabs.org
---
 drivers/pci/search.c |   37 +++--
 include/linux/pci.h  |4 
 2 files changed, 7 insertions(+), 34 deletions(-)

diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index db0c3a9..329c533 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -79,44 +79,22 @@ static struct pci_bus *pci_do_find_bus(struct pci_bus *bus, 
unsigned char busnr)
  */
 struct pci_bus * pci_find_bus(int domain, int busnr)
 {
-   struct pci_bus *bus = NULL;
+   struct pci_host_bridge *host_bridge = NULL;
struct pci_bus *tmp_bus;
 
-   while ((bus = pci_find_next_bus(bus)) != NULL)  {
-   if (pci_domain_nr(bus) != domain)
+   for_each_pci_host_bridge(host_bridge) {
+   if (pci_domain_nr(host_bridge-bus) != domain)
continue;
-   tmp_bus = pci_do_find_bus(bus, busnr);
-   if (tmp_bus)
+   tmp_bus = pci_do_find_bus(host_bridge-bus, busnr);
+   if (tmp_bus) {
+   put_device(host_bridge-dev);
return tmp_bus;
+   }
}
return NULL;
 }
 
 /**
- * pci_find_next_bus - begin or continue searching for a PCI bus
- * @from: Previous PCI bus found, or %NULL for new search.
- *
- * Iterates through the list of known PCI busses.  A new search is
- * initiated by passing %NULL as the @from argument.  Otherwise if
- * @from is not %NULL, searches continue from next device on the
- * global list.
- */
-struct pci_bus * 
-pci_find_next_bus(const struct pci_bus *from)
-{
-   struct list_head *n;
-   struct pci_bus *b = NULL;
-
-   WARN_ON(in_interrupt());
-   down_read(pci_bus_sem);
-   n = from ? from-node.next : pci_root_buses.next;
-   if (n != pci_root_buses)
-   b = pci_bus_b(n);
-   up_read(pci_bus_sem);
-   return b;
-}
-
-/**
  * pci_get_slot - locate PCI device for a given PCI slot
  * @bus: PCI bus on which desired PCI device resides
  * @devfn: encodes number of PCI slot in which the desired PCI 
@@ -356,7 +334,6 @@ EXPORT_SYMBOL(pci_dev_present);
 
 /* For boot time work */
 EXPORT_SYMBOL(pci_find_bus);
-EXPORT_SYMBOL(pci_find_next_bus);
 /* For everyone */
 EXPORT_SYMBOL(pci_get_device);
 EXPORT_SYMBOL(pci_get_subsys);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 67879cb..bb07db2 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -763,7 +763,6 @@ int pci_find_ext_capability(struct pci_dev *dev, int cap);
 int pci_find_next_ext_capability(struct pci_dev *dev, int pos, int cap);
 int pci_find_ht_capability(struct pci_dev *dev, int ht_cap);
 int pci_find_next_ht_capability(struct pci_dev *dev, int pos, int ht_cap);
-struct pci_bus *pci_find_next_bus(const struct pci_bus *from);
 
 struct pci_host_bridge *pci_get_next_host_bridge(struct pci_host_bridge *from);
 struct pci_dev *pci_get_device(unsigned int vendor, unsigned int device,
@@ -1404,9 +1403,6 @@ static inline int pci_block_cfg_access_in_atomic(struct 
pci_dev *dev)
 static inline void pci_unblock_cfg_access(struct pci_dev *dev)
 { }
 
-static inline struct pci_bus *pci_find_next_bus(const struct pci_bus *from)
-{ return NULL; }
-
 static inline struct pci_dev *pci_get_slot(struct pci_bus *bus,
unsigned int devfn)
 { return NULL; }
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 11/22] PCI, drm: Kill pci_root_buses in alpha hose setting

[Yinghai Lu]

Signed-off-by: Yinghai Lu 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_fops.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 133b413..b92a9cc 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -356,9 +356,13 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
pci_dev_put(pci_dev);
}
if (!dev->hose) {
-   struct pci_bus *b = pci_bus_b(pci_root_buses.next);
-   if (b)
-   dev->hose = b->sysdata;
+   struct pci_host_bridge *host_bridge;
+
+   host_bridge = pci_next_host_bridge(NULL);
+   if (host_bridge) {
+   dev->hose = host_bridge->bus->sysdata;
+   put_device(_bridge->dev);
+   }
}
}
 #endif
-- 
1.7.10.4

[PATCH v2 11/22] PCI, drm: Kill pci_root_buses in alpha hose setting

[Yinghai Lu]

Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/drm_fops.c |   10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 133b413..b92a9cc 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -356,9 +356,13 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
pci_dev_put(pci_dev);
}
if (!dev-hose) {
-   struct pci_bus *b = pci_bus_b(pci_root_buses.next);
-   if (b)
-   dev-hose = b-sysdata;
+   struct pci_host_bridge *host_bridge;
+
+   host_bridge = pci_next_host_bridge(NULL);
+   if (host_bridge) {
+   dev-hose = host_bridge-bus-sysdata;
+   put_device(host_bridge-dev);
+   }
}
}
 #endif
-- 
1.7.10.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 18/29] PCI, drm: kill pci_root_buses in alpha hose setting

[Yinghai Lu]

Signed-off-by: Yinghai Lu 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
---
 drivers/gpu/drm/drm_fops.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 5062eec..ff4cdf3 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -340,9 +340,13 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
pci_dev_put(pci_dev);
}
if (!dev->hose) {
-   struct pci_bus *b = pci_bus_b(pci_root_buses.next);
-   if (b)
-   dev->hose = b->sysdata;
+   struct pci_host_bridge *host_bridge;
+
+   host_bridge = pci_next_host_bridge(NULL);
+   if (host_bridge) {
+   dev->hose = host_bridge->bus->sysdata;
+   put_device(_bridge->dev);
+   }
}
}
 #endif
-- 
1.7.7

[PATCH 18/29] PCI, drm: kill pci_root_buses in alpha hose setting

[Yinghai Lu]

Signed-off-by: Yinghai Lu ying...@kernel.org
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.freedesktop.org
---
 drivers/gpu/drm/drm_fops.c |   10 +++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c
index 5062eec..ff4cdf3 100644
--- a/drivers/gpu/drm/drm_fops.c
+++ b/drivers/gpu/drm/drm_fops.c
@@ -340,9 +340,13 @@ static int drm_open_helper(struct inode *inode, struct 
file *filp,
pci_dev_put(pci_dev);
}
if (!dev-hose) {
-   struct pci_bus *b = pci_bus_b(pci_root_buses.next);
-   if (b)
-   dev-hose = b-sysdata;
+   struct pci_host_bridge *host_bridge;
+
+   host_bridge = pci_next_host_bridge(NULL);
+   if (host_bridge) {
+   dev-hose = host_bridge-bus-sysdata;
+   put_device(host_bridge-dev);
+   }
}
}
 #endif
-- 
1.7.7

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Yinghai Lu]

On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu  wrote:
> On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu  wrote:
>> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury  
>> wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Strange, the busn branch is merged with for-pci-res-alloc, but for
>>> some reason it isn't working. ?Only the bridge is detected, not the
>>> devices behind it.
>>
>> Can you post the boot log ? maybe recently reordering patches applying
>> sequence break it.
>
> Never mind, found the problem.

updated for-pci-res-alloc branch. please check it.

Thanks

Yinghai

PCI resources above 4GB

[Yinghai Lu]

On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu  wrote:
> On Thu, May 17, 2012 at 5:34 AM, Steven Newbury  
> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Strange, the busn branch is merged with for-pci-res-alloc, but for
>> some reason it isn't working. ?Only the bridge is detected, not the
>> devices behind it.
>
> Can you post the boot log ? maybe recently reordering patches applying
> sequence break it.

Never mind, found the problem.

will check if i could fix it tomorrow.

Yinghai

Re: PCI resources above 4GB

[Yinghai Lu]

On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu ying...@kernel.org wrote:
 On Thu, May 17, 2012 at 5:34 AM, Steven Newbury st...@snewbury.org.uk wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Strange, the busn branch is merged with for-pci-res-alloc, but for
 some reason it isn't working.  Only the bridge is detected, not the
 devices behind it.

 Can you post the boot log ? maybe recently reordering patches applying
 sequence break it.

Never mind, found the problem.

will check if i could fix it tomorrow.

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Yinghai Lu]

On Fri, May 18, 2012 at 12:45 AM, Yinghai Lu ying...@kernel.org wrote:
 On Thu, May 17, 2012 at 9:36 AM, Yinghai Lu ying...@kernel.org wrote:
 On Thu, May 17, 2012 at 5:34 AM, Steven Newbury st...@snewbury.org.uk 
 wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Strange, the busn branch is merged with for-pci-res-alloc, but for
 some reason it isn't working.  Only the bridge is detected, not the
 devices behind it.

 Can you post the boot log ? maybe recently reordering patches applying
 sequence break it.

 Never mind, found the problem.

updated for-pci-res-alloc branch. please check it.

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Yinghai Lu]

On Thu, May 17, 2012 at 5:34 AM, Steven Newbury  
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Strange, the busn branch is merged with for-pci-res-alloc, but for
> some reason it isn't working. ?Only the bridge is detected, not the
> devices behind it.

Can you post the boot log ? maybe recently reordering patches applying
sequence break it.

Yinghai

Re: PCI resources above 4GB

[Yinghai Lu]

On Thu, May 17, 2012 at 5:34 AM, Steven Newbury st...@snewbury.org.uk wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Strange, the busn branch is merged with for-pci-res-alloc, but for
 some reason it isn't working.  Only the bridge is detected, not the
 devices behind it.

Can you post the boot log ? maybe recently reordering patches applying
sequence break it.

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Yinghai Lu]

On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu  wrote:
> On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu  wrote:
>>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but
>>> that could fail.
>>> ? so could hack it like a. disable bar 0x10 and steal BAR address,
>>> then set 0x30 to that address then copy ROM to ram.
>>> ? after that, disable rom again and set back address to 0x10.
>>> ? You try to update radeon_get_bios() to achieve that.
>
> patches for solution 3:
> map_rom.patch will try to borrow mem or mem pref bar for ROM copying
>
> and You still need to use pci=norom

map_rom.patch missed one !

Please check map_rom_v2.patch

Thanks

Yinghai
-- next part --
A non-text attachment was scrubbed...
Name: map_rom_v2.patch
Type: application/octet-stream
Size: 4307 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120416/ff392496/attachment.obj>

PCI resources above 4GB

[Yinghai Lu]

On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu  wrote:
>> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but
>> that could fail.
>> ? so could hack it like a. disable bar 0x10 and steal BAR address,
>> then set 0x30 to that address then copy ROM to ram.
>> ? after that, disable rom again and set back address to 0x10.
>> ? You try to update radeon_get_bios() to achieve that.

patches for solution 3:
map_rom.patch will try to borrow mem or mem pref bar for ROM copying

and You still need to use pci=norom

Yinghai
-- next part --
A non-text attachment was scrubbed...
Name: rom_option.patch
Type: application/octet-stream
Size: 1672 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120415/78abbf24/attachment-0003.obj>
-- next part --
A non-text attachment was scrubbed...
Name: rom_option_1.patch
Type: application/octet-stream
Size: 2253 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120415/78abbf24/attachment-0004.obj>
-- next part --
A non-text attachment was scrubbed...
Name: map_rom.patch
Type: application/octet-stream
Size: 4306 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120415/78abbf24/attachment-0005.obj>

Re: PCI resources above 4GB

[Yinghai Lu]

On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu ying...@kernel.org wrote:
 3. use pci_bus_allocate_resource in drm/radeon driver ... === but
 that could fail.
   so could hack it like a. disable bar 0x10 and steal BAR address,
 then set 0x30 to that address then copy ROM to ram.
   after that, disable rom again and set back address to 0x10.
   You try to update radeon_get_bios() to achieve that.

patches for solution 3:
map_rom.patch will try to borrow mem or mem pref bar for ROM copying

and You still need to use pci=norom

Yinghai


rom_option.patch
Description: Binary data


rom_option_1.patch
Description: Binary data


map_rom.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Yinghai Lu]

On Sun, Apr 15, 2012 at 11:54 PM, Yinghai Lu ying...@kernel.org wrote:
 On Sun, Apr 15, 2012 at 1:06 PM, Yinghai Lu ying...@kernel.org wrote:
 3. use pci_bus_allocate_resource in drm/radeon driver ... === but
 that could fail.
   so could hack it like a. disable bar 0x10 and steal BAR address,
 then set 0x30 to that address then copy ROM to ram.
   after that, disable rom again and set back address to 0x10.
   You try to update radeon_get_bios() to achieve that.

 patches for solution 3:
 map_rom.patch will try to borrow mem or mem pref bar for ROM copying

 and You still need to use pci=norom

map_rom.patch missed one !

Please check map_rom_v2.patch

Thanks

Yinghai


map_rom_v2.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Yinghai Lu]

On Sun, Apr 15, 2012 at 1:05 PM, Yinghai Lu  wrote:
> On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury  
> wrote:
>>>>>>>>
>>>>>>>> pci :03:08.0: BAR 15: can't assign mem pref (size
>>>>>>>> 0x1800)
>>>>>>> Ah! Not enough space for the bridge window!:(
>>>>>>>
>>>
>>>>>> please append pci=norom ...
>>>
>>>>> That worked. ?Except of course the radeon driver can't POST the
>>>>> ?card without the ROM! :-P
>>>> Can the ROM resource be mapped above 4G?
>>> I didn't really think that through, obviously it can't because
>>> it's not on a 64-bit capable bridge. ?I wonder though, could it be
>>> shadowed then disabled early before the IOMEM?
>> I see there's "#if 0"'d helper functions for exactly that in rom.c.
>> They've been disabled since 2007!
>
> solution could be one of three:
> 1. when bridge support 64bit pref, will not allocate rom bar in bridge
> pref resource.
> > patch: rom_pref.patch
>
> 2. unconditionally to make rom bar allocation in bridge non-pref range.
> > patch: rom_no_pref.patch

missed attach rom_no_pref.patch

> Looks like BIOS and at least one of other OSes is doing that.
>
> I can not find the the history why ROM res is with PREFETCH bit set.
> Maybe Linus has some idea about that.
>
> 3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but
> that could fail.
> ? so could hack it like a. disable bar 0x10 and steal BAR address,
> then set 0x30 to that address then copy ROM to ram.
> ? after that, disable rom again and set back address to 0x10.
> ? You try to update radeon_get_bios() to achieve that.
>
> ? ? ?Yinghai
-- next part --
A non-text attachment was scrubbed...
Name: rom_no_pref.patch
Type: application/octet-stream
Size: 839 bytes
Desc: not available
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120415/953419b1/attachment.obj>

PCI resources above 4GB

[Yinghai Lu]

On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury  
wrote:
>>>
>>> pci :03:08.0: BAR 15: can't assign mem pref (size
>>> 0x1800)
>> Ah! Not enough space for the bridge window!:(
>>
>>
> please append pci=norom ...
>>
 That worked. ?Except of course the radeon driver can't POST the
 ?card without the ROM! :-P
>>> Can the ROM resource be mapped above 4G?
>> I didn't really think that through, obviously it can't because
>> it's not on a 64-bit capable bridge. ?I wonder though, could it be
>> shadowed then disabled early before the IOMEM?
> I see there's "#if 0"'d helper functions for exactly that in rom.c.
> They've been disabled since 2007!

solution could be one of three:
1. when bridge support 64bit pref, will not allocate rom bar in bridge
pref resource.
> patch: rom_pref.patch

2. unconditionally to make rom bar allocation in bridge non-pref range.
> patch: rom_no_pref.patch
Looks like BIOS and at least one of other OSes is doing that.

I can not find the the history why ROM res is with PREFETCH bit set.
Maybe Linus has some idea about that.

3. use pci_bus_allocate_resource in drm/radeon driver ... ===> but
that could fail.
   so could hack it like a. disable bar 0x10 and steal BAR address,
then set 0x30 to that address then copy ROM to ram.
   after that, disable rom again and set back address to 0x10.
   You try to update radeon_get_bios() to achieve that.

  Yinghai
-- next part --
A non-text attachment was scrubbed...
Name: rom_pref.patch
Type: application/octet-stream
Size: 1101 bytes
Desc: not available
URL: 

Re: PCI resources above 4GB

[Yinghai Lu]

On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury st...@snewbury.org.uk wrote:

 pci :03:08.0: BAR 15: can't assign mem pref (size
 0x1800)
 Ah! Not enough space for the bridge window!:(


 please append pci=norom ...

 That worked.  Except of course the radeon driver can't POST the
  card without the ROM! :-P
 Can the ROM resource be mapped above 4G?
 I didn't really think that through, obviously it can't because
 it's not on a 64-bit capable bridge.  I wonder though, could it be
 shadowed then disabled early before the IOMEM?
 I see there's #if 0'd helper functions for exactly that in rom.c.
 They've been disabled since 2007!

solution could be one of three:
1. when bridge support 64bit pref, will not allocate rom bar in bridge
pref resource.
 patch: rom_pref.patch

2. unconditionally to make rom bar allocation in bridge non-pref range.
 patch: rom_no_pref.patch
Looks like BIOS and at least one of other OSes is doing that.

I can not find the the history why ROM res is with PREFETCH bit set.
Maybe Linus has some idea about that.

3. use pci_bus_allocate_resource in drm/radeon driver ... === but
that could fail.
   so could hack it like a. disable bar 0x10 and steal BAR address,
then set 0x30 to that address then copy ROM to ram.
   after that, disable rom again and set back address to 0x10.
   You try to update radeon_get_bios() to achieve that.

  Yinghai


rom_pref.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Yinghai Lu]

On Sun, Apr 15, 2012 at 1:05 PM, Yinghai Lu ying...@kernel.org wrote:
 On Sun, Apr 15, 2012 at 10:31 AM, Steven Newbury st...@snewbury.org.uk 
 wrote:

 pci :03:08.0: BAR 15: can't assign mem pref (size
 0x1800)
 Ah! Not enough space for the bridge window!:(


 please append pci=norom ...

 That worked.  Except of course the radeon driver can't POST the
  card without the ROM! :-P
 Can the ROM resource be mapped above 4G?
 I didn't really think that through, obviously it can't because
 it's not on a 64-bit capable bridge.  I wonder though, could it be
 shadowed then disabled early before the IOMEM?
 I see there's #if 0'd helper functions for exactly that in rom.c.
 They've been disabled since 2007!

 solution could be one of three:
 1. when bridge support 64bit pref, will not allocate rom bar in bridge
 pref resource.
  patch: rom_pref.patch

 2. unconditionally to make rom bar allocation in bridge non-pref range.
  patch: rom_no_pref.patch

missed attach rom_no_pref.patch

 Looks like BIOS and at least one of other OSes is doing that.

 I can not find the the history why ROM res is with PREFETCH bit set.
 Maybe Linus has some idea about that.

 3. use pci_bus_allocate_resource in drm/radeon driver ... === but
 that could fail.
   so could hack it like a. disable bar 0x10 and steal BAR address,
 then set 0x30 to that address then copy ROM to ram.
   after that, disable rom again and set back address to 0x10.
   You try to update radeon_get_bios() to achieve that.

      Yinghai


rom_no_pref.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Yinghai Lu]

On Sat, Apr 14, 2012 at 10:37 AM, Steven Newbury  
wrote:
> I've created a new quirk utilising an extra PCI resource flag to force
> reallocation of the resource. ?It's the first approach I've had any
> success at. ?It does work. ?Only "Intel Page Flush" now gets allocated
> @0xe000!

Maybe we can be more aggressive with pci=pref_bar to reassign all pref mem.

Please check attached patch.

Yinghai
-- next part --
A non-text attachment was scrubbed...
Name: pci_assign_pref.patch
Type: application/octet-stream
Size: 2357 bytes
Desc: not available
URL: 

PCI resources above 4GB

[Yinghai Lu]

On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury  
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 14/04/12 20:08, Steven Newbury wrote:
>> On 14/04/12 19:42, Steven Newbury wrote:
>>> On 14/04/12 19:05, Steven Newbury wrote:
>>>> On 14/04/12 18:37, Steven Newbury wrote:
>>>>> On 12/04/12 17:40, Steven Newbury wrote:
>>>>>> On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu
>>>>>>  wrote:
>>
>>>>>>> On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury
>>>>>>>  wrote:
>>>>>>>> Thanks, that fixed it! :) I had a similar patch I've
>>>>>>>> been working on but I had my fix in the wrong place!
>>>>>>>>
>>>>>>>> In the working case, initially the BIOS has set GMA to
>>>>>>>> ?within the low system DRAM 0xC000 obviously
>>>>>>>> invalid. This conflict is detected and it's
>>>>>>>> relallocated to 0x1200.
>>>>>>>>
>>>>>>>> I've attempted to modify probe.c to disable 64-bit
>>>>>>>> BARs not allocated above 4G so they get reallocated
>>>>>>>> above when possible later. ?It seemed to work, but
>>>>>>>> again broke GMA despite the BAR originally containing
>>>>>>>> an invalid address as mentioned above, it seems for
>>>>>>>> some reason something is different when the conflict is
>>>>>>>> detected and rellocated, compared to disabling it early
>>>>>>>> then allocating a valid value..?
>>>>>>>>
>>>>> I've created a new quirk utilising an extra PCI resource
>>>>> flag to force reallocation of the resource. ?It's the first
>>>>> approach I've had any success at. ?It does work. ?Only
>>>>> "Intel Page Flush" now gets allocated @0xe000!
>>
>>
>>>> Hopefully this should fix "Intel Flush Page"
>>> Need to export pci_bus_alloc_resource_fit for intel-gtt.
>> Nearly worked... Or at least it should have worked, but for some
>> reason the allocator failed to utilise 0xe000-0xefff for
>> 04:00.0 BAR0..?
>>
>>
>> pci :03:08.0: BAR 15: can't assign mem pref (size 0x1800)
> Ah! Not enough space for the bridge window!:(
>

please append pci=norom ...

Yinghai

Re: PCI resources above 4GB

[Yinghai Lu]

On Sat, Apr 14, 2012 at 12:21 PM, Steven Newbury st...@snewbury.org.uk wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 14/04/12 20:08, Steven Newbury wrote:
 On 14/04/12 19:42, Steven Newbury wrote:
 On 14/04/12 19:05, Steven Newbury wrote:
 On 14/04/12 18:37, Steven Newbury wrote:
 On 12/04/12 17:40, Steven Newbury wrote:
 On Thu, 12 Apr 2012, 17:07:33 BST, Yinghai Lu
 ying...@kernel.org wrote:

 On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury
 st...@snewbury.org.uk wrote:
 Thanks, that fixed it! :) I had a similar patch I've
 been working on but I had my fix in the wrong place!

 In the working case, initially the BIOS has set GMA to
  within the low system DRAM 0xC000 obviously
 invalid. This conflict is detected and it's
 relallocated to 0x1200.

 I've attempted to modify probe.c to disable 64-bit
 BARs not allocated above 4G so they get reallocated
 above when possible later.  It seemed to work, but
 again broke GMA despite the BAR originally containing
 an invalid address as mentioned above, it seems for
 some reason something is different when the conflict is
 detected and rellocated, compared to disabling it early
 then allocating a valid value..?

 I've created a new quirk utilising an extra PCI resource
 flag to force reallocation of the resource.  It's the first
 approach I've had any success at.  It does work.  Only
 Intel Page Flush now gets allocated @0xe000!


 Hopefully this should fix Intel Flush Page
 Need to export pci_bus_alloc_resource_fit for intel-gtt.
 Nearly worked... Or at least it should have worked, but for some
 reason the allocator failed to utilise 0xe000-0xefff for
 04:00.0 BAR0..?


 pci :03:08.0: BAR 15: can't assign mem pref (size 0x1800)
 Ah! Not enough space for the bridge window!:(


please append pci=norom ...

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PCI resources above 4GB

[Yinghai Lu]

On Sat, Apr 14, 2012 at 10:37 AM, Steven Newbury st...@snewbury.org.uk wrote:
 I've created a new quirk utilising an extra PCI resource flag to force
 reallocation of the resource.  It's the first approach I've had any
 success at.  It does work.  Only Intel Page Flush now gets allocated
 @0xe000!

Maybe we can be more aggressive with pci=pref_bar to reassign all pref mem.

Please check attached patch.

Yinghai


pci_assign_pref.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Yinghai Lu]

>> Looks like either a btrfs regression or bad interaction with
>> for-pci-res-alloc. ?Oops attached.
> Just hit the same oops on the rc1+for-pci-res-alloc kernel I tried
> earlier so it's not definitely something new in the btrfs code. ?Seems
> like it's a 64/32bit pointer issue??

for-pci-res-alloc include

for-pci-hostbridge-cleanup
for-pci-busn-alloc
for-pci-root-bus-hotplug
for-pci-for-each-res-addon
at plus 7 patches.

maybe there is some problem with for-pci-for-each-res-addon.

just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please
check if the problem still there.

Thanks

Yinghai

PCI resources above 4GB

[Yinghai Lu]

On Thu, Apr 12, 2012 at 9:40 AM, Steven Newbury  
wrote:
>> >
>> > It would be useful to preserve as much low PCI memory address space as
>> > possible for hotplug devices (like my Radeon), but the other problem
>> > is small regions get allocated at the bottom, resulting in the
>> > inability to find large aligned regions later on. ?I see code to
>> > default to top-down allocation was reverted, I guess I'm going to have
>> > to dig into the archive to find out why...

Please check attached patches that will find_resource with fit. It may
leave space for your hotplug devices.

  PCI: Should add children device res to fail list
  PCI: Try to allocate mem64 above 4G at first
  intel-gtt: Read 64bit for gmar_bus_addr
  PCI: Make sure assign same align with large size resource at first
  resource: make find_resource could return just fit resource
  PCI: Don't allocate small resource in big empty space.
  resource: only return range with needed align

You can get them from

   git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
for-pci-res-alloc

Thanks

Yinghai
-- next part --
A non-text attachment was scrubbed...
Name: assign_sorting.patch
Type: application/octet-stream
Size: 1259 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: find_one_just_fit_1.patch
Type: application/octet-stream
Size: 2803 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: find_one_just_fit_2.patch
Type: application/octet-stream
Size: 11856 bytes
Desc: not available
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: save_big_align.patch
Type: application/octet-stream
Size: 1096 bytes
Desc: not available
URL: 

Re: drm-next i915 regression? ( was: Re: PCI resources above 4GB)

[Yinghai Lu]

 Looks like either a btrfs regression or bad interaction with
 for-pci-res-alloc.  Oops attached.
 Just hit the same oops on the rc1+for-pci-res-alloc kernel I tried
 earlier so it's not definitely something new in the btrfs code.  Seems
 like it's a 64/32bit pointer issue??

for-pci-res-alloc include

for-pci-hostbridge-cleanup
for-pci-busn-alloc
for-pci-root-bus-hotplug
for-pci-for-each-res-addon
at plus 7 patches.

maybe there is some problem with for-pci-for-each-res-addon.

just rebase for-pci-res-alloc to for-pci-root-bus-hotplug. Please
check if the problem still there.

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Yinghai Lu]

On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury  
wrote:
> Thanks, that fixed it! :) I had a similar patch I've been working on but I 
> had my fix in the wrong place!
>
> In the working case, initially the BIOS has set GMA to within the low system 
> DRAM 0xC000 obviously invalid. ?This conflict is detected and it's 
> relallocated to 0x1200.
>
> I've attempted to modify probe.c to disable 64-bit BARs not allocated above 
> 4G so they get reallocated above when possible later. ?It seemed to work, but 
> again broke GMA despite the BAR originally containing an invalid address as 
> mentioned above, it seems for some reason something is different when the 
> conflict is detected and rellocated, compared to disabling it early then 
> allocating a valid value..?
>
> It would be useful to preserve as much low PCI memory address space as 
> possible for hotplug devices (like my Radeon), but the other problem is small 
> regions get allocated at the bottom, resulting in the inability to find large 
> aligned regions later on. ?I see code to default to top-down allocation was 
> reverted, I guess I'm going to have to dig into the archive to find out why...

for hotplug case, You can work around like:
after hotplug add,
1. use lspci and /proc/iomem to find out offending device and bridge.
2. use /sys/.../unbind etc to stop driver for those devices.
3. use setpci to clear related BAR
4. use /sys/devices/pci000/remove to remove those devices
5. echo 1 > /sys/bus/pci/rescan

then it should work...

Yinghai

Re: PCI resources above 4GB

[Yinghai Lu]

On Thu, Apr 12, 2012 at 4:22 AM, Steven Newbury st...@snewbury.org.uk wrote:
 Thanks, that fixed it! :) I had a similar patch I've been working on but I 
 had my fix in the wrong place!

 In the working case, initially the BIOS has set GMA to within the low system 
 DRAM 0xC000 obviously invalid.  This conflict is detected and it's 
 relallocated to 0x1200.

 I've attempted to modify probe.c to disable 64-bit BARs not allocated above 
 4G so they get reallocated above when possible later.  It seemed to work, but 
 again broke GMA despite the BAR originally containing an invalid address as 
 mentioned above, it seems for some reason something is different when the 
 conflict is detected and rellocated, compared to disabling it early then 
 allocating a valid value..?

 It would be useful to preserve as much low PCI memory address space as 
 possible for hotplug devices (like my Radeon), but the other problem is small 
 regions get allocated at the bottom, resulting in the inability to find large 
 aligned regions later on.  I see code to default to top-down allocation was 
 reverted, I guess I'm going to have to dig into the archive to find out why...

for hotplug case, You can work around like:
after hotplug add,
1. use lspci and /proc/iomem to find out offending device and bridge.
2. use /sys/.../unbind etc to stop driver for those devices.
3. use setpci to clear related BAR
4. use /sys/devices/pci000/remove to remove those devices
5. echo 1  /sys/bus/pci/rescan

then it should work...

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

PCI resources above 4GB

[Yinghai Lu]

On Tue, Apr 10, 2012 at 2:19 PM, Steven Newbury  
wrote:
> Another thought, normally the integrated graphics has an "AGP"
> aperture of 256M @0xe000, which is detected by agpgart-intel, this
> will need to be moved up above 4G to free up 0xe000 for the
> radeon, assuming the "agp_bridge" has a 64bit base register... ?I
> noticed in my docked dmesg, "AGP aperture is 256M @ 0x2000", but
> the PCI base: "12000-12fff : :00:02.0" so only 32bits have
> been set in agpgart-intel. ?Explains why i915 wasn't initialised.

Attached patch should fix that high 32bit missing problem.

Yinghai
-- next part --
A non-text attachment was scrubbed...
Name: fix_i915_gma_bus_addr.patch
Type: application/octet-stream
Size: 1216 bytes
Desc: not available
URL: 

Re: PCI resources above 4GB

[Yinghai Lu]

On Tue, Apr 10, 2012 at 2:19 PM, Steven Newbury st...@snewbury.org.uk wrote:
 Another thought, normally the integrated graphics has an AGP
 aperture of 256M @0xe000, which is detected by agpgart-intel, this
 will need to be moved up above 4G to free up 0xe000 for the
 radeon, assuming the agp_bridge has a 64bit base register...  I
 noticed in my docked dmesg, AGP aperture is 256M @ 0x2000, but
 the PCI base: 12000-12fff : :00:02.0 so only 32bits have
 been set in agpgart-intel.  Explains why i915 wasn't initialised.

Attached patch should fix that high 32bit missing problem.

Yinghai


fix_i915_gma_bus_addr.patch
Description: Binary data
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Linux 2.6.39-rc3

[Yinghai Lu]

On 04/15/2011 12:06 PM, Ingo Molnar wrote:

> 
> Joerg, mind submitting it with a changelog that includes everything we 
> learned 
> about this bug and all the Tested-by's in place?
> 
> Is anyone of the opinion that we should try to revert the allocation 
> order/alignment changes in addition to this fix?

We should figure out what is written to 0xa0001000 (main memory) by GPU before 
internal GART is setup.

Joerg,
can you insert some dump code in the drm/radon code to find out which function 
cause the problem?

Thanks

Yinghai

Re: Linux 2.6.39-rc3

[Yinghai Lu]

On 04/15/2011 12:06 PM, Ingo Molnar wrote:

 
 Joerg, mind submitting it with a changelog that includes everything we 
 learned 
 about this bug and all the Tested-by's in place?
 
 Is anyone of the opinion that we should try to revert the allocation 
 order/alignment changes in addition to this fix?

We should figure out what is written to 0xa0001000 (main memory) by GPU before 
internal GART is setup.

Joerg,
can you insert some dump code in the drm/radon code to find out which function 
cause the problem?

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Linux 2.6.39-rc3

[Yinghai Lu]

On 04/13/2011 04:39 PM, Linus Torvalds wrote:
> On Wed, Apr 13, 2011 at 2:23 PM, Yinghai Lu  wrote:
>>>
>>> What are all the magic numbers, and why would 0x8000 be special?
>>
>> that is the old value when kernel was doing bottom-up bootmem allocation.
> 
> I understand, BUT THAT IS STILL A TOTALLY MAGIC NUMBER!
> 
> It makes it come out the same ON THAT ONE MACHINE.  So no, it's not
> "the old value". It's a random value that gets the old value in one
> specific case.

Alexandre's system is working 2.6.38.2 and kernel allocate from 0xa400
Joerg's system working 2.6.39-rc3 while revert the top down bootmem patch 
1a4a678b12c84db9ae5dce424e0e97f0559bb57c
and kernel allocate to 0x8000.
Alexandre's system is working while increasing alignment to 1g, and make kernel 
to
allocate 0x8000 to gart.

they are not working if kernel allocate from 0xa000

the 0xa000 looks like same value from radon GTT.


[4.250159] radeon :01:05.0: VRAM: 320M 0xC000 - 
0xD3FF (320M used)
[4.258830] radeon :01:05.0: GTT: 512M 0xA000 - 
0xBFFF
[4.266742] [drm] Detected VRAM RAM=320M, BAR=256M
[4.271549] [drm] RAM width 32bits DDR
[4.275435] [TTM] Zone  kernel: Available graphics memory: 1896526 kiB.
[4.282066] [TTM] Initializing pool allocator.
[4.282085] usb 7-2: new full speed USB device number 2 using ohci_hcd
[4.293076] [drm] radeon: 320M of VRAM memory ready
[4.298277] [drm] radeon: 512M of GTT memory ready.
[4.303218] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[4.309854] [drm] Driver supports precise vblank timestamp query.
[4.315970] [drm] radeon: irq initialized.
[4.320094] [drm] GART: num cpu pages 131072, num gpu pages 131072

Alex said that 0xa000 is ok and is from GPU address space
---
The VRAM and GTT addresses in the dmesg are internal GPU addresses not
system addresses.  The GPU has it's own internal address space for
on-chip memory clients (texture samplers, render buffers, display
controllers, etc.).  The GPU sets up two apertures in it's internal
address space and on-chip client requests are forwarded to the
appropriate place by the GPU's memory controller.  Addresses in the
GPU's VRAM aperture go to local vram on discrete cards, or to the
stolen memory at the top of system memory for IGP cards.  Addresses in
the GPU's GTT aperture hit a page table and get forwarded to the
appropriate dma pages.
---

> 
>>> Why don't we write code that just works?
>>>
>>> Or absent a "just works" set of patches, why don't we revert to code
>>> that has years of testing?
>>>
>>> This kind of "I broke things, so now I will jiggle things randomly
>>> until they unbreak" is not acceptable.
>>>
>>> Either explain why that fixes a real BUG (and why the magic constants
>>> need to be what they are), or just revert the patch that caused the
>>> problem, and go back to the allocation patters that have years of
>>> experience.
>>>
>>> Guys, we've had this discussion before, in PCI allocation. We don't do
>>> this. We tried switching the PCI region allocations to top-down, and
>>> IT WAS A FAILURE. We reverted it to what we had years of testing with.
>>>
>>> Don't just make random changes. There really are only two acceptable
>>> models of development: "think and analyze" or "years and years of
>>> testing on thousands of machines". Those two really do work.
>>
>> We did do the analyzing, and only difference seems to be:
> 
> No.
> 
> Yinghai, we have had this discussion before, and dammit, you need to
> understand the difference between "understanding the problem" and "put
> in random values until it works on one machine".
> 
> There was absolutely _zero_ analysis done. You do not actually
> understand WHY the numbers matter. You just look at two random
> numbers, and one works, the other does not. That's not "analyzing".
> That's just "random number games".
> 
> If you cannot see and understand the difference between an actual
> analytical solution where you _understand_ what the code is doing and
> why, and "random numbers that happen to work on one machine", I don't
> know what to tell you.
> 
>> good one is using 0x8000
>> and bad one is using 0xa000.
>>
>> We try to figure out if it needs low address and it happen to work
>> because kernel was doing bottom up allocation.
> 
> No.
> 
> Let me repeat my point one more time.
> 
> You have TWO choices. Not more, not less:
> 
>  - choice #1: go back to the old allocation model

Linux 2.6.39-rc3

[Yinghai Lu]

On 04/13/2011 02:50 PM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
>> -addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
>> +addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
> 
> Btw, while looking at this code I wondered why the 512M goal is enforced
> by the alignment. Start could be set to 512M instead and the alignment
> can be aper_size as it should. Any reason for such a big alignment?
> 

when using bootmem, try to use big alignment (512M ), so we could avoid take 
ram range below 512M.

commit 7677b2ef6c0c4fddc84f6473f3863f40eb71821b
Author: Yinghai Lu 
Date:   Mon Apr 14 20:40:37 2008 -0700

x86_64: allocate gart aperture from 512M

because we try to reserve dma32 early, so we have chance to get aperture
from 64M.

with some sequence aperture allocated from RAM, could become E820_RESERVED.

and then if doing a kexec with a big kernel that uncompressed size is above
64M we could have a range conflict with still using gart.

So allocate gart aperture from 512M instead.

Also change the fallback_aper_order to 5, because we don't have chance to 
get
2G or 4G aperture.

We can change it back to 32M or make it equal to size.

> 
> P.S.: The box is still in the office, I will try this debug-patch
>   tomorrow.

Alexandre's system is working at 0xa400 with 2.6.38.2

So it is not low address problem. could be other reason like
some other code could need lower address.

Thanks

Yinghai

Linux 2.6.39-rc3

[Yinghai Lu]

On 04/13/2011 01:54 PM, Linus Torvalds wrote:
> On Wed, Apr 13, 2011 at 1:48 PM, Yinghai Lu  wrote:
>>
>> can you try following change ? it will push gart to 0x8000
>>
>> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
>> index 86d1ad4..3b6a9d5 100644
>> --- a/arch/x86/kernel/aperture_64.c
>> +++ b/arch/x86/kernel/aperture_64.c
>> @@ -83,7 +83,7 @@ static u32 __init allocate_aperture(void)
>> * so don't use 512M below as gart iommu, leave the space for kernel
>> * code for safe
>> */
>> -   addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
>> +   addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
> 
> What are all the magic numbers, and why would 0x8000 be special?

that is the old value when kernel was doing bottom-up bootmem allocation.

> 
> Why don't we write code that just works?
> 
> Or absent a "just works" set of patches, why don't we revert to code
> that has years of testing?
> 
> This kind of "I broke things, so now I will jiggle things randomly
> until they unbreak" is not acceptable.
> 
> Either explain why that fixes a real BUG (and why the magic constants
> need to be what they are), or just revert the patch that caused the
> problem, and go back to the allocation patters that have years of
> experience.
> 
> Guys, we've had this discussion before, in PCI allocation. We don't do
> this. We tried switching the PCI region allocations to top-down, and
> IT WAS A FAILURE. We reverted it to what we had years of testing with.
> 
> Don't just make random changes. There really are only two acceptable
> models of development: "think and analyze" or "years and years of
> testing on thousands of machines". Those two really do work.

We did do the analyzing, and only difference seems to be:
good one is using 0x8000
and bad one is using 0xa000.

We try to figure out if it needs low address and it happen to work 
because kernel was doing bottom up allocation.

Thanks

Yinghai

Linux 2.6.39-rc3

[Yinghai Lu]

On 04/13/2011 12:34 PM, Joerg Roedel wrote:
> On Wed, Apr 13, 2011 at 12:14:55PM -0700, Yinghai Lu wrote:
>> thanks for the bisecting...
>>
>> so those two patches uncover some problems.
>>
>> [0.00] Checking aperture...
>> [0.00] No AGP bridge found
>> [0.00] Node 0: aperture @ a000 size 32 MB
>> [0.00] Aperture pointing to e820 RAM. Ignoring.
>> [0.00] Your BIOS doesn't leave a aperture memory hole
>> [0.00] Please enable the IOMMU option in the BIOS setup
>> [0.00] This costs you 64 MB of RAM
>> [0.00] memblock_x86_reserve_range: [0xa000-0xa3ff]   
>> aperture64
>> [0.00] Mapping aperture over 65536 KB of RAM @ a000
>>
>> so kernel try to reallocate apperture. because BIOS allocated is pointed to 
>> RAM or size is too small.
> 
> It is actually beyond 4GB on that machine, this value read here is from
> the previous kernel-boot. The BIOS does not reset these values on a
> reboot.
> 
>> but your radeon does use [0xa000, 0xbfff)
> 
> Yes, I suspected that too (and spent a few hours reading radeon code),
> but then I talked the Alex Deucher and he explained that these addresses
> which the driver prints for GTT and VRAM are in the GPU address space
> and do not refer to system ram. So this shouldn't be the problem.


can you try following change ? it will push gart to 0x8000

diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index 86d1ad4..3b6a9d5 100644
--- a/arch/x86/kernel/aperture_64.c
+++ b/arch/x86/kernel/aperture_64.c
@@ -83,7 +83,7 @@ static u32 __init allocate_aperture(void)
 * so don't use 512M below as gart iommu, leave the space for kernel
 * code for safe
 */
-   addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<20);
+   addr = memblock_find_in_range(0, 1ULL<<32, aper_size, 512ULL<<21);
if (addr == MEMBLOCK_ERROR || addr + aper_size > 0x) {
printk(KERN_ERR
"Cannot allocate aperture memory hole (%lx,%uK)\n",

Linux 2.6.39-rc3

[Yinghai Lu]

e)
[0.00]  BIOS-e820: afd4f000 - afdcf000 (reserved)
[0.00]  BIOS-e820: afdcf000 - afecf000 (ACPI NVS)
[0.00]  BIOS-e820: afecf000 - afeff000 (ACPI data)
[0.00]  BIOS-e820: afeff000 - aff0 (usable)


so looks bios program wrong address to the radon card?

Thanks

Yinghai Lu

Re: Linux 2.6.39-rc3

[Yinghai Lu]

)
[0.00]  BIOS-e820: afecf000 - afeff000 (ACPI data)
[0.00]  BIOS-e820: afeff000 - aff0 (usable)


so looks bios program wrong address to the radon card?

Thanks

Yinghai Lu
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Yinghai Lu]

On 04/13/2011 12:34 PM, Joerg Roedel wrote:
 On Wed, Apr 13, 2011 at 12:14:55PM -0700, Yinghai Lu wrote:
 thanks for the bisecting...

 so those two patches uncover some problems.

 [0.00] Checking aperture...
 [0.00] No AGP bridge found
 [0.00] Node 0: aperture @ a000 size 32 MB
 [0.00] Aperture pointing to e820 RAM. Ignoring.
 [0.00] Your BIOS doesn't leave a aperture memory hole
 [0.00] Please enable the IOMMU option in the BIOS setup
 [0.00] This costs you 64 MB of RAM
 [0.00] memblock_x86_reserve_range: [0xa000-0xa3ff]   
 aperture64
 [0.00] Mapping aperture over 65536 KB of RAM @ a000

 so kernel try to reallocate apperture. because BIOS allocated is pointed to 
 RAM or size is too small.
 
 It is actually beyond 4GB on that machine, this value read here is from
 the previous kernel-boot. The BIOS does not reset these values on a
 reboot.
 
 but your radeon does use [0xa000, 0xbfff)
 
 Yes, I suspected that too (and spent a few hours reading radeon code),
 but then I talked the Alex Deucher and he explained that these addresses
 which the driver prints for GTT and VRAM are in the GPU address space
 and do not refer to system ram. So this shouldn't be the problem.


can you try following change ? it will push gart to 0x8000

diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index 86d1ad4..3b6a9d5 100644
--- a/arch/x86/kernel/aperture_64.c
+++ b/arch/x86/kernel/aperture_64.c
@@ -83,7 +83,7 @@ static u32 __init allocate_aperture(void)
 * so don't use 512M below as gart iommu, leave the space for kernel
 * code for safe
 */
-   addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL20);
+   addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL21);
if (addr == MEMBLOCK_ERROR || addr + aper_size  0x) {
printk(KERN_ERR
Cannot allocate aperture memory hole (%lx,%uK)\n,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Yinghai Lu]

On 04/13/2011 01:54 PM, Linus Torvalds wrote:
 On Wed, Apr 13, 2011 at 1:48 PM, Yinghai Lu ying...@kernel.org wrote:

 can you try following change ? it will push gart to 0x8000

 diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
 index 86d1ad4..3b6a9d5 100644
 --- a/arch/x86/kernel/aperture_64.c
 +++ b/arch/x86/kernel/aperture_64.c
 @@ -83,7 +83,7 @@ static u32 __init allocate_aperture(void)
 * so don't use 512M below as gart iommu, leave the space for kernel
 * code for safe
 */
 -   addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL20);
 +   addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL21);
 
 What are all the magic numbers, and why would 0x8000 be special?

that is the old value when kernel was doing bottom-up bootmem allocation.

 
 Why don't we write code that just works?
 
 Or absent a just works set of patches, why don't we revert to code
 that has years of testing?
 
 This kind of I broke things, so now I will jiggle things randomly
 until they unbreak is not acceptable.
 
 Either explain why that fixes a real BUG (and why the magic constants
 need to be what they are), or just revert the patch that caused the
 problem, and go back to the allocation patters that have years of
 experience.
 
 Guys, we've had this discussion before, in PCI allocation. We don't do
 this. We tried switching the PCI region allocations to top-down, and
 IT WAS A FAILURE. We reverted it to what we had years of testing with.
 
 Don't just make random changes. There really are only two acceptable
 models of development: think and analyze or years and years of
 testing on thousands of machines. Those two really do work.

We did do the analyzing, and only difference seems to be:
good one is using 0x8000
and bad one is using 0xa000.

We try to figure out if it needs low address and it happen to work 
because kernel was doing bottom up allocation.

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Yinghai Lu]

On 04/13/2011 02:50 PM, Joerg Roedel wrote:
 On Wed, Apr 13, 2011 at 01:48:48PM -0700, Yinghai Lu wrote:
 -addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL20);
 +addr = memblock_find_in_range(0, 1ULL32, aper_size, 512ULL21);
 
 Btw, while looking at this code I wondered why the 512M goal is enforced
 by the alignment. Start could be set to 512M instead and the alignment
 can be aper_size as it should. Any reason for such a big alignment?
 

when using bootmem, try to use big alignment (512M ), so we could avoid take 
ram range below 512M.

commit 7677b2ef6c0c4fddc84f6473f3863f40eb71821b
Author: Yinghai Lu yhlu.kernel.s...@gmail.com
Date:   Mon Apr 14 20:40:37 2008 -0700

x86_64: allocate gart aperture from 512M

because we try to reserve dma32 early, so we have chance to get aperture
from 64M.

with some sequence aperture allocated from RAM, could become E820_RESERVED.

and then if doing a kexec with a big kernel that uncompressed size is above
64M we could have a range conflict with still using gart.

So allocate gart aperture from 512M instead.

Also change the fallback_aper_order to 5, because we don't have chance to 
get
2G or 4G aperture.

We can change it back to 32M or make it equal to size.

 
 P.S.: The box is still in the office, I will try this debug-patch
   tomorrow.

Alexandre's system is working at 0xa400 with 2.6.38.2

So it is not low address problem. could be other reason like
some other code could need lower address.

Thanks

Yinghai
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: Linux 2.6.39-rc3

[Yinghai Lu]

On 04/13/2011 04:39 PM, Linus Torvalds wrote:
 On Wed, Apr 13, 2011 at 2:23 PM, Yinghai Lu ying...@kernel.org wrote:

 What are all the magic numbers, and why would 0x8000 be special?

 that is the old value when kernel was doing bottom-up bootmem allocation.
 
 I understand, BUT THAT IS STILL A TOTALLY MAGIC NUMBER!
 
 It makes it come out the same ON THAT ONE MACHINE.  So no, it's not
 the old value. It's a random value that gets the old value in one
 specific case.

Alexandre's system is working 2.6.38.2 and kernel allocate from 0xa400
Joerg's system working 2.6.39-rc3 while revert the top down bootmem patch 
1a4a678b12c84db9ae5dce424e0e97f0559bb57c
and kernel allocate to 0x8000.
Alexandre's system is working while increasing alignment to 1g, and make kernel 
to
allocate 0x8000 to gart.

they are not working if kernel allocate from 0xa000

the 0xa000 looks like same value from radon GTT.


[4.250159] radeon :01:05.0: VRAM: 320M 0xC000 - 
0xD3FF (320M used)
[4.258830] radeon :01:05.0: GTT: 512M 0xA000 - 
0xBFFF
[4.266742] [drm] Detected VRAM RAM=320M, BAR=256M
[4.271549] [drm] RAM width 32bits DDR
[4.275435] [TTM] Zone  kernel: Available graphics memory: 1896526 kiB.
[4.282066] [TTM] Initializing pool allocator.
[4.282085] usb 7-2: new full speed USB device number 2 using ohci_hcd
[4.293076] [drm] radeon: 320M of VRAM memory ready
[4.298277] [drm] radeon: 512M of GTT memory ready.
[4.303218] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[4.309854] [drm] Driver supports precise vblank timestamp query.
[4.315970] [drm] radeon: irq initialized.
[4.320094] [drm] GART: num cpu pages 131072, num gpu pages 131072

Alex said that 0xa000 is ok and is from GPU address space
---
The VRAM and GTT addresses in the dmesg are internal GPU addresses not
system addresses.  The GPU has it's own internal address space for
on-chip memory clients (texture samplers, render buffers, display
controllers, etc.).  The GPU sets up two apertures in it's internal
address space and on-chip client requests are forwarded to the
appropriate place by the GPU's memory controller.  Addresses in the
GPU's VRAM aperture go to local vram on discrete cards, or to the
stolen memory at the top of system memory for IGP cards.  Addresses in
the GPU's GTT aperture hit a page table and get forwarded to the
appropriate dma pages.
---

 
 Why don't we write code that just works?

 Or absent a just works set of patches, why don't we revert to code
 that has years of testing?

 This kind of I broke things, so now I will jiggle things randomly
 until they unbreak is not acceptable.

 Either explain why that fixes a real BUG (and why the magic constants
 need to be what they are), or just revert the patch that caused the
 problem, and go back to the allocation patters that have years of
 experience.

 Guys, we've had this discussion before, in PCI allocation. We don't do
 this. We tried switching the PCI region allocations to top-down, and
 IT WAS A FAILURE. We reverted it to what we had years of testing with.

 Don't just make random changes. There really are only two acceptable
 models of development: think and analyze or years and years of
 testing on thousands of machines. Those two really do work.

 We did do the analyzing, and only difference seems to be:
 
 No.
 
 Yinghai, we have had this discussion before, and dammit, you need to
 understand the difference between understanding the problem and put
 in random values until it works on one machine.
 
 There was absolutely _zero_ analysis done. You do not actually
 understand WHY the numbers matter. You just look at two random
 numbers, and one works, the other does not. That's not analyzing.
 That's just random number games.
 
 If you cannot see and understand the difference between an actual
 analytical solution where you _understand_ what the code is doing and
 why, and random numbers that happen to work on one machine, I don't
 know what to tell you.
 
 good one is using 0x8000
 and bad one is using 0xa000.

 We try to figure out if it needs low address and it happen to work
 because kernel was doing bottom up allocation.
 
 No.
 
 Let me repeat my point one more time.
 
 You have TWO choices. Not more, not less:
 
  - choice #1: go back to the old allocation model. It's tested. It
 doesn't regress. Admittedly we may not know exactly _why_ it works,
 and it might not work on all machines, but it doesn't cause
 regressions (ie the machines it doesn't work on it _never_ worked on).
 
And this doesn't mean old value for that _one_ machine. It means
 old value for _every_ machine. So it means we revert the whole
 bottom-down thing entirely. Not just change one random number so that
 the totally different allocation pattern happens to give the same
 result on one particular machine.
 
Quite frankly, I don't see the point of doing