Hi Bin, On 2 February 2016 at 20:44, Bin Meng <bmeng...@gmail.com> wrote: > 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.
Yes - I just built this and it boots OK on edison. I've sent an email to two of the authors to see if they are interested in mainlining it. > >> 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! Yes. Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
