[U-Boot] [PATCH v5 2/4] net: designware: Add support to PCI designware devices
Bin Meng
bmeng.cn at gmail.com
Tue Sep 15 16:20:26 CEST 2015
Hi Simon,
On Tue, Sep 15, 2015 at 9:51 PM, Simon Glass <sjg at chromium.org> wrote:
> On 11 September 2015 at 04:24, Bin Meng <bmeng.cn at 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 at 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 at 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.
>
>> +};
>> +
>> +U_BOOT_PCI_DEVICE(eth_designware, supported);
>> #endif
>> --
Regards,
Bin
More information about the U-Boot
mailing list