|
Armin Steinhoff
|
[QNX 7.0] pci_device_map_as
|
|
Armin Steinhoff
10/29/2017 11:48 AM
post118156
|
[QNX 7.0] pci_device_map_as
I have some questions about the semantic of pci_device_map_as.
Is the code below the way to allocate DMA buffers for QNX 7 ??
/*
* do other driver specific processing. For example, if the device does DMA then translate your
* allocated memory buffers into addresses suitable for access from PCI address space
*/
pci_ba_t buf =
{
.addr = <physical address of memory buffer(s)>, .size = <size of buffer>,
.type = pci_asType_e_MEM, .attr = pci_asAttr_e_INBOUND | pci_asAttr_e_CONTIG,
};
pci_ba_t xlate;
r = pci_device_map_as(hdl, &buf, &xlate);
if (r == PCI_ERR_OK)
{
/* use xlate.addr to program DMA transfers */
}
If yes, what happens with the preallocated original noncontigous buffer?
Setting "attr" to "pci_asAttr_e_OUTBOUND" does it return the physical address related to "addr" if "addr" is an
address of the CPU space?
Best Regards
Armin
|
|
|
|
|
|
Michael Kisel
|
Re: [QNX 7.0] pci_device_map_as
|
|
Michael Kisel
10/30/2017 8:23 AM
post118159
|
Re: [QNX 7.0] pci_device_map_as
"Is the code below the way to allocate DMA buffers for QNX 7 ??"
Yes.
"If yes, what happens with the preallocated original noncontigous buffer?"
A new buffer is not allocated. Rather a translation, if one is required by the platform, is provided for use by the PCI/
PCIe device which will master transactions (ex. DMA). The allocated buffer for this use case should be physically
contiguous and both the address passed in and the translated address provided back are physical addresses
"Setting "attr" to "pci_asAttr_e_OUTBOUND" does it return the physical address related to "addr" if "addr" is an
address of the CPU space?"
No. This API is not the same as mem_offset() which is used to obtain the physical address for the virtual address of
some portion of memory, both from the CPU's perspective. Rather, the pci_device_map_as() is used to translate physical
addresses between CPU and PCI address spaces. And since the pci_device_read_ba() function already provides the
translated address to use for OUTBOUND accesses, the pci_device_map_as() is typically only used for INBOUND translations
for devices capable of mastering transactions.
|
|
|
|
|
|
Armin Steinhoff
|
Re: [QNX 7.0] pci_device_map_as
|
|
Armin Steinhoff
11/02/2017 9:48 AM
post118173
|
Re: [QNX 7.0] pci_device_map_as
Michael Kisel schrieb:
> "Is the code below the way to allocate DMA buffers for QNX 7 ??"
> Yes.
>
> "If yes, what happens with the preallocated original noncontigous buffer?"
> A new buffer is not allocated. Rather a translation, if one is required by the platform, is provided for use by the
PCI/PCIe device which will master transactions (ex. DMA). The allocated buffer for this use case should be physically
contiguous and both the address passed in and the translated address provided back are physical addresses
Ok ... we have to support DMA controllers supporting only 24bits and 32
bit physical adresses. How to solve that issue?
There is the possibility to create 24/32/64 bits DMA buffers using the
mmap API and the flag "MAP_BELOW addr".
Is it correct that the actual parameter "adr" must specify the top
boarder or inside of the 24/32bit physical address space?
> "Setting "attr" to "pci_asAttr_e_OUTBOUND" does it return the physical address related to "addr" if "addr" is an
address of the CPU space?"
> No. This API is not the same as mem_offset() which is used to obtain the physical address for the virtual address of
some portion of memory, both from the CPU's perspective. Rather, the pci_device_map_as() is used to translate physical
addresses between CPU and PCI address spaces. And since the pci_device_read_ba() function already provides the
translated address to use for OUTBOUND accesses,
Not clear for me. IMHO ... pci_device_read_ba() interpretes the PCI
specific bits of a base address register in order to get its real
physical address (IO or Mem). I don`t see here a translation from CPU to
PCI space.
> the pci_device_map_as() is typically only used for INBOUND translations for devices capable of mastering
transactions.
My experiences is that pci_device_map_as() changes nothing on a ba read
by pci_device_read_ba().
However ... the OUTBOUND translation is just for mapping physcal PCI
addresses to the physical address space of the CPU?
Regards
Armin
PS: the first 64bits CAN resource manager for a PCIexpr interface is working
>
>
>
>
> _______________________________________________
>
> OSTech
> http://community.qnx.com/sf/go/post118159
> To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
>
|
|
|
|
|
|
Armin Steinhoff
|
Re: [QNX 7.0] pci_device_map_as
|
|
Armin Steinhoff
11/02/2017 10:42 AM
post118174
|
Re: [QNX 7.0] pci_device_map_as
Sorry, the previous post was unreadable ...
Michael Kisel schrieb:
> "Is the code below the way to allocate DMA buffers for QNX 7 ??"
> Yes.
>
> "If yes, what happens with the preallocated original noncontigous buffer?"
> A new buffer is not allocated. Rather a translation, if one is required by the platform, is provided for use by the
PCI/PCIe device which will master transactions (ex. DMA). The allocated buffer for this use case should be physically
contiguous and both the address passed in and the translated address provided back are physical addresses
Ok ... we have to support DMA controllers supporting only 24bits and 32
bit physical adresses. How to solve that issue?
There is also the possibility to create 24/32/64 bits DMA buffers using
the mmap API and the flag "MAP_BELOW addr".
Is it correct that the actual parameter "adr" must specify the top
boarder or inside of the 24/32bit physical address space?
> "Setting "attr" to "pci_asAttr_e_OUTBOUND" does it return the physical address related to "addr" if "addr" is an
address of the CPU space?"
> No. This API is not the same as mem_offset() which is used to obtain the physical address for the virtual address of
some portion of memory, both from the CPU's perspective. Rather, the pci_device_map_as() is used to translate physical
addresses between CPU and PCI address spaces. And since the pci_device_read_ba() function already provides the
translated address to use for OUTBOUND accesses,
Not clear for me. IMHO ... pci_device_read_ba() interpretes the PCI
specific bits of a base address register in order to get its real
physical address (IO or Mem). I don`t see here a translation from CPU to
PCI space.
>>>> the pci_device_map_as() is typically only used for INBOUND translations for devices capable of mastering
transactions.
My experiences is that pci_device_map_as() changes nothing on a ba read
by pci_device_read_ba().
However ... the OUTBOUND translation is just for mapping physcal PCI
addresses to the physical address space of the CPU?
Regards
Armin
PS: the first 64bits CAN resource manager for a PCIexpr interface is working
>
>
>
>
> _______________________________________________
>
> OSTech
> http://community.qnx.com/sf/go/post118159
> To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
>
|
|
|
|
|
|
Elad Lahav
|
Re: [QNX 7.0] pci_device_map_as
|
|
Elad Lahav
11/02/2017 11:13 AM
post118175
|
Re: [QNX 7.0] pci_device_map_as
On Thu, 2017-11-02 at 15:21 +0100, Armin Steinhoff wrote:
> Ok ... we have to support DMA controllers supporting only 24bits and
> 32
> bit physical adresses. How to solve that issue?
>
> There is also the possibility to create 24/32/64 bits DMA buffers
> using
> the mmap API and the flag "MAP_BELOW addr".
> Is it correct that the actual parameter "adr" must specify the top
> boarder or inside of the 24/32bit physical address space?
The MAP_BELOW flags are no longer supported.
To achieve what you are looking for you need to use POSIX typed memory.
A below4G entry should be available in every BSP. For 24-bit addresses
you will need to add a relevant entry in startup (e.g., "below16M").
--Elad
|
|
|
|
|
|
Armin Steinhoff
|
Re: [QNX 7.0] pci_device_map_as
|
|
Armin Steinhoff
11/03/2017 5:18 AM
post118177
|
Re: [QNX 7.0] pci_device_map_as
Elad Lahav schrieb:
> On Thu, 2017-11-02 at 15:21 +0100, Armin Steinhoff wrote:
>> Ok ... we have to support DMA controllers supporting only 24bits and
>> 32Â
>> bit physical adresses. How to solve that issue?
>>
>> There is also the possibility to create 24/32/64 bits DMA buffers
>> usingÂ
>> the mmap API and the flag "MAP_BELOW addr".
>> Is it correct that the actual parameter "adr" must specify the topÂ
>> boarder or inside of the 24/32bit physical address space?
> The MAP_BELOW flags are no longer supported.
Please polishup the documentation of mmap.
> To achieve what you are looking for you need to use POSIX typed memory.
> A below4G entry should be available in every BSP. For 24-bit addresses
> you will need to add a relevant entry in startup (e.g., "below16M").
There are still old fashion PC systems - e.g. PC104 systems - used as
targets. Does it make no sense to add an "below16M" entry to the generic
startup?
Regards
Armin
>
> --Elad
>
>
>
> _______________________________________________
>
> OSTech
> http://community.qnx.com/sf/go/post118175
> To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
|
|
|
|
|
|
Elad Lahav
|
RE: [QNX 7.0] pci_device_map_as
|
|
Elad Lahav
11/03/2017 7:13 AM
post118179
|
RE: [QNX 7.0] pci_device_map_as
Are you looking at the 7.0 version of the documentation? I don't see any reference in there to MAP_BELOW16:
http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.lib_ref/topic/m/mmap.html
And I don't believe 7.0 officially supports the kind of targets you are referring to.
--Elad
________________________________________
From: Armin Steinhoff [community-noreply@qnx.com]
Sent: November-03-17 4:57 AM
To: ostech-core_os@community.qnx.com
Subject: Re: [QNX 7.0] pci_device_map_as
Elad Lahav schrieb:
> On Thu, 2017-11-02 at 15:21 +0100, Armin Steinhoff wrote:
>> Ok ... we have to support DMA controllers supporting only 24bits and
>> 32Â
>> bit physical adresses. How to solve that issue?
>>
>> There is also the possibility to create 24/32/64 bits DMA buffers
>> usingÂ
>> the mmap API and the flag "MAP_BELOW addr".
>> Is it correct that the actual parameter "adr" must specify the topÂ
>> boarder or inside of the 24/32bit physical address space?
> The MAP_BELOW flags are no longer supported.
Please polishup the documentation of mmap.
> To achieve what you are looking for you need to use POSIX typed memory.
> A below4G entry should be available in every BSP. For 24-bit addresses
> you will need to add a relevant entry in startup (e.g., "below16M").
There are still old fashion PC systems - e.g. PC104 systems - used as
targets. Does it make no sense to add an "below16M" entry to the generic
startup?
Regards
Armin
>
> --Elad
>
>
>
> _______________________________________________
>
> OSTech
> http://community.qnx.com/sf/go/post118175
> To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
_______________________________________________
OSTech
http://community.qnx.com/sf/go/post118177
To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
|
|
|
|
|
|
Armin Steinhoff
|
Re: [QNX 7.0] pci_device_map_as
|
|
Armin Steinhoff
11/03/2017 4:34 PM
post118182
|
Re: [QNX 7.0] pci_device_map_as
Elad Lahav schrieb:
> Are you looking at the 7.0 version of the documentation? I don't see any reference in there to MAP_BELOW16:
>
> http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.lib_ref/topic/m/mmap.html
OK ... than read it carefully and you will find:
*MAP_BELOW
*
*Map below the given **addr**, if possible. *
The question is just: what means "if possible" ??
> "if
>
> And I don't believe 7.0 officially supports the kind of targets you are referring to.
So you "believe" that 7.0 will not support low level IoT devices?
Armin
|
|
|
|
|
|
Elad Lahav
|
Re: [QNX 7.0] pci_device_map_as
|
|
Elad Lahav
11/03/2017 4:44 PM
post118183
|
Re: [QNX 7.0] pci_device_map_as
The name is unfortunate, but MAP_BELOW has nothing to do with the now-
removed MAP_BELOW16. The former refers to virtual addresses, the latter
to physical addresses. The first argument to mmap() is a hint as to
where to put the mapped region in the caller's address space (unless
combined with MAP_FIXED, which turns it into a string requirement).
MAP_BELOW changes the meaning of the hint to be where the region should
end instead of where it should begin. But since it's a hint, the memory
manager can still place the region above the given address if there is
no hole big enough to accommodate the request.
--Elad
On Fri, 2017-11-03 at 21:14 +0100, Armin Steinhoff wrote:
> Elad Lahav schrieb:
> > Are you looking at the 7.0 version of the documentation? I don't
> > see any reference in there to MAP_BELOW16:
> >
> > http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutrino.lib_
> > ref/topic/m/mmap.html
>
> OK ... than read it carefully and you will find:
>
> MAP_BELOW
> Map below the given addr, if possible.
> The question is just: what means "if possible" ??
>
> > "if
> >
> > And I don't believe 7.0 officially supports the kind of targets you
> > are referring to.
>
> So you "believe" that 7.0 will not support low level IoT devices?
>
> Armin
>
|
|
|
|
|
|
Armin Steinhoff
|
Re: [QNX 7.0] pci_device_map_as
|
|
Armin Steinhoff
11/03/2017 8:32 PM
post118184
|
Re: [QNX 7.0] pci_device_map_as
Elad Lahav schrieb:
> The name is unfortunate, but MAP_BELOW has nothing to do with the now-
> removed MAP_BELOW16. The former refers to virtual addresses, the latter
> to physical addresses. The first argument to mmap() is a hint as to
> where to put the mapped region in the caller's address space (unless
> combined with MAP_FIXED, which turns it into a string requirement).
> MAP_BELOW changes the meaning of the hint to be where the region should
> end instead of where it should begin.
Ok ... the flag MAP_BELOW isn't mentioned in POSIX. So I got the
impression that MAP_BELOW will change the semantic of
the parameter "addr" as an replacement of MAP_BELOW16M.
But the actual semantic isn't very well documented.
Armin
|
|
|
|
|
|
Michael Kisel
|
Re: [QNX 7.0] pci_device_map_as
|
|
Michael Kisel
11/02/2017 11:19 AM
post118176
|
Re: [QNX 7.0] pci_device_map_as
>
> Sorry, the previous post was unreadable ...
>
> Michael Kisel schrieb:
> > "Is the code below the way to allocate DMA buffers for QNX 7 ??"
> > Yes.
> >
> > "If yes, what happens with the preallocated original noncontigous buffer?"
> > A new buffer is not allocated. Rather a translation, if one is required by
> the platform, is provided for use by the PCI/PCIe device which will master
> transactions (ex. DMA). The allocated buffer for this use case should be
> physically contiguous and both the address passed in and the translated
> address provided back are physical addresses
>
>
> Ok ... we have to support DMA controllers supporting only 24bits and 32
> bit physical adresses. How to solve that issue?
>
> There is also the possibility to create 24/32/64 bits DMA buffers using
> the mmap API and the flag "MAP_BELOW addr".
> Is it correct that the actual parameter "adr" must specify the top
> boarder or inside of the 24/32bit physical address space?
The translation is done by the PCI HW module as it is arch/board specific whether or not any translations exist at all.
For example, the x86 HW module currently uses a 1:1 translation (in reality, no translation at all since there is no
IOMMU support yet). Other HW modules may or may not do translation and those translations are governed by the
capabilities of the (ATU) hardware units. Currently for our supported HW modules, the translated physical address will
have the same attributes (16/32/64 bit) as the incoming address so if your DMA engine only supports 32 bit addresses,
you will need to ensure the physical address of the contiguous allocated buffer is below 4G
>
>
> > "Setting "attr" to "pci_asAttr_e_OUTBOUND" does it return the physical
> address related to "addr" if "addr" is an address of the CPU space?"
> > No. This API is not the same as mem_offset() which is used to obtain the
> physical address for the virtual address of some portion of memory, both from
> the CPU's perspective. Rather, the pci_device_map_as() is used to translate
> physical addresses between CPU and PCI address spaces. And since the
> pci_device_read_ba() function already provides the translated address to use
> for OUTBOUND accesses,
>
>
> Not clear for me. IMHO ... pci_device_read_ba() interpretes the PCI
> specific bits of a base address register in order to get its real
> physical address (IO or Mem). I don`t see here a translation from CPU to
> PCI space.
>
It's actually the reverse. The address space requirements of all enumerated devices are used to configure the BAR's of
those devices. If there is a translation (see comment above), then the values returned in the pci_device_read_ba() call
will be the OUTBOUND translated address to use by the CPU such that it will "hit" the targeted BAR of the targeted
device
>
> >>>> the pci_device_map_as() is typically only used for INBOUND translations
> for devices capable of mastering transactions.
>
>
> My experiences is that pci_device_map_as() changes nothing on a ba read
> by pci_device_read_ba().
>
> However ... the OUTBOUND translation is just for mapping physcal PCI
> addresses to the physical address space of the CPU?
>
> Regards
>
> Armin
>
> PS: the first 64bits CAN resource manager for a PCIexpr interface is working
>
> >
> >
> >
> >
> > _______________________________________________
> >
> > OSTech
> > http://community.qnx.com/sf/go/post118159
> > To cancel your subscription to this discussion, please e-mail ostech-core_os
> -unsubscribe@community.qnx.com
> >
>
|
|
|
|
|
|
Armin Steinhoff
|
Re: [QNX 7.0] pci_device_map_as
|
|
Armin Steinhoff
11/03/2017 5:26 AM
post118178
|
Re: [QNX 7.0] pci_device_map_as
Michael Kisel schrieb:
>> Sorry, the previous post was unreadable ...
>>
>> Michael Kisel schrieb:
>>> "Is the code below the way to allocate DMA buffers for QNX 7 ??"
>>> Yes.
>>>
>>> "If yes, what happens with the preallocated original noncontigous buffer?"
>>> A new buffer is not allocated. Rather a translation, if one is required by
>> the platform, is provided for use by the PCI/PCIe device which will master
>> transactions (ex. DMA). The allocated buffer for this use case should be
>> physically contiguous and both the address passed in and the translated
>> address provided back are physical addresses
>>
>>
>> Ok ... we have to support DMA controllers supporting only 24bits and 32
>> bit physical adresses. How to solve that issue?
>>
>> There is also the possibility to create 24/32/64 bits DMA buffers using
>> the mmap API and the flag "MAP_BELOW addr".
>> Is it correct that the actual parameter "adr" must specify the top
>> boarder or inside of the 24/32bit physical address space?
> The translation is done by the PCI HW module as it is arch/board specific whether or not any translations exist at all
. For example, the x86 HW module currently uses a 1:1 translation (in reality, no translation at all since there is no
IOMMU support yet). Other HW modules may or may not do translation and those translations are governed by the
capabilities of the (ATU) hardware units. Currently for our supported HW modules, the translated physical address will
have the same attributes (16/32/64 bit) as the incoming address so if your DMA engine only supports 32 bit addresses,
you will need to ensure the physical address of the contiguous allocated buffer is below 4G
>>
>>> "Setting "attr" to "pci_asAttr_e_OUTBOUND" does it return the physical
>> address related to "addr" if "addr" is an address of the CPU space?"
>>> No. This API is not the same as mem_offset() which is used to obtain the
>> physical address for the virtual address of some portion of memory, both from
>> the CPU's perspective. Rather, the pci_device_map_as() is used to translate
>> physical addresses between CPU and PCI address spaces. And since the
>> pci_device_read_ba() function already provides the translated address to use
>> for OUTBOUND accesses,
>>
>>
>> Not clear for me. IMHO ... pci_device_read_ba() interpretes the PCI
>> specific bits of a base address register in order to get its real
>> physical address (IO or Mem). I don`t see here a translation from CPU to
>> PCI space.
>>
> It's actually the reverse. The address space requirements of all enumerated devices are used to configure the BAR's of
those devices. If there is a translation (see comment above), then the values returned in the pci_device_read_ba() call
will be the OUTBOUND translated address to use by the CPU such that it will "hit" the targeted BAR of the targeted
device
OK ... I think I have mixedup the contents of the PCI config space and
the real hardware access.
Thanks a lot.
Armin
>
> OSTech
> http://community.qnx.com/sf/go/post118176
> To cancel your subscription to this discussion, please e-mail ostech-core_os-unsubscribe@community.qnx.com
|
|
|
|
|
|
