Hi Javier,
On 2017-12-12 09:00, Javier Martinez Canillas wrote:
On Tue, Dec 12, 2017 at 8:54 AM, Marek Szyprowski
<m.szyprowski@xxxxxxxxxxx> wrote:
On 2017-12-12 00:25, Shuah Khan wrote:
On 12/11/2017 04:02 PM, Russell King - ARM Linux wrote:
On Mon, Dec 11, 2017 at 10:58:29PM +0000, Russell King - ARM Linux wrote:
On Mon, Dec 11, 2017 at 11:54:48PM +0100, Javier Martinez Canillas
wrote:
So I gave a quick look to this, and at the very least there's a bug in
the Exynos5800 Peach Pi DTS caused by commit 1cb686c08d12 ("ARM: dts:
exynos: Add status property to Exynos 542x Mixer nodes").
I've posted a fix for that:
https://patchwork.kernel.org/patch/10105921/
I believe this could be also be the cause for the boot failure, since
I see in the boot log that things start to go wrong after exynos-drm
fails to bind the HDMI component:
[ 2.916347] exynos-drm exynos-drm: failed to bind 14530000.hdmi (ops
0xc1398690): -1
Umm, -1 ? Looking that error code up in
include/uapi/asm-generic/errno-base.h says it's -EPERM.
I suspect that's someone just returning -1 because they're lazy...
which is real bad form and needs fixing.
Oh, it really is -EPERM:
struct exynos_drm_crtc *exynos_drm_crtc_get_by_type(struct drm_device
*drm_dev,
enum exynos_drm_output_type
out_type)
{
struct drm_crtc *crtc;
drm_for_each_crtc(crtc, drm_dev)
if (to_exynos_crtc(crtc)->type == out_type)
return to_exynos_crtc(crtc);
return ERR_PTR(-EPERM);
}
Does "Operation not permitted" really convey the error here? It doesn't
look like a permission error to me.
Can we please avoid abusing errno codes?
I tried 4.15-rc3 on odroid-xu4 after seeing drm issues reported. 4.15-rc2+
with top commit g968edbd worked just fine for me last Friday. I ran
several
tests and everything checked out except the exynos-gsc lockdep issue I
sent
a 4.14 patch for.
However, with 4.15-rc3, dmesg is gets filled with
[ 342.337181] [drm] Non-contiguous allocation is not supported without
IOMMU, falling back to contiguous buffer
[ 342.337470] [drm] Non-contiguous allocation is not supported without
IOMMU, falling back to contiguous buffer
[ 342.337851] [drm] Non-contiguous allocation is not supported without
IOMMU, falling back to contiguous buffer
[ 402.382346] [drm] Non-contiguous allocation is not supported without
IOMMU, falling back to contiguous buffer
[ 402.396682] [drm] Non-contiguous allocation is not supported without
IOMMU, falling back to contiguous buffer
[ 402.399244] [drm] Non-contiguous allocation is not supported without
IOMMU, falling back to contiguous buffer
[ 402.399496] [drm] Non-contiguous allocation is not supported without
IOMMU, falling back to contiguous buffer
[ 402.399848] [drm] Non-contiguous allocation is not supported without
IOMMU, falling back to contiguous buffer
[ 402.400163] [drm] Non-contiguous allocation is not supported without
IOMMU, falling back to contiguous buffer
[ 402.400495] [drm] Non-contiguous allocation is not supported without
IOMMU, falling back to contiguous buffer
[ 402.401294] [drm] Non-contiguous allocation is not supported without
IOMMU, falling back to contiguous buffer
[ 402.401595] [drm] Non-contiguous allocation is not supported without
IOMMU, falling back to contiguous buffer
Something broke in 4.15-rc3 on odroix-xu4 badly with exynos_defconfig.
I will start bisect and try to isolate the problem. I suspect this is
related to dts
changes perhaps? I used to this problem a while back and it has been
fixed.
This warning has been added intentionally, see following discussions:
https://patchwork.kernel.org/patch/10034919/
https://patchwork.kernel.org/patch/10070475/
This means that your test apps should be updated or you should enable Exynos
IOMMU support in your config. Maybe it is a good time to finally enable it
in exynos_defconfig.
Has the issue that the boot-loader keeps the display controller
enabled and scanning pages on the Exynos Chromebooks resolved?
I think that's that preventing to enable it by default in
exynos_defconfig since it caused boot failures when enabled on these
machines. I don't follow exynos development too closely nowadays so
maybe there's a fix in place now.
Not directly. I still didn't find time to properly add support for
devices, which were left in-working state (with active DMA
transactions) by bootloader, but due to some other changes in the
order of operations during boot process, power domains are
initialized very early and due to temporary lack of devices (which
are not yet added to the system), are turned off. This practically
stops FIMD for scanning framebuffer and "solves" this issue.
I've checked now and Exynos Snow Chromebook boots fine with IOMMU
support enabled, both with v4.15-rc3 and linux-next.
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
