All of lore.kernel.org
 help / color / mirror / Atom feed
From: Murali Karicheri <m-karicheri2@ti.com>
To: Bjorn Helgaas <bhelgaas@google.com>
Cc: linux-arm <linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"open list:INTEL IOMMU (VT-d)" <iommu@lists.linux-foundation.org>,
	Joerg Roedel <joro@8bytes.org>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robh+dt@kernel.org>,
	Will Deacon <will.deacon@arm.com>,
	Russell King <linux@arm.linux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
Subject: Re: [PATCH v4 4/6] of/pci: add of_pci_dma_configure() update dma configuration
Date: Tue, 27 Jan 2015 13:45:46 -0500	[thread overview]
Message-ID: <54C7DCDA.4030809@ti.com> (raw)
In-Reply-To: <CAErSpo4Awgqu0ZtoMm0XSZzhnYtXh3xxH2OJMkyth5YDR9GUiA@mail.gmail.com>

On 01/27/2015 01:42 PM, Bjorn Helgaas wrote:
> On Tue, Jan 27, 2015 at 12:14 PM, Murali Karicheri<m-karicheri2@ti.com>  wrote:
>> On 01/26/2015 06:59 PM, Bjorn Helgaas wrote:
>>>
>>> On Mon, Jan 26, 2015 at 5:25 PM, Murali Karicheri<m-karicheri2@ti.com>
>>> wrote:
>>>>
>>>> On 01/23/2015 06:41 PM, Bjorn Helgaas wrote:
>>>>>
>>>>>
>>>>> On Fri, Jan 23, 2015 at 05:32:37PM -0500, Murali Karicheri wrote:
>>>>>>
>>>>>>
>>>>>> Add of_pci_dma_configure() to allow updating the dma configuration
>>>>>> of the pci device using the configuration from DT of the parent of
>>>>>> the root bridge device.
>>>>>>
>>    -- Cut ---
>>
>>>>>>
>>>>>> Signed-off-by: Murali Karicheri<m-karicheri2@ti.com>
>>>>>> ---
>>>>>>     drivers/of/of_pci.c    |   39
>>>>>> +++++++++++++++++++++++++++++++++++++++
>>>>>>     include/linux/of_pci.h |   12 ++++++++++++
>>>>>>     2 files changed, 51 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
>>>>>> index 88471d3..34878c9 100644
>>>>>> --- a/drivers/of/of_pci.c
>>>>>> +++ b/drivers/of/of_pci.c
>>>>>> @@ -2,6 +2,7 @@
>>>>>>     #include<linux/export.h>
>>>>>>     #include<linux/of.h>
>>>>>>     #include<linux/of_address.h>
>>>>>> +#include<linux/of_device.h>
>>>>>>     #include<linux/of_pci.h>
>>>>>>     #include<linux/slab.h>
>>>>>>
>>>>>> @@ -229,6 +230,44 @@ parse_failed:
>>>>>>           return err;
>>>>>>     }
>>>>>>     EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
>>>>>> +
>>>>>> +/**
>>>>>> + * of_get_pci_root_bridge_parent - get the OF node of the root
>>>>>> bridge's
>>>>>> parent
>>>>>> + * @dev: ptr to pci_dev struct of the pci device
>>>>>> + *
>>>>>> + * This function will traverse the bus up to the root bus starting
>>>>>> with
>>>>>> + * the child and return the OF node ptr to root bridge device's parent
>>>>>> device.
>>>>>> + */
>>>>>> +struct device_node *of_get_pci_root_bridge_parent(struct pci_dev *dev)
>>>>>
>>>>>
>>>>>
>>>>> I'm not an OF person, but this interface seems like it might be too
>>>>> special-purpose.  Maybe it would be enough to add
>>>>> "of_get_pci_root_bridge()", and the caller could do this:
>>>>>
>>>>>        struct device *bridge = of_get_pci_root_bridge(dev);
>>>>>        struct device_node *parent_np = bridge->parent->of_node;
>>>>>
>>>>> Also, the name "of_get_..." suggests that it increments a refcount, as
>>>>> of_get_parent() does.  But you aren't doing anything with the refcount.
>>>>>
>>>>> But I guess an "of_get_pci_root_bridge()" isn't doing anything
>>>>> OF-related,
>>>>> so maybe we should just add a "pci_get_host_bridge(struct pci_dev *)"
>>>>> to PCI instead.
>>>>
>>>>
>>>>
>>>> Bjorn,
>>>>
>>>> Thanks for the comment.
>>>>
>>>> I think adding pci_get_host_bridge() is a good idea. There is already
>>>> similar function in host-bridge.c. I have added this function re-using
>>>> existing function find_pci_root_bus(). See the incremental diff below
>>>> after
>>>> this change. Does this look good?
>>>
>>>
>>> I like the implementation, but I think either we need to take a
>>> reference on the host bridge, or change the name to  something like
>>> "pci_find_host_bridge()", because using "_get_" is conventional for
>>> functions that acquire a reference.
>>>
>>> Since host bridges are hot-pluggable, at least in theory, I vote for
>>> taking a reference.  Then of course, you'd have to add code to drop
>>> the reference when you're finished with it.
>>>
>> Bjorn,
>>
>> Thanks. I agree with your suggestion even though the convention is not
>> followed fully :) of_pci_get_devfn(), of_get_pci_domain_nr(),
>> of_pci_get_host_bridge_resources() are some of those functions not following
>> the convention. I plan to change the function as below. Also want to name
>> functions as pci_get/put_host_bridge_device() as existing function
>> find_pci_host_bridge() is actually returning ptr to struct pci_host_bridge
>> vs the new function returning ptr to device. Here are the new functions and
>> how they will be used. Please review and respond so that I can avoid a
>> re-spin.
>>
>> in linux/include/pci.h add the prototypes of
>> pci_get/put_host_bridge_device().
>>
>> in drivers/pci/host-bridge.c add two new functions.
>>
>> struct device *pci_get_host_bridge_device(struct pci_dev *dev)
>> {
>>          struct pci_bus *root_bus = find_pci_root_bus(dev->bus);
>>          struct device *bridge = root_bus->bridge;
>>
>>          kobject_get(&bridge->kobj);
>>          return bridge;
>> }
>
> Looks good to me.
>
>> void  pci_put_host_bridge_device(struct pci_dev *dev)
>> {
>>          struct pci_bus *root_bus = find_pci_root_bus(dev->bus);
>>          struct device *bridge = root_bus->bridge;
>>
>>          kobject_put(&bridge->kobj);
>> }
>
> I think I would pass in the "struct device *" here so we don't have to
> call find_pci_root_bus() again.
>
>> drivers/of/of_pci.c
>>
>> void of_pci_dma_configure(struct pci_dev *pci_dev)
>> {
>>          struct device *dev =&pci_dev->dev;
>>          struct device *bridge = pci_get_host_bridge_device(pci_dev);
>>
>>          of_dma_configure(dev, bridge->parent->of_node);
>>          pci_put_host_bridge_device(pci_dev);
>
> Then this would become "pci_put_host_bridge_device(bridge)"

Agree with both. Will become part of my v5 of the series. I am adding 
this as a separate commit.

Murali
>
>> }
>>
>> Murali
>>
>>> Bjorn
>>>
>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Murali Karicheri
>>>> Linux Kernel, Texas Instruments
>>
>>
>>
>> --
>> Murali Karicheri
>> Linux Kernel, Texas Instruments


