linux-kernel - Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 22 Jul 2015 17:12:08 +0900
From:	Joonyoung Shim <jy0922.shim@...sung.com>
To:	Inki Dae <inki.dae@...sung.com>,
	Krzysztof Kozlowski <k.kozlowski@...sung.com>,
	Seung-Woo Kim <sw0312.kim@...sung.com>
Cc:	dri-devel@...ts.freedesktop.org,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Kukjin Kim <kgene@...nel.org>,
	linux-samsung-soc@...r.kernel.org, linux-kernel@...r.kernel.org,
	Marek Szyprowski <m.szyprowski@...sung.com>
Subject: Re: Linux-next, Exynos Octa boot fail,
 bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"

On 07/22/2015 01:55 PM, Inki Dae wrote:
> On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
>> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
>>> Hi,
>>>
>>> Today's linux-next (next-20150721) encounters boot failures on Exynos
>>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
>>>
>>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
>>> commit d80167b85024982c5f18d0481a5c248100360118
>>> Author: Joonyoung Shim <jy0922.shim@...sung.com>
>>> Date:   Thu Jul 2 21:49:39 2015 +0900
>>>
>>>     drm/exynos: remove drm_iommu_attach_device_if_possible
>>>
>>>     Already drm_iommu_attach_device checks whether support iommu internally.
>>>     It should clear channels always regardless iommu support. We didn't know
>>>     because we can detect the problem when iommu is enabled, so we don't
>>>     have to use drm_iommu_attach_device_if_possible and then we can remove
>>>     drm_iommu_attach_device_if_possible and clear_channels function pointer.
>>>
>>>     Signed-off-by: Joonyoung Shim <jy0922.shim@...sung.com>
>>>     Tested-by: Marek Szyprowski <m.szyprowski@...sung.com>
>>>     Signed-off-by: Inki Dae <inki.dae@...sung.com>
>>>
>>> :040000 040000 83379efbf4960f58d680371628ec04387935bd53
>>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
>>>
>>>
>>> Config: exynos
>>> Boot log from Odroid XU3-Lite attached.
>>>
>>> Any hints or ideas?
>>
>> The point that hangs is when accesses fimd register in
>> fimd_clear_channels function, so i doubt clock setting for fimd.
>>
>> It's gone something that hangs after i enable gating for ACLK_200_DISP1
>> clock.
>>
>> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
>> support. Any ideas?
> 
> I think bootloader should have enabled ACLK_200_DISP1 clock and also
> device driver should enable all relevant clocks before the device
> accesses its own registers.
> 
> Best way would be that the clock is enabled by common clock framework
> but it seems there is no anything that the clock framework can do it. So
> I think what we have to do is to add the clock support to device tree.

It's not easy problem to me. Should we add which clock? I think we
cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
hierarchy, right? Then we should control gate clocks, but we have not
controlled any gate clocks using BTS_ prefix.

The clock hierarchy from Exynos5422 user manual,
ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
                                       HDMI PHY
                                       MIC1
                                       DSIM1
                                       DPTX LINK
                                       MDNIE1
                                       SYSMMU_MIXER
                                       SYSMMU_FIMD1_M0
                                       SYSMMU_FIMD1_M1
                                       BTS_TVM0
                                       BTS_TVM1
                                       BTS_FIMD1_M0
                                       BTS_FIMD1_M1

Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
just it should be controlled by connector drivers, e.g. dsi, dp because
fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
about this, just i thought that Exynos5 SoCs don't have any gpios for
dpi, so they cannot use dpi, right?).

It needs to probe connector driver like dsi or dp earlier than fimd and
fimd_bind function should return error if connector driver like dsi or
dp was not probed. This is also not easy to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/