[U-Boot] [PATCH 00/23] x86: Convert to use DM PCI APIs completely

[Bin Meng]

Hi Simon,

On Tue, Feb 2, 2016 at 11:55 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Bin,
>
> On 1 February 2016 at 19:25, Bin Meng <bmeng.cn at gmail.com> wrote:
>> Hi Simon,
>>
>> On Tue, Feb 2, 2016 at 12:19 AM, Simon Glass <sjg at chromium.org> wrote:
>>> Hi Bin,
>>>
>>> On 1 February 2016 at 02:40, Bin Meng <bmeng.cn at 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