Hi Simon, On Wed, Feb 3, 2016 at 11:30 AM, Simon Glass <s...@chromium.org> wrote: > Hi Bin, > > On 1 February 2016 at 23:34, Bin Meng <bmeng...@gmail.com> wrote: >> 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. > > OK let's worry about it later. > > This series: > > Tested on link > Tested-by: Simon Glass <s...@chromium.org> > >> >>>> >>>>> - 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: > > g...@github.com:01org/edison-u-boot.git >
This is great! Looks https://github.com/01org/edison-u-boot/commits/edison-v2015.10 is the branch and commits for edison. > I'll see if I can find someone at Intel to ask if they plan to upstream it. > That would be nice if Intel is willing to contribute something to the U-Boot x86 support! Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
