Message ID | 1487058728-16501-1-git-send-email-m.szyprowski@samsung.com |
---|---|
Headers | show |
Series | Exynos MFC v6+ - remove the need for the reserved memory | expand |
Le mardi 14 février 2017 à 08:51 +0100, Marek Szyprowski a écrit : > Dear All, > > This patchset is a result of my work on enabling full support for MFC device > (multimedia codec) on Exynos 5433 on ARM64 architecture. Initially I thought > that to let it working on ARM64 architecture with IOMMU, I would need to > solve the issue related to the fact that s5p-mfc driver was depending on the > first-fit allocation method in the DMA-mapping / IOMMU glue code (ARM64 use > different algorithm). It turned out, that there is a much simpler way. > > During my research I found that some of the requirements for the memory > buffers for MFC v6+ devices were blindly copied from the previous > hardware (v5) version and simply turned out to be excessive. It turned out > that there is no strict requirement for ALL buffers to be allocated on > the higher addresses than the firmware base. This requirement is true only > for the device and per-context buffers. All video data buffers can be > allocated anywhere for all MFC v6+ versions. This heavily simplifies > memory management in the driver. > > Such relaxed requirements for the memory buffers can be easily fulfilled > by allocating firmware, device and per-context buffers from the probe-time > preallocated larger buffer. There is no need to create special reserved > memory regions. The only case, when those memory regions are needed is an > oldest Exynos series - Exynos4210 or Exyno4412, which both have MFC v5 > hardware, and only when IOMMU is disabled. > > This patchset has been tested on Odroid U3 (Exynos4412 with MFC v5), Google > Snow (Exynos5250 with MFC v6), Odroid XU3 (Exynos5422 with MFC v8) and > TM2 (Exynos5433 with MFC v8, ARM64) boards. > > To get it working on TM2/Exynos5433 with IOMMU enabled, the 'architectural > clock gating' in SYSMMU has to be disabled. Fixing this will be handled > separately. As a temporary solution, one need to clear CFG_ACGEN bit in > REG_MMU_CFG of the SYSMMU, see __sysmmu_init_config function in > drivers/iommu/exynos-iommu.c. > > Patches are based on linux-next from 9th February 2017 with "media: > s5p-mfc: Fix initialization of internal structures" patch applied: > https://patchwork.linuxtv.org/patch/39198/ > > I've tried to split changes into small pieces to make it easier to review > the code. I've also did a bit of cleanup while touching the driver. > > Best regards > Marek Szyprowski > Samsung R&D Institute Poland > > > Patch summary: > > Marek Szyprowski (15): > media: s5p-mfc: Remove unused structures and dead code > media: s5p-mfc: Use generic of_device_get_match_data helper > media: s5p-mfc: Replace mem_dev_* entries with an array > media: s5p-mfc: Replace bank1/bank2 entries with an array > media: s5p-mfc: Simplify alloc/release private buffer functions > media: s5p-mfc: Move setting DMA max segmetn size to DMA configure > function Just notice this small typo "segmetn", associated patch will need update too. > media: s5p-mfc: Put firmware to private buffer structure > media: s5p-mfc: Move firmware allocation to DMA configure function > media: s5p-mfc: Allocate firmware with internal private buffer alloc > function > media: s5p-mfc: Reduce firmware buffer size for MFC v6+ variants > media: s5p-mfc: Split variant DMA memory configuration into separate > functions > media: s5p-mfc: Add support for probe-time preallocated block based > allocator > media: s5p-mfc: Remove special configuration of IOMMU domain > media: s5p-mfc: Use preallocated block allocator always for MFC v6+ > ARM: dts: exynos: Remove MFC reserved buffers > > .../devicetree/bindings/media/s5p-mfc.txt | 2 +- > arch/arm/boot/dts/exynos5250-arndale.dts | 1 - > arch/arm/boot/dts/exynos5250-smdk5250.dts | 1 - > arch/arm/boot/dts/exynos5250-spring.dts | 1 - > arch/arm/boot/dts/exynos5420-arndale-octa.dts | 1 - > arch/arm/boot/dts/exynos5420-peach-pit.dts | 1 - > arch/arm/boot/dts/exynos5420-smdk5420.dts | 1 - > arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 1 - > arch/arm/boot/dts/exynos5800-peach-pi.dts | 1 - > drivers/media/platform/s5p-mfc/regs-mfc-v6.h | 2 +- > drivers/media/platform/s5p-mfc/regs-mfc-v7.h | 2 +- > drivers/media/platform/s5p-mfc/regs-mfc-v8.h | 2 +- > drivers/media/platform/s5p-mfc/s5p_mfc.c | 210 +++++++++++++-------- > drivers/media/platform/s5p-mfc/s5p_mfc_cmd_v5.c | 2 +- > drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 43 ++--- > drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.c | 71 +++---- > drivers/media/platform/s5p-mfc/s5p_mfc_ctrl.h | 1 - > drivers/media/platform/s5p-mfc/s5p_mfc_dec.c | 8 +- > drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 10 +- > drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h | 51 +---- > drivers/media/platform/s5p-mfc/s5p_mfc_opr.c | 65 +++++-- > drivers/media/platform/s5p-mfc/s5p_mfc_opr.h | 8 +- > drivers/media/platform/s5p-mfc/s5p_mfc_opr_v5.c | 48 ++--- > drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 14 +- > 24 files changed, 264 insertions(+), 283 deletions(-) >
Hello Marek, On 02/14/2017 04:51 AM, Marek Szyprowski wrote: > Remove unused structures, definitions and functions that are no longer > called from the driver code. > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> > --- Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Also on an Exynos5422 Odroid XU4 and Exyos5800 Peach Pi boards: Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello Marek, On 02/14/2017 04:52 AM, Marek Szyprowski wrote: > Move code for DMA memory configuration with IOMMU into separate function > to make it easier to compare what is being done in each case. > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> > --- > drivers/media/platform/s5p-mfc/s5p_mfc.c | 102 ++++++++++++++++++------------- > 1 file changed, 61 insertions(+), 41 deletions(-) > > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c > index 92a88c20b26d..a18740c81c55 100644 > --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c > @@ -1107,41 +1107,13 @@ static struct device *s5p_mfc_alloc_memdev(struct device *dev, > return NULL; > } > > -static int s5p_mfc_configure_dma_memory(struct s5p_mfc_dev *mfc_dev) > +static int s5p_mfc_configure_2port_memory(struct s5p_mfc_dev *mfc_dev) > { > struct device *dev = &mfc_dev->plat_dev->dev; > void *bank2_virt; > dma_addr_t bank2_dma_addr; > unsigned long align_size = 1 << MFC_BASE_ALIGN_ORDER; > - struct s5p_mfc_priv_buf *fw_buf = &mfc_dev->fw_buf; > - > - /* > - * When IOMMU is available, we cannot use the default configuration, > - * because of MFC firmware requirements: address space limited to > - * 256M and non-zero default start address. > - * This is still simplified, not optimal configuration, but for now > - * IOMMU core doesn't allow to configure device's IOMMUs channel > - * separately. > - */ > - if (exynos_is_iommu_available(dev)) { > - int ret = exynos_configure_iommu(dev, S5P_MFC_IOMMU_DMA_BASE, > - S5P_MFC_IOMMU_DMA_SIZE); > - if (ret) > - return ret; > - > - mfc_dev->mem_dev[BANK1_CTX] = mfc_dev->mem_dev[BANK2_CTX] = dev; > - ret = s5p_mfc_alloc_firmware(mfc_dev); > - if (ret) { > - exynos_unconfigure_iommu(dev); > - return ret; > - } > - > - mfc_dev->dma_base[BANK1_CTX] = mfc_dev->fw_buf.dma; > - mfc_dev->dma_base[BANK2_CTX] = mfc_dev->fw_buf.dma; > - vb2_dma_contig_set_max_seg_size(dev, DMA_BIT_MASK(32)); > - > - return 0; > - } > + int ret; This should be declared in patch 8/15. > > /* > * Create and initialize virtual devices for accessing > @@ -1188,26 +1160,74 @@ static int s5p_mfc_configure_dma_memory(struct s5p_mfc_dev *mfc_dev) > DMA_BIT_MASK(32)); > vb2_dma_contig_set_max_seg_size(mfc_dev->mem_dev[BANK2_CTX], > DMA_BIT_MASK(32)); > - This seems to be an unrelated change. The rest looks good to me. Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html