Hi Bin, On 2 February 2016 at 20:58, Bin Meng <bmeng...@gmail.com> wrote: > Hi Simon, > > On Wed, Feb 3, 2016 at 11:37 AM, Simon Glass <s...@chromium.org> wrote: >> HI Bin, >> >> On 1 February 2016 at 09:19, 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 >>> - pci_x86_read/write_config() move into drivers/pci/pci_x86.c (needs >>> ivybridge fix which I'll look at) >> >> This is baord_debug_uart_init(), but I can't find a way to get rid of >> this. Let me know if you have ideas. It is called very early, before >> there is a PCI controller device. > > I see. Maybe we can move this baord_debug_uart_init() to > early_board_init in board/google/common/early_init.S? I see the > existing codes in early_init.S program something to a PCI > configuration register too.
Thinking about it, I don't think it helps to duplicate the PCI access code in link. Probably the way it is is better for now. > >>> - disable DM_PCI_COMPAT for x86 >>> - use the PCI mmio access method instead of I/O once it becomes possible >>> - moving vesa video to driver model (UCLASS_VIDEO) > > Regards, > Bin Regards, Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
