| Message ID | 1487058728-16501-15-git-send-email-m.szyprowski@samsung.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Exynos MFC v6+ - remove the need for the reserved memory | expand |
Hello Marek, On 02/14/2017 04:52 AM, Marek Szyprowski wrote: > It turned out that all versions of MFC v6+ hardware doesn't have a strict > requirement for ALL buffers to be allocated on higher addresses than the > firmware base like it was documented for MFC v5. 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. Basing on this fact, the > special DMA configuration based on two reserved memory regions is not > really needed for MFC v6+ devices, because the memory requirements for the > firmware, device and per-context buffers can be fulfilled by the simple > probe-time pre-allocated block allocator instroduced in previous patch. s/instroduced/introduced > > This patch enables support for such pre-allocated block based allocator > always for MFC v6+ devices. Due to the limitations of the memory management > subsystem the largest supported size of the pre-allocated buffer when no > CMA (Contiguous Memory Allocator) is enabled is 4MiB. > > This patch also removes the requirement to provide two reserved memory > regions for MFC v6+ devices in device tree. Now the driver is fully > functional without them. > Great! > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> > --- The patch looks good to me though and it works on my tests, I've just one comment below. Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> > Documentation/devicetree/bindings/media/s5p-mfc.txt | 2 +- > drivers/media/platform/s5p-mfc/s5p_mfc.c | 9 ++++++--- > 2 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt > index 2c901286d818..d3404b5d4d17 100644 > --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt > +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt > @@ -28,7 +28,7 @@ Optional properties: > - memory-region : from reserved memory binding: phandles to two reserved > memory regions, first is for "left" mfc memory bus interfaces, > second if for the "right" mfc memory bus, used when no SYSMMU > - support is available > + support is available; used only by MFC v5 present in Exynos4 SoCs > > Obsolete properties: > - samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c > index 8fc6fe4ba087..36f0aec2a1b3 100644 > --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c > @@ -1178,9 +1178,12 @@ static void s5p_mfc_unconfigure_2port_memory(struct s5p_mfc_dev *mfc_dev) > static int s5p_mfc_configure_common_memory(struct s5p_mfc_dev *mfc_dev) > { > struct device *dev = &mfc_dev->plat_dev->dev; > - unsigned long mem_size = SZ_8M; > + unsigned long mem_size = SZ_4M; > unsigned int bitmap_size; > > + if (IS_ENABLED(CONFIG_DMA_CMA) || exynos_is_iommu_available(dev)) > + mem_size = SZ_8M; > + > if (mfc_mem_size) > mem_size = memparse(mfc_mem_size, NULL); > The driver allows the user to set mem_size > SZ_4M using the s5p_mfc.mem parameter even when CMA ins't enabled and IOMMU isn't available. Maybe it should fail early instead and notify the user what's missing? 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
Hi Javier, On 2017-02-17 22:13, Javier Martinez Canillas wrote: > On 02/14/2017 04:52 AM, Marek Szyprowski wrote: >> It turned out that all versions of MFC v6+ hardware doesn't have a strict >> requirement for ALL buffers to be allocated on higher addresses than the >> firmware base like it was documented for MFC v5. 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. Basing on this fact, the >> special DMA configuration based on two reserved memory regions is not >> really needed for MFC v6+ devices, because the memory requirements for the >> firmware, device and per-context buffers can be fulfilled by the simple >> probe-time pre-allocated block allocator instroduced in previous patch. > s/instroduced/introduced > >> This patch enables support for such pre-allocated block based allocator >> always for MFC v6+ devices. Due to the limitations of the memory management >> subsystem the largest supported size of the pre-allocated buffer when no >> CMA (Contiguous Memory Allocator) is enabled is 4MiB. >> >> This patch also removes the requirement to provide two reserved memory >> regions for MFC v6+ devices in device tree. Now the driver is fully >> functional without them. >> > Great! > >> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> >> --- > The patch looks good to me though and it works on my tests, > I've just one comment below. > > Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> > Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> > >> Documentation/devicetree/bindings/media/s5p-mfc.txt | 2 +- >> drivers/media/platform/s5p-mfc/s5p_mfc.c | 9 ++++++--- >> 2 files changed, 7 insertions(+), 4 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt >> index 2c901286d818..d3404b5d4d17 100644 >> --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt >> +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt >> @@ -28,7 +28,7 @@ Optional properties: >> - memory-region : from reserved memory binding: phandles to two reserved >> memory regions, first is for "left" mfc memory bus interfaces, >> second if for the "right" mfc memory bus, used when no SYSMMU >> - support is available >> + support is available; used only by MFC v5 present in Exynos4 SoCs >> >> Obsolete properties: >> - samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region >> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c >> index 8fc6fe4ba087..36f0aec2a1b3 100644 >> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c >> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c >> @@ -1178,9 +1178,12 @@ static void s5p_mfc_unconfigure_2port_memory(struct s5p_mfc_dev *mfc_dev) >> static int s5p_mfc_configure_common_memory(struct s5p_mfc_dev *mfc_dev) >> { >> struct device *dev = &mfc_dev->plat_dev->dev; >> - unsigned long mem_size = SZ_8M; >> + unsigned long mem_size = SZ_4M; >> unsigned int bitmap_size; >> >> + if (IS_ENABLED(CONFIG_DMA_CMA) || exynos_is_iommu_available(dev)) >> + mem_size = SZ_8M; >> + >> if (mfc_mem_size) >> mem_size = memparse(mfc_mem_size, NULL); >> > The driver allows the user to set mem_size > SZ_4M using the s5p_mfc.mem > parameter even when CMA ins't enabled and IOMMU isn't available. Maybe it > should fail early instead and notify the user what's missing? It will notify user that driver failed to preallocate memory. 4M is the upper limit for standard kernel configuration, but afair there were some kconfig knobs to force kernel to use larger buckets for buddy allocator (what changes the limit). Frankly I would leave it as is. If user wants to specify s5p-mfc.mem, he already has some knowledge how to configure the kernel. I don't think that driver should check all possible scenarios of failing and give detailed explanation what was configured wrong. You can also enable CMA and configure the 8MiB of the default global area. In such configuration preallocation of mfc firmware buffer will also fail. Should the driver care about it? IMO it is enough to tell user that preallocating of given megabytes failed. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- 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/20/2017 10:23 AM, Marek Szyprowski wrote: > Hi Javier, > > On 2017-02-17 22:13, Javier Martinez Canillas wrote: >> On 02/14/2017 04:52 AM, Marek Szyprowski wrote: >>> It turned out that all versions of MFC v6+ hardware doesn't have a strict >>> requirement for ALL buffers to be allocated on higher addresses than the >>> firmware base like it was documented for MFC v5. 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. Basing on this fact, the >>> special DMA configuration based on two reserved memory regions is not >>> really needed for MFC v6+ devices, because the memory requirements for the >>> firmware, device and per-context buffers can be fulfilled by the simple >>> probe-time pre-allocated block allocator instroduced in previous patch. >> s/instroduced/introduced >> >>> This patch enables support for such pre-allocated block based allocator >>> always for MFC v6+ devices. Due to the limitations of the memory management >>> subsystem the largest supported size of the pre-allocated buffer when no >>> CMA (Contiguous Memory Allocator) is enabled is 4MiB. >>> >>> This patch also removes the requirement to provide two reserved memory >>> regions for MFC v6+ devices in device tree. Now the driver is fully >>> functional without them. >>> >> Great! >> >>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> >>> --- >> The patch looks good to me though and it works on my tests, >> I've just one comment below. >> >> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com> >> Tested-by: Javier Martinez Canillas <javier@osg.samsung.com> >> >>> Documentation/devicetree/bindings/media/s5p-mfc.txt | 2 +- >>> drivers/media/platform/s5p-mfc/s5p_mfc.c | 9 ++++++--- >>> 2 files changed, 7 insertions(+), 4 deletions(-) >>> >>> diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt >>> index 2c901286d818..d3404b5d4d17 100644 >>> --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt >>> +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt >>> @@ -28,7 +28,7 @@ Optional properties: >>> - memory-region : from reserved memory binding: phandles to two reserved >>> memory regions, first is for "left" mfc memory bus interfaces, >>> second if for the "right" mfc memory bus, used when no SYSMMU >>> - support is available >>> + support is available; used only by MFC v5 present in Exynos4 SoCs >>> Obsolete properties: >>> - samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region >>> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c >>> index 8fc6fe4ba087..36f0aec2a1b3 100644 >>> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c >>> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c >>> @@ -1178,9 +1178,12 @@ static void s5p_mfc_unconfigure_2port_memory(struct s5p_mfc_dev *mfc_dev) >>> static int s5p_mfc_configure_common_memory(struct s5p_mfc_dev *mfc_dev) >>> { >>> struct device *dev = &mfc_dev->plat_dev->dev; >>> - unsigned long mem_size = SZ_8M; >>> + unsigned long mem_size = SZ_4M; >>> unsigned int bitmap_size; >>> + if (IS_ENABLED(CONFIG_DMA_CMA) || exynos_is_iommu_available(dev)) >>> + mem_size = SZ_8M; >>> + >>> if (mfc_mem_size) >>> mem_size = memparse(mfc_mem_size, NULL); >>> >> The driver allows the user to set mem_size > SZ_4M using the s5p_mfc.mem >> parameter even when CMA ins't enabled and IOMMU isn't available. Maybe it >> should fail early instead and notify the user what's missing? > > It will notify user that driver failed to preallocate memory. 4M is the upper > limit for standard kernel configuration, but afair there were some kconfig > knobs to force kernel to use larger buckets for buddy allocator (what changes > the limit). Frankly I would leave it as is. > > If user wants to specify s5p-mfc.mem, he already has some knowledge how to > configure the kernel. I don't think that driver should check all possible > scenarios of failing and give detailed explanation what was configured > wrong. You can also enable CMA and configure the 8MiB of the default global > area. In such configuration preallocation of mfc firmware buffer will also > fail. Should the driver care about it? IMO it is enough to tell user that > preallocating of given megabytes failed. > Right, it makes sense to leave it at is then indeed and let the users figure out why the allocation failed with their specific kernel configuration. > Best regards 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
On Tue, Feb 14, 2017 at 12:52 AM, Marek Szyprowski <m.szyprowski@samsung.com> wrote: > It turned out that all versions of MFC v6+ hardware doesn't have a strict > requirement for ALL buffers to be allocated on higher addresses than the > firmware base like it was documented for MFC v5. 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. Basing on this fact, the > special DMA configuration based on two reserved memory regions is not > really needed for MFC v6+ devices, because the memory requirements for the > firmware, device and per-context buffers can be fulfilled by the simple > probe-time pre-allocated block allocator instroduced in previous patch. > > This patch enables support for such pre-allocated block based allocator > always for MFC v6+ devices. Due to the limitations of the memory management > subsystem the largest supported size of the pre-allocated buffer when no > CMA (Contiguous Memory Allocator) is enabled is 4MiB. > > This patch also removes the requirement to provide two reserved memory > regions for MFC v6+ devices in device tree. Now the driver is fully > functional without them. > > Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Hi Marek, This patch breaks display manager. exynos_drm_gem_create() isn't happy. dmesg and console are flooded with odroid login: [ 209.170566] [drm:exynos_drm_gem_create] *ERROR* failed to allo. [ 212.173222] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 215.354790] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 218.736464] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 221.837128] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 226.284827] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 229.242498] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 232.063150] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 235.799993] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 239.472061] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 242.567465] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 246.500541] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 249.996018] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 253.837272] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 257.048782] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 260.084819] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 263.448611] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 266.271074] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 269.011558] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 272.039066] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 275.404938] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 278.339033] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 281.274751] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 284.641202] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 287.461039] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 291.062011] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 294.746870] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. [ 298.246570] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. I don't think this is an acceptable behavior. It is a regression. thanks, -- Shuah > --- > Documentation/devicetree/bindings/media/s5p-mfc.txt | 2 +- > drivers/media/platform/s5p-mfc/s5p_mfc.c | 9 ++++++--- > 2 files changed, 7 insertions(+), 4 deletions(-) > > diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt > index 2c901286d818..d3404b5d4d17 100644 > --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt > +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt > @@ -28,7 +28,7 @@ Optional properties: > - memory-region : from reserved memory binding: phandles to two reserved > memory regions, first is for "left" mfc memory bus interfaces, > second if for the "right" mfc memory bus, used when no SYSMMU > - support is available > + support is available; used only by MFC v5 present in Exynos4 SoCs > > Obsolete properties: > - samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region > diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c > index 8fc6fe4ba087..36f0aec2a1b3 100644 > --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c > +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c > @@ -1178,9 +1178,12 @@ static void s5p_mfc_unconfigure_2port_memory(struct s5p_mfc_dev *mfc_dev) > static int s5p_mfc_configure_common_memory(struct s5p_mfc_dev *mfc_dev) > { > struct device *dev = &mfc_dev->plat_dev->dev; > - unsigned long mem_size = SZ_8M; > + unsigned long mem_size = SZ_4M; > unsigned int bitmap_size; > > + if (IS_ENABLED(CONFIG_DMA_CMA) || exynos_is_iommu_available(dev)) > + mem_size = SZ_8M; > + > if (mfc_mem_size) > mem_size = memparse(mfc_mem_size, NULL); > > @@ -1240,7 +1243,7 @@ static int s5p_mfc_configure_dma_memory(struct s5p_mfc_dev *mfc_dev) > { > struct device *dev = &mfc_dev->plat_dev->dev; > > - if (exynos_is_iommu_available(dev)) > + if (exynos_is_iommu_available(dev) || !IS_TWOPORT(mfc_dev)) > return s5p_mfc_configure_common_memory(mfc_dev); > else > return s5p_mfc_configure_2port_memory(mfc_dev); > @@ -1251,7 +1254,7 @@ static void s5p_mfc_unconfigure_dma_memory(struct s5p_mfc_dev *mfc_dev) > struct device *dev = &mfc_dev->plat_dev->dev; > > s5p_mfc_release_firmware(mfc_dev); > - if (exynos_is_iommu_available(dev)) > + if (exynos_is_iommu_available(dev) || !IS_TWOPORT(mfc_dev)) > s5p_mfc_unconfigure_common_memory(mfc_dev); > else > s5p_mfc_unconfigure_2port_memory(mfc_dev); > -- > 1.9.1 > -- 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
Hi Shuah On 2017-02-23 22:43, Shuah Khan wrote: > On Tue, Feb 14, 2017 at 12:52 AM, Marek Szyprowski > <m.szyprowski@samsung.com> wrote: >> It turned out that all versions of MFC v6+ hardware doesn't have a strict >> requirement for ALL buffers to be allocated on higher addresses than the >> firmware base like it was documented for MFC v5. 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. Basing on this fact, the >> special DMA configuration based on two reserved memory regions is not >> really needed for MFC v6+ devices, because the memory requirements for the >> firmware, device and per-context buffers can be fulfilled by the simple >> probe-time pre-allocated block allocator instroduced in previous patch. >> >> This patch enables support for such pre-allocated block based allocator >> always for MFC v6+ devices. Due to the limitations of the memory management >> subsystem the largest supported size of the pre-allocated buffer when no >> CMA (Contiguous Memory Allocator) is enabled is 4MiB. >> >> This patch also removes the requirement to provide two reserved memory >> regions for MFC v6+ devices in device tree. Now the driver is fully >> functional without them. >> >> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> > Hi Marek, > > This patch breaks display manager. exynos_drm_gem_create() isn't happy. > dmesg and console are flooded with > > odroid login: [ 209.170566] [drm:exynos_drm_gem_create] *ERROR* failed to allo. > [ 212.173222] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 215.354790] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 218.736464] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 221.837128] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 226.284827] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 229.242498] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 232.063150] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 235.799993] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 239.472061] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 242.567465] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 246.500541] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 249.996018] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 253.837272] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 257.048782] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 260.084819] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 263.448611] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 266.271074] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 269.011558] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 272.039066] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 275.404938] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 278.339033] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 281.274751] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 284.641202] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 287.461039] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 291.062011] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 294.746870] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > [ 298.246570] [drm:exynos_drm_gem_create] *ERROR* failed to allocate buffer. > > I don't think this is an acceptable behavior. It is a regression. This is a really poor bug report... Could you elaborate a bit how to reproduce this? Could you provide your kernel config and information about test environment? I suspect that you use CMA without IOMMU and you have too small global CMA region. After this patch MFC driver uses global CMA region instead of the MFC's private ones, so one has to ensure that the global region is large enough. > [...] Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- 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
Hi Marek, On Thu, Feb 23, 2017 at 11:26 PM, Marek Szyprowski <m.szyprowski@samsung.com> wrote: > Hi Shuah > > > > On 2017-02-23 22:43, Shuah Khan wrote: >> >> On Tue, Feb 14, 2017 at 12:52 AM, Marek Szyprowski >> <m.szyprowski@samsung.com> wrote: >>> >>> It turned out that all versions of MFC v6+ hardware doesn't have a strict >>> requirement for ALL buffers to be allocated on higher addresses than the >>> firmware base like it was documented for MFC v5. 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. Basing on this fact, the >>> special DMA configuration based on two reserved memory regions is not >>> really needed for MFC v6+ devices, because the memory requirements for >>> the >>> firmware, device and per-context buffers can be fulfilled by the simple >>> probe-time pre-allocated block allocator instroduced in previous patch. >>> >>> This patch enables support for such pre-allocated block based allocator >>> always for MFC v6+ devices. Due to the limitations of the memory >>> management >>> subsystem the largest supported size of the pre-allocated buffer when no >>> CMA (Contiguous Memory Allocator) is enabled is 4MiB. >>> >>> This patch also removes the requirement to provide two reserved memory >>> regions for MFC v6+ devices in device tree. Now the driver is fully >>> functional without them. >>> >>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> >> >> Hi Marek, >> >> This patch breaks display manager. exynos_drm_gem_create() isn't happy. >> dmesg and console are flooded with >> >> odroid login: [ 209.170566] [drm:exynos_drm_gem_create] *ERROR* failed to >> allo. >> [ 212.173222] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 215.354790] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 218.736464] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 221.837128] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 226.284827] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 229.242498] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 232.063150] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 235.799993] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 239.472061] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 242.567465] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 246.500541] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 249.996018] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 253.837272] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 257.048782] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 260.084819] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 263.448611] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 266.271074] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 269.011558] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 272.039066] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 275.404938] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 278.339033] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 281.274751] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 284.641202] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 287.461039] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 291.062011] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 294.746870] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> [ 298.246570] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >> buffer. >> >> I don't think this is an acceptable behavior. It is a regression. > > > This is a really poor bug report... Could you elaborate a bit how to > reproduce > this? Could you provide your kernel config and information about test > environment? Yeah. I should have give you more information. My bad. > > I suspect that you use CMA without IOMMU and you have too small global CMA > region. Yes. I have CMA and using exynos_defconfig. Nothing fancy. I think what's happening is s5p_mfc pre-allocates and there is nothing left when disaply manager starts requestuing gem buffers. This failure happens when systemd kicks off lightdm. > After this patch MFC driver uses global CMA region instead of the MFC's > private > ones, so one has to ensure that the global region is large enough. This is still a regression since it requires users to take some action. I think we need some kind of checks to warn users there isn't a large enough CMA region. This is the same config I have been using forever and with this patch, it breaks. Easy to reproduce on odroid-xu4 with HDMI display. You just have to boot the system with exynos_defconfig. Display manager will fail when it requests buffers. thanks, -- Shuah > >> [...] > > > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland > -- 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
Hi Shuah, On 2017-02-24 15:23, Shuah Khan wrote: > On Thu, Feb 23, 2017 at 11:26 PM, Marek Szyprowski > <m.szyprowski@samsung.com> wrote: >> On 2017-02-23 22:43, Shuah Khan wrote: >>> On Tue, Feb 14, 2017 at 12:52 AM, Marek Szyprowski >>> <m.szyprowski@samsung.com> wrote: >>>> It turned out that all versions of MFC v6+ hardware doesn't have a strict >>>> requirement for ALL buffers to be allocated on higher addresses than the >>>> firmware base like it was documented for MFC v5. 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. Basing on this fact, the >>>> special DMA configuration based on two reserved memory regions is not >>>> really needed for MFC v6+ devices, because the memory requirements for >>>> the >>>> firmware, device and per-context buffers can be fulfilled by the simple >>>> probe-time pre-allocated block allocator instroduced in previous patch. >>>> >>>> This patch enables support for such pre-allocated block based allocator >>>> always for MFC v6+ devices. Due to the limitations of the memory >>>> management >>>> subsystem the largest supported size of the pre-allocated buffer when no >>>> CMA (Contiguous Memory Allocator) is enabled is 4MiB. >>>> >>>> This patch also removes the requirement to provide two reserved memory >>>> regions for MFC v6+ devices in device tree. Now the driver is fully >>>> functional without them. >>>> >>>> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> >>> Hi Marek, >>> >>> This patch breaks display manager. exynos_drm_gem_create() isn't happy. >>> dmesg and console are flooded with >>> >>> odroid login: [ 209.170566] [drm:exynos_drm_gem_create] *ERROR* failed to >>> allo. >>> [ 212.173222] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 215.354790] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 218.736464] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 221.837128] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 226.284827] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 229.242498] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 232.063150] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 235.799993] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 239.472061] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 242.567465] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 246.500541] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 249.996018] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 253.837272] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 257.048782] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 260.084819] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 263.448611] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 266.271074] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 269.011558] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 272.039066] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 275.404938] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 278.339033] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 281.274751] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 284.641202] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 287.461039] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 291.062011] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 294.746870] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> [ 298.246570] [drm:exynos_drm_gem_create] *ERROR* failed to allocate >>> buffer. >>> >>> I don't think this is an acceptable behavior. It is a regression. >> >> This is a really poor bug report... Could you elaborate a bit how to >> reproduce >> this? Could you provide your kernel config and information about test >> environment? > Yeah. I should have give you more information. My bad. > >> I suspect that you use CMA without IOMMU and you have too small global CMA >> region. > Yes. I have CMA and using exynos_defconfig. Nothing fancy. I think > what's happening is s5p_mfc pre-allocates and there is nothing left > when disaply manager starts requestuing gem buffers. This failure > happens when systemd kicks off lightdm. > >> After this patch MFC driver uses global CMA region instead of the MFC's >> private >> ones, so one has to ensure that the global region is large enough. > This is still a regression since it requires users to take some > action. I think we need some kind of checks to warn users there isn't > a large enough CMA region. This is the same config I have been using > forever and with this patch, it breaks. > > Easy to reproduce on odroid-xu4 with HDMI display. You just have to > boot the system with exynos_defconfig. Display manager will fail when > it requests buffers. That is still a bit strange. MFC pre-allocates 8MiB buffer. The default CMA global region size is 64MiB, which should be enough for a few display buffers. It looks that your display manager consumes quite a lot of memory and it already almost hits the limit from the exynos_defconfig. It should be safe to increase default CMA region size to 80MiB or even 96MiB in the exynos_defconfig to avoid such problem. Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- 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
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt index 2c901286d818..d3404b5d4d17 100644 --- a/Documentation/devicetree/bindings/media/s5p-mfc.txt +++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt @@ -28,7 +28,7 @@ Optional properties: - memory-region : from reserved memory binding: phandles to two reserved memory regions, first is for "left" mfc memory bus interfaces, second if for the "right" mfc memory bus, used when no SYSMMU - support is available + support is available; used only by MFC v5 present in Exynos4 SoCs Obsolete properties: - samsung,mfc-r, samsung,mfc-l : support removed, please use memory-region diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 8fc6fe4ba087..36f0aec2a1b3 100644 --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c @@ -1178,9 +1178,12 @@ static void s5p_mfc_unconfigure_2port_memory(struct s5p_mfc_dev *mfc_dev) static int s5p_mfc_configure_common_memory(struct s5p_mfc_dev *mfc_dev) { struct device *dev = &mfc_dev->plat_dev->dev; - unsigned long mem_size = SZ_8M; + unsigned long mem_size = SZ_4M; unsigned int bitmap_size; + if (IS_ENABLED(CONFIG_DMA_CMA) || exynos_is_iommu_available(dev)) + mem_size = SZ_8M; + if (mfc_mem_size) mem_size = memparse(mfc_mem_size, NULL); @@ -1240,7 +1243,7 @@ static int s5p_mfc_configure_dma_memory(struct s5p_mfc_dev *mfc_dev) { struct device *dev = &mfc_dev->plat_dev->dev; - if (exynos_is_iommu_available(dev)) + if (exynos_is_iommu_available(dev) || !IS_TWOPORT(mfc_dev)) return s5p_mfc_configure_common_memory(mfc_dev); else return s5p_mfc_configure_2port_memory(mfc_dev); @@ -1251,7 +1254,7 @@ static void s5p_mfc_unconfigure_dma_memory(struct s5p_mfc_dev *mfc_dev) struct device *dev = &mfc_dev->plat_dev->dev; s5p_mfc_release_firmware(mfc_dev); - if (exynos_is_iommu_available(dev)) + if (exynos_is_iommu_available(dev) || !IS_TWOPORT(mfc_dev)) s5p_mfc_unconfigure_common_memory(mfc_dev); else s5p_mfc_unconfigure_2port_memory(mfc_dev);
It turned out that all versions of MFC v6+ hardware doesn't have a strict requirement for ALL buffers to be allocated on higher addresses than the firmware base like it was documented for MFC v5. 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. Basing on this fact, the special DMA configuration based on two reserved memory regions is not really needed for MFC v6+ devices, because the memory requirements for the firmware, device and per-context buffers can be fulfilled by the simple probe-time pre-allocated block allocator instroduced in previous patch. This patch enables support for such pre-allocated block based allocator always for MFC v6+ devices. Due to the limitations of the memory management subsystem the largest supported size of the pre-allocated buffer when no CMA (Contiguous Memory Allocator) is enabled is 4MiB. This patch also removes the requirement to provide two reserved memory regions for MFC v6+ devices in device tree. Now the driver is fully functional without them. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> --- Documentation/devicetree/bindings/media/s5p-mfc.txt | 2 +- drivers/media/platform/s5p-mfc/s5p_mfc.c | 9 ++++++--- 2 files changed, 7 insertions(+), 4 deletions(-) -- 1.9.1 -- 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