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

[Bin Meng]

Hi Simon,

On Wed, Feb 3, 2016 at 11:30 AM, Simon Glass <sjg at chromium.org> wrote:
> Hi Bin,
>
> On 1 February 2016 at 23:34, Bin Meng <bmeng.cn at gmail.com> wrote:
>> 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.
>
> OK let's worry about it later.
>
> This series:
>
> Tested on link
> Tested-by: Simon Glass <sjg at 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:
>
> git at 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