<br><br><div class="gmail_quote">2013/8/2 Vikas Sajjan <span dir="ltr"><<a href="mailto:vikas.sajjan@linaro.org" target="_blank">vikas.sajjan@linaro.org</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
Hi Rob,<br>
<div><div class="h5"><br>
On 2 August 2013 06:03, Rob Clark <<a href="mailto:robdclark@gmail.com">robdclark@gmail.com</a>> wrote:<br>
> On Thu, Aug 1, 2013 at 7:20 PM, Tomasz Figa <<a href="mailto:tomasz.figa@gmail.com">tomasz.figa@gmail.com</a>> wrote:<br>
>> Hi Vikas,<br>
>><br>
>> On Thursday 01 of August 2013 16:49:32 Vikas Sajjan wrote:<br>
>>> While trying to get boot-logo up on exynos5420 SMDK which has eDP panel<br>
>>> connected with resolution 2560x1600, following error occured even with<br>
>>> IOMMU enabled:<br>
>>> [0.880000] [drm:lowlevel_buffer_allocate] *ERROR* failed to allocate<br>
>>> buffer. [0.890000] [drm] Initialized exynos 1.0.0 20110530 on minor 0<br>
>>><br>
>>> This patch fixes the issue by adding a check for IOMMU.<br>
>>><br>
>>> Signed-off-by: Vikas Sajjan <<a href="mailto:vikas.sajjan@linaro.org">vikas.sajjan@linaro.org</a>><br>
>>> Signed-off-by: Arun Kumar <<a href="mailto:arun.kk@samsung.com">arun.kk@samsung.com</a>><br>
>>> ---<br>
>>> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 9 ++++++++-<br>
>>> 1 file changed, 8 insertions(+), 1 deletion(-)<br>
>>><br>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c<br>
>>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c index 8e60bd6..2a86666<br>
>>> 100644<br>
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c<br>
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c<br>
>>> @@ -16,6 +16,7 @@<br>
>>> #include <drm/drm_crtc.h><br>
>>> #include <drm/drm_fb_helper.h><br>
>>> #include <drm/drm_crtc_helper.h><br>
>>> +#include <drm/exynos_drm.h><br>
>>><br>
>>> #include "exynos_drm_drv.h"<br>
>>> #include "exynos_drm_fb.h"<br>
>>> @@ -143,6 +144,7 @@ static int exynos_drm_fbdev_create(struct<br>
>>> drm_fb_helper *helper, struct platform_device *pdev = dev->platformdev;<br>
>>> unsigned long size;<br>
>>> int ret;<br>
>>> + unsigned int flag;<br>
>>><br>
>>> DRM_DEBUG_KMS("surface width(%d), height(%d) and bpp(%d\n",<br>
>>> sizes->surface_width, sizes->surface_height,<br>
>>> @@ -166,7 +168,12 @@ static int exynos_drm_fbdev_create(struct<br>
>>> drm_fb_helper *helper, size = mode_cmd.pitches[0] * mode_cmd.height;<br>
>>><br>
>>> /* 0 means to allocate physically continuous memory */<br>
>>> - exynos_gem_obj = exynos_drm_gem_create(dev, 0, size);<br>
>>> + if (!is_drm_iommu_supported(dev))<br>
>>> + flag = 0;<br>
>>> + else<br>
>>> + flag = EXYNOS_BO_NONCONTIG;<br>
>><br>
>> While noncontig memory might be used for devices that support IOMMU, there<br>
>> should be no problem with using contig memory for them, so this seems more<br>
>> like masking the original problem rather than tracking it down.<br>
><br>
> it is probably a good idea to not require contig memory when it is not<br>
> needed for performance or functionality (and if it is only<br>
> performance, then fallback gracefully to non-contig).. but yeah, would<br>
> be good to know if this is masking another issue all the same<br>
><br>
<br>
</div></div>Whats happening with CONTIG flag and with IOMMU, is<br>
<br>
__iommu_alloc_buffer() ---> dma_alloc_from_contiguous() and in this<br>
function it fails at<br>
this condition check if (pageno >= cma->count)<br>
<br>
So I tried increasing the CONFIG_CMA_SIZE_MBYTES to 24, this check<br>
succeeds and it works well without my patch.<br>
<br>
But what about the case where CONFIG_CMA is disabled , yet i want<br>
bigger memory for a device.<br>
I think using IOMMU we can achieve this.<br>
<br>
correct me, if i am wrong.<br>
<div class="im HOEnZb"><br></div></blockquote><div> </div><div>I'm on summer vacation so I'm afraid that I cannot test and look into it but I guess you guy didn't declare CMA region for Exynos drm. And in this case, the size of CMA declared region is 16MB as default. That is why works well after increasing default size, CONFIG_CMA_SIZE_MBYTES, to 24MB. And I mentioned long time ago, we are required to use physically contiguous memory in case that bootloader uses physically contiguous memory for its own framebuffer, and kernel wants to share the bootloader's framebuffer region to resolve flickering issue while booted; that is required for product. And one question, is there any reason that you guy should use non-contiguous memory for framebuffer with iommu?</div>
<div> </div><div>Thanks,</div><div>Inki Dae</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div class="im HOEnZb">
<br>
> BR,<br>
> -R<br>
><br>
>> Could you check why the allocation fails when requesting contiguous<br>
>> memory?<br>
>><br>
>> Best regards,<br>
>> Tomasz<br>
>><br>
>> --<br>
>> To unsubscribe from this list: send the line "unsubscribe linux-media" in<br>
>> the body of a message to <a href="mailto:majordomo@vger.kernel.org">majordomo@vger.kernel.org</a><br>
>> More majordomo info at <a href="http://vger.kernel.org/majordomo-info.html" target="_blank">http://vger.kernel.org/majordomo-info.html</a><br>
<br>
<br>
<br>
--<br>
</div><div class="im HOEnZb">Thanks and Regards<br>
Vikas Sajjan<br>
</div><div class="HOEnZb"><div class="h5">--<br>
To unsubscribe from this list: send the line "unsubscribe linux-media" in<br>
the body of a message to <a href="mailto:majordomo@vger.kernel.org">majordomo@vger.kernel.org</a><br>
More majordomo info at <a href="http://vger.kernel.org/majordomo-info.html" target="_blank">http://vger.kernel.org/majordomo-info.html</a><br>
</div></div></blockquote></div><br>