[U-Boot] [PATCH 1/6] Fix incorrect comments in linker_lists.h

[U-Boot] [PATCH 1/6] Fix incorrect comments in linker_lists.h

[Bin Meng]

This corrects several typos in the comment block as well as some
indentions and nits in the linker_lists.h.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 include/linker_lists.h | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/include/linker_lists.h b/include/linker_lists.h
index b22d169..76898ab 100644
--- a/include/linker_lists.h
+++ b/include/linker_lists.h
@@ -83,7 +83,7 @@
  * global list name ("outer"); iterators for only a sub-list should use
  * the full sub-list name ("outer_2_inner").
  *
- *  Here is an example of the sections generated from a global list
+ * Here is an example of the sections generated from a global list
  * named "drivers", two sub-lists named "i2c" and "pci", and iterators
  * defined for the whole list and each sub-list:
  *
@@ -103,7 +103,7 @@
  */
 
 /**
- * ll_sym() - Access a linker-generated array entry
+ * llsym() - Access a linker-generated array entry
  * @_type:	Data type of the entry
  * @_name:	Name of the entry
  * @_list:	name of the list. Should contain only characters allowed
@@ -142,7 +142,7 @@
  *    the inner sections are present in the array.
  *
  * Example:
- * ll_entry_declare(struct my_sub_cmd, my_sub_cmd, cmd_sub, cmd.sub) = {
+ * ll_entry_declare(struct my_sub_cmd, my_sub_cmd, cmd_sub) = {
  *         .x = 3,
  *         .y = 4,
  * };
@@ -162,7 +162,7 @@
  * This is like ll_entry_declare() but creates multiple entries. It should
  * be assigned to an array.
  *
- * ll_entry_declare_list(struct my_sub_cmd, my_sub_cmd, cmd_sub, cmd.sub) = {
+ * ll_entry_declare_list(struct my_sub_cmd, my_sub_cmd, cmd_sub) = {
  *	{ .x = 3, .y = 4 },
  *	{ .x = 8, .y = 2 },
  *	{ .x = 1, .y = 7 }
@@ -222,7 +222,7 @@
  */
 #define ll_entry_end(_type, _list)					\
 ({									\
-	static char end[0] __aligned(4) __attribute__((unused,	\
+	static char end[0] __aligned(4) __attribute__((unused,		\
 		section(".u_boot_list_2_"#_list"_3")));			\
 	(_type *)&end;							\
 })
@@ -256,8 +256,8 @@
  * @_name:	Name of the entry
  * @_list:	Name of the list in which this entry is placed
  *
- * This function returns a pointer to a particular entry in LG-array
- * identified by the subsection of u_boot_list where the entry resides
+ * This function returns a pointer to a particular entry in linker-generated
+ * array identified by the subsection of u_boot_list where the entry resides
  * and it's name.
  *
  * Example:
@@ -272,7 +272,7 @@
 	({								\
 		extern _type _u_boot_list_2_##_list##_2_##_name;	\
 		_type *_ll_result =					\
-			&_u_boot_list_2_##_list##_2_##_name;	\
+			&_u_boot_list_2_##_list##_2_##_name;		\
 		_ll_result;						\
 	})
 
@@ -297,7 +297,7 @@
 })
 
 /**
- * ll_entry_end() - Point after last entry of last linker-generated array
+ * ll_end() - Point after last entry of last linker-generated array
  * @_type:	Data type of the entry
  *
  * This function returns (_type *) pointer after the very last entry of
@@ -311,7 +311,7 @@
  */
 #define ll_end(_type)							\
 ({									\
-	static char end[0] __aligned(4) __attribute__((unused,	\
+	static char end[0] __aligned(4) __attribute__((unused,		\
 		section(".u_boot_list_3")));				\
 	(_type *)&end;							\
 })
-- 
1.8.2.1

[U-Boot] [PATCH 2/6] dm: pci: Correct primary/secondary/subordinate bus number assignment

[Bin Meng]

In driver model, each pci bridge device has its own hose structure.
hose->first_busno points to the bridge device's device number, so
we should not substract hose->first_busno before programming the
bridge device's primary/secondary/subordinate bus number registers.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/pci/pci_auto.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index e034ed1..ef6dc4f 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -224,10 +224,15 @@ void pciauto_prescan_setup_bridge(struct pci_controller *hose,
 	prefechable_64 &= PCI_PREF_RANGE_TYPE_MASK;
 
 	/* Configure bus number registers */
+#ifdef CONFIG_DM_PCI
+	pci_hose_write_config_byte(hose, dev, PCI_PRIMARY_BUS, PCI_BUS(dev));
+	pci_hose_write_config_byte(hose, dev, PCI_SECONDARY_BUS, sub_bus);
+#else
 	pci_hose_write_config_byte(hose, dev, PCI_PRIMARY_BUS,
 				   PCI_BUS(dev) - hose->first_busno);
 	pci_hose_write_config_byte(hose, dev, PCI_SECONDARY_BUS,
 				   sub_bus - hose->first_busno);
+#endif
 	pci_hose_write_config_byte(hose, dev, PCI_SUBORDINATE_BUS, 0xff);
 
 	if (pci_mem) {
@@ -295,8 +300,12 @@ void pciauto_postscan_setup_bridge(struct pci_controller *hose,
 	struct pci_region *pci_io = hose->pci_io;
 
 	/* Configure bus number registers */
+#ifdef CONFIG_DM_PCI
+	pci_hose_write_config_byte(hose, dev, PCI_SUBORDINATE_BUS, sub_bus);
+#else
 	pci_hose_write_config_byte(hose, dev, PCI_SUBORDINATE_BUS,
 				   sub_bus - hose->first_busno);
+#endif
 
 	if (pci_mem) {
 		/* Round memory allocator to 1MB boundary */
-- 
1.8.2.1

[U-Boot] [PATCH 3/6] dm: pci: Use complete bdf in all pci config read/write routines

[Bin Meng]

Currently pci_bus_read_config() and pci_bus_write_config() are
called with bus number masked off in the parameter bdf, and bus
number is supposed to be added back in the bridge driver's pci
config read/write ops if the device is behind a pci bridge.
However this logic only works for a pci topology where there is
only one bridge off the root controller. If there is addtional
bridge in the system, the logic will create a non-existent bdf
where its bus number gets accumulated across bridges.

To correct this, we change all pci config read/write routines
to use complete bdf all the way up to the root controller.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/pci/pci-uclass.c | 46 +++++++++++++++++++++++-----------------------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 5b91fe3..e92e4f3 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -199,8 +199,7 @@ int pci_write_config(pci_dev_t bdf, int offset, unsigned long value,
 	if (ret)
 		return ret;
 
-	return pci_bus_write_config(bus, PCI_MASK_BUS(bdf), offset, value,
-				    size);
+	return pci_bus_write_config(bus, bdf, offset, value, size);
 }
 
 int pci_write_config32(pci_dev_t bdf, int offset, u32 value)
@@ -239,8 +238,7 @@ int pci_read_config(pci_dev_t bdf, int offset, unsigned long *valuep,
 	if (ret)
 		return ret;
 
-	return pci_bus_read_config(bus, PCI_MASK_BUS(bdf), offset, valuep,
-				   size);
+	return pci_bus_read_config(bus, bdf, offset, valuep, size);
 }
 
 int pci_read_config32(pci_dev_t bdf, int offset, u32 *valuep)
@@ -357,41 +355,43 @@ int pci_bind_bus_devices(struct udevice *bus)
 {
 	ulong vendor, device;
 	ulong header_type;
-	pci_dev_t devfn, end;
+	pci_dev_t bdf, end;
 	bool found_multi;
 	int ret;
 
 	found_multi = false;
-	end = PCI_DEVFN(PCI_MAX_PCI_DEVICES - 1, PCI_MAX_PCI_FUNCTIONS - 1);
-	for (devfn = PCI_DEVFN(0, 0); devfn < end; devfn += PCI_DEVFN(0, 1)) {
+	end = PCI_BDF(bus->seq, PCI_MAX_PCI_DEVICES - 1,
+		      PCI_MAX_PCI_FUNCTIONS - 1);
+	for (bdf = PCI_BDF(bus->seq, 0, 0); bdf < end;
+	     bdf += PCI_BDF(0, 0, 1)) {
 		struct pci_child_platdata *pplat;
 		struct udevice *dev;
 		ulong class;
 
-		if (PCI_FUNC(devfn) && !found_multi)
+		if (PCI_FUNC(bdf) && !found_multi)
 			continue;
 		/* Check only the first access, we don't expect problems */
-		ret = pci_bus_read_config(bus, devfn, PCI_HEADER_TYPE,
+		ret = pci_bus_read_config(bus, bdf, PCI_HEADER_TYPE,
 					  &header_type, PCI_SIZE_8);
 		if (ret)
 			goto error;
-		pci_bus_read_config(bus, devfn, PCI_VENDOR_ID, &vendor,
+		pci_bus_read_config(bus, bdf, PCI_VENDOR_ID, &vendor,
 				    PCI_SIZE_16);
 		if (vendor == 0xffff || vendor == 0x0000)
 			continue;
 
-		if (!PCI_FUNC(devfn))
+		if (!PCI_FUNC(bdf))
 			found_multi = header_type & 0x80;
 
 		debug("%s: bus %d/%s: found device %x, function %d\n", __func__,
-		      bus->seq, bus->name, PCI_DEV(devfn), PCI_FUNC(devfn));
-		pci_bus_read_config(bus, devfn, PCI_DEVICE_ID, &device,
+		      bus->seq, bus->name, PCI_DEV(bdf), PCI_FUNC(bdf));
+		pci_bus_read_config(bus, bdf, PCI_DEVICE_ID, &device,
 				    PCI_SIZE_16);
-		pci_bus_read_config(bus, devfn, PCI_CLASS_DEVICE, &class,
+		pci_bus_read_config(bus, bdf, PCI_CLASS_DEVICE, &class,
 				    PCI_SIZE_16);
 
 		/* Find this device in the device tree */
-		ret = pci_bus_find_devfn(bus, devfn, &dev);
+		ret = pci_bus_find_devfn(bus, PCI_MASK_BUS(bdf), &dev);
 
 		/* If nothing in the device tree, bind a generic device */
 		if (ret == -ENODEV) {
@@ -399,7 +399,7 @@ int pci_bind_bus_devices(struct udevice *bus)
 			const char *drv;
 
 			sprintf(name, "pci_%x:%x.%x", bus->seq,
-				PCI_DEV(devfn), PCI_FUNC(devfn));
+				PCI_DEV(bdf), PCI_FUNC(bdf));
 			str = strdup(name);
 			if (!str)
 				return -ENOMEM;
@@ -412,7 +412,7 @@ int pci_bind_bus_devices(struct udevice *bus)
 
 		/* Update the platform data */
 		pplat = dev_get_parent_platdata(dev);
-		pplat->devfn = devfn;
+		pplat->devfn = PCI_MASK_BUS(bdf);
 		pplat->vendor = vendor;
 		pplat->device = device;
 		pplat->class = class;
@@ -583,20 +583,20 @@ static int pci_uclass_child_post_bind(struct udevice *dev)
 	return 0;
 }
 
-int pci_bridge_read_config(struct udevice *bus, pci_dev_t devfn, uint offset,
-			   ulong *valuep, enum pci_size_t size)
+static int pci_bridge_read_config(struct udevice *bus, pci_dev_t bdf,
+				  uint offset, ulong *valuep,
+				  enum pci_size_t size)
 {
 	struct pci_controller *hose = bus->uclass_priv;
-	pci_dev_t bdf = PCI_ADD_BUS(bus->seq, devfn);
 
 	return pci_bus_read_config(hose->ctlr, bdf, offset, valuep, size);
 }
 
-int pci_bridge_write_config(struct udevice *bus, pci_dev_t devfn, uint offset,
-			    ulong value, enum pci_size_t size)
+static int pci_bridge_write_config(struct udevice *bus, pci_dev_t bdf,
+				   uint offset, ulong value,
+				   enum pci_size_t size)
 {
 	struct pci_controller *hose = bus->uclass_priv;
-	pci_dev_t bdf = PCI_ADD_BUS(bus->seq, devfn);
 
 	return pci_bus_write_config(hose->ctlr, bdf, offset, value, size);
 }
-- 
1.8.2.1

[U-Boot] [PATCH 4/6] dm: pci: Pass only device/function to pci_bus_find_devfn()

[Bin Meng]

In dm_pci_hose_probe_bus(), pci_bus_find_devfn() is called with a bdf
which includes a bus number, but it really should not as this routine
only expects a device/function encoding.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/pci/pci-uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index e92e4f3..164e3e9 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -323,7 +323,7 @@ int dm_pci_hose_probe_bus(struct pci_controller *hose, pci_dev_t bdf)
 	parent = hose->bus;
 
 	/* Find the bus within the parent */
-	ret = pci_bus_find_devfn(parent, bdf, &bus);
+	ret = pci_bus_find_devfn(parent, PCI_MASK_BUS(bdf), &bus);
 	if (ret) {
 		debug("%s: Cannot find device %x on bus %s: %d\n", __func__,
 		      bdf, parent->name, ret);
-- 
1.8.2.1

[U-Boot] [PATCH 5/6] dm: pci: Support bridge device configuration correctly

[Bin Meng]

Commit aec241d "dm: pci: Use the correct hose when configuring devices"
was an attempt to fix pci bridge device configuration, but unfortunately
that does not work 100%. In pciauto_config_devices(), the fix tried to
call pciauto_config_device() with a ctlr_hose which is supposed to be
the root controller hose, however when walking through a pci topology
with 2 or more pci bridges this logic simply fails.

The call chain is: pciauto_config_devices()->pciauto_config_device()
->dm_pci_hose_probe_bus(). Here the call to dm_pci_hose_probe_bus()
does not make any sense as the given hose is not the bridge device's
hose, instead it is either the root controller's hose (case#1: if it
is the 2nd pci bridge), or the bridge's parent bridge's hose (case#2:
if it is the 3rd pci bridge). In both cases the logic is wrong.

For example, for failing case#1 if the bridge device to config has the
same devfn as one of the devices under the root controller, the call
to pci_bus_find_devfn() will return the udevice of that pci device
under the root controller as the bus, but this is wrong as the udevice
is not a bus which does not contain all the necessary bits associated
with the udevice which causes further failures.

To correctly support pci bridge device configuration, we should still
call pciauto_config_device() with the pci bridge's hose directly.
In order to access valid pci region information, we need to refer to
the root controller simply by a call to pci_bus_to_hose(0) and get the
region information there in the pciauto_prescan_setup_bridge(),
pciauto_postscan_setup_bridge() and pciauto_config_device().

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 drivers/pci/pci-uclass.c |  6 +----
 drivers/pci/pci_auto.c   | 66 +++++++++++++++++++++++++++++++++++++++---------
 drivers/pci/pci_common.c |  7 ++++-
 3 files changed, 61 insertions(+), 18 deletions(-)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 164e3e9..92dcc01 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -294,7 +294,6 @@ int pci_auto_config_devices(struct udevice *bus)
 	     !ret && dev;
 	     ret = device_find_next_child(&dev)) {
 		struct pci_child_platdata *pplat;
-		struct pci_controller *ctlr_hose;
 
 		pplat = dev_get_parent_platdata(dev);
 		unsigned int max_bus;
@@ -302,10 +301,7 @@ int pci_auto_config_devices(struct udevice *bus)
 
 		bdf = PCI_ADD_BUS(bus->seq, pplat->devfn);
 		debug("%s: device %s\n", __func__, dev->name);
-
-		/* The root controller has the region information */
-		ctlr_hose = hose->ctlr->uclass_priv;
-		max_bus = pciauto_config_device(ctlr_hose, bdf);
+		max_bus = pciauto_config_device(hose, bdf);
 		sub_bus = max(sub_bus, max_bus);
 	}
 	debug("%s: done\n", __func__);
diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index ef6dc4f..a7af8cb 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -213,11 +213,24 @@ void pciauto_setup_device(struct pci_controller *hose,
 void pciauto_prescan_setup_bridge(struct pci_controller *hose,
 					 pci_dev_t dev, int sub_bus)
 {
-	struct pci_region *pci_mem = hose->pci_mem;
-	struct pci_region *pci_prefetch = hose->pci_prefetch;
-	struct pci_region *pci_io = hose->pci_io;
+	struct pci_region *pci_mem;
+	struct pci_region *pci_prefetch;
+	struct pci_region *pci_io;
 	u16 cmdstat, prefechable_64;
 
+#ifdef CONFIG_DM_PCI
+	/* The root controller has the region information */
+	struct pci_controller *ctlr_hose = pci_bus_to_hose(0);
+
+	pci_mem = ctlr_hose->pci_mem;
+	pci_prefetch = ctlr_hose->pci_prefetch;
+	pci_io = ctlr_hose->pci_io;
+#else
+	pci_mem = hose->pci_mem;
+	pci_prefetch = hose->pci_prefetch;
+	pci_io = hose->pci_io;
+#endif
+
 	pci_hose_read_config_word(hose, dev, PCI_COMMAND, &cmdstat);
 	pci_hose_read_config_word(hose, dev, PCI_PREF_MEMORY_BASE,
 				&prefechable_64);
@@ -295,9 +308,22 @@ void pciauto_prescan_setup_bridge(struct pci_controller *hose,
 void pciauto_postscan_setup_bridge(struct pci_controller *hose,
 					  pci_dev_t dev, int sub_bus)
 {
-	struct pci_region *pci_mem = hose->pci_mem;
-	struct pci_region *pci_prefetch = hose->pci_prefetch;
-	struct pci_region *pci_io = hose->pci_io;
+	struct pci_region *pci_mem;
+	struct pci_region *pci_prefetch;
+	struct pci_region *pci_io;
+
+#ifdef CONFIG_DM_PCI
+	/* The root controller has the region information */
+	struct pci_controller *ctlr_hose = pci_bus_to_hose(0);
+
+	pci_mem = ctlr_hose->pci_mem;
+	pci_prefetch = ctlr_hose->pci_prefetch;
+	pci_io = ctlr_hose->pci_io;
+#else
+	pci_mem = hose->pci_mem;
+	pci_prefetch = hose->pci_prefetch;
+	pci_io = hose->pci_io;
+#endif
 
 	/* Configure bus number registers */
 #ifdef CONFIG_DM_PCI
@@ -425,10 +451,26 @@ void pciauto_config_init(struct pci_controller *hose)
  */
 int pciauto_config_device(struct pci_controller *hose, pci_dev_t dev)
 {
+	struct pci_region *pci_mem;
+	struct pci_region *pci_prefetch;
+	struct pci_region *pci_io;
 	unsigned int sub_bus = PCI_BUS(dev);
 	unsigned short class;
 	int n;
 
+#ifdef CONFIG_DM_PCI
+	/* The root controller has the region information */
+	struct pci_controller *ctlr_hose = pci_bus_to_hose(0);
+
+	pci_mem = ctlr_hose->pci_mem;
+	pci_prefetch = ctlr_hose->pci_prefetch;
+	pci_io = ctlr_hose->pci_io;
+#else
+	pci_mem = hose->pci_mem;
+	pci_prefetch = hose->pci_prefetch;
+	pci_io = hose->pci_io;
+#endif
+
 	pci_hose_read_config_word(hose, dev, PCI_CLASS_DEVICE, &class);
 
 	switch (class) {
@@ -436,8 +478,8 @@ int pciauto_config_device(struct pci_controller *hose, pci_dev_t dev)
 		DEBUGF("PCI Autoconfig: Found P2P bridge, device %d\n",
 		       PCI_DEV(dev));
 
-		pciauto_setup_device(hose, dev, 2, hose->pci_mem,
-			hose->pci_prefetch, hose->pci_io);
+		pciauto_setup_device(hose, dev, 2, pci_mem,
+				     pci_prefetch, pci_io);
 
 #ifdef CONFIG_DM_PCI
 		n = dm_pci_hose_probe_bus(hose, dev);
@@ -467,8 +509,8 @@ int pciauto_config_device(struct pci_controller *hose, pci_dev_t dev)
 		 * just do a minimal setup of the bridge,
 		 * let the OS take care of the rest
 		 */
-		pciauto_setup_device(hose, dev, 0, hose->pci_mem,
-			hose->pci_prefetch, hose->pci_io);
+		pciauto_setup_device(hose, dev, 0, pci_mem,
+				     pci_prefetch, pci_io);
 
 		DEBUGF("PCI Autoconfig: Found P2CardBus bridge, device %d\n",
 			PCI_DEV(dev));
@@ -502,8 +544,8 @@ int pciauto_config_device(struct pci_controller *hose, pci_dev_t dev)
 		DEBUGF("PCI AutoConfig: Found PowerPC device\n");
 
 	default:
-		pciauto_setup_device(hose, dev, 6, hose->pci_mem,
-			hose->pci_prefetch, hose->pci_io);
+		pciauto_setup_device(hose, dev, 6, pci_mem,
+				     pci_prefetch, pci_io);
 		break;
 	}
 
diff --git a/drivers/pci/pci_common.c b/drivers/pci/pci_common.c
index f67c9c7..07f1726 100644
--- a/drivers/pci/pci_common.c
+++ b/drivers/pci/pci_common.c
@@ -224,7 +224,7 @@ phys_addr_t pci_hose_bus_to_phys(struct pci_controller *hose,
 
 #ifdef CONFIG_DM_PCI
 	/* The root controller has the region information */
-	hose = hose->ctlr->uclass_priv;
+	hose = pci_bus_to_hose(0);
 #endif
 
 	/*
@@ -289,6 +289,11 @@ pci_addr_t pci_hose_phys_to_bus(struct pci_controller *hose,
 		return bus_addr;
 	}
 
+#ifdef CONFIG_DM_PCI
+	/* The root controller has the region information */
+	hose = pci_bus_to_hose(0);
+#endif
+
 	/*
 	 * if PCI_REGION_MEM is set we do a two pass search with preference
 	 * on matches that don't have PCI_REGION_SYS_MEMORY set
-- 
1.8.2.1

[U-Boot] [PATCH 6/6] x86: Convert to use driver model pci on queensbay/crownbay

[Bin Meng]

Move to driver model pci for Intel queensbay/crownbay.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

---

 arch/x86/cpu/queensbay/Makefile  |  1 -
 arch/x86/cpu/queensbay/tnc.c     |  5 -----
 arch/x86/cpu/queensbay/tnc_pci.c | 46 ----------------------------------------
 arch/x86/dts/crownbay.dts        |  6 +++++-
 configs/crownbay_defconfig       |  1 +
 5 files changed, 6 insertions(+), 53 deletions(-)
 delete mode 100644 arch/x86/cpu/queensbay/tnc_pci.c

diff --git a/arch/x86/cpu/queensbay/Makefile b/arch/x86/cpu/queensbay/Makefile
index d8761fd..660f967 100644
--- a/arch/x86/cpu/queensbay/Makefile
+++ b/arch/x86/cpu/queensbay/Makefile
@@ -6,4 +6,3 @@
 
 obj-y += fsp_configs.o
 obj-y += tnc.o topcliff.o
-obj-$(CONFIG_PCI) += tnc_pci.o
diff --git a/arch/x86/cpu/queensbay/tnc.c b/arch/x86/cpu/queensbay/tnc.c
index d27b2d9..de50893 100644
--- a/arch/x86/cpu/queensbay/tnc.c
+++ b/arch/x86/cpu/queensbay/tnc.c
@@ -25,7 +25,6 @@ static void unprotect_spi_flash(void)
 
 int arch_cpu_init(void)
 {
-	struct pci_controller *hose;
 	int ret;
 
 	post_code(POST_CPU_INIT);
@@ -37,10 +36,6 @@ int arch_cpu_init(void)
 	if (ret)
 		return ret;
 
-	ret = pci_early_init_hose(&hose);
-	if (ret)
-		return ret;
-
 	unprotect_spi_flash();
 
 	return 0;
diff --git a/arch/x86/cpu/queensbay/tnc_pci.c b/arch/x86/cpu/queensbay/tnc_pci.c
deleted file mode 100644
index 6c291f9..0000000
--- a/arch/x86/cpu/queensbay/tnc_pci.c
+++ /dev/null
@@ -1,46 +0,0 @@
-/*
- * Copyright (C) 2014, Bin Meng <bmeng.cn@gmail.com>
- *
- * SPDX-License-Identifier:	GPL-2.0+
- */
-
-#include <common.h>
-#include <pci.h>
-#include <asm/pci.h>
-#include <asm/fsp/fsp_support.h>
-
-DECLARE_GLOBAL_DATA_PTR;
-
-void board_pci_setup_hose(struct pci_controller *hose)
-{
-	hose->first_busno = 0;
-	hose->last_busno = 0;
-
-	/* PCI memory space */
-	pci_set_region(hose->regions + 0,
-		       CONFIG_PCI_MEM_BUS,
-		       CONFIG_PCI_MEM_PHYS,
-		       CONFIG_PCI_MEM_SIZE,
-		       PCI_REGION_MEM);
-
-	/* PCI IO space */
-	pci_set_region(hose->regions + 1,
-		       CONFIG_PCI_IO_BUS,
-		       CONFIG_PCI_IO_PHYS,
-		       CONFIG_PCI_IO_SIZE,
-		       PCI_REGION_IO);
-
-	pci_set_region(hose->regions + 2,
-		       CONFIG_PCI_PREF_BUS,
-		       CONFIG_PCI_PREF_PHYS,
-		       CONFIG_PCI_PREF_SIZE,
-		       PCI_REGION_PREFETCH);
-
-	pci_set_region(hose->regions + 3,
-		       0,
-		       0,
-		       gd->ram_size,
-		       PCI_REGION_MEM | PCI_REGION_SYS_MEMORY);
-
-	hose->region_count = 4;
-}
diff --git a/arch/x86/dts/crownbay.dts b/arch/x86/dts/crownbay.dts
index 60da1f5..3af9cc3 100644
--- a/arch/x86/dts/crownbay.dts
+++ b/arch/x86/dts/crownbay.dts
@@ -90,8 +90,12 @@
 	pci {
 		#address-cells = <3>;
 		#size-cells = <2>;
-		compatible = "intel,pci";
+		compatible = "pci-x86";
 		device_type = "pci";
+		u-boot,dm-pre-reloc;
+		ranges = <0x02000000 0x0 0x40000000 0x40000000 0 0x80000000
+			  0x42000000 0x0 0xc0000000 0xc0000000 0 0x20000000
+			  0x01000000 0x0 0x2000 0x2000 0 0xe000>;
 
 		pcie at 17,0 {
 			#address-cells = <3>;
diff --git a/configs/crownbay_defconfig b/configs/crownbay_defconfig
index 17e6a72..aa1232d 100644
--- a/configs/crownbay_defconfig
+++ b/configs/crownbay_defconfig
@@ -17,6 +17,7 @@ CONFIG_BOOTSTAGE_REPORT=y
 CONFIG_CMD_BOOTSTAGE=y
 CONFIG_OF_CONTROL=y
 CONFIG_CPU=y
+CONFIG_DM_PCI=y
 CONFIG_SPI_FLASH=y
 CONFIG_VIDEO_VESA=y
 CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
-- 
1.8.2.1

[U-Boot] [PATCH 1/6] Fix incorrect comments in linker_lists.h

[Simon Glass]

On 18 July 2015 at 10:20, Bin Meng <bmeng.cn@gmail.com> wrote:
> This corrects several typos in the comment block as well as some
> indentions and nits in the linker_lists.h.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  include/linker_lists.h | 20 ++++++++++----------
>  1 file changed, 10 insertions(+), 10 deletions(-)

Acked-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 2/6] dm: pci: Correct primary/secondary/subordinate bus number assignment

[Simon Glass]

Hi Bin,

On 18 July 2015 at 10:20, Bin Meng <bmeng.cn@gmail.com> wrote:
> In driver model, each pci bridge device has its own hose structure.
> hose->first_busno points to the bridge device's device number, so
> we should not substract hose->first_busno before programming the
> bridge device's primary/secondary/subordinate bus number registers.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  drivers/pci/pci_auto.c | 9 +++++++++
>  1 file changed, 9 insertions(+)

Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

I'm not happy with how each PCI bridge has its own hose structure. I
think that was a mistake. It just creates problems.

I'm thinking we should instead have a UCLASS_PCI which is strictly for
the PCI controller, and a new UCLASS_PCI_BRIDGE for bridges.

What do you think?

Regards,
Simon

[U-Boot] [PATCH 3/6] dm: pci: Use complete bdf in all pci config read/write routines

[Simon Glass]

On 18 July 2015 at 10:20, Bin Meng <bmeng.cn@gmail.com> wrote:
> Currently pci_bus_read_config() and pci_bus_write_config() are
> called with bus number masked off in the parameter bdf, and bus
> number is supposed to be added back in the bridge driver's pci
> config read/write ops if the device is behind a pci bridge.
> However this logic only works for a pci topology where there is
> only one bridge off the root controller. If there is addtional
> bridge in the system, the logic will create a non-existent bdf
> where its bus number gets accumulated across bridges.
>
> To correct this, we change all pci config read/write routines
> to use complete bdf all the way up to the root controller.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  drivers/pci/pci-uclass.c | 46 +++++++++++++++++++++++-----------------------
>  1 file changed, 23 insertions(+), 23 deletions(-)

Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 4/6] dm: pci: Pass only device/function to pci_bus_find_devfn()

[Simon Glass]

On 18 July 2015 at 10:20, Bin Meng <bmeng.cn@gmail.com> wrote:
> In dm_pci_hose_probe_bus(), pci_bus_find_devfn() is called with a bdf
> which includes a bus number, but it really should not as this routine
> only expects a device/function encoding.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  drivers/pci/pci-uclass.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 5/6] dm: pci: Support bridge device configuration correctly

[Simon Glass]

On 18 July 2015 at 10:20, Bin Meng <bmeng.cn@gmail.com> wrote:
> Commit aec241d "dm: pci: Use the correct hose when configuring devices"
> was an attempt to fix pci bridge device configuration, but unfortunately
> that does not work 100%. In pciauto_config_devices(), the fix tried to
> call pciauto_config_device() with a ctlr_hose which is supposed to be
> the root controller hose, however when walking through a pci topology
> with 2 or more pci bridges this logic simply fails.
>
> The call chain is: pciauto_config_devices()->pciauto_config_device()
> ->dm_pci_hose_probe_bus(). Here the call to dm_pci_hose_probe_bus()
> does not make any sense as the given hose is not the bridge device's
> hose, instead it is either the root controller's hose (case#1: if it
> is the 2nd pci bridge), or the bridge's parent bridge's hose (case#2:
> if it is the 3rd pci bridge). In both cases the logic is wrong.
>
> For example, for failing case#1 if the bridge device to config has the
> same devfn as one of the devices under the root controller, the call
> to pci_bus_find_devfn() will return the udevice of that pci device
> under the root controller as the bus, but this is wrong as the udevice
> is not a bus which does not contain all the necessary bits associated
> with the udevice which causes further failures.
>
> To correctly support pci bridge device configuration, we should still
> call pciauto_config_device() with the pci bridge's hose directly.
> In order to access valid pci region information, we need to refer to
> the root controller simply by a call to pci_bus_to_hose(0) and get the
> region information there in the pciauto_prescan_setup_bridge(),
> pciauto_postscan_setup_bridge() and pciauto_config_device().
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
>
>  drivers/pci/pci-uclass.c |  6 +----
>  drivers/pci/pci_auto.c   | 66 +++++++++++++++++++++++++++++++++++++++---------
>  drivers/pci/pci_common.c |  7 ++++-
>  3 files changed, 61 insertions(+), 18 deletions(-)

Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 6/6] x86: Convert to use driver model pci on queensbay/crownbay

[Simon Glass]

On 18 July 2015 at 10:20, Bin Meng <bmeng.cn@gmail.com> wrote:
> Move to driver model pci for Intel queensbay/crownbay.
>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>
> ---
>
>  arch/x86/cpu/queensbay/Makefile  |  1 -
>  arch/x86/cpu/queensbay/tnc.c     |  5 -----
>  arch/x86/cpu/queensbay/tnc_pci.c | 46 ----------------------------------------
>  arch/x86/dts/crownbay.dts        |  6 +++++-
>  configs/crownbay_defconfig       |  1 +
>  5 files changed, 6 insertions(+), 53 deletions(-)
>  delete mode 100644 arch/x86/cpu/queensbay/tnc_pci.c

Acked-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>

[U-Boot] [PATCH 2/6] dm: pci: Correct primary/secondary/subordinate bus number assignment

[Bin Meng]

Hi Simon,

On Mon, Jul 20, 2015 at 9:59 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 18 July 2015 at 10:20, Bin Meng <bmeng.cn@gmail.com> wrote:
>> In driver model, each pci bridge device has its own hose structure.
>> hose->first_busno points to the bridge device's device number, so
>> we should not substract hose->first_busno before programming the
>> bridge device's primary/secondary/subordinate bus number registers.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  drivers/pci/pci_auto.c | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>
> Acked-by: Simon Glass <sjg@chromium.org>
> Tested-by: Simon Glass <sjg@chromium.org>
>
> I'm not happy with how each PCI bridge has its own hose structure. I
> think that was a mistake. It just creates problems.
>
> I'm thinking we should instead have a UCLASS_PCI which is strictly for
> the PCI controller, and a new UCLASS_PCI_BRIDGE for bridges.
>
> What do you think?
>

I guess that may help. During the debug, I feel the dm pci codes are
really not that intuitive than the previous non-dm version. It took me
sometime to figure out where is the problem.

Regards,
Bin

[U-Boot] [PATCH 1/6] Fix incorrect comments in linker_lists.h

[Simon Glass]

On 19 July 2015 at 19:59, Simon Glass <sjg@chromium.org> wrote:
> On 18 July 2015 at 10:20, Bin Meng <bmeng.cn@gmail.com> wrote:
>> This corrects several typos in the comment block as well as some
>> indentions and nits in the linker_lists.h.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  include/linker_lists.h | 20 ++++++++++----------
>>  1 file changed, 10 insertions(+), 10 deletions(-)
>
> Acked-by: Simon Glass <sjg@chromium.org>

Applied to u-boot-x86, thanks!

[U-Boot] [PATCH 2/6] dm: pci: Correct primary/secondary/subordinate bus number assignment

[Simon Glass]

On 19 July 2015 at 19:59, Simon Glass <sjg@chromium.org> wrote:
> Hi Bin,
>
> On 18 July 2015 at 10:20, Bin Meng <bmeng.cn@gmail.com> wrote:
>> In driver model, each pci bridge device has its own hose structure.
>> hose->first_busno points to the bridge device's device number, so
>> we should not substract hose->first_busno before programming the
>> bridge device's primary/secondary/subordinate bus number registers.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  drivers/pci/pci_auto.c | 9 +++++++++
>>  1 file changed, 9 insertions(+)
>
> Acked-by: Simon Glass <sjg@chromium.org>
> Tested-by: Simon Glass <sjg@chromium.org>
>
Applied to u-boot-x86, thanks!

[snip]

[U-Boot] [PATCH 3/6] dm: pci: Use complete bdf in all pci config read/write routines

[Simon Glass]

On 19 July 2015 at 19:59, Simon Glass <sjg@chromium.org> wrote:
> On 18 July 2015 at 10:20, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Currently pci_bus_read_config() and pci_bus_write_config() are
>> called with bus number masked off in the parameter bdf, and bus
>> number is supposed to be added back in the bridge driver's pci
>> config read/write ops if the device is behind a pci bridge.
>> However this logic only works for a pci topology where there is
>> only one bridge off the root controller. If there is addtional
>> bridge in the system, the logic will create a non-existent bdf
>> where its bus number gets accumulated across bridges.
>>
>> To correct this, we change all pci config read/write routines
>> to use complete bdf all the way up to the root controller.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  drivers/pci/pci-uclass.c | 46 +++++++++++++++++++++++-----------------------
>>  1 file changed, 23 insertions(+), 23 deletions(-)
>
> Acked-by: Simon Glass <sjg@chromium.org>
> Tested-by: Simon Glass <sjg@chromium.org>

Applied to u-boot-x86, thanks!

[U-Boot] [PATCH 4/6] dm: pci: Pass only device/function to pci_bus_find_devfn()

[Simon Glass]

On 19 July 2015 at 19:59, Simon Glass <sjg@chromium.org> wrote:
> On 18 July 2015 at 10:20, Bin Meng <bmeng.cn@gmail.com> wrote:
>> In dm_pci_hose_probe_bus(), pci_bus_find_devfn() is called with a bdf
>> which includes a bus number, but it really should not as this routine
>> only expects a device/function encoding.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  drivers/pci/pci-uclass.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Acked-by: Simon Glass <sjg@chromium.org>
> Tested-by: Simon Glass <sjg@chromium.org>

Applied to u-boot-x86, thanks!

[U-Boot] [PATCH 5/6] dm: pci: Support bridge device configuration correctly

[Simon Glass]

On 19 July 2015 at 19:59, Simon Glass <sjg@chromium.org> wrote:
> On 18 July 2015 at 10:20, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Commit aec241d "dm: pci: Use the correct hose when configuring devices"
>> was an attempt to fix pci bridge device configuration, but unfortunately
>> that does not work 100%. In pciauto_config_devices(), the fix tried to
>> call pciauto_config_device() with a ctlr_hose which is supposed to be
>> the root controller hose, however when walking through a pci topology
>> with 2 or more pci bridges this logic simply fails.
>>
>> The call chain is: pciauto_config_devices()->pciauto_config_device()
>> ->dm_pci_hose_probe_bus(). Here the call to dm_pci_hose_probe_bus()
>> does not make any sense as the given hose is not the bridge device's
>> hose, instead it is either the root controller's hose (case#1: if it
>> is the 2nd pci bridge), or the bridge's parent bridge's hose (case#2:
>> if it is the 3rd pci bridge). In both cases the logic is wrong.
>>
>> For example, for failing case#1 if the bridge device to config has the
>> same devfn as one of the devices under the root controller, the call
>> to pci_bus_find_devfn() will return the udevice of that pci device
>> under the root controller as the bus, but this is wrong as the udevice
>> is not a bus which does not contain all the necessary bits associated
>> with the udevice which causes further failures.
>>
>> To correctly support pci bridge device configuration, we should still
>> call pciauto_config_device() with the pci bridge's hose directly.
>> In order to access valid pci region information, we need to refer to
>> the root controller simply by a call to pci_bus_to_hose(0) and get the
>> region information there in the pciauto_prescan_setup_bridge(),
>> pciauto_postscan_setup_bridge() and pciauto_config_device().
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>> ---
>>
>>  drivers/pci/pci-uclass.c |  6 +----
>>  drivers/pci/pci_auto.c   | 66 +++++++++++++++++++++++++++++++++++++++---------
>>  drivers/pci/pci_common.c |  7 ++++-
>>  3 files changed, 61 insertions(+), 18 deletions(-)
>
> Acked-by: Simon Glass <sjg@chromium.org>
> Tested-by: Simon Glass <sjg@chromium.org>

Applied to u-boot-x86, thanks!

[U-Boot] [PATCH 6/6] x86: Convert to use driver model pci on queensbay/crownbay

[Simon Glass]

On 19 July 2015 at 19:59, Simon Glass <sjg@chromium.org> wrote:
> On 18 July 2015 at 10:20, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Move to driver model pci for Intel queensbay/crownbay.
>>
>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>
>> ---
>>
>>  arch/x86/cpu/queensbay/Makefile  |  1 -
>>  arch/x86/cpu/queensbay/tnc.c     |  5 -----
>>  arch/x86/cpu/queensbay/tnc_pci.c | 46 ----------------------------------------
>>  arch/x86/dts/crownbay.dts        |  6 +++++-
>>  configs/crownbay_defconfig       |  1 +
>>  5 files changed, 6 insertions(+), 53 deletions(-)
>>  delete mode 100644 arch/x86/cpu/queensbay/tnc_pci.c
>
> Acked-by: Simon Glass <sjg@chromium.org>
> Tested-by: Simon Glass <sjg@chromium.org>

Applied to u-boot-x86, thanks!

[U-Boot] [PATCH 2/6] dm: pci: Correct primary/secondary/subordinate bus number assignment

[Simon Glass]

Hi Bin,

On 19 July 2015 at 20:38, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Mon, Jul 20, 2015 at 9:59 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi Bin,
>>
>> On 18 July 2015 at 10:20, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> In driver model, each pci bridge device has its own hose structure.
>>> hose->first_busno points to the bridge device's device number, so
>>> we should not substract hose->first_busno before programming the
>>> bridge device's primary/secondary/subordinate bus number registers.
>>>
>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>> ---
>>>
>>>  drivers/pci/pci_auto.c | 9 +++++++++
>>>  1 file changed, 9 insertions(+)
>>
>> Acked-by: Simon Glass <sjg@chromium.org>
>> Tested-by: Simon Glass <sjg@chromium.org>
>>
>> I'm not happy with how each PCI bridge has its own hose structure. I
>> think that was a mistake. It just creates problems.
>>
>> I'm thinking we should instead have a UCLASS_PCI which is strictly for
>> the PCI controller, and a new UCLASS_PCI_BRIDGE for bridges.
>>
>> What do you think?
>>
>
> I guess that may help. During the debug, I feel the dm pci codes are
> really not that intuitive than the previous non-dm version. It took me
> sometime to figure out where is the problem.

Agreed. Part of the problem I think is that it is still compatible
with the old code.

We should be able to do things like pci_read_config16(struct udevice *dev, ...)

I guess we could move to separate things more.

Regards,
Simon