Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters
On Sat, May 6, 2017 at 11:00 AM, Oza Oza wrote:
> On Fri, May 5, 2017 at 8:55 PM, Robin Murphy wrote:
>> On 04/05/17 19:41, Oza Oza wrote:
>> [...]
> 5) leaves scope of adding PCI flag handling for inbound memory
> by the new function.
Which flags would ever actually matter? DMA windows aren't going to be
to config or I/O space, so the memory type can be assumed, and the
32/64-bit distinction is irrelevant as it's not a relocatable BAR;
DMA-able system memory isn't going to be read-sensitive, so the
prefetchable flag shouldn't matter; and not being a BAR none of the
others would be relevant either.
>>>
>>> Thanks Robin; for your reply and attention:
>>>
>>> agree with you, at present it would not matter,
>>> but it does not mean that we do not scope it to make it matter in future.
>>>
>>> now where it could matter:
>>> there is Relaxed Ordering for inbound memory for PCI.
>>> According to standard, Relaxed Ordering (RO) bit can be set only for
>>> Memory requests and completions (if present in the original request).
>>> Also, according to transaction ordering rules, I/O and configuration
>>> requests can still be re-ordered ahead of each other.
>>> and we would like to make use of it.
>>> for e.g. lets say we mark memory as Relaxed Ordered with flag.
>>> the special about this memory is incoming PCI transactions can be
>>> reordered and rest memory has to be strongly ordered.
>>
>> Please look at "PCI Bus Binding to: IEEE Std 1275-1994 Standard for Boot
>> (Initialization Configuration) Firmware" (as referenced in DTSpec) and
>> explain how PCIe Relaxed Order has anything to do with the DT binding.
>>
>>> how it our SOC would make use of this is out of scope for the
>>> discussion at this point of time, but I am just bringing in the
>>> idea/point how flags could be useful
>>> for inbound memory, since we would not like throw-away flags completely.
>>
>> The premise for implementing a PCI-specific parser is that you claim we
>> need to do something with the phys.hi cell of a DT PCI address, rather
>> than just taking the numerical part out of the phys.mid and phys.lo
>> cells. Please make that argument in reference to the flags which that
>> upper cell actually encodes, not unrelated things.
>>
>
> I think, the whole discussion around inbound flags is not what I
> intended to bring.
> this patch does nothing about inbound flag and never intends to solve
> anything regarding inbound flags.
> infact I would like to remove point 5 form the commit message. which
> should keep it out of discussion completely.
>
> let met tell what this patch is trying to address/solve 2 BUGs
> 1) fix wrong size return from of_dma_configure for PCI masters. (which
> is right now BUG)
>
> 2) handles multiple dma-ranges cleanly
>
> 3) It takes care of dma-ranges being optional.
>
> 4) following is the comment on function of_dma_get_range (which is also a BUG)
> "It returns -ENODEV if "dma-ranges" property was not found
> * for this device in DT."
> which I think is wrong for PCI device, because if dma-ranges are
> absent then instead of returning -ENODEV,
> it should return 0 with largest possible host memory.
>
> it solves all the above 4 problems.
>
>> [...]
> +int of_pci_get_dma_ranges(struct device_node *np, struct list_head
> *resources)
> +{
> + struct device_node *node = of_node_get(np);
> + int rlen;
> + int ret = 0;
> + const int na = 3, ns = 2;
> + struct resource *res;
> + struct of_pci_range_parser parser;
> + struct of_pci_range range;
> +
> + if (!node)
> + return -EINVAL;
> +
> + parser.node = node;
> + parser.pna = of_n_addr_cells(node);
> + parser.np = parser.pna + na + ns;
> +
> + parser.range = of_get_property(node, "dma-ranges", &rlen);
> +
> + if (!parser.range) {
> + pr_debug("pcie device has no dma-ranges defined for
> node(%s)\n",
> + np->full_name);
> + ret = -EINVAL;
> + goto out;
> + }
> +
> + parser.end = parser.range + rlen / sizeof(__be32);
> +
> + for_each_of_pci_range(&parser, &range) {
This is plain wrong - of_pci_range_parser_one() will translate upwards
through parent "ranges" properties, which is completely backwards for
DMA addresses.
Robin.
>>>
>>> No it does not, this patch is thoroughly tested on our SOC and it works.
>>> of_pci_range_parser_one does not translate upwards through parent. it
>>> just sticks to given PCI parser.
>>
>> Frankly, I'm losing patience with this attitude. Please look at the code
>> you call:
>>
>> #define for_each_of_pci_range(parser, range) \
>> for (; of_pci_range_parser_one(parser, range);)
>>
>>
>> struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser
>> *parser,
>
Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters
On Fri, May 5, 2017 at 8:55 PM, Robin Murphy wrote:
> On 04/05/17 19:41, Oza Oza wrote:
> [...]
5) leaves scope of adding PCI flag handling for inbound memory
by the new function.
>>>
>>> Which flags would ever actually matter? DMA windows aren't going to be
>>> to config or I/O space, so the memory type can be assumed, and the
>>> 32/64-bit distinction is irrelevant as it's not a relocatable BAR;
>>> DMA-able system memory isn't going to be read-sensitive, so the
>>> prefetchable flag shouldn't matter; and not being a BAR none of the
>>> others would be relevant either.
>>>
>>
>> Thanks Robin; for your reply and attention:
>>
>> agree with you, at present it would not matter,
>> but it does not mean that we do not scope it to make it matter in future.
>>
>> now where it could matter:
>> there is Relaxed Ordering for inbound memory for PCI.
>> According to standard, Relaxed Ordering (RO) bit can be set only for
>> Memory requests and completions (if present in the original request).
>> Also, according to transaction ordering rules, I/O and configuration
>> requests can still be re-ordered ahead of each other.
>> and we would like to make use of it.
>> for e.g. lets say we mark memory as Relaxed Ordered with flag.
>> the special about this memory is incoming PCI transactions can be
>> reordered and rest memory has to be strongly ordered.
>
> Please look at "PCI Bus Binding to: IEEE Std 1275-1994 Standard for Boot
> (Initialization Configuration) Firmware" (as referenced in DTSpec) and
> explain how PCIe Relaxed Order has anything to do with the DT binding.
>
>> how it our SOC would make use of this is out of scope for the
>> discussion at this point of time, but I am just bringing in the
>> idea/point how flags could be useful
>> for inbound memory, since we would not like throw-away flags completely.
>
> The premise for implementing a PCI-specific parser is that you claim we
> need to do something with the phys.hi cell of a DT PCI address, rather
> than just taking the numerical part out of the phys.mid and phys.lo
> cells. Please make that argument in reference to the flags which that
> upper cell actually encodes, not unrelated things.
>
I think, the whole discussion around inbound flags is not what I
intended to bring.
this patch does nothing about inbound flag and never intends to solve
anything regarding inbound flags.
infact I would like to remove point 5 form the commit message. which
should keep it out of discussion completely.
let met tell what this patch is trying to address/solve 2 BUGs
1) fix wrong size return from of_dma_configure for PCI masters. (which
is right now BUG)
2) handles multiple dma-ranges cleanly
3) It takes care of dma-ranges being optional.
4) following is the comment on function of_dma_get_range (which is also a BUG)
"It returns -ENODEV if "dma-ranges" property was not found
* for this device in DT."
which I think is wrong for PCI device, because if dma-ranges are
absent then instead of returning -ENODEV,
it should return 0 with largest possible host memory.
it solves all the above 4 problems.
> [...]
+int of_pci_get_dma_ranges(struct device_node *np, struct list_head
*resources)
+{
+ struct device_node *node = of_node_get(np);
+ int rlen;
+ int ret = 0;
+ const int na = 3, ns = 2;
+ struct resource *res;
+ struct of_pci_range_parser parser;
+ struct of_pci_range range;
+
+ if (!node)
+ return -EINVAL;
+
+ parser.node = node;
+ parser.pna = of_n_addr_cells(node);
+ parser.np = parser.pna + na + ns;
+
+ parser.range = of_get_property(node, "dma-ranges", &rlen);
+
+ if (!parser.range) {
+ pr_debug("pcie device has no dma-ranges defined for
node(%s)\n",
+ np->full_name);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ parser.end = parser.range + rlen / sizeof(__be32);
+
+ for_each_of_pci_range(&parser, &range) {
>>>
>>> This is plain wrong - of_pci_range_parser_one() will translate upwards
>>> through parent "ranges" properties, which is completely backwards for
>>> DMA addresses.
>>>
>>> Robin.
>>>
>>
>> No it does not, this patch is thoroughly tested on our SOC and it works.
>> of_pci_range_parser_one does not translate upwards through parent. it
>> just sticks to given PCI parser.
>
> Frankly, I'm losing patience with this attitude. Please look at the code
> you call:
>
> #define for_each_of_pci_range(parser, range) \
> for (; of_pci_range_parser_one(parser, range);)
>
>
> struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser
> *parser,
> struct of_pci_range *range)
> {
> const int na = 3, ns = 2;
>
> if (!range)
> return NULL;
>
> if (!pa
Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters
On 04/05/17 19:41, Oza Oza wrote:
[...]
>>> 5) leaves scope of adding PCI flag handling for inbound memory
>>> by the new function.
>>
>> Which flags would ever actually matter? DMA windows aren't going to be
>> to config or I/O space, so the memory type can be assumed, and the
>> 32/64-bit distinction is irrelevant as it's not a relocatable BAR;
>> DMA-able system memory isn't going to be read-sensitive, so the
>> prefetchable flag shouldn't matter; and not being a BAR none of the
>> others would be relevant either.
>>
>
> Thanks Robin; for your reply and attention:
>
> agree with you, at present it would not matter,
> but it does not mean that we do not scope it to make it matter in future.
>
> now where it could matter:
> there is Relaxed Ordering for inbound memory for PCI.
> According to standard, Relaxed Ordering (RO) bit can be set only for
> Memory requests and completions (if present in the original request).
> Also, according to transaction ordering rules, I/O and configuration
> requests can still be re-ordered ahead of each other.
> and we would like to make use of it.
> for e.g. lets say we mark memory as Relaxed Ordered with flag.
> the special about this memory is incoming PCI transactions can be
> reordered and rest memory has to be strongly ordered.
Please look at "PCI Bus Binding to: IEEE Std 1275-1994 Standard for Boot
(Initialization Configuration) Firmware" (as referenced in DTSpec) and
explain how PCIe Relaxed Order has anything to do with the DT binding.
> how it our SOC would make use of this is out of scope for the
> discussion at this point of time, but I am just bringing in the
> idea/point how flags could be useful
> for inbound memory, since we would not like throw-away flags completely.
The premise for implementing a PCI-specific parser is that you claim we
need to do something with the phys.hi cell of a DT PCI address, rather
than just taking the numerical part out of the phys.mid and phys.lo
cells. Please make that argument in reference to the flags which that
upper cell actually encodes, not unrelated things.
[...]
>>> +int of_pci_get_dma_ranges(struct device_node *np, struct list_head
>>> *resources)
>>> +{
>>> + struct device_node *node = of_node_get(np);
>>> + int rlen;
>>> + int ret = 0;
>>> + const int na = 3, ns = 2;
>>> + struct resource *res;
>>> + struct of_pci_range_parser parser;
>>> + struct of_pci_range range;
>>> +
>>> + if (!node)
>>> + return -EINVAL;
>>> +
>>> + parser.node = node;
>>> + parser.pna = of_n_addr_cells(node);
>>> + parser.np = parser.pna + na + ns;
>>> +
>>> + parser.range = of_get_property(node, "dma-ranges", &rlen);
>>> +
>>> + if (!parser.range) {
>>> + pr_debug("pcie device has no dma-ranges defined for
>>> node(%s)\n",
>>> + np->full_name);
>>> + ret = -EINVAL;
>>> + goto out;
>>> + }
>>> +
>>> + parser.end = parser.range + rlen / sizeof(__be32);
>>> +
>>> + for_each_of_pci_range(&parser, &range) {
>>
>> This is plain wrong - of_pci_range_parser_one() will translate upwards
>> through parent "ranges" properties, which is completely backwards for
>> DMA addresses.
>>
>> Robin.
>>
>
> No it does not, this patch is thoroughly tested on our SOC and it works.
> of_pci_range_parser_one does not translate upwards through parent. it
> just sticks to given PCI parser.
Frankly, I'm losing patience with this attitude. Please look at the code
you call:
#define for_each_of_pci_range(parser, range) \
for (; of_pci_range_parser_one(parser, range);)
struct of_pci_range *of_pci_range_parser_one(struct of_pci_range_parser
*parser,
struct of_pci_range *range)
{
const int na = 3, ns = 2;
if (!range)
return NULL;
if (!parser->range || parser->range + parser->np > parser->end)
return NULL;
range->pci_space = parser->range[0];
range->flags = of_bus_pci_get_flags(parser->range);
range->pci_addr = of_read_number(parser->range + 1, ns);
range->cpu_addr = of_translate_address(parser->node,
parser->range + na);
...
u64 of_translate_address(struct device_node *dev, const __be32 *in_addr)
{
return __of_translate_address(dev, in_addr, "ranges");
}
I don't doubt that you still manage to get the right result on *your*
SoC, because you probably have neither further "ranges" nor "dma-ranges"
translations above your host controller node anyway. That does not
change the fact that the proposed code is still obviously wrong for more
complex DT topologies that do.
We're doing upstream work in core code here: I don't particularly care
about making your SoC work; I don't really care about making Juno work
properly either; what I do care about is that code to parse dma-ranges
actually parses dma-ranges *correctly* for all possible valid uses of
dm
Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters
On Thu, May 4, 2017 at 11:32 PM, Robin Murphy wrote:
> [apologies for the silence - I've been on holiday]
>
> On 03/05/17 05:46, Oza Pawandeep wrote:
>> current device framework and of framework integration assumes
>> dma-ranges in a way where memory-mapped devices define their
>> dma-ranges. (child-bus-address, parent-bus-address, length).
>
> Well, yes, that is simply the definition of dma-ranges, and remains true
> regardless of the particular format of either bus address.
>
>> of_dma_configure is specifically written to take care of memory
>> mapped devices. but no implementation exists for pci to take
>> care of pcie based memory ranges.
>
> That still doesn't make sense. To repeat myself again, PCI devices *ARE*
> memory-mapped devices. Yes, there do exist some platforms where I/O
> space is not treated as MMIO, but config space and memory space are very
> much memory-mapped however you look at them, and in the context of DMA,
> only memory space is relevant anyway.
>
> What *is* true about the current code is that of_dma_get_range() expects
> to be passed an OF node representing the device itself, and doesn't work
> properly when passed the node of the device's parent bus directly, which
> happens to be what pci_dma_configure() currently does. That's the only
> reason why it doesn't work for (single-entry) host controller dma-ranges
> today. This does not mean it's a PCI problem, it is simply the case that
> pci_dma_configure() is the only caller currently hitting it. Other
> discoverable, DMA-capable buses like fsl-mc are still going to face the
> exact same problem with or without this patch.
>
the new v2 is hooking callbacks for defualt and pci bus.
so now the implementation will not really look cluttered.
and for fsl-mc buses, we could choose to implement it in default bus callbacks.
will post the patch-set soon.
also with these patch-set we really do not need to prepare emulated child node.
>> for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
>> world dma-ranges.
>> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
>>
>> this patch serves following:
>>
>> 1) exposes interface to the pci host driver for their
>> inbound memory ranges
>>
>> 2) provide an interface to callers such as of_dma_get_ranges.
>> so then the returned size get best possible (largest) dma_mask.
>> because PCI RC drivers do not call APIs such as
>> dma_set_coherent_mask() and hence rather it shows its addressing
>> capabilities based on dma-ranges.
>> for e.g.
>> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
>> we should get dev->coherent_dma_mask=0x7f.
>>
>> 3) this patch handles multiple inbound windows and dma-ranges.
>> it is left to the caller, how it wants to use them.
>> the new function returns the resources in a standard and unform way
>>
>> 4) this way the callers of for e.g. of_dma_get_ranges
>> does not need to change.
>>
>> 5) leaves scope of adding PCI flag handling for inbound memory
>> by the new function.
>
> Which flags would ever actually matter? DMA windows aren't going to be
> to config or I/O space, so the memory type can be assumed, and the
> 32/64-bit distinction is irrelevant as it's not a relocatable BAR;
> DMA-able system memory isn't going to be read-sensitive, so the
> prefetchable flag shouldn't matter; and not being a BAR none of the
> others would be relevant either.
>
>>
>> Bug: SOC-5216
>> Change-Id: Ie045386df91e1e0587846bb147ae40d96f6d7d2e
>> Signed-off-by: Oza Pawandeep
>> Reviewed-on: http://gerrit-ccxsw.broadcom.net/40428
>> Reviewed-by: vpx_checkpatch status
>> Reviewed-by: CCXSW
>> Reviewed-by: Ray Jui
>> Tested-by: vpx_autobuild status
>> Tested-by: vpx_smoketest status
>> Tested-by: CCXSW
>> Reviewed-by: Scott Branden
>>
>> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
>> index 0ee42c3..ed6e69a 100644
>> --- a/drivers/of/of_pci.c
>> +++ b/drivers/of/of_pci.c
>> @@ -283,6 +283,83 @@ int of_pci_get_host_bridge_resources(struct device_node
>> *dev,
>> return err;
>> }
>> EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
>> +
>> +/**
>> + * of_pci_get_dma_ranges - Parse PCI host bridge inbound resources from DT
>> + * @np: device node of the host bridge having the dma-ranges property
>> + * @resources: list where the range of resources will be added after DT
>> parsing
>> + *
>> + * It is the caller's job to free the @resources list.
>> + *
>> + * This function will parse the "dma-ranges" property of a
>> + * PCI host bridge device node and setup the resource mapping based
>> + * on its content.
>> + *
>> + * It returns zero if the range parsing has been successful or a standard
>> error
>> + * value if it failed.
>> + */
>> +
>> +int of_pci_get_dma_ranges(struct device_node *np, struct list_head
>> *resources)
>> +{
>> + struct device_node *node = of_node_get(np);
>> + int rlen;
>> + int ret = 0;
>> + const int na = 3, ns = 2;
>> + struct resource *res;
>> + struct of_pci_range_parser pa
Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters
On Thu, May 4, 2017 at 11:32 PM, Robin Murphy wrote: > [apologies for the silence - I've been on holiday] > > On 03/05/17 05:46, Oza Pawandeep wrote: >> current device framework and of framework integration assumes >> dma-ranges in a way where memory-mapped devices define their >> dma-ranges. (child-bus-address, parent-bus-address, length). > > Well, yes, that is simply the definition of dma-ranges, and remains true > regardless of the particular format of either bus address. > >> of_dma_configure is specifically written to take care of memory >> mapped devices. but no implementation exists for pci to take >> care of pcie based memory ranges. > > That still doesn't make sense. To repeat myself again, PCI devices *ARE* > memory-mapped devices. Yes, there do exist some platforms where I/O > space is not treated as MMIO, but config space and memory space are very > much memory-mapped however you look at them, and in the context of DMA, > only memory space is relevant anyway. > > What *is* true about the current code is that of_dma_get_range() expects > to be passed an OF node representing the device itself, and doesn't work > properly when passed the node of the device's parent bus directly, which > happens to be what pci_dma_configure() currently does. That's the only > reason why it doesn't work for (single-entry) host controller dma-ranges > today. This does not mean it's a PCI problem, it is simply the case that > pci_dma_configure() is the only caller currently hitting it. Other > discoverable, DMA-capable buses like fsl-mc are still going to face the > exact same problem with or without this patch. > >> for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI >> world dma-ranges. >> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>; >> >> this patch serves following: >> >> 1) exposes interface to the pci host driver for their >> inbound memory ranges >> >> 2) provide an interface to callers such as of_dma_get_ranges. >> so then the returned size get best possible (largest) dma_mask. >> because PCI RC drivers do not call APIs such as >> dma_set_coherent_mask() and hence rather it shows its addressing >> capabilities based on dma-ranges. >> for e.g. >> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>; >> we should get dev->coherent_dma_mask=0x7f. >> >> 3) this patch handles multiple inbound windows and dma-ranges. >> it is left to the caller, how it wants to use them. >> the new function returns the resources in a standard and unform way >> >> 4) this way the callers of for e.g. of_dma_get_ranges >> does not need to change. >> >> 5) leaves scope of adding PCI flag handling for inbound memory >> by the new function. > > Which flags would ever actually matter? DMA windows aren't going to be > to config or I/O space, so the memory type can be assumed, and the > 32/64-bit distinction is irrelevant as it's not a relocatable BAR; > DMA-able system memory isn't going to be read-sensitive, so the > prefetchable flag shouldn't matter; and not being a BAR none of the > others would be relevant either. > Thanks Robin; for your reply and attention: agree with you, at present it would not matter, but it does not mean that we do not scope it to make it matter in future. now where it could matter: there is Relaxed Ordering for inbound memory for PCI. According to standard, Relaxed Ordering (RO) bit can be set only for Memory requests and completions (if present in the original request). Also, according to transaction ordering rules, I/O and configuration requests can still be re-ordered ahead of each other. and we would like to make use of it. for e.g. lets say we mark memory as Relaxed Ordered with flag. the special about this memory is incoming PCI transactions can be reordered and rest memory has to be strongly ordered. how it our SOC would make use of this is out of scope for the discussion at this point of time, but I am just bringing in the idea/point how flags could be useful for inbound memory, since we would not like throw-away flags completely. >> >> Bug: SOC-5216 >> Change-Id: Ie045386df91e1e0587846bb147ae40d96f6d7d2e >> Signed-off-by: Oza Pawandeep >> Reviewed-on: http://gerrit-ccxsw.broadcom.net/40428 >> Reviewed-by: vpx_checkpatch status >> Reviewed-by: CCXSW >> Reviewed-by: Ray Jui >> Tested-by: vpx_autobuild status >> Tested-by: vpx_smoketest status >> Tested-by: CCXSW >> Reviewed-by: Scott Branden >> >> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c >> index 0ee42c3..ed6e69a 100644 >> --- a/drivers/of/of_pci.c >> +++ b/drivers/of/of_pci.c >> @@ -283,6 +283,83 @@ int of_pci_get_host_bridge_resources(struct device_node >> *dev, >> return err; >> } >> EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources); >> + >> +/** >> + * of_pci_get_dma_ranges - Parse PCI host bridge inbound resources from DT >> + * @np: device node of the host bridge having the dma-ranges property >> + * @resources: list where the range of resources will be added after DT >> pars
Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters
[apologies for the silence - I've been on holiday]
On 03/05/17 05:46, Oza Pawandeep wrote:
> current device framework and of framework integration assumes
> dma-ranges in a way where memory-mapped devices define their
> dma-ranges. (child-bus-address, parent-bus-address, length).
Well, yes, that is simply the definition of dma-ranges, and remains true
regardless of the particular format of either bus address.
> of_dma_configure is specifically written to take care of memory
> mapped devices. but no implementation exists for pci to take
> care of pcie based memory ranges.
That still doesn't make sense. To repeat myself again, PCI devices *ARE*
memory-mapped devices. Yes, there do exist some platforms where I/O
space is not treated as MMIO, but config space and memory space are very
much memory-mapped however you look at them, and in the context of DMA,
only memory space is relevant anyway.
What *is* true about the current code is that of_dma_get_range() expects
to be passed an OF node representing the device itself, and doesn't work
properly when passed the node of the device's parent bus directly, which
happens to be what pci_dma_configure() currently does. That's the only
reason why it doesn't work for (single-entry) host controller dma-ranges
today. This does not mean it's a PCI problem, it is simply the case that
pci_dma_configure() is the only caller currently hitting it. Other
discoverable, DMA-capable buses like fsl-mc are still going to face the
exact same problem with or without this patch.
> for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
> world dma-ranges.
> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
>
> this patch serves following:
>
> 1) exposes interface to the pci host driver for their
> inbound memory ranges
>
> 2) provide an interface to callers such as of_dma_get_ranges.
> so then the returned size get best possible (largest) dma_mask.
> because PCI RC drivers do not call APIs such as
> dma_set_coherent_mask() and hence rather it shows its addressing
> capabilities based on dma-ranges.
> for e.g.
> dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
> we should get dev->coherent_dma_mask=0x7f.
>
> 3) this patch handles multiple inbound windows and dma-ranges.
> it is left to the caller, how it wants to use them.
> the new function returns the resources in a standard and unform way
>
> 4) this way the callers of for e.g. of_dma_get_ranges
> does not need to change.
>
> 5) leaves scope of adding PCI flag handling for inbound memory
> by the new function.
Which flags would ever actually matter? DMA windows aren't going to be
to config or I/O space, so the memory type can be assumed, and the
32/64-bit distinction is irrelevant as it's not a relocatable BAR;
DMA-able system memory isn't going to be read-sensitive, so the
prefetchable flag shouldn't matter; and not being a BAR none of the
others would be relevant either.
>
> Bug: SOC-5216
> Change-Id: Ie045386df91e1e0587846bb147ae40d96f6d7d2e
> Signed-off-by: Oza Pawandeep
> Reviewed-on: http://gerrit-ccxsw.broadcom.net/40428
> Reviewed-by: vpx_checkpatch status
> Reviewed-by: CCXSW
> Reviewed-by: Ray Jui
> Tested-by: vpx_autobuild status
> Tested-by: vpx_smoketest status
> Tested-by: CCXSW
> Reviewed-by: Scott Branden
>
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> index 0ee42c3..ed6e69a 100644
> --- a/drivers/of/of_pci.c
> +++ b/drivers/of/of_pci.c
> @@ -283,6 +283,83 @@ int of_pci_get_host_bridge_resources(struct device_node
> *dev,
> return err;
> }
> EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
> +
> +/**
> + * of_pci_get_dma_ranges - Parse PCI host bridge inbound resources from DT
> + * @np: device node of the host bridge having the dma-ranges property
> + * @resources: list where the range of resources will be added after DT
> parsing
> + *
> + * It is the caller's job to free the @resources list.
> + *
> + * This function will parse the "dma-ranges" property of a
> + * PCI host bridge device node and setup the resource mapping based
> + * on its content.
> + *
> + * It returns zero if the range parsing has been successful or a standard
> error
> + * value if it failed.
> + */
> +
> +int of_pci_get_dma_ranges(struct device_node *np, struct list_head
> *resources)
> +{
> + struct device_node *node = of_node_get(np);
> + int rlen;
> + int ret = 0;
> + const int na = 3, ns = 2;
> + struct resource *res;
> + struct of_pci_range_parser parser;
> + struct of_pci_range range;
> +
> + if (!node)
> + return -EINVAL;
> +
> + parser.node = node;
> + parser.pna = of_n_addr_cells(node);
> + parser.np = parser.pna + na + ns;
> +
> + parser.range = of_get_property(node, "dma-ranges", &rlen);
> +
> + if (!parser.range) {
> + pr_debug("pcie device has no dma-ranges defined for node(%s)\n",
> + np->full_name);
> + ret = -EINVAL;
> + goto
Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters
On Tue, May 2, 2017 at 11:46 PM, Oza Pawandeep wrote: > current device framework and of framework integration assumes > dma-ranges in a way where memory-mapped devices define their > dma-ranges. (child-bus-address, parent-bus-address, length). > > of_dma_configure is specifically written to take care of memory > mapped devices. but no implementation exists for pci to take > care of pcie based memory ranges. > > for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI > world dma-ranges. > dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>; > > this patch serves following: > > 1) exposes interface to the pci host driver for their > inbound memory ranges > > 2) provide an interface to callers such as of_dma_get_ranges. > so then the returned size get best possible (largest) dma_mask. > because PCI RC drivers do not call APIs such as > dma_set_coherent_mask() and hence rather it shows its addressing > capabilities based on dma-ranges. > for e.g. > dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>; > we should get dev->coherent_dma_mask=0x7f. > > 3) this patch handles multiple inbound windows and dma-ranges. > it is left to the caller, how it wants to use them. > the new function returns the resources in a standard and unform way > > 4) this way the callers of for e.g. of_dma_get_ranges > does not need to change. > > 5) leaves scope of adding PCI flag handling for inbound memory > by the new function. > > Bug: SOC-5216 > Change-Id: Ie045386df91e1e0587846bb147ae40d96f6d7d2e > Signed-off-by: Oza Pawandeep > Reviewed-on: http://gerrit-ccxsw.broadcom.net/40428 > Reviewed-by: vpx_checkpatch status > Reviewed-by: CCXSW > Reviewed-by: Ray Jui > Tested-by: vpx_autobuild status > Tested-by: vpx_smoketest status > Tested-by: CCXSW All these non-person, probably internal Broadcom Tested-by and Reviewed-by's should be removed too. > Reviewed-by: Scott Branden > Rob
Re: [PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters
I will send v2 after removing GERRIT details from commit message. My apologies for the noise. Regards, Oza
[PATCH 1/3] of/pci/dma: fix DMA configuration for PCI masters
current device framework and of framework integration assumes
dma-ranges in a way where memory-mapped devices define their
dma-ranges. (child-bus-address, parent-bus-address, length).
of_dma_configure is specifically written to take care of memory
mapped devices. but no implementation exists for pci to take
care of pcie based memory ranges.
for e.g. iproc based SOCs and other SOCs(suc as rcar) have PCI
world dma-ranges.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
this patch serves following:
1) exposes interface to the pci host driver for their
inbound memory ranges
2) provide an interface to callers such as of_dma_get_ranges.
so then the returned size get best possible (largest) dma_mask.
because PCI RC drivers do not call APIs such as
dma_set_coherent_mask() and hence rather it shows its addressing
capabilities based on dma-ranges.
for e.g.
dma-ranges = <0x4300 0x00 0x00 0x00 0x00 0x80 0x00>;
we should get dev->coherent_dma_mask=0x7f.
3) this patch handles multiple inbound windows and dma-ranges.
it is left to the caller, how it wants to use them.
the new function returns the resources in a standard and unform way
4) this way the callers of for e.g. of_dma_get_ranges
does not need to change.
5) leaves scope of adding PCI flag handling for inbound memory
by the new function.
Bug: SOC-5216
Change-Id: Ie045386df91e1e0587846bb147ae40d96f6d7d2e
Signed-off-by: Oza Pawandeep
Reviewed-on: http://gerrit-ccxsw.broadcom.net/40428
Reviewed-by: vpx_checkpatch status
Reviewed-by: CCXSW
Reviewed-by: Ray Jui
Tested-by: vpx_autobuild status
Tested-by: vpx_smoketest status
Tested-by: CCXSW
Reviewed-by: Scott Branden
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 0ee42c3..ed6e69a 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -283,6 +283,83 @@ int of_pci_get_host_bridge_resources(struct device_node
*dev,
return err;
}
EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
+
+/**
+ * of_pci_get_dma_ranges - Parse PCI host bridge inbound resources from DT
+ * @np: device node of the host bridge having the dma-ranges property
+ * @resources: list where the range of resources will be added after DT parsing
+ *
+ * It is the caller's job to free the @resources list.
+ *
+ * This function will parse the "dma-ranges" property of a
+ * PCI host bridge device node and setup the resource mapping based
+ * on its content.
+ *
+ * It returns zero if the range parsing has been successful or a standard error
+ * value if it failed.
+ */
+
+int of_pci_get_dma_ranges(struct device_node *np, struct list_head *resources)
+{
+ struct device_node *node = of_node_get(np);
+ int rlen;
+ int ret = 0;
+ const int na = 3, ns = 2;
+ struct resource *res;
+ struct of_pci_range_parser parser;
+ struct of_pci_range range;
+
+ if (!node)
+ return -EINVAL;
+
+ parser.node = node;
+ parser.pna = of_n_addr_cells(node);
+ parser.np = parser.pna + na + ns;
+
+ parser.range = of_get_property(node, "dma-ranges", &rlen);
+
+ if (!parser.range) {
+ pr_debug("pcie device has no dma-ranges defined for node(%s)\n",
+ np->full_name);
+ ret = -EINVAL;
+ goto out;
+ }
+
+ parser.end = parser.range + rlen / sizeof(__be32);
+
+ for_each_of_pci_range(&parser, &range) {
+ /*
+* If we failed translation or got a zero-sized region
+* then skip this range
+*/
+ if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
+ continue;
+
+ res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+ if (!res) {
+ ret = -ENOMEM;
+ goto parse_failed;
+ }
+
+ ret = of_pci_range_to_resource(&range, np, res);
+ if (ret) {
+ kfree(res);
+ continue;
+ }
+
+ pci_add_resource_offset(resources, res,
+ res->start - range.pci_addr);
+ }
+
+ return ret;
+
+parse_failed:
+ pci_free_resource_list(resources);
+out:
+ of_node_put(node);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(of_pci_get_dma_ranges);
#endif /* CONFIG_OF_ADDRESS */
#ifdef CONFIG_PCI_MSI
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 0e0974e..617b90d 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -76,6 +76,7 @@ static inline void of_pci_check_probe_only(void) { }
int of_pci_get_host_bridge_resources(struct device_node *dev,
unsigned char busno, unsigned char bus_max,
struct list_head *resources, resource_size_t *io_base);
+int of_pci_get_dma_ranges(struct device_node *np, struct list_head *resources);
#else
static inline int of_pci_get_host_bridge_resource
