On 15 September 2015 at 08:20, Bin Meng bmeng.cn@gmail.com wrote:
Hi Simon,
On Tue, Sep 15, 2015 at 9:51 PM, Simon Glass sjg@chromium.org wrote:
On 11 September 2015 at 04:24, Bin Meng bmeng.cn@gmail.com wrote:
The Designware ethernet controller is also seen on PCI bus, e.g. on Intel Quark SoC. Add this support in the DM version driver.
Signed-off-by: Bin Meng bmeng.cn@gmail.com
Changes in v5:
- Wrap PCI device support with CONFIG_DM_PCI
Changes in v3:
- Change to use dm_pci_read_config32()
Changes in v2:
- Change to use device_is_on_pci_bus()
drivers/net/designware.c | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+)
Acked-by: Simon Glass sjg@chromium.org
Please see below.
diff --git a/drivers/net/designware.c b/drivers/net/designware.c index ae78d21..6433896 100644 --- a/drivers/net/designware.c +++ b/drivers/net/designware.c @@ -14,6 +14,7 @@ #include <errno.h> #include <miiphy.h> #include <malloc.h> +#include <pci.h> #include <linux/compiler.h> #include <linux/err.h> #include <asm/io.h> @@ -558,6 +559,22 @@ static int designware_eth_write_hwaddr(struct udevice *dev) return _dw_write_hwaddr(priv, pdata->enetaddr); }
+static int designware_eth_bind(struct udevice *dev) +{ +#ifdef CONFIG_DM_PCI
static int num_cards;char name[20];/* Create a unique device name for PCI type devices */if (device_is_on_pci_bus(dev)) {sprintf(name, "eth_designware#%u", num_cards++);device_set_name(dev, name);}+#endif
return 0;+}
static int designware_eth_probe(struct udevice *dev) { struct eth_pdata *pdata = dev_get_platdata(dev); @@ -565,6 +582,23 @@ static int designware_eth_probe(struct udevice *dev) u32 iobase = pdata->iobase; int ret;
+#ifdef CONFIG_DM_PCI
/** If we are on PCI bus, either directly attached to a PCI root port,* or via a PCI bridge, fill in platdata before we probe the hardware.*/if (device_is_on_pci_bus(dev)) {pci_dev_t bdf = pci_get_bdf(dev);dm_pci_read_config32(dev, PCI_BASE_ADDRESS_0, &iobase);iobase &= PCI_BASE_ADDRESS_MEM_MASK;iobase = pci_mem_to_phys(bdf, iobase);pdata->iobase = iobase;pdata->phy_interface = PHY_INTERFACE_MODE_RMII;}+#endif
debug("%s, iobase=%x, priv=%p\n", __func__, iobase, priv); priv->mac_regs_p = (struct eth_mac_regs *)iobase; priv->dma_regs_p = (struct eth_dma_regs *)(iobase + DW_DMA_BASE_OFFSET);@@ -617,10 +651,18 @@ U_BOOT_DRIVER(eth_designware) = { .id = UCLASS_ETH, .of_match = designware_eth_ids, .ofdata_to_platdata = designware_eth_ofdata_to_platdata,
.bind = designware_eth_bind, .probe = designware_eth_probe, .ops = &designware_eth_ops, .priv_auto_alloc_size = sizeof(struct dw_eth_dev), .platdata_auto_alloc_size = sizeof(struct eth_pdata), .flags = DM_FLAG_ALLOC_PRIV_DMA,};
+static struct pci_device_id supported[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_QRK_EMAC) },{ }Rather than ending up with a table of these device IDs, should this go in the device tree?
I am OK for either way. In fact compared to the widely available PCI NS16550 devices from many chipset vendors, there are just two or three PCI variants of designware ethernet devices so far (seen from linux driver). I guess putting a device ID table here is not that bad.
OK let's revisit it if needed.
Applied to u-boot-x86, thanks!