pci: Treat all PCI bus addresses as 64-bit

PATCH New Kumar Gala 3 participants 8 messages Oct 21, 2008 PCI

Share & tools

Kumar Gala

author

2008-10-21 14:15 UTC #0 lore raw

PATCH 1/1 pci: Treat all PCI bus addresses as 64-bit

PCI bus is inherently 64-bit. We should treat all PCI related bus addresses as 64-bit quanities. This allows us to have the ability to support devices or memory on the PCI bus above the 32-bit boundary.

Signed-off-by Kumar Gala <[email protected]>

---
 drivers/pci/pci.c      |    4 ++--
 drivers/pci/pci_auto.c |   10 +++++-----
 include/pci.h          |   16 ++++++++--------
 3 files changed, 15 insertions(+), 15 deletions(-)

drivers/pci/pci.c +2 -2

index 41780db..253e1f5 100644
@@ -223,7 +223,7 @@ unsigned long pci_hose_phys_to_bus (struct pci_controller *hose,
 				    unsigned long flags)
 {
 	struct pci_region *res;
-	unsigned long bus_addr;
+	u64 bus_addr;
 	int i;
 
 	if (!hose) {

@@ -252,7 +252,7 @@ Done:
 }
 
 phys_addr_t pci_hose_bus_to_phys(struct pci_controller* hose,
-				 unsigned long bus_addr,
+				 u64 bus_addr,
 				 unsigned long flags)
 {
 	struct pci_region *res;

drivers/pci/pci_auto.c +5 -5

index 3844359..ea362a9 100644
@@ -52,7 +52,7 @@ void pciauto_region_align(struct pci_region *res, unsigned long size)
 
 int pciauto_region_allocate(struct pci_region* res, unsigned int size, unsigned int *bar)
 {
-	unsigned long addr;
+	u64 addr;
 
 	if (!res) {
 		DEBUGF("No resource");

@@ -68,7 +68,7 @@ int pciauto_region_allocate(struct pci_region* res, unsigned int size, unsigned
 
 	res->bus_lower = addr + size;
 
-	DEBUGF("address=0x%lx bus_lower=%x", addr, res->bus_lower);
+	DEBUGF("address=0x%llx bus_lower=%llx", addr, res->bus_lower);
 
 	*bar = addr;
 	return 0;

@@ -289,7 +289,7 @@ void pciauto_config_init(struct pci_controller *hose)
 	if (hose->pci_mem) {
 		pciauto_region_init(hose->pci_mem);
 
-		DEBUGF("PCI Autoconfig: Bus Memory region: [%lx-%lx],\n"
+		DEBUGF("PCI Autoconfig: Bus Memory region: [%llx-%llx],\n"
 		       "\t\tPhysical Memory [%x-%x]\n",
 		    hose->pci_mem->bus_start,
 		    hose->pci_mem->bus_start + hose->pci_mem->size - 1,

@@ -300,7 +300,7 @@ void pciauto_config_init(struct pci_controller *hose)
 	if (hose->pci_prefetch) {
 		pciauto_region_init(hose->pci_prefetch);
 
-		DEBUGF("PCI Autoconfig: Bus Prefetchable Mem: [%lx-%lx],\n"
+		DEBUGF("PCI Autoconfig: Bus Prefetchable Mem: [%llx-%llx],\n"
 		       "\t\tPhysical Memory [%x-%x]\n",
 		    hose->pci_prefetch->bus_start,
 		    hose->pci_prefetch->bus_start + hose->pci_prefetch->size - 1,

@@ -312,7 +312,7 @@ void pciauto_config_init(struct pci_controller *hose)
 	if (hose->pci_io) {
 		pciauto_region_init(hose->pci_io);
 
-		DEBUGF("PCI Autoconfig: Bus I/O region: [%lx-%lx],\n"
+		DEBUGF("PCI Autoconfig: Bus I/O region: [%llx-%llx],\n"
 		       "\t\tPhysical Memory: [%x-%x]\n",
 		    hose->pci_io->bus_start,
 		    hose->pci_io->bus_start + hose->pci_io->size - 1,

include/pci.h +8 -8

index 1c8e216..2689640 100644
@@ -313,12 +313,12 @@
 #include <pci_ids.h>
 
 struct pci_region {
-	unsigned long bus_start;		/* Start on the bus */
-	phys_addr_t phys_start;			/* Start in physical address space */
-	unsigned long size;			/* Size */
-	unsigned long flags;			/* Resource flags */
+	u64 bus_start;		/* Start on the bus */
+	phys_addr_t phys_start;	/* Start in physical address space */
+	u64 size;		/* Size */
+	unsigned long flags;	/* Resource flags */
 
-	unsigned long bus_lower;
+	u64 bus_lower;
 };
 
 #define PCI_REGION_MEM		0x00000000	/* PCI memory space */

@@ -330,9 +330,9 @@ struct pci_region {
 #define PCI_REGION_RO		0x00000200	/* Read-only memory */
 
 extern __inline__ void pci_set_region(struct pci_region *reg,
-				      unsigned long bus_start,
+				      u64 bus_start,
 				      phys_addr_t phys_start,
-				      unsigned long size,
+				      u64 size,
 				      unsigned long flags) {
 	reg->bus_start	= bus_start;
 	reg->phys_start = phys_start;

@@ -433,7 +433,7 @@ extern __inline__ void pci_set_ops(struct pci_controller *hose,
 extern void pci_setup_indirect(struct pci_controller* hose, u32 cfg_addr, u32 cfg_data);
 
 extern phys_addr_t pci_hose_bus_to_phys(struct pci_controller* hose,
-					unsigned long addr, unsigned long flags);
+					u64 addr, unsigned long flags);
 extern unsigned long pci_hose_phys_to_bus(struct pci_controller* hose,
 					  phys_addr_t addr, unsigned long flags);

Signature · 1 line

1.5.5.1

Wolfgang Denk

2008-10-21 14:46 UTC #1 lore raw

PATCH 1/1 pci: Treat all PCI bus addresses as 64-bit

Dear Kumar Gala,

Quoted 3 lines · In message <[email protected]> you…

PCI bus is inherently 64-bit. We should treat all PCI related bus addresses as 64-bit quanities. This allows us to have the ability to support devices or memory on the PCI bus above the 32-bit boundary.

I don't think this is a good idea. There are pure 32 bit systems out there which will never use more than 32 bit for the PCI resources, so why load them with the additional memory size and execution time?

Should we not enable this only for such systems that actually need it?

Best regards,

Wolfgang Denk

Signature · 5 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Keep your eyes wide open before marriage, half shut afterwards.
                                                 -- Benjamin Franklin

Jerry Van Baren

2008-10-21 14:55 UTC #2 lore raw

PATCH 1/1 pci: Treat all PCI bus addresses as 64-bit

Quoted 11 lines · Wolfgang Denk

Dear Kumar Gala,
Quoted 3 lines · In message <[email protected]> you…
PCI bus is inherently 64-bit. We should treat all PCI related bus addresses as 64-bit quanities. This allows us to have the ability to support devices or memory on the PCI bus above the 32-bit boundary.
I don't think this is a good idea. There are pure 32 bit systems out there which will never use more than 32 bit for the PCI resources, so why load them with the additional memory size and execution time?

Quoted 5 lines

Should we not enable this only for such systems that actually need it?
Best regards,
Wolfgang Denk

Why would we not use phys_addr_t and phys_size_t for the PCI addresses?

Best regards,
gvb

Kumar Gala

author

2008-10-21 14:59 UTC #3 lore raw

PATCH 1/1 pci: Treat all PCI bus addresses as 64-bit

Quoted 16 lines · Jerry Van Baren

Quoted 7 lines · Wolfgang Denk
Dear Kumar Gala,
In message <[email protected]
Quoted 5 lines
you wrote:
PCI bus is inherently 64-bit. We should treat all PCI related bus addresses as 64-bit quanities. This allows us to have the ability to support devices or memory on the PCI bus above the 32-bit boundary.
Quoted 7 lines
I don't think this is a good idea. There are pure 32 bit systems out there which will never use more than 32 bit for the PCI resources, so why load them with the additional memory size and execution time? Should we not enable this only for such systems that actually need it?
Best regards,
Wolfgang Denk

Quoted 2 lines

Why would we not use phys_addr_t and phys_size_t for the PCI addresses?

Because they aren't coupled. I can reasonable want 64-bit PCI accessible on a pure 32-bit system.

If we want to do this we should introduce a pci_addr_t/pci_size_t.

- k

Wolfgang Denk

2008-10-21 15:03 UTC #4 lore raw

PATCH 1/1 pci: Treat all PCI bus addresses as 64-bit

In reply to Jerry Van Baren

Dear Jerry Van Baren,

Quoted 2 lines · In message <[email protected]> you wrote:

Quoted 2 lines
Should we not enable this only for such systems that actually need it?

...

Quoted 1 line

Why would we not use phys_addr_t and phys_size_t for the PCI addresses?

Good point.

Best regards,

Wolfgang Denk

Signature · 5 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A wise person makes his  own  decisions,  a  weak  one  obeys  public
opinion.                                           -- Chinese proverb

Kumar Gala

author

2008-10-21 15:00 UTC #5 lore raw

PATCH 1/1 pci: Treat all PCI bus addresses as 64-bit

In reply to Wolfgang Denk

Quoted 9 lines · Wolfgang Denk

Dear Kumar Gala,
In message <1224598531-2698-1-git-send-email-
Quoted 4 lines · galak at kernel.crashing.org> you wrote:
PCI bus is inherently 64-bit. We should treat all PCI related bus addresses as 64-bit quanities. This allows us to have the ability to support devices or memory on the PCI bus above the 32-bit boundary.

Quoted 5 lines

I don't think this is a good idea. There are pure 32 bit systems out there which will never use more than 32 bit for the PCI resources, so why load them with the additional memory size and execution time?
Should we not enable this only for such systems that actually need it?

We could, however it seems the impact is pretty small on those systems with pure 32-bit PCI. I think the different in testing etc may not be worth it:

text data bss dec hex filename

  350588	  44964	  41909	 437461	  6acd5	u-boot (32-bit pci structs)
  351100	  44964	  42349	 438413	  6b08d	u-boot (64-bit pci structs)
----------------------------------------------
     512       0     440     952     3b8

If this is desired to be configurable should I introduce a pci_addr_t/ pci_size_t? Coupling to phys_addr_t/phys_size_t doesn't make sense to me because its perfectly reasonable to have a 64-bit PCI device work in a 32-bit system.

- k

Wolfgang Denk

2008-10-21 15:06 UTC #6 lore raw

PATCH 1/1 pci: Treat all PCI bus addresses as 64-bit

Dear Kumar Gala,

Quoted 5 lines · In message <[email protected]> you wrote:

If this is desired to be configurable should I introduce a pci_addr_t/ pci_size_t? Coupling to phys_addr_t/phys_size_t doesn't make sense to me because its perfectly reasonable to have a 64-bit PCI device work in a 32-bit system.

I think using pci_addr_t/pci_size_t is the most reasonable
suggestion, then (but it may turn into fighting a lot of new warnings about incompatible types for one board or another).

Best regards,

Wolfgang Denk

Signature · 6 lines

DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Am I your nanny? The kernel is there to support  user  programs,  but
it's a _resource_ handler, not a baby feeder.     - Linus Torvalds in
      <[email protected]>

Kumar Gala

author

2008-10-21 15:29 UTC #7 lore raw

PATCH 1/1 pci: Treat all PCI bus addresses as 64-bit

Quoted 12 lines · Wolfgang Denk

Dear Kumar Gala,
In message <A16160A4-977E-48A0-83D1-
Quoted 7 lines · FBAB41E1C0B6 at kernel.crashing.org> you wrote:
If this is desired to be configurable should I introduce a pci_addr_t/
pci_size_t? Coupling to phys_addr_t/phys_size_t doesn't make sense to
me because its perfectly reasonable to have a 64-bit PCI device work in a 32-bit system.

Quoted 3 lines

I think using pci_addr_t/pci_size_t is the most reasonable
suggestion, then (but it may turn into fighting a lot of new warnings about incompatible types for one board or another).

Ok, I'll switch over to these types and post a new patch.

- k