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

[Simon Glass]

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

I'll see if I can find someone at Intel to ask if they plan to upstream it.

Regards,
Simon