Hi Bin, On 1 February 2016 at 23:34, Bin Meng <[email protected]> wrote: > Hi Simon, > > On Tue, Feb 2, 2016 at 11:55 AM, Simon Glass <[email protected]> wrote: >> Hi Bin, >> >> On 1 February 2016 at 19:25, Bin Meng <[email protected]> wrote: >>> Hi Simon, >>> >>> On Tue, Feb 2, 2016 at 12:19 AM, Simon Glass <[email protected]> wrote: >>>> Hi Bin, >>>> >>>> On 1 February 2016 at 02:40, Bin Meng <[email protected]> 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.
OK let's worry about it later. This series: Tested on link Tested-by: Simon Glass <[email protected]> > >>> >>>> - 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 It seems that it uses U-Boot: [email protected]:01org/edison-u-boot.git I'll see if I can find someone at Intel to ask if they plan to upstream it. Regards, Simon _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
