will simply ignore the
> attribute and exhibit default behavior.
>
>
> In case of ARM SoC, it seems like that it just ignores the attribute
> without iommu: in case of no iommu, dma_alloc_attr() always maps pages
> allocated from highmem with kernel space. So I think we make sure that
> exynos drm driver sets the attribute only with iommu to avoid such
> confusing. For this, will post it soon.
IMHO this case simply shows that ExynosDRM driver should manage IO address
space on it's own, because DMA-mapping api is too limited. ExynosDRM is
unlikely to be used on a hardware other than Samsung Exynos, so it can
better use hardware if it access IOMMU and CMA subsystems directly and
have its own address space manager to avoid hacking in internal structures
of dma-mapping.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
mu to avoid such
confusing. For this, will post it soon.
IMHO this case simply shows that ExynosDRM driver should manage IO address
space on it's own, because DMA-mapping api is too limited. ExynosDRM is
unlikely to be used on a hardware other than Samsung Exynos, so it can
better use hard
Szyprowski.
Marek, please give me ack.
common: DMA-mapping: add DMA_ATTR_FORCE_CONTIGUOUS attribute
ARM: dma-mapping: add support for DMA_ATTR_FORCE_CONTIGUOUS attribute.
For the dma-mapping related changes:
Acked-by: Marek Szyprowski
This patch is used to allocate fully
ng DMA Mapping framework maintainer, Marek Szyprowski.
> Marek, please give me ack.
>common: DMA-mapping: add DMA_ATTR_FORCE_CONTIGUOUS attribute
>ARM: dma-mapping: add support for DMA_ATTR_FORCE_CONTIGUOUS attribute.
For the dma-mapping related changes:
Acked-by: Marek Szypr
e into existing
dma-mapping design.
> What would be the difference design-wise
> between them if this patch is merged?
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
nce design-wise
between them if this patch is merged?
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Hello,
On Tuesday, July 31, 2012 10:19 AM Jingoo Han wrote:
> On Tuesday, July 31, 2012 3:28 PM Marek Szyprowski wrote:
> >
> > Hello,
> >
> > On Tuesday, July 31, 2012 2:48 AM Jingoo Han wrote:
> >
> > > On Monday, July 30, 2012 8:16 PM, Leela Krishna A
0))
>
> In this case, the FIMD driver does not need to change.
> Also, one binary is available.
Please don't mix two methods of runtime detection. FIMD driver (s3c-fb) already
has runtime hw detection based on platform device id. Adding such detection for
exynos5 to DRM FIMD driver should not be a big issue too.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Hello,
On Tuesday, July 31, 2012 10:19 AM Jingoo Han wrote:
> On Tuesday, July 31, 2012 3:28 PM Marek Szyprowski wrote:
> >
> > Hello,
> >
> > On Tuesday, July 31, 2012 2:48 AM Jingoo Han wrote:
> >
> > > On Monday, July 30, 2012 8:16 PM, Leela Krishna A
0))
>
> In this case, the FIMD driver does not need to change.
> Also, one binary is available.
Please don't mix two methods of runtime detection. FIMD driver (s3c-fb) already
has runtime hw detection based on platform device id. Adding such detection for
exynos5 to DRM FIMD driver should not be a big issue too.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
that is needed, except whether the importer has constraints about
> maximum number of segments.
>
> Signed-off-by: Rob Clark
Yea, it is a really good idea to add this to struct device_dma_parameters.
We only need to initialize it to '1' in platform startup code for all
d
that is needed, except whether the importer has constraints about
> maximum number of segments.
>
> Signed-off-by: Rob Clark
Yea, it is a really good idea to add this to struct device_dma_parameters.
We only need to initialize it to '1' in platform startup code for all
d
ntiguous
> memory region(for example, if physically contiguous memory allocation is
> failed then it should return an error so that we can check it)
>
> Marek, for this, could you please give us comments?
If I understand right, you want to be able to allocate both physically
contiguous
and physically discontiguous memory buffers for the same device with IOMMU.
This
can be achieved by adding a new attribute to dma-mapping subsystem, let's call
it
DMA_ATTR_FORCE_CONTIGUOUS, which forces dma-mapping to allocate the buffer from
the CMA area or reserved memory (depending on what is available) instead of
assembling it from individual pages.
Would it solve your problem?
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
or example, if physically contiguous memory allocation is
> failed then it should return an error so that we can check it)
>
> Marek, for this, could you please give us comments?
If I understand right, you want to be able to allocate both physically
contiguous
and physically discontiguo
videobuf/videobuf2-dma-contig
are able to use userptr memory access method only with physically contiguous
memory. This means that in fact they work only buffers, which come from other
devices and dev2dev transfers are the only possibility. malloc()ed memory
buffers are rejected.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
videobuf/videobuf2-dma-contig
are able to use userptr memory access method only with physically contiguous
memory. This means that in fact they work only buffers, which come from other
devices and dev2dev transfers are the only possibility. malloc()ed memory
buffers are rejected.
Best regards
--
(so the framebuffer
driver cannot be removed/unloaded once we use its memory, yes, pretty
theoretical case).
Copying vma was the only solution for the races that usually happen on process
cleanup or special 'nasty' test case which closed the device before closing the
other v4l2 which used its memory with user pointer method.
The most critical parts of vma are NULLed (vm_mm, vm_next, vm_prev) to catch
possible issues, but the sane close callback should not touch them anyway.
Besides vm_private_data, close callback might need to access vm_file,
vm_start/vm_end and vm_flags. Maybe coping them explicitly while keeping
everything else NULLed would be a better idea.
(snipped)
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
(so the framebuffer
driver cannot be removed/unloaded once we use its memory, yes, pretty
theoretical case).
Copying vma was the only solution for the races that usually happen on process
cleanup or special 'nasty' test case which closed the device before closing the
other v4l2 which used its memory with user pointer method.
The most critical parts of vma are NULLed (vm_mm, vm_next, vm_prev) to catch
possible issues, but the sane close callback should not touch them anyway.
Besides vm_private_data, close callback might need to access vm_file,
vm_start/vm_end and vm_flags. Maybe coping them explicitly while keeping
everything else NULLed would be a better idea.
(snipped)
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
ks of memory and create a contiguous DMA
mapping.
To fulfill dma mapping request you also need to create a cpu coherent mapping
for
them and right now my core uses the same remapping function as linear version.
The only limitation here will be vmalloc space and its fragmentation.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
Hi Arnd,
On Thursday, April 12, 2012 1:18 PM Arnd Bergmann wrote:
> On Thursday 12 April 2012, Marek Szyprowski wrote:
> > Scatter lists were initially designed for the disk based block io
> > operations,
> > hence the presence of the in-page offsets and length
ve choosen this.
> > >
> > > I don't think this works on ARM. Maybe I'm not seeing the whole picture
> > > but
> > > judging by a quick look through the kernel tree there aren't any users
> > > that
> > > map DMA memory through an
ks of memory and create a contiguous DMA
mapping.
To fulfill dma mapping request you also need to create a cpu coherent mapping
for
them and right now my core uses the same remapping function as linear version.
The only limitation here will be vmalloc space and its fragmentation.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Hi Arnd,
On Thursday, April 12, 2012 1:18 PM Arnd Bergmann wrote:
> On Thursday 12 April 2012, Marek Szyprowski wrote:
> > Scatter lists were initially designed for the disk based block io
> > operations,
> > hence the presence of the in-page offsets and length
ve choosen this.
> > >
> > > I don't think this works on ARM. Maybe I'm not seeing the whole picture
> > > but
> > > judging by a quick look through the kernel tree there aren't any users
> > > that
> > > map DMA memory through an
ected to be merged via akpm tree together with other core memory
management
patches. I got a message that Andrew Morton scheduled it for v3.5 kernel, so it
should
be soon available in linux-next tree.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
_
ected to be merged via akpm tree together with other core memory
management
patches. I got a message that Andrew Morton scheduled it for v3.5 kernel, so it
should
be soon available in linux-next tree.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
he memory that belongs to the exported buffer (might be pinned). How
do you want to solve the following case - the gpu hardware from your diagram
and a simple usb webcam with generic driver. The application would like to
export a buffer from the webcam to scanout engine. How the generic webcam
driver might know HOW to set up the tiller to create correct mappings for
the GPU/scanout? IMHO only a GPU driver is capable of doing that assuming
it got just a scatter list from the webcam driver.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
he memory that belongs to the exported buffer (might be pinned). How
do you want to solve the following case - the gpu hardware from your diagram
and a simple usb webcam with generic driver. The application would like to
export a buffer from the webcam to scanout engine. How the generic webcam
driver might know HOW to set up the tiller to create correct mappings for
the GPU/scanout? IMHO only a GPU driver is capable of doing that assuming
it got just a scatter list from the webcam driver.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
client devices. What if the device
needs additional custom hooks/hacks during the mappings? This will be a serious
problem for the current GPU drivers for example. IMHO the API will be much
clearer if each client driver will map the scatter list gathered from the
dma buf by itself. Only the client driver has the complete knowledge how
to do this correctly for this particular device. This way it will also work
with devices that don't do the real DMA (like for example USB devices that
copy all data from usb packets to the target buffer with the cpu).
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
client devices. What if the device
needs additional custom hooks/hacks during the mappings? This will be a serious
problem for the current GPU drivers for example. IMHO the API will be much
clearer if each client driver will map the scatter list gathered from the
dma buf by itself. Only the client driver has the complete knowledge how
to do this correctly for this particular device. This way it will also work
with devices that don't do the real DMA (like for example USB devices that
copy all data from usb packets to the target buffer with the cpu).
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
s a way to pass a buffer to them (i.e. using
dma_buf method). However the driver must be able to address that memory.
CMA private pools were designed mainly to resolve the problem that some
weird hardware can access certain types of buffers only at particular
memory address ranges which matches parti
e is a way to pass a buffer to them (i.e. using
dma_buf method). However the driver must be able to address that memory.
CMA private pools were designed mainly to resolve the problem that some
weird hardware can access certain types of buffers only at particular
memory address ranges which matches p
; though, and turn that on if needed.
The drivers shouldn't do ANY byte swapping at all. Only tools that
extract pixel data with some 'accelerated' methods (like 32bit integer
casting and bit-level shifting) should be aware of endianess.
> I really need to run some tests, but I've been telling myself this for
> years now :-(
I've checked the BTTV board in my PowerMac/G4 and the display was
correct with xawtv. It is just a matter of selecting correct pix format
basing on the information returned by xsever.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
; though, and turn that on if needed.
The drivers shouldn't do ANY byte swapping at all. Only tools that
extract pixel data with some 'accelerated' methods (like 32bit integer
casting and bit-level shifting) should be aware of endianess.
> I really need to run some tests, but I'v
1001 - 1034 of 1034 matches
Mail list logo
