Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753440AbbGXHe2 (ORCPT ); Fri, 24 Jul 2015 03:34:28 -0400 Received: from mailout2.samsung.com ([203.254.224.25]:41817 "EHLO mailout2.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752851AbbGXHe0 (ORCPT ); Fri, 24 Jul 2015 03:34:26 -0400 MIME-version: 1.0 Content-type: text/plain; charset=utf-8 X-AuditID: cbfee68f-f793b6d000005f66-01-55b1ea7faf7b Content-transfer-encoding: 8BIT Message-id: <55B1EA7F.3000203@samsung.com> Date: Fri, 24 Jul 2015 16:34:23 +0900 From: Inki Dae User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 To: Joonyoung Shim , Krzysztof Kozlowski , Seung-Woo Kim Cc: dri-devel@lists.freedesktop.org, Kyungmin Park , Kukjin Kim , linux-samsung-soc@vger.kernel.org, linux-kernel@vger.kernel.org, Marek Szyprowski Subject: Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible" References: <55AEF9AD.6090709@samsung.com> <55AF222F.1060303@samsung.com> <55AF5058.3060106@samsung.com> <55AF52BF.4030201@samsung.com> <55AF577F.10606@samsung.com> <55AF6BB3.9000505@samsung.com> In-reply-to: <55AF6BB3.9000505@samsung.com> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsWyRsSkSLf+1cZQgx09KhZXvr5ns3hx7yKL xesXhhb9j18zW5xtesNucXnXHDaLGef3MVmsPXKX3WLG5JdsDpwem1Z1snnc7z7O5NG3ZRWj x+dNcgEsUVw2Kak5mWWpRfp2CVwZC86/ZCq4pl+x7sQW1gbGFpUuRk4OCQETic3fN7NB2GIS F+6tB7K5OIQEljJKHD29mBGmaOO5vUwQiUWMEofeXGECSfAKCEr8mHyPpYuRg4NZQF7iyKVs CFNdYsqUXIjy+4wS7+8tYIMo15J4eHgTO4jNIqAqseLvYRYQmw3InrjiPliNqECExNvLJ8HG iwi0M0psfe8AMogZZFBj0wxmkISwQLnE3e1/mCE2TGCS2H74FtilnALaEgtblrCDJCQELrFL rHv3F2qdgMS3yYfALpUQkJXYdIAZ4jNJiYMrbrBMYBSbheSfWQj/zEL4ZwEj8ypG0dSC5ILi pPQiY73ixNzi0rx0veT83E2MwOg7/e9Z/w7GuwesDzEKcDAq8fBmTNgYKsSaWFZcmXuI0RTo honMUqLJ+cAYzyuJNzQ2M7IwNTE1NjK3NFMS510o9TNYSCA9sSQ1OzW1ILUovqg0J7X4ECMT B6dUA+OxKZFu3Rt+bjEoWndpVtgfkx/mL7tMTOZryP2x7Lrl4CuSccLg9L/7HA4SVbPuna2t 8Lpzd7Jy8avS+nyfkKhJ36YkhKb+3X3uwkuZY5OO3vx7kD2rf+HzuMMbolknXzl58dU15n3+ l/dPyZnm3L3U1SDwo3X9ozd/rlR7nzmxf2fIzc0/UxwfKbEUZyQaajEXFScCAKCM8mS5AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsVy+t9jAd36VxtDDa69krW48vU9m8WLexdZ LF6/MLTof/ya2eJs0xt2i8u75rBZzDi/j8li7ZG77BYzJr9kc+D02LSqk83jfvdxJo++LasY PT5vkgtgiWpgtMlITUxJLVJIzUvOT8nMS7dV8g6Od443NTMw1DW0tDBXUshLzE21VXLxCdB1 y8wBukVJoSwxpxQoFJBYXKykb4dpQmiIm64FTGOErm9IEFyPkQEaSFjDmLHg/Eumgmv6FetO bGFtYGxR6WLk5JAQMJHYeG4vE4QtJnHh3nq2LkYuDiGBRYwSh95cAUvwCghK/Jh8j6WLkYOD WUBe4silbAhTXWLKlFyI8vuMEu/vLWCDKNeSeHh4EzuIzSKgKrHi72EWEJsNyJ644j5YjahA hMTbyyfBxosItDNKbH3vADKIGWRQY9MMZpCEsEC5xN3tf5ghNkxgkth++BYjSIJTQFtiYcsS 9gmMArOQ3DcL4b5ZCPctYGRexSiaWpBcUJyUnmukV5yYW1yal66XnJ+7iREc28+kdzCuarA4 xCjAwajEw5sxYWOoEGtiWXFl7iFGCQ5mJRFehmNAId6UxMqq1KL8+KLSnNTiQ4ymQN9NZJYS Tc4Hpp28knhDYxMzI0sjc0MLI2NzJXHek/k+oUIC6YklqdmpqQWpRTB9TBycUg2M8qfXMP2e c9Q1K6tyKavqFMmpgmsX9hWlBUn9Y87edV3q8MZ75f26c3yXZ/yptP/4a/1fgyLBjoIvQmks 3Pb/X6Q98thr8STwjuh0o8b7P//NWZXn/lLqyBmjO83T3daE7/6sX3OPpejyDbbDHHKnDOW6 HvLU3F2TJ9S76Of36OrrLGGcDK1qSizFGYmGWsxFxYkANqiOwgMDAAA= DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 6212 Lines: 140 On 2015년 07월 22일 19:08, Inki Dae wrote: > On 2015년 07월 22일 17:42, Joonyoung Shim wrote: >> On 07/22/2015 05:22 PM, Inki Dae wrote: >>> On 2015년 07월 22일 17:12, Joonyoung Shim wrote: >>>> 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 >>>>>>> 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 >>>>>>> Tested-by: Marek Szyprowski >>>>>>> Signed-off-by: Inki Dae >>>>>>> >>>>>>> :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. >>> >>> In this case, if one of above gate clocks is enabled, the ACLK_200_DISP1 >>> should be enabled. So I guess the problem would be due to below line of >>> clk-exynos5420.c, >>> >>> GATE(CLK_FIMD1, "fimd1", "aclk300_disp1", GATE_IP_DISP1, 0, 0, 0), >>> >>> Can you check it again after modifying it like below?, >>> GATE(CLK_FIMD1, "fimd1", "aclk200_disp1", GATE_IP_DISP1, 0, 0, 0), >> >> No, parent clock of fimd1 gate clock is ACLK_300_DISP1. > > Yes, I checked just it through exynos5420 and exynos5422 document. I > just guessed. So do you mean that aclk200_disp1 affects FIMD controller > even though aclk200_disp1 isn't a parent clock of FIMD? If so, it's very > strange. Root problem was because it had tried to access FIMD registers before crtc and connector driver binding is completed. ACLK200_DISP1 will be enabled by connector driver - MIPI-DSI - of FIMD like above clock hierarchy commented by Joonyoung. So all we have to do would be, 1. to put off clearing channel and attaching iommu just after the binding completion between crtc and connector drivers - in case of Exynos drm driver, the binding is done before modeset operation. Or 2. to enable FIMD relevant clock gates, BTS_FIMD1_M0/1 in FIMD driver. In case of number 1, we would need to add a new interface which can notify that crtc drivers enable their iommu units just after the binding completion. In case of number 2, it would mean we should consider to enable relevant clock gates for other crtc drivers - decon drivers for Exynos5433 and Exynos7. I tend to proper number 2 because it's easier way than number 1. Thanks, Inki Dae > >> -- >> 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 >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/