-- 
Murali Karicheri
Linux Kernel, Texas Instruments

WARNING: multiple messages have this Message-ID (diff)
From: Murali Karicheri <m-karicheri2-l0cyMroinI0@public.gmane.org>
To: Bjorn Helgaas <bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	"linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"open list:INTEL IOMMU (VT-d)"
	<iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org>,
	Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Grant Likely
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	linux-arm
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH v4 4/6] of/pci: add of_pci_dma_configure() update dma configuration
Date: Tue, 27 Jan 2015 13:45:46 -0500	[thread overview]
Message-ID: <54C7DCDA.4030809@ti.com> (raw)
In-Reply-To: <CAErSpo4Awgqu0ZtoMm0XSZzhnYtXh3xxH2OJMkyth5YDR9GUiA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 01/27/2015 01:42 PM, Bjorn Helgaas wrote:
> On Tue, Jan 27, 2015 at 12:14 PM, Murali Karicheri<m-karicheri2-l0cyMroinI0@public.gmane.org>  wrote:
>> On 01/26/2015 06:59 PM, Bjorn Helgaas wrote:
>>>
>>> On Mon, Jan 26, 2015 at 5:25 PM, Murali Karicheri<m-karicheri2-l0cyMroinI0@public.gmane.org>
>>> wrote:
>>>>
>>>> On 01/23/2015 06:41 PM, Bjorn Helgaas wrote:
>>>>>
>>>>>
>>>>> On Fri, Jan 23, 2015 at 05:32:37PM -0500, Murali Karicheri wrote:
>>>>>>
>>>>>>
>>>>>> Add of_pci_dma_configure() to allow updating the dma configuration
>>>>>> of the pci device using the configuration from DT of the parent of
>>>>>> the root bridge device.
>>>>>>
>>    -- Cut ---
>>
>>>>>>
>>>>>> Signed-off-by: Murali Karicheri<m-karicheri2-l0cyMroinI0@public.gmane.org>
>>>>>> ---
>>>>>>     drivers/of/of_pci.c    |   39
>>>>>> +++++++++++++++++++++++++++++++++++++++
>>>>>>     include/linux/of_pci.h |   12 ++++++++++++
>>>>>>     2 files changed, 51 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
>>>>>> index 88471d3..34878c9 100644
>>>>>> --- a/drivers/of/of_pci.c
>>>>>> +++ b/drivers/of/of_pci.c
>>>>>> @@ -2,6 +2,7 @@
>>>>>>     #include<linux/export.h>
>>>>>>     #include<linux/of.h>
>>>>>>     #include<linux/of_address.h>
>>>>>> +#include<linux/of_device.h>
>>>>>>     #include<linux/of_pci.h>
>>>>>>     #include<linux/slab.h>
>>>>>>
>>>>>> @@ -229,6 +230,44 @@ parse_failed:
>>>>>>           return err;
>>>>>>     }
>>>>>>     EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
>>>>>> +
>>>>>> +/**
>>>>>> + * of_get_pci_root_bridge_parent - get the OF node of the root
>>>>>> bridge's
>>>>>> parent
>>>>>> + * @dev: ptr to pci_dev struct of the pci device
>>>>>> + *
>>>>>> + * This function will traverse the bus up to the root bus starting
>>>>>> with
>>>>>> + * the child and return the OF node ptr to root bridge device's parent
>>>>>> device.
>>>>>> + */
>>>>>> +struct device_node *of_get_pci_root_bridge_parent(struct pci_dev *dev)
>>>>>
>>>>>
>>>>>
>>>>> I'm not an OF person, but this interface seems like it might be too
>>>>> special-purpose.  Maybe it would be enough to add
>>>>> "of_get_pci_root_bridge()", and the caller could do this:
>>>>>
>>>>>        struct device *bridge = of_get_pci_root_bridge(dev);
>>>>>        struct device_node *parent_np = bridge->parent->of_node;
>>>>>
>>>>> Also, the name "of_get_..." suggests that it increments a refcount, as
>>>>> of_get_parent() does.  But you aren't doing anything with the refcount.
>>>>>
>>>>> But I guess an "of_get_pci_root_bridge()" isn't doing anything
>>>>> OF-related,
>>>>> so maybe we should just add a "pci_get_host_bridge(struct pci_dev *)"
>>>>> to PCI instead.
>>>>
>>>>
>>>>
>>>> Bjorn,
>>>>
>>>> Thanks for the comment.
>>>>
>>>> I think adding pci_get_host_bridge() is a good idea. There is already
>>>> similar function in host-bridge.c. I have added this function re-using
>>>> existing function find_pci_root_bus(). See the incremental diff below
>>>> after
>>>> this change. Does this look good?
>>>
>>>
>>> I like the implementation, but I think either we need to take a
>>> reference on the host bridge, or change the name to  something like
>>> "pci_find_host_bridge()", because using "_get_" is conventional for
>>> functions that acquire a reference.
>>>
>>> Since host bridges are hot-pluggable, at least in theory, I vote for
>>> taking a reference.  Then of course, you'd have to add code to drop
>>> the reference when you're finished with it.
>>>
>> Bjorn,
>>
>> Thanks. I agree with your suggestion even though the convention is not
>> followed fully :) of_pci_get_devfn(), of_get_pci_domain_nr(),
>> of_pci_get_host_bridge_resources() are some of those functions not following
>> the convention. I plan to change the function as below. Also want to name
>> functions as pci_get/put_host_bridge_device() as existing function
>> find_pci_host_bridge() is actually returning ptr to struct pci_host_bridge
>> vs the new function returning ptr to device. Here are the new functions and
>> how they will be used. Please review and respond so that I can avoid a
>> re-spin.
>>
>> in linux/include/pci.h add the prototypes of
>> pci_get/put_host_bridge_device().
>>
>> in drivers/pci/host-bridge.c add two new functions.
>>
>> struct device *pci_get_host_bridge_device(struct pci_dev *dev)
>> {
>>          struct pci_bus *root_bus = find_pci_root_bus(dev->bus);
>>          struct device *bridge = root_bus->bridge;
>>
>>          kobject_get(&bridge->kobj);
>>          return bridge;
>> }
>
> Looks good to me.
>
>> void  pci_put_host_bridge_device(struct pci_dev *dev)
>> {
>>          struct pci_bus *root_bus = find_pci_root_bus(dev->bus);
>>          struct device *bridge = root_bus->bridge;
>>
>>          kobject_put(&bridge->kobj);
>> }
>
> I think I would pass in the "struct device *" here so we don't have to
> call find_pci_root_bus() again.
>
>> drivers/of/of_pci.c
>>
>> void of_pci_dma_configure(struct pci_dev *pci_dev)
>> {
>>          struct device *dev =&pci_dev->dev;
>>          struct device *bridge = pci_get_host_bridge_device(pci_dev);
>>
>>          of_dma_configure(dev, bridge->parent->of_node);
>>          pci_put_host_bridge_device(pci_dev);
>
> Then this would become "pci_put_host_bridge_device(bridge)"

Agree with both. Will become part of my v5 of the series. I am adding 
this as a separate commit.

Murali
>
>> }
>>
>> Murali
>>
>>> Bjorn
>>>
>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Murali Karicheri
>>>> Linux Kernel, Texas Instruments
>>
>>
>>
>> --
>> Murali Karicheri
>> Linux Kernel, Texas Instruments


