Hi Simon, On Tue, Feb 2, 2016 at 11:55 AM, Simon Glass <s...@chromium.org> wrote: > Hi Bin, > > On 1 February 2016 at 19:25, Bin Meng <bmeng...@gmail.com> wrote: >> Hi Simon, >> >> On Tue, Feb 2, 2016 at 12:19 AM, Simon Glass <s...@chromium.org> wrote: >>> Hi Bin, >>> >>> On 1 February 2016 at 02:40, Bin Meng <bmeng...@gmail.com> wrote: >>>> There are still some codes that use the legacy PCI APIs to access >>>> the configuration space registers. This series converts those codes >>>> to completely use DM PCI APIs. >>>> >>>> This includes adding several new ops to the PCH uclass driver, and >>>> some clean up to the SPI/GPIO/IRQ drivers. >>>> >>>> Tested on QEMU and Crown Bay. This series is available in pci-working >>>> branch of u-boot-x86 repo. >>> >>> Looks great! This is a big step forward. >>> >>> I've tested it on minnowmax and will test on link in the next day or so. >>> >>> Here are a few things that I think can still be cleaned up: >>> - void pci_assign_irqs(int bus, int device, u8 irq[4]) should use a >>> struct udevice >> >> I guess no, unless we expand struct udevice to include interrupt >> routing information? But that's not generic across architectures. I am >> not sure how. > > I suppose we can adjust it to take a struct udevice and drop the bus > and device parameters. But then we need to be able to support reading > from different functions, so will need to use pci_bus_read_config(). > But at least that is a DM function. Hmmm.... >
Currently bus and device parameters come from the device tree <intel,pirq-routing> property. If we just pass struct udevice, that means we have to saving the routing information <INTx mapping to PIRQx) somewhere in the udevice. I doubt that will be generic. >> >>> - pci_x86_read/write_config() move into drivers/pci/pci_x86.c (needs >>> ivybridge fix which I'll look at) >> >> Yep. I wanted to do this when reviewing one of previous patches. > > OK let's see what I find. > >> >>> - disable DM_PCI_COMPAT for x86 >> >> Looks e1000 and pch_gbe (Crown Bay) ethernet drivers are still using >> legacy PCI APIs. e1000 might need quite amount of work as it is being >> widely used on lots of boards. I can update pch_gbe driver later. > > I converted rtl8169 using #ifdef and it seemed to work OK. We don't > need to remove the old code. > >> >>> - use the PCI mmio access method instead of I/O once it becomes possible >> >> Yep. >> >>> - moving vesa video to driver model (UCLASS_VIDEO) >> >> I was not following the dm video changes recently, but I guess yes. > > It only merged recently. I haven't tried looking at that. > > On another note, I just got an Edison. What do you think about > supporting that in U-Boot? > I think that's Intel Edison [1] you are talking about? It's based on one Atom (don't know which exact model it is) plus one Quark processor. Did Intel release any open source SDK for this board? [1] http://www.intel.com/buy/us/en/product/emergingtechnologies/intel-edison-compute-module-iot-463633 Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
