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

[Simon Glass]

Hi Bin,

On 2 February 2016 at 20:44, Bin Meng <bmeng.cn at gmail.com> wrote:
> 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.

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