-- 
Murali Karicheri
Linux Kernel, Texas Instruments

WARNING: multiple messages have this Message-ID (diff)
From: m-karicheri2@ti.com (Murali Karicheri)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 4/6] of/pci: add of_pci_dma_configure() update dma configuration
Date: Tue, 27 Jan 2015 13:45:46 -0500	[thread overview]
Message-ID: <54C7DCDA.4030809@ti.com> (raw)
In-Reply-To: <CAErSpo4Awgqu0ZtoMm0XSZzhnYtXh3xxH2OJMkyth5YDR9GUiA@mail.gmail.com>

On 01/27/2015 01:42 PM, Bjorn Helgaas wrote:
> On Tue, Jan 27, 2015 at 12:14 PM, Murali Karicheri<m-karicheri2@ti.com>  wrote:
>> On 01/26/2015 06:59 PM, Bjorn Helgaas wrote:
>>>
>>> On Mon, Jan 26, 2015 at 5:25 PM, Murali Karicheri<m-karicheri2@ti.com>
>>> wrote:
>>>>
>>>> On 01/23/2015 06:41 PM, Bjorn Helgaas wrote:
>>>>>
>>>>>
>>>>> On Fri, Jan 23, 2015 at 05:32:37PM -0500, Murali Karicheri wrote:
>>>>>>
>>>>>>
>>>>>> Add of_pci_dma_configure() to allow updating the dma configuration
>>>>>> of the pci device using the configuration from DT of the parent of
>>>>>> the root bridge device.
>>>>>>
>>    -- Cut ---
>>
>>>>>>
>>>>>> Signed-off-by: Murali Karicheri<m-karicheri2@ti.com>
>>>>>> ---
>>>>>>     drivers/of/of_pci.c    |   39
>>>>>> +++++++++++++++++++++++++++++++++++++++
>>>>>>     include/linux/of_pci.h |   12 ++++++++++++
>>>>>>     2 files changed, 51 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
>>>>>> index 88471d3..34878c9 100644
>>>>>> --- a/drivers/of/of_pci.c
>>>>>> +++ b/drivers/of/of_pci.c
>>>>>> @@ -2,6 +2,7 @@
>>>>>>     #include<linux/export.h>
>>>>>>     #include<linux/of.h>
>>>>>>     #include<linux/of_address.h>
>>>>>> +#include<linux/of_device.h>
>>>>>>     #include<linux/of_pci.h>
>>>>>>     #include<linux/slab.h>
>>>>>>
>>>>>> @@ -229,6 +230,44 @@ parse_failed:
>>>>>>           return err;
>>>>>>     }
>>>>>>     EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
>>>>>> +
>>>>>> +/**
>>>>>> + * of_get_pci_root_bridge_parent - get the OF node of the root
>>>>>> bridge's
>>>>>> parent
>>>>>> + * @dev: ptr to pci_dev struct of the pci device
>>>>>> + *
>>>>>> + * This function will traverse the bus up to the root bus starting
>>>>>> with
>>>>>> + * the child and return the OF node ptr to root bridge device's parent
>>>>>> device.
>>>>>> + */
>>>>>> +struct device_node *of_get_pci_root_bridge_parent(struct pci_dev *dev)
>>>>>
>>>>>
>>>>>
>>>>> I'm not an OF person, but this interface seems like it might be too
>>>>> special-purpose.  Maybe it would be enough to add
>>>>> "of_get_pci_root_bridge()", and the caller could do this:
>>>>>
>>>>>        struct device *bridge = of_get_pci_root_bridge(dev);
>>>>>        struct device_node *parent_np = bridge->parent->of_node;
>>>>>
>>>>> Also, the name "of_get_..." suggests that it increments a refcount, as
>>>>> of_get_parent() does.  But you aren't doing anything with the refcount.
>>>>>
>>>>> But I guess an "of_get_pci_root_bridge()" isn't doing anything
>>>>> OF-related,
>>>>> so maybe we should just add a "pci_get_host_bridge(struct pci_dev *)"
>>>>> to PCI instead.
>>>>
>>>>
>>>>
>>>> Bjorn,
>>>>
>>>> Thanks for the comment.
>>>>
>>>> I think adding pci_get_host_bridge() is a good idea. There is already
>>>> similar function in host-bridge.c. I have added this function re-using
>>>> existing function find_pci_root_bus(). See the incremental diff below
>>>> after
>>>> this change. Does this look good?
>>>
>>>
>>> I like the implementation, but I think either we need to take a
>>> reference on the host bridge, or change the name to  something like
>>> "pci_find_host_bridge()", because using "_get_" is conventional for
>>> functions that acquire a reference.
>>>
>>> Since host bridges are hot-pluggable, at least in theory, I vote for
>>> taking a reference.  Then of course, you'd have to add code to drop
>>> the reference when you're finished with it.
>>>
>> Bjorn,
>>
>> Thanks. I agree with your suggestion even though the convention is not
>> followed fully :) of_pci_get_devfn(), of_get_pci_domain_nr(),
>> of_pci_get_host_bridge_resources() are some of those functions not following
>> the convention. I plan to change the function as below. Also want to name
>> functions as pci_get/put_host_bridge_device() as existing function
>> find_pci_host_bridge() is actually returning ptr to struct pci_host_bridge
>> vs the new function returning ptr to device. Here are the new functions and
>> how they will be used. Please review and respond so that I can avoid a
>> re-spin.
>>
>> in linux/include/pci.h add the prototypes of
>> pci_get/put_host_bridge_device().
>>
>> in drivers/pci/host-bridge.c add two new functions.
>>
>> struct device *pci_get_host_bridge_device(struct pci_dev *dev)
>> {
>>          struct pci_bus *root_bus = find_pci_root_bus(dev->bus);
>>          struct device *bridge = root_bus->bridge;
>>
>>          kobject_get(&bridge->kobj);
>>          return bridge;
>> }
>
> Looks good to me.
>
>> void  pci_put_host_bridge_device(struct pci_dev *dev)
>> {
>>          struct pci_bus *root_bus = find_pci_root_bus(dev->bus);
>>          struct device *bridge = root_bus->bridge;
>>
>>          kobject_put(&bridge->kobj);
>> }
>
> I think I would pass in the "struct device *" here so we don't have to
> call find_pci_root_bus() again.
>
>> drivers/of/of_pci.c
>>
>> void of_pci_dma_configure(struct pci_dev *pci_dev)
>> {
>>          struct device *dev =&pci_dev->dev;
>>          struct device *bridge = pci_get_host_bridge_device(pci_dev);
>>
>>          of_dma_configure(dev, bridge->parent->of_node);
>>          pci_put_host_bridge_device(pci_dev);
>
> Then this would become "pci_put_host_bridge_device(bridge)"

Agree with both. Will become part of my v5 of the series. I am adding 
this as a separate commit.

Murali
>
>> }
>>
>> Murali
>>
>>> Bjorn
>>>
>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Murali Karicheri
>>>> Linux Kernel, Texas Instruments
>>
>>
>>
>> --
>> Murali Karicheri
>> Linux Kernel, Texas Instruments


