[lkml]   [2015]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v6 0/7] PCI: get DMA configuration from parent device
On 02/11/2015 11:54 AM, Murali Karicheri wrote:
> On 02/06/2015 01:36 PM, Murali Karicheri wrote:
>> On 02/06/2015 12:53 PM, Bjorn Helgaas wrote:
>>> On Fri, Feb 6, 2015 at 9:28 AM, Murali Karicheri<>
>>> wrote:
>>>> On 02/06/2015 10:15 AM, Catalin Marinas wrote:
>>>>> On Thu, Feb 05, 2015 at 09:52:52PM +0000, Murali Karicheri wrote:
>>>>>> This patch add an important capability to PCI driver on Keystone. I
>>>>>> hope
>>>>>> to
>>>>>> have this merged to the upstream branch so that it is available for
>>>>>> v3.20.
>>>>> It's very late for 3.20 and the code hasn't been in linux-next at all
>>>>> (but it's not me who's merging this code), unless you can squeeze
>>>>> it in
>>>>> as a bug-fix.
>>>> This is in fact a bug fix as PCI on Keystone is broken without this.
>>> Oh, sorry, I didn't realize that this was so urgent. I guess I read
>>> "this adds an important capability" in the cover letter and concluded
>>> that it was new functionality.
>> Bjorn,
>> Thanks for responding.
>> Let me give you some context on this without which my explanation won't
>> be complete. For using PCI driver on Keystone, I had submitted patches
>> related to machine and DTS to the arm mailing list to enable the driver
>> on Keystone. Subsequenty one of the patch from my series was Nack-ed and
>> I was asked to implememented in a different way and started this series.
>> You can refer to the discussion of this at
>> The PCI driver enablement on Keystone is still a working in progress and
>> I am trying to get it fully functional on the upstream. Another missing
>> piece is the SerDes phy driver patch. We have started working on the
>> other part (SerDes phy driver) already as the initial one was not
>> accepted. So it is fine if we are too late for the v3.20 merge window to
>> merge this series and this can be applied to the next branch for v3.21.
>>> Anyway, if it's broken, presumably PCI on Keystone *did* work at one
>>> point. Can you identify the commit that broke it and requires these
>>> fixes, so we can figure out how far the fixes need to be backported?
>> I am trying to get this driver enabled on Keystone by adding the missing
>> pieces as described above. So I guess we don't have to back port
>> anything here.
>>> If I merge it, I would like to get into my for-linus branch and get a
>>> little time in -next before asking Linus to pull it. The merge window
>>> is a little wrinkle there -- I don't like to add new things to the mix
>>> during the window. But if it's an important fix we can still get it
>>> in before the final v3.20.
>> Please apply this to next branch for v3.21. It currently apply cleanly
>> to v3.19-rc7. If you want me rebase to another branch, let me know I can
>> apply and send you an updated patch.
> Bjorn, Arnd,
> I am assuming, Bjorn is going to merge this to his next branch for
> v3.21. If not, it might have to be merged through the arm soc? There are
> a couple of Tested-by and Acked-by received after v7. Do you want me to
> post v8 with these updated in the patches?

These are the updates.
Series was

1) Tested-by: Suravee Suthikulpanit <>
(on AMD Seattle platform w/ PCI Generic Host controller)
2) Acked-by: Will Deacon <>
3) Reviewed-by: Catalin Marinas <>

If you want to send a updated series with these, please let me know.

Thanks and regards,

> Murali
>> Thanks
>> Murali
>>> Bjorn

Murali Karicheri
Linux Kernel, Texas Instruments

 \ /
  Last update: 2015-02-11 18:21    [W:0.067 / U:3.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site