[PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
Hello Marek, > -Original Message- > From: Marek Szyprowski [mailto:m.szyprowski at samsung.com] > Sent: Tuesday, July 17, 2012 5:04 PM > To: 'Inki Dae'; 'Subash Patel' > Cc: 'Prathyush K'; dri-devel at lists.freedesktop.org; prathyush at > chromium.org > Subject: RE: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM > > Hello, > > On Monday, July 16, 2012 3:47 PM Inki Dae wrote: > > > > -Original Message- > > > From: Subash Patel [mailto:subash.ramaswamy at linaro.org] > > > Sent: Friday, July 13, 2012 3:58 PM > > > To: Inki Dae > > > Cc: 'Prathyush K'; dri-devel at lists.freedesktop.org; > > prathyush at chromium.org; > > > m.szyprowski at samsung.com > > > Subject: Re: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM > > > > > > On 07/13/2012 12:09 PM, Inki Dae wrote: > > > > > > > >> -Original Message- > > > >> From: Prathyush K [mailto:prathyush.k at samsung.com] > > > >> Sent: Wednesday, July 11, 2012 6:40 PM > > > >> To: dri-devel at lists.freedesktop.org > > > >> Cc: prathyush at chromium.org; m.szyprowski at samsung.com; > > > > inki.dae at samsung.com; > > > >> subash.ramaswamy at linaro.org > > > >> Subject: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM > > > >> > > > >> The dma-mapping framework needs a IOMMU mapping to be created for > the > > > >> device which allocates/maps/frees the non-contig buffer. In the DRM > > > >> framework, a gem buffer is created by the DRM virtual device and > not > > > >> directly by any of the physical devices (FIMD, HDMI etc). Each gem > > > object > > > >> can be set as a framebuffer to one or many of the drm devices. So a > gem > > > >> object cannot be allocated for any one device. All the DRM devices > > > should > > > >> be able to access this buffer. > > > >> > > > > It's good to use unified iommu table so I agree to your opinion but > we > > > don't > > > > decide whether we use dma mapping api or not. now dma mapping api > has > > > one > > > > issue. > > > > in case of using iommu with dma mapping api, we couldn't use > physically > > > > contiguous memory region with iommu. for this, there is a case that > we > > > > should use physically contiguous memory region with iommu. it is > because > > > we > > > > sometime may use mfc(hw video codec) with secure zone such as ARM > > > TrustZone. > > > > Then, it needs physically contiguous memory region. > > > > > > > > Thanks, > > > > Inki Dae > > > I agree. In the mainline code, as of now only the arm_dma_ops has the > > > support allocating > > > from the CMA. But in the function arm_iommu_alloc_attrs(), there is no > > > way to know if the > > > device had declared a contiguous memory range. The reason, we don't > > > store that cookie > > > into the device during the dma_declare_contiguous(). So is it > advisable > > > to store such information > > > like mapping(in the iommu operations) in the device.archdata? > > > > > > Regards, > > > Subash > > > > There was my missing point. dma mapping api with iommu tries to allocate > > pages contiguously if possible. as HW Video codec above, there is the > case > > that physically contiguous memory region is need necessarily but it > seems > > like that now dma mapping api doesn't guarantee fully physically > contiguous > > 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? > Yes, it does. we need DMA_ATTR_FORCE_CONGIGUOUS feature so that the CMA can guarantee fully physically contiguous memory allocation in some case. Thanks, Inki Dae > Best regards > -- > Marek Szyprowski > Samsung Poland R Center
[PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
Hello, On Monday, July 16, 2012 3:47 PM Inki Dae wrote: > > -Original Message- > > From: Subash Patel [mailto:subash.ramaswamy at linaro.org] > > Sent: Friday, July 13, 2012 3:58 PM > > To: Inki Dae > > Cc: 'Prathyush K'; dri-devel at lists.freedesktop.org; > prathyush at chromium.org; > > m.szyprowski at samsung.com > > Subject: Re: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM > > > > On 07/13/2012 12:09 PM, Inki Dae wrote: > > > > > >> -Original Message- > > >> From: Prathyush K [mailto:prathyush.k at samsung.com] > > >> Sent: Wednesday, July 11, 2012 6:40 PM > > >> To: dri-devel at lists.freedesktop.org > > >> Cc: prathyush at chromium.org; m.szyprowski at samsung.com; > > > inki.dae at samsung.com; > > >> subash.ramaswamy at linaro.org > > >> Subject: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM > > >> > > >> The dma-mapping framework needs a IOMMU mapping to be created for the > > >> device which allocates/maps/frees the non-contig buffer. In the DRM > > >> framework, a gem buffer is created by the DRM virtual device and not > > >> directly by any of the physical devices (FIMD, HDMI etc). Each gem > > object > > >> can be set as a framebuffer to one or many of the drm devices. So a gem > > >> object cannot be allocated for any one device. All the DRM devices > > should > > >> be able to access this buffer. > > >> > > > It's good to use unified iommu table so I agree to your opinion but we > > don't > > > decide whether we use dma mapping api or not. now dma mapping api has > > one > > > issue. > > > in case of using iommu with dma mapping api, we couldn't use physically > > > contiguous memory region with iommu. for this, there is a case that we > > > should use physically contiguous memory region with iommu. it is because > > we > > > sometime may use mfc(hw video codec) with secure zone such as ARM > > TrustZone. > > > Then, it needs physically contiguous memory region. > > > > > > Thanks, > > > Inki Dae > > I agree. In the mainline code, as of now only the arm_dma_ops has the > > support allocating > > from the CMA. But in the function arm_iommu_alloc_attrs(), there is no > > way to know if the > > device had declared a contiguous memory range. The reason, we don't > > store that cookie > > into the device during the dma_declare_contiguous(). So is it advisable > > to store such information > > like mapping(in the iommu operations) in the device.archdata? > > > > Regards, > > Subash > > There was my missing point. dma mapping api with iommu tries to allocate > pages contiguously if possible. as HW Video codec above, there is the case > that physically contiguous memory region is need necessarily but it seems > like that now dma mapping api doesn't guarantee fully physically contiguous > 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 Center
RE: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
Hello Marek, -Original Message- From: Marek Szyprowski [mailto:m.szyprow...@samsung.com] Sent: Tuesday, July 17, 2012 5:04 PM To: 'Inki Dae'; 'Subash Patel' Cc: 'Prathyush K'; dri-devel@lists.freedesktop.org; prathy...@chromium.org Subject: RE: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM Hello, On Monday, July 16, 2012 3:47 PM Inki Dae wrote: -Original Message- From: Subash Patel [mailto:subash.ramasw...@linaro.org] Sent: Friday, July 13, 2012 3:58 PM To: Inki Dae Cc: 'Prathyush K'; dri-devel@lists.freedesktop.org; prathy...@chromium.org; m.szyprow...@samsung.com Subject: Re: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM On 07/13/2012 12:09 PM, Inki Dae wrote: -Original Message- From: Prathyush K [mailto:prathyus...@samsung.com] Sent: Wednesday, July 11, 2012 6:40 PM To: dri-devel@lists.freedesktop.org Cc: prathy...@chromium.org; m.szyprow...@samsung.com; inki@samsung.com; subash.ramasw...@linaro.org Subject: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM The dma-mapping framework needs a IOMMU mapping to be created for the device which allocates/maps/frees the non-contig buffer. In the DRM framework, a gem buffer is created by the DRM virtual device and not directly by any of the physical devices (FIMD, HDMI etc). Each gem object can be set as a framebuffer to one or many of the drm devices. So a gem object cannot be allocated for any one device. All the DRM devices should be able to access this buffer. It's good to use unified iommu table so I agree to your opinion but we don't decide whether we use dma mapping api or not. now dma mapping api has one issue. in case of using iommu with dma mapping api, we couldn't use physically contiguous memory region with iommu. for this, there is a case that we should use physically contiguous memory region with iommu. it is because we sometime may use mfc(hw video codec) with secure zone such as ARM TrustZone. Then, it needs physically contiguous memory region. Thanks, Inki Dae I agree. In the mainline code, as of now only the arm_dma_ops has the support allocating from the CMA. But in the function arm_iommu_alloc_attrs(), there is no way to know if the device had declared a contiguous memory range. The reason, we don't store that cookie into the device during the dma_declare_contiguous(). So is it advisable to store such information like mapping(in the iommu operations) in the device.archdata? Regards, Subash There was my missing point. dma mapping api with iommu tries to allocate pages contiguously if possible. as HW Video codec above, there is the case that physically contiguous memory region is need necessarily but it seems like that now dma mapping api doesn't guarantee fully physically contiguous 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? Yes, it does. we need DMA_ATTR_FORCE_CONGIGUOUS feature so that the CMA can guarantee fully physically contiguous memory allocation in some case. Thanks, Inki Dae Best regards -- Marek Szyprowski Samsung Poland RD Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
Hello, On Monday, July 16, 2012 3:47 PM Inki Dae wrote: -Original Message- From: Subash Patel [mailto:subash.ramasw...@linaro.org] Sent: Friday, July 13, 2012 3:58 PM To: Inki Dae Cc: 'Prathyush K'; dri-devel@lists.freedesktop.org; prathy...@chromium.org; m.szyprow...@samsung.com Subject: Re: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM On 07/13/2012 12:09 PM, Inki Dae wrote: -Original Message- From: Prathyush K [mailto:prathyus...@samsung.com] Sent: Wednesday, July 11, 2012 6:40 PM To: dri-devel@lists.freedesktop.org Cc: prathy...@chromium.org; m.szyprow...@samsung.com; inki@samsung.com; subash.ramasw...@linaro.org Subject: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM The dma-mapping framework needs a IOMMU mapping to be created for the device which allocates/maps/frees the non-contig buffer. In the DRM framework, a gem buffer is created by the DRM virtual device and not directly by any of the physical devices (FIMD, HDMI etc). Each gem object can be set as a framebuffer to one or many of the drm devices. So a gem object cannot be allocated for any one device. All the DRM devices should be able to access this buffer. It's good to use unified iommu table so I agree to your opinion but we don't decide whether we use dma mapping api or not. now dma mapping api has one issue. in case of using iommu with dma mapping api, we couldn't use physically contiguous memory region with iommu. for this, there is a case that we should use physically contiguous memory region with iommu. it is because we sometime may use mfc(hw video codec) with secure zone such as ARM TrustZone. Then, it needs physically contiguous memory region. Thanks, Inki Dae I agree. In the mainline code, as of now only the arm_dma_ops has the support allocating from the CMA. But in the function arm_iommu_alloc_attrs(), there is no way to know if the device had declared a contiguous memory range. The reason, we don't store that cookie into the device during the dma_declare_contiguous(). So is it advisable to store such information like mapping(in the iommu operations) in the device.archdata? Regards, Subash There was my missing point. dma mapping api with iommu tries to allocate pages contiguously if possible. as HW Video codec above, there is the case that physically contiguous memory region is need necessarily but it seems like that now dma mapping api doesn't guarantee fully physically contiguous 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 RD Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
> -Original Message- > From: Subash Patel [mailto:subash.ramaswamy at linaro.org] > Sent: Friday, July 13, 2012 3:58 PM > To: Inki Dae > Cc: 'Prathyush K'; dri-devel at lists.freedesktop.org; prathyush at chromium.org; > m.szyprowski at samsung.com > Subject: Re: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM > > On 07/13/2012 12:09 PM, Inki Dae wrote: > > > >> -Original Message- > >> From: Prathyush K [mailto:prathyush.k at samsung.com] > >> Sent: Wednesday, July 11, 2012 6:40 PM > >> To: dri-devel at lists.freedesktop.org > >> Cc: prathyush at chromium.org; m.szyprowski at samsung.com; > > inki.dae at samsung.com; > >> subash.ramaswamy at linaro.org > >> Subject: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM > >> > >> The dma-mapping framework needs a IOMMU mapping to be created for the > >> device which allocates/maps/frees the non-contig buffer. In the DRM > >> framework, a gem buffer is created by the DRM virtual device and not > >> directly by any of the physical devices (FIMD, HDMI etc). Each gem > object > >> can be set as a framebuffer to one or many of the drm devices. So a gem > >> object cannot be allocated for any one device. All the DRM devices > should > >> be able to access this buffer. > >> > > It's good to use unified iommu table so I agree to your opinion but we > don't > > decide whether we use dma mapping api or not. now dma mapping api has > one > > issue. > > in case of using iommu with dma mapping api, we couldn't use physically > > contiguous memory region with iommu. for this, there is a case that we > > should use physically contiguous memory region with iommu. it is because > we > > sometime may use mfc(hw video codec) with secure zone such as ARM > TrustZone. > > Then, it needs physically contiguous memory region. > > > > Thanks, > > Inki Dae > I agree. In the mainline code, as of now only the arm_dma_ops has the > support allocating > from the CMA. But in the function arm_iommu_alloc_attrs(), there is no > way to know if the > device had declared a contiguous memory range. The reason, we don't > store that cookie > into the device during the dma_declare_contiguous(). So is it advisable > to store such information > like mapping(in the iommu operations) in the device.archdata? > > Regards, > Subash There was my missing point. dma mapping api with iommu tries to allocate pages contiguously if possible. as HW Video codec above, there is the case that physically contiguous memory region is need necessarily but it seems like that now dma mapping api doesn't guarantee fully physically contiguous 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? Thanks, Inki Dae > > > >> The proposed method is to create a common IOMMU mapping during drm init. > >> This > >> mapping is then attached to all of the drm devices including the drm > >> device. > >> [PATCH 1/7] drm/exynos: create common IOMMU mapping for DRM > >> > >> During the probe of drm fimd, the driver retrieves a 'sysmmu' field > >> in the device node for fimd. If such a field exists, the driver > retrieves > >> the > >> platform device of the sysmmu device. This sysmmu is set as the sysmmu > >> for fimd. The common mapping created is then attached to fimd. > >> This needs to be done for all the other devices (hdmi, vidi etc). > >> [PATCH 2/7] ARM: EXYNOS5: add sysmmu field to fimd device node > >> [PATCH 3/7] drm/exynos: add IOMMU support to drm fimd > >> > >> During DRM's probe which happens last, the common mapping is set to its > >> archdata > >> and iommu ops are set as its dma ops. This requires a modification in > the > >> dma-mapping framework so that the iommu ops can be visible to all > drivers. > >> [PATCH 4/7] ARM: dma-mapping: rename and export iommu_ops > >> [PATCH 5/7] drm/exynos: attach drm device with common drm mapping > >> > >> Currently allocation and free use the iommu framework by calling > >> dma_alloc_writecombine and dma_free_writecombine respectively. > >> For mapping the buffers to user space, the mmap functions assume that > >> the buffer is contiguous. This is modified by calling > >> dma_mmap_writecombine. > >> [PATCH 6/7] drm/exynos: Add exynos drm specific fb_mmap function > >> [PATCH 7/7] Add IOMMU support for mapping gem object > >> > >
RE: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
-Original Message- From: Subash Patel [mailto:subash.ramasw...@linaro.org] Sent: Friday, July 13, 2012 3:58 PM To: Inki Dae Cc: 'Prathyush K'; dri-devel@lists.freedesktop.org; prathy...@chromium.org; m.szyprow...@samsung.com Subject: Re: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM On 07/13/2012 12:09 PM, Inki Dae wrote: -Original Message- From: Prathyush K [mailto:prathyus...@samsung.com] Sent: Wednesday, July 11, 2012 6:40 PM To: dri-devel@lists.freedesktop.org Cc: prathy...@chromium.org; m.szyprow...@samsung.com; inki@samsung.com; subash.ramasw...@linaro.org Subject: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM The dma-mapping framework needs a IOMMU mapping to be created for the device which allocates/maps/frees the non-contig buffer. In the DRM framework, a gem buffer is created by the DRM virtual device and not directly by any of the physical devices (FIMD, HDMI etc). Each gem object can be set as a framebuffer to one or many of the drm devices. So a gem object cannot be allocated for any one device. All the DRM devices should be able to access this buffer. It's good to use unified iommu table so I agree to your opinion but we don't decide whether we use dma mapping api or not. now dma mapping api has one issue. in case of using iommu with dma mapping api, we couldn't use physically contiguous memory region with iommu. for this, there is a case that we should use physically contiguous memory region with iommu. it is because we sometime may use mfc(hw video codec) with secure zone such as ARM TrustZone. Then, it needs physically contiguous memory region. Thanks, Inki Dae I agree. In the mainline code, as of now only the arm_dma_ops has the support allocating from the CMA. But in the function arm_iommu_alloc_attrs(), there is no way to know if the device had declared a contiguous memory range. The reason, we don't store that cookie into the device during the dma_declare_contiguous(). So is it advisable to store such information like mapping(in the iommu operations) in the device.archdata? Regards, Subash There was my missing point. dma mapping api with iommu tries to allocate pages contiguously if possible. as HW Video codec above, there is the case that physically contiguous memory region is need necessarily but it seems like that now dma mapping api doesn't guarantee fully physically contiguous 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? Thanks, Inki Dae The proposed method is to create a common IOMMU mapping during drm init. This mapping is then attached to all of the drm devices including the drm device. [PATCH 1/7] drm/exynos: create common IOMMU mapping for DRM During the probe of drm fimd, the driver retrieves a 'sysmmu' field in the device node for fimd. If such a field exists, the driver retrieves the platform device of the sysmmu device. This sysmmu is set as the sysmmu for fimd. The common mapping created is then attached to fimd. This needs to be done for all the other devices (hdmi, vidi etc). [PATCH 2/7] ARM: EXYNOS5: add sysmmu field to fimd device node [PATCH 3/7] drm/exynos: add IOMMU support to drm fimd During DRM's probe which happens last, the common mapping is set to its archdata and iommu ops are set as its dma ops. This requires a modification in the dma-mapping framework so that the iommu ops can be visible to all drivers. [PATCH 4/7] ARM: dma-mapping: rename and export iommu_ops [PATCH 5/7] drm/exynos: attach drm device with common drm mapping Currently allocation and free use the iommu framework by calling dma_alloc_writecombine and dma_free_writecombine respectively. For mapping the buffers to user space, the mmap functions assume that the buffer is contiguous. This is modified by calling dma_mmap_writecombine. [PATCH 6/7] drm/exynos: Add exynos drm specific fb_mmap function [PATCH 7/7] Add IOMMU support for mapping gem object The device tree based patches are based on Leela's patch which was posted last week for adding DT support to DRM FIMD. The patch to add sysmmu field is for reference only and will be posted to the device tree mailing list. Same with the rename and export iommu_ops patch. These patches are tested on Exynos5250 SMDK board and tested with modetest from libdrm tests. Prathyush K (7): drm/exynos: create common IOMMU mapping for DRM ARM: EXYNOS5: add sysmmu field to fimd device node drm/exynos: add IOMMU support to drm fimd ARM: dma-mapping: rename and export iommu_ops drm/exynos: attach drm device with common drm mapping drm/exynos: Add exynos drm specific fb_mmap function drm/exynos: Add IOMMU support for mapping gem object arch/arm/boot/dts/exynos5250.dtsi
[PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
> -Original Message- > From: Prathyush K [mailto:prathyush.k at samsung.com] > Sent: Wednesday, July 11, 2012 6:40 PM > To: dri-devel at lists.freedesktop.org > Cc: prathyush at chromium.org; m.szyprowski at samsung.com; inki.dae at samsung.com; > subash.ramaswamy at linaro.org > Subject: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM > > The dma-mapping framework needs a IOMMU mapping to be created for the > device which allocates/maps/frees the non-contig buffer. In the DRM > framework, a gem buffer is created by the DRM virtual device and not > directly by any of the physical devices (FIMD, HDMI etc). Each gem object > can be set as a framebuffer to one or many of the drm devices. So a gem > object cannot be allocated for any one device. All the DRM devices should > be able to access this buffer. > It's good to use unified iommu table so I agree to your opinion but we don't decide whether we use dma mapping api or not. now dma mapping api has one issue. in case of using iommu with dma mapping api, we couldn't use physically contiguous memory region with iommu. for this, there is a case that we should use physically contiguous memory region with iommu. it is because we sometime may use mfc(hw video codec) with secure zone such as ARM TrustZone. Then, it needs physically contiguous memory region. Thanks, Inki Dae > The proposed method is to create a common IOMMU mapping during drm init. > This > mapping is then attached to all of the drm devices including the drm > device. > [PATCH 1/7] drm/exynos: create common IOMMU mapping for DRM > > During the probe of drm fimd, the driver retrieves a 'sysmmu' field > in the device node for fimd. If such a field exists, the driver retrieves > the > platform device of the sysmmu device. This sysmmu is set as the sysmmu > for fimd. The common mapping created is then attached to fimd. > This needs to be done for all the other devices (hdmi, vidi etc). > [PATCH 2/7] ARM: EXYNOS5: add sysmmu field to fimd device node > [PATCH 3/7] drm/exynos: add IOMMU support to drm fimd > > During DRM's probe which happens last, the common mapping is set to its > archdata > and iommu ops are set as its dma ops. This requires a modification in the > dma-mapping framework so that the iommu ops can be visible to all drivers. > [PATCH 4/7] ARM: dma-mapping: rename and export iommu_ops > [PATCH 5/7] drm/exynos: attach drm device with common drm mapping > > Currently allocation and free use the iommu framework by calling > dma_alloc_writecombine and dma_free_writecombine respectively. > For mapping the buffers to user space, the mmap functions assume that > the buffer is contiguous. This is modified by calling > dma_mmap_writecombine. > [PATCH 6/7] drm/exynos: Add exynos drm specific fb_mmap function > [PATCH 7/7] Add IOMMU support for mapping gem object > > The device tree based patches are based on Leela's patch which was posted > last week for adding DT support to DRM FIMD. The patch to add sysmmu > field is for reference only and will be posted to the device tree > mailing list. Same with the rename and export iommu_ops patch. > > These patches are tested on Exynos5250 SMDK board and tested with modetest > from libdrm tests. > > Prathyush K (7): > drm/exynos: create common IOMMU mapping for DRM > ARM: EXYNOS5: add sysmmu field to fimd device node > drm/exynos: add IOMMU support to drm fimd > ARM: dma-mapping: rename and export iommu_ops > drm/exynos: attach drm device with common drm mapping > drm/exynos: Add exynos drm specific fb_mmap function > drm/exynos: Add IOMMU support for mapping gem object > > arch/arm/boot/dts/exynos5250.dtsi |1 + > arch/arm/include/asm/dma-mapping.h|1 + > arch/arm/mm/dma-mapping.c |5 ++- > drivers/gpu/drm/exynos/exynos_drm_core.c |3 ++ > drivers/gpu/drm/exynos/exynos_drm_drv.c | 30 > drivers/gpu/drm/exynos/exynos_drm_drv.h | 10 + > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 16 > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 54 > - > drivers/gpu/drm/exynos/exynos_drm_gem.c | 35 -- > 9 files changed, 133 insertions(+), 22 deletions(-)
[PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
On 07/13/2012 12:09 PM, Inki Dae wrote: > >> -Original Message- >> From: Prathyush K [mailto:prathyush.k at samsung.com] >> Sent: Wednesday, July 11, 2012 6:40 PM >> To: dri-devel at lists.freedesktop.org >> Cc: prathyush at chromium.org; m.szyprowski at samsung.com; > inki.dae at samsung.com; >> subash.ramaswamy at linaro.org >> Subject: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM >> >> The dma-mapping framework needs a IOMMU mapping to be created for the >> device which allocates/maps/frees the non-contig buffer. In the DRM >> framework, a gem buffer is created by the DRM virtual device and not >> directly by any of the physical devices (FIMD, HDMI etc). Each gem object >> can be set as a framebuffer to one or many of the drm devices. So a gem >> object cannot be allocated for any one device. All the DRM devices should >> be able to access this buffer. >> > It's good to use unified iommu table so I agree to your opinion but we don't > decide whether we use dma mapping api or not. now dma mapping api has one > issue. > in case of using iommu with dma mapping api, we couldn't use physically > contiguous memory region with iommu. for this, there is a case that we > should use physically contiguous memory region with iommu. it is because we > sometime may use mfc(hw video codec) with secure zone such as ARM TrustZone. > Then, it needs physically contiguous memory region. > > Thanks, > Inki Dae I agree. In the mainline code, as of now only the arm_dma_ops has the support allocating from the CMA. But in the function arm_iommu_alloc_attrs(), there is no way to know if the device had declared a contiguous memory range. The reason, we don't store that cookie into the device during the dma_declare_contiguous(). So is it advisable to store such information like mapping(in the iommu operations) in the device.archdata? Regards, Subash > >> The proposed method is to create a common IOMMU mapping during drm init. >> This >> mapping is then attached to all of the drm devices including the drm >> device. >> [PATCH 1/7] drm/exynos: create common IOMMU mapping for DRM >> >> During the probe of drm fimd, the driver retrieves a 'sysmmu' field >> in the device node for fimd. If such a field exists, the driver retrieves >> the >> platform device of the sysmmu device. This sysmmu is set as the sysmmu >> for fimd. The common mapping created is then attached to fimd. >> This needs to be done for all the other devices (hdmi, vidi etc). >> [PATCH 2/7] ARM: EXYNOS5: add sysmmu field to fimd device node >> [PATCH 3/7] drm/exynos: add IOMMU support to drm fimd >> >> During DRM's probe which happens last, the common mapping is set to its >> archdata >> and iommu ops are set as its dma ops. This requires a modification in the >> dma-mapping framework so that the iommu ops can be visible to all drivers. >> [PATCH 4/7] ARM: dma-mapping: rename and export iommu_ops >> [PATCH 5/7] drm/exynos: attach drm device with common drm mapping >> >> Currently allocation and free use the iommu framework by calling >> dma_alloc_writecombine and dma_free_writecombine respectively. >> For mapping the buffers to user space, the mmap functions assume that >> the buffer is contiguous. This is modified by calling >> dma_mmap_writecombine. >> [PATCH 6/7] drm/exynos: Add exynos drm specific fb_mmap function >> [PATCH 7/7] Add IOMMU support for mapping gem object >> >> The device tree based patches are based on Leela's patch which was posted >> last week for adding DT support to DRM FIMD. The patch to add sysmmu >> field is for reference only and will be posted to the device tree >> mailing list. Same with the rename and export iommu_ops patch. >> >> These patches are tested on Exynos5250 SMDK board and tested with modetest >> from libdrm tests. >> >> Prathyush K (7): >>drm/exynos: create common IOMMU mapping for DRM >>ARM: EXYNOS5: add sysmmu field to fimd device node >>drm/exynos: add IOMMU support to drm fimd >>ARM: dma-mapping: rename and export iommu_ops >>drm/exynos: attach drm device with common drm mapping >>drm/exynos: Add exynos drm specific fb_mmap function >>drm/exynos: Add IOMMU support for mapping gem object >> >> arch/arm/boot/dts/exynos5250.dtsi |1 + >> arch/arm/include/asm/dma-mapping.h|1 + >> arch/arm/mm/dma-mapping.c |5 ++- >> drivers/gpu/drm/exynos/exynos_drm_core.c |3 ++ >> drivers/gpu/drm/exynos/exynos_drm_drv.c | 30 >> drivers/gpu/drm/exynos/exynos_drm_drv.h | 10 + >> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 16 >> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 54 >> - >> drivers/gpu/drm/exynos/exynos_drm_gem.c | 35 -- >> 9 files changed, 133 insertions(+), 22 deletions(-)
RE: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
-Original Message- From: Prathyush K [mailto:prathyus...@samsung.com] Sent: Wednesday, July 11, 2012 6:40 PM To: dri-devel@lists.freedesktop.org Cc: prathy...@chromium.org; m.szyprow...@samsung.com; inki@samsung.com; subash.ramasw...@linaro.org Subject: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM The dma-mapping framework needs a IOMMU mapping to be created for the device which allocates/maps/frees the non-contig buffer. In the DRM framework, a gem buffer is created by the DRM virtual device and not directly by any of the physical devices (FIMD, HDMI etc). Each gem object can be set as a framebuffer to one or many of the drm devices. So a gem object cannot be allocated for any one device. All the DRM devices should be able to access this buffer. It's good to use unified iommu table so I agree to your opinion but we don't decide whether we use dma mapping api or not. now dma mapping api has one issue. in case of using iommu with dma mapping api, we couldn't use physically contiguous memory region with iommu. for this, there is a case that we should use physically contiguous memory region with iommu. it is because we sometime may use mfc(hw video codec) with secure zone such as ARM TrustZone. Then, it needs physically contiguous memory region. Thanks, Inki Dae The proposed method is to create a common IOMMU mapping during drm init. This mapping is then attached to all of the drm devices including the drm device. [PATCH 1/7] drm/exynos: create common IOMMU mapping for DRM During the probe of drm fimd, the driver retrieves a 'sysmmu' field in the device node for fimd. If such a field exists, the driver retrieves the platform device of the sysmmu device. This sysmmu is set as the sysmmu for fimd. The common mapping created is then attached to fimd. This needs to be done for all the other devices (hdmi, vidi etc). [PATCH 2/7] ARM: EXYNOS5: add sysmmu field to fimd device node [PATCH 3/7] drm/exynos: add IOMMU support to drm fimd During DRM's probe which happens last, the common mapping is set to its archdata and iommu ops are set as its dma ops. This requires a modification in the dma-mapping framework so that the iommu ops can be visible to all drivers. [PATCH 4/7] ARM: dma-mapping: rename and export iommu_ops [PATCH 5/7] drm/exynos: attach drm device with common drm mapping Currently allocation and free use the iommu framework by calling dma_alloc_writecombine and dma_free_writecombine respectively. For mapping the buffers to user space, the mmap functions assume that the buffer is contiguous. This is modified by calling dma_mmap_writecombine. [PATCH 6/7] drm/exynos: Add exynos drm specific fb_mmap function [PATCH 7/7] Add IOMMU support for mapping gem object The device tree based patches are based on Leela's patch which was posted last week for adding DT support to DRM FIMD. The patch to add sysmmu field is for reference only and will be posted to the device tree mailing list. Same with the rename and export iommu_ops patch. These patches are tested on Exynos5250 SMDK board and tested with modetest from libdrm tests. Prathyush K (7): drm/exynos: create common IOMMU mapping for DRM ARM: EXYNOS5: add sysmmu field to fimd device node drm/exynos: add IOMMU support to drm fimd ARM: dma-mapping: rename and export iommu_ops drm/exynos: attach drm device with common drm mapping drm/exynos: Add exynos drm specific fb_mmap function drm/exynos: Add IOMMU support for mapping gem object arch/arm/boot/dts/exynos5250.dtsi |1 + arch/arm/include/asm/dma-mapping.h|1 + arch/arm/mm/dma-mapping.c |5 ++- drivers/gpu/drm/exynos/exynos_drm_core.c |3 ++ drivers/gpu/drm/exynos/exynos_drm_drv.c | 30 drivers/gpu/drm/exynos/exynos_drm_drv.h | 10 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 16 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 54 - drivers/gpu/drm/exynos/exynos_drm_gem.c | 35 -- 9 files changed, 133 insertions(+), 22 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
On 07/13/2012 12:09 PM, Inki Dae wrote: -Original Message- From: Prathyush K [mailto:prathyus...@samsung.com] Sent: Wednesday, July 11, 2012 6:40 PM To: dri-devel@lists.freedesktop.org Cc: prathy...@chromium.org; m.szyprow...@samsung.com; inki@samsung.com; subash.ramasw...@linaro.org Subject: [PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM The dma-mapping framework needs a IOMMU mapping to be created for the device which allocates/maps/frees the non-contig buffer. In the DRM framework, a gem buffer is created by the DRM virtual device and not directly by any of the physical devices (FIMD, HDMI etc). Each gem object can be set as a framebuffer to one or many of the drm devices. So a gem object cannot be allocated for any one device. All the DRM devices should be able to access this buffer. It's good to use unified iommu table so I agree to your opinion but we don't decide whether we use dma mapping api or not. now dma mapping api has one issue. in case of using iommu with dma mapping api, we couldn't use physically contiguous memory region with iommu. for this, there is a case that we should use physically contiguous memory region with iommu. it is because we sometime may use mfc(hw video codec) with secure zone such as ARM TrustZone. Then, it needs physically contiguous memory region. Thanks, Inki Dae I agree. In the mainline code, as of now only the arm_dma_ops has the support allocating from the CMA. But in the function arm_iommu_alloc_attrs(), there is no way to know if the device had declared a contiguous memory range. The reason, we don't store that cookie into the device during the dma_declare_contiguous(). So is it advisable to store such information like mapping(in the iommu operations) in the device.archdata? Regards, Subash The proposed method is to create a common IOMMU mapping during drm init. This mapping is then attached to all of the drm devices including the drm device. [PATCH 1/7] drm/exynos: create common IOMMU mapping for DRM During the probe of drm fimd, the driver retrieves a 'sysmmu' field in the device node for fimd. If such a field exists, the driver retrieves the platform device of the sysmmu device. This sysmmu is set as the sysmmu for fimd. The common mapping created is then attached to fimd. This needs to be done for all the other devices (hdmi, vidi etc). [PATCH 2/7] ARM: EXYNOS5: add sysmmu field to fimd device node [PATCH 3/7] drm/exynos: add IOMMU support to drm fimd During DRM's probe which happens last, the common mapping is set to its archdata and iommu ops are set as its dma ops. This requires a modification in the dma-mapping framework so that the iommu ops can be visible to all drivers. [PATCH 4/7] ARM: dma-mapping: rename and export iommu_ops [PATCH 5/7] drm/exynos: attach drm device with common drm mapping Currently allocation and free use the iommu framework by calling dma_alloc_writecombine and dma_free_writecombine respectively. For mapping the buffers to user space, the mmap functions assume that the buffer is contiguous. This is modified by calling dma_mmap_writecombine. [PATCH 6/7] drm/exynos: Add exynos drm specific fb_mmap function [PATCH 7/7] Add IOMMU support for mapping gem object The device tree based patches are based on Leela's patch which was posted last week for adding DT support to DRM FIMD. The patch to add sysmmu field is for reference only and will be posted to the device tree mailing list. Same with the rename and export iommu_ops patch. These patches are tested on Exynos5250 SMDK board and tested with modetest from libdrm tests. Prathyush K (7): drm/exynos: create common IOMMU mapping for DRM ARM: EXYNOS5: add sysmmu field to fimd device node drm/exynos: add IOMMU support to drm fimd ARM: dma-mapping: rename and export iommu_ops drm/exynos: attach drm device with common drm mapping drm/exynos: Add exynos drm specific fb_mmap function drm/exynos: Add IOMMU support for mapping gem object arch/arm/boot/dts/exynos5250.dtsi |1 + arch/arm/include/asm/dma-mapping.h|1 + arch/arm/mm/dma-mapping.c |5 ++- drivers/gpu/drm/exynos/exynos_drm_core.c |3 ++ drivers/gpu/drm/exynos/exynos_drm_drv.c | 30 drivers/gpu/drm/exynos/exynos_drm_drv.h | 10 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 16 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 54 - drivers/gpu/drm/exynos/exynos_drm_gem.c | 35 -- 9 files changed, 133 insertions(+), 22 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
The dma-mapping framework needs a IOMMU mapping to be created for the device which allocates/maps/frees the non-contig buffer. In the DRM framework, a gem buffer is created by the DRM virtual device and not directly by any of the physical devices (FIMD, HDMI etc). Each gem object can be set as a framebuffer to one or many of the drm devices. So a gem object cannot be allocated for any one device. All the DRM devices should be able to access this buffer. The proposed method is to create a common IOMMU mapping during drm init. This mapping is then attached to all of the drm devices including the drm device. [PATCH 1/7] drm/exynos: create common IOMMU mapping for DRM During the probe of drm fimd, the driver retrieves a 'sysmmu' field in the device node for fimd. If such a field exists, the driver retrieves the platform device of the sysmmu device. This sysmmu is set as the sysmmu for fimd. The common mapping created is then attached to fimd. This needs to be done for all the other devices (hdmi, vidi etc). [PATCH 2/7] ARM: EXYNOS5: add sysmmu field to fimd device node [PATCH 3/7] drm/exynos: add IOMMU support to drm fimd During DRM's probe which happens last, the common mapping is set to its archdata and iommu ops are set as its dma ops. This requires a modification in the dma-mapping framework so that the iommu ops can be visible to all drivers. [PATCH 4/7] ARM: dma-mapping: rename and export iommu_ops [PATCH 5/7] drm/exynos: attach drm device with common drm mapping Currently allocation and free use the iommu framework by calling dma_alloc_writecombine and dma_free_writecombine respectively. For mapping the buffers to user space, the mmap functions assume that the buffer is contiguous. This is modified by calling dma_mmap_writecombine. [PATCH 6/7] drm/exynos: Add exynos drm specific fb_mmap function [PATCH 7/7] Add IOMMU support for mapping gem object The device tree based patches are based on Leela's patch which was posted last week for adding DT support to DRM FIMD. The patch to add sysmmu field is for reference only and will be posted to the device tree mailing list. Same with the rename and export iommu_ops patch. These patches are tested on Exynos5250 SMDK board and tested with modetest from libdrm tests. Prathyush K (7): drm/exynos: create common IOMMU mapping for DRM ARM: EXYNOS5: add sysmmu field to fimd device node drm/exynos: add IOMMU support to drm fimd ARM: dma-mapping: rename and export iommu_ops drm/exynos: attach drm device with common drm mapping drm/exynos: Add exynos drm specific fb_mmap function drm/exynos: Add IOMMU support for mapping gem object arch/arm/boot/dts/exynos5250.dtsi |1 + arch/arm/include/asm/dma-mapping.h|1 + arch/arm/mm/dma-mapping.c |5 ++- drivers/gpu/drm/exynos/exynos_drm_core.c |3 ++ drivers/gpu/drm/exynos/exynos_drm_drv.c | 30 drivers/gpu/drm/exynos/exynos_drm_drv.h | 10 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 16 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 54 - drivers/gpu/drm/exynos/exynos_drm_gem.c | 35 -- 9 files changed, 133 insertions(+), 22 deletions(-)
[PATCH 0/7] [RFC] drm/exynos: Add IOMMU support to DRM
The dma-mapping framework needs a IOMMU mapping to be created for the device which allocates/maps/frees the non-contig buffer. In the DRM framework, a gem buffer is created by the DRM virtual device and not directly by any of the physical devices (FIMD, HDMI etc). Each gem object can be set as a framebuffer to one or many of the drm devices. So a gem object cannot be allocated for any one device. All the DRM devices should be able to access this buffer. The proposed method is to create a common IOMMU mapping during drm init. This mapping is then attached to all of the drm devices including the drm device. [PATCH 1/7] drm/exynos: create common IOMMU mapping for DRM During the probe of drm fimd, the driver retrieves a 'sysmmu' field in the device node for fimd. If such a field exists, the driver retrieves the platform device of the sysmmu device. This sysmmu is set as the sysmmu for fimd. The common mapping created is then attached to fimd. This needs to be done for all the other devices (hdmi, vidi etc). [PATCH 2/7] ARM: EXYNOS5: add sysmmu field to fimd device node [PATCH 3/7] drm/exynos: add IOMMU support to drm fimd During DRM's probe which happens last, the common mapping is set to its archdata and iommu ops are set as its dma ops. This requires a modification in the dma-mapping framework so that the iommu ops can be visible to all drivers. [PATCH 4/7] ARM: dma-mapping: rename and export iommu_ops [PATCH 5/7] drm/exynos: attach drm device with common drm mapping Currently allocation and free use the iommu framework by calling dma_alloc_writecombine and dma_free_writecombine respectively. For mapping the buffers to user space, the mmap functions assume that the buffer is contiguous. This is modified by calling dma_mmap_writecombine. [PATCH 6/7] drm/exynos: Add exynos drm specific fb_mmap function [PATCH 7/7] Add IOMMU support for mapping gem object The device tree based patches are based on Leela's patch which was posted last week for adding DT support to DRM FIMD. The patch to add sysmmu field is for reference only and will be posted to the device tree mailing list. Same with the rename and export iommu_ops patch. These patches are tested on Exynos5250 SMDK board and tested with modetest from libdrm tests. Prathyush K (7): drm/exynos: create common IOMMU mapping for DRM ARM: EXYNOS5: add sysmmu field to fimd device node drm/exynos: add IOMMU support to drm fimd ARM: dma-mapping: rename and export iommu_ops drm/exynos: attach drm device with common drm mapping drm/exynos: Add exynos drm specific fb_mmap function drm/exynos: Add IOMMU support for mapping gem object arch/arm/boot/dts/exynos5250.dtsi |1 + arch/arm/include/asm/dma-mapping.h|1 + arch/arm/mm/dma-mapping.c |5 ++- drivers/gpu/drm/exynos/exynos_drm_core.c |3 ++ drivers/gpu/drm/exynos/exynos_drm_drv.c | 30 drivers/gpu/drm/exynos/exynos_drm_drv.h | 10 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 16 drivers/gpu/drm/exynos/exynos_drm_fimd.c | 54 - drivers/gpu/drm/exynos/exynos_drm_gem.c | 35 -- 9 files changed, 133 insertions(+), 22 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