-- 
Murali Karicheri
Linux Kernel, Texas Instruments

  reply	other threads:[~2015-01-27 18:46 UTC|newest]

Thread overview: 159+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-23 22:32 [PATCH v4 0/6] PCI: get DMA configuration from parent device Murali Karicheri
2015-01-23 22:32 ` Murali Karicheri
2015-01-23 22:32 ` Murali Karicheri
2015-01-23 22:32 ` [PATCH v4 1/6] of: iommu: add ptr to OF node arg to of_iommu_configure() Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-25 13:32   ` Laurent Pinchart
2015-01-25 13:32     ` Laurent Pinchart
2015-01-25 13:32     ` Laurent Pinchart
2015-01-26 18:49     ` Murali Karicheri
2015-01-26 18:49       ` Murali Karicheri
2015-01-26 18:49       ` Murali Karicheri
2015-01-28 11:33       ` Will Deacon
2015-01-28 11:33         ` Will Deacon
2015-01-28 11:33         ` Will Deacon
2015-01-28 11:33         ` Will Deacon
2015-01-28 12:23         ` Laurent Pinchart
2015-01-28 12:23           ` Laurent Pinchart
2015-01-28 12:23           ` Laurent Pinchart
2015-01-28 12:23           ` Laurent Pinchart
2015-01-28 12:29           ` Will Deacon
2015-01-28 12:29             ` Will Deacon
2015-01-28 12:29             ` Will Deacon
2015-01-28 12:29             ` Will Deacon
2015-01-28 13:15             ` Laurent Pinchart
2015-01-28 13:15               ` Laurent Pinchart
2015-01-28 13:15               ` Laurent Pinchart
2015-01-28 13:15               ` Laurent Pinchart
2015-01-28 13:32               ` Will Deacon
2015-01-28 13:32                 ` Will Deacon
2015-01-28 13:32                 ` Will Deacon
2015-01-28 13:32                 ` Will Deacon
2015-01-28 15:21                 ` Murali Karicheri
2015-01-28 15:21                   ` Murali Karicheri
2015-01-28 15:21                   ` Murali Karicheri
2015-01-28 15:21                   ` Murali Karicheri
2015-01-28 23:32                 ` Laurent Pinchart
2015-01-28 23:32                   ` Laurent Pinchart
2015-01-28 23:32                   ` Laurent Pinchart
2015-01-28 23:32                   ` Laurent Pinchart
2015-01-29 14:59                   ` Murali Karicheri
2015-01-29 14:59                     ` Murali Karicheri
2015-01-29 14:59                     ` Murali Karicheri
2015-01-29 14:59                     ` Murali Karicheri
2015-01-29 16:49                   ` Rob Herring
2015-01-29 16:49                     ` Rob Herring
2015-01-29 16:49                     ` Rob Herring
2015-01-29 16:49                     ` Rob Herring
2015-01-30  0:24                     ` Laurent Pinchart
2015-01-30  0:24                       ` Laurent Pinchart
2015-01-30  0:24                       ` Laurent Pinchart
2015-01-30  0:24                       ` Laurent Pinchart
2015-01-30 15:23                       ` Murali Karicheri
2015-01-30 15:23                         ` Murali Karicheri
2015-01-30 15:23                         ` Murali Karicheri
2015-01-30 15:23                         ` Murali Karicheri
2015-01-23 22:32 ` [PATCH v4 2/6] of: move of_dma_configure() to device.c to help re-use Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 22:32 ` [PATCH v4 3/6] of: fix size when dma-range is not used Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-27 11:27   ` Robin Murphy
2015-01-27 11:27     ` Robin Murphy
2015-01-27 11:27     ` Robin Murphy
2015-01-27 15:44     ` Murali Karicheri
2015-01-27 15:44       ` Murali Karicheri
2015-01-27 15:44       ` Murali Karicheri
2015-01-27 18:55     ` Murali Karicheri
2015-01-27 18:55       ` Murali Karicheri
2015-01-27 18:55       ` Murali Karicheri
2015-01-27 18:55       ` Murali Karicheri
2015-01-28 11:05       ` Catalin Marinas
2015-01-28 11:05         ` Catalin Marinas
2015-01-28 11:05         ` Catalin Marinas
2015-01-28 11:05         ` Catalin Marinas
2015-01-28 15:45         ` Rob Herring
2015-01-28 15:45           ` Rob Herring
2015-01-28 15:45           ` Rob Herring
2015-01-28 15:45           ` Rob Herring
2015-01-28 17:23           ` Catalin Marinas
2015-01-28 17:23             ` Catalin Marinas
2015-01-28 17:23             ` Catalin Marinas
2015-01-28 17:23             ` Catalin Marinas
2015-01-28 17:34           ` Murali Karicheri
2015-01-28 17:34             ` Murali Karicheri
2015-01-28 17:34             ` Murali Karicheri
2015-01-28 17:34             ` Murali Karicheri
2015-01-28 15:55         ` Robin Murphy
2015-01-28 15:55           ` Robin Murphy
2015-01-28 15:55           ` Robin Murphy
2015-01-28 15:55           ` Robin Murphy
2015-01-28 17:30           ` Catalin Marinas
2015-01-28 17:30             ` Catalin Marinas
2015-01-28 17:30             ` Catalin Marinas
2015-01-28 17:30             ` Catalin Marinas
2015-01-30 18:06             ` Murali Karicheri
2015-01-30 18:06               ` Murali Karicheri
2015-01-30 18:06               ` Murali Karicheri
2015-02-02 12:18               ` Catalin Marinas
2015-02-02 12:18                 ` Catalin Marinas
2015-02-02 12:18                 ` Catalin Marinas
2015-02-02 12:18                 ` Catalin Marinas
2015-02-02 16:10                 ` Murali Karicheri
2015-02-02 16:10                   ` Murali Karicheri
2015-02-02 16:10                   ` Murali Karicheri
2015-02-02 16:10                   ` Murali Karicheri
2015-02-05 21:42                 ` Murali Karicheri
2015-02-05 21:42                   ` Murali Karicheri
2015-02-05 21:42                   ` Murali Karicheri
2015-02-05 22:44                   ` Catalin Marinas
2015-02-05 22:44                     ` Catalin Marinas
2015-02-05 22:44                     ` Catalin Marinas
2015-02-05 22:44                     ` Catalin Marinas
2015-01-23 22:32 ` [PATCH v4 4/6] of/pci: add of_pci_dma_configure() update dma configuration Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 23:41   ` Bjorn Helgaas
2015-01-23 23:41     ` Bjorn Helgaas
2015-01-23 23:41     ` Bjorn Helgaas
2015-01-26 23:25     ` Murali Karicheri
2015-01-26 23:25       ` Murali Karicheri
2015-01-26 23:25       ` Murali Karicheri
2015-01-26 23:59       ` Bjorn Helgaas
2015-01-26 23:59         ` Bjorn Helgaas
2015-01-26 23:59         ` Bjorn Helgaas
2015-01-27 18:14         ` Murali Karicheri
2015-01-27 18:14           ` Murali Karicheri
2015-01-27 18:14           ` Murali Karicheri
2015-01-27 18:42           ` Bjorn Helgaas
2015-01-27 18:42             ` Bjorn Helgaas
2015-01-27 18:42             ` Bjorn Helgaas
2015-01-27 18:45             ` Murali Karicheri [this message]
2015-01-27 18:45               ` Murali Karicheri
2015-01-27 18:45               ` Murali Karicheri
2015-01-23 22:32 ` [PATCH v4 5/6] PCI: update dma configuration from DT Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 23:27   ` Bjorn Helgaas
2015-01-23 23:27     ` Bjorn Helgaas
2015-01-23 23:27     ` Bjorn Helgaas
2015-01-26 23:28     ` Murali Karicheri
2015-01-26 23:28       ` Murali Karicheri
2015-01-26 23:28       ` Murali Karicheri
2015-01-23 22:32 ` [PATCH v4 6/6] arm: dma-mapping: updates to limit dma_mask and iommu mapping size Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-23 22:32   ` Murali Karicheri
2015-01-27 11:12   ` Robin Murphy
2015-01-27 11:12     ` Robin Murphy
2015-01-27 11:12     ` Robin Murphy
2015-01-27 11:12     ` Robin Murphy
2015-01-27 11:34     ` Catalin Marinas
2015-01-27 11:34       ` Catalin Marinas
2015-01-27 11:34       ` Catalin Marinas
2015-01-27 11:34       ` Catalin Marinas
2015-01-27 15:19       ` Murali Karicheri
2015-01-27 15:19         ` Murali Karicheri
2015-01-27 15:19         ` Murali Karicheri
2015-01-27 15:19         ` Murali Karicheri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54C7DCDA.4030809@ti.com \
    --to=m-karicheri2@ti.com \
    --cc=Suravee.Suthikulpanit@amd.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=robh+dt@kernel.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.