Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
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 >>> >>> :04 04 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
Re: Linux-next, Exynos Octa boot fail, bisected to: drm/exynos: remove drm_iommu_attach_device_if_possible
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 jy0922.s...@samsung.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.s...@samsung.com Tested-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Inki Dae inki@samsung.com :04 04 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
Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
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 >> >> :04 04 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. > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read
Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
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 > > :04 04 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
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 :04 04 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), Thanks, Inki Dae > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 >>> 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 >>> >>> :04 04 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-next, Exynos Octa boot fail, bisected to: drm/exynos: remove drm_iommu_attach_device_if_possible
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 jy0922.s...@samsung.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.s...@samsung.com Tested-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Inki Dae inki@samsung.com :04 04 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), Thanks, Inki Dae -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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.s...@samsung.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.s...@samsung.com Tested-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Inki Dae inki@samsung.com :04 04 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-next, Exynos Octa boot fail, bisected to: drm/exynos: remove drm_iommu_attach_device_if_possible
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 jy0922.s...@samsung.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.s...@samsung.com Tested-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Inki Dae inki@samsung.com :04 04 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-next, Exynos Octa boot fail, bisected to: drm/exynos: remove drm_iommu_attach_device_if_possible
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 jy0922.s...@samsung.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.s...@samsung.com Tested-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Inki Dae inki@samsung.com :04 04 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. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
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 >> >> :04 04 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. Other idea? Thanks, Inki Dae > > Thanks. > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
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 > > :04 04 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? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"
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 :04 04 83379efbf4960f58d680371628ec04387935bd53 da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers Config: exynos Boot log from Odroid XU3-Lite attached. Any hints or ideas? Best regards, Krzysztof Starting kernel ... [0.00] Booting Linux on physical CPU 0x100 [0.00] Linux version 4.2.0-rc2-00314-gd80167b85024 (kozik@kozik-lap) (gcc version 4.7.4 (Ubuntu/Linaro 4.7.4-2ubuntu1) ) #766 SMP PREEMPT Tue Jul 21 22:12:16 KST 2015 [0.00] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: Hardkernel Odroid XU3 Lite [0.00] cma: Reserved 64 MiB at 0xba80 [0.00] Memory policy: Data cache writealloc [0.00] Samsung CPU ID: 0xe5422001 [0.00] Running under secure firmware. [0.00] PERCPU: Embedded 11 pages/cpu @ee77f000 s15040 r8192 d21824 u45056 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 513040 [0.00] Kernel command line: console=tty1 console=ttySAC2,115200n8 root=/dev/mmcblk0p1 rootwait rw smsc95xx.macaddr=00:1e:06:61:7a:93 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 1957712K/2058240K available (6176K kernel code, 314K rwdata, 2232K rodata, 412K init, 8223K bss, 34992K reserved, 65536K cma-reserved, 1230848K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc083e2e8 (8409 kB) [0.00] .init : 0xc083f000 - 0xc08a6000 ( 412 kB) [0.00] .data : 0xc08a6000 - 0xc08f4b68 ( 315 kB) [0.00].bss : 0xc08f7000 - 0xc10fef60 (8224 kB) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 [0.00] Running RCU self tests [0.00] Preemptible hierarchical RCU implementation. [0.00] RCU lockdep checking is enabled. [0.00] Additional per-CPU info printed with stalls. [0.00] Build-time adjustment of leaf fanout to 32. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] GIC physical location is 0x10481000 [0.00] L2C: failed to init: -19 [0.00] Switching to timer-based delay loop, resolution 41ns [0.00] clocksource: mct-frc: mask: 0x max_cycles: 0x, max_idle_ns: 79635851949 ns [0.08] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns [0.000986] Console: colour dummy device 80x30 [0.003960] console [tty1] enabled [0.004000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.004063] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.004102] ... MAX_LOCK_DEPTH: 48 [0.004140] ... MAX_LOCKDEP_KEYS:8191 [0.004179] ... CLASSHASH_SIZE: 4096 [0.004218] ... MAX_LOCKDEP_ENTRIES: 32768 [0.004258] ... MAX_LOCKDEP_CHAINS: 65536 [0.004297] ... CHAINHASH_SIZE: 32768 [0.004336] memory used by lock dependency info: 5167 kB [0.004379] per task-struct memory footprint: 1536 bytes [0.004471] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=12) [0.004557] pid_max: default: 32768 minimum: 301 [0.005348] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.005410] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.008857] CPU: Testing write buffer coherency: ok [0.010644] CPU0: update cpu_capacity 448 [0.010702] CPU0: thread -1, cpu 0, socket
Re: Linux-next, Exynos Octa boot fail, bisected to: drm/exynos: remove drm_iommu_attach_device_if_possible
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.s...@samsung.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.s...@samsung.com Tested-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Inki Dae inki@samsung.com :04 04 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. Other idea? Thanks, Inki Dae Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-next, Exynos Octa boot fail, bisected to: drm/exynos: remove drm_iommu_attach_device_if_possible
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.s...@samsung.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.s...@samsung.com Tested-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Inki Dae inki@samsung.com :04 04 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? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Linux-next, Exynos Octa boot fail, bisected to: drm/exynos: remove drm_iommu_attach_device_if_possible
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.s...@samsung.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.s...@samsung.com Tested-by: Marek Szyprowski m.szyprow...@samsung.com Signed-off-by: Inki Dae inki@samsung.com :04 04 83379efbf4960f58d680371628ec04387935bd53 da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers Config: exynos Boot log from Odroid XU3-Lite attached. Any hints or ideas? Best regards, Krzysztof Starting kernel ... [0.00] Booting Linux on physical CPU 0x100 [0.00] Linux version 4.2.0-rc2-00314-gd80167b85024 (kozik@kozik-lap) (gcc version 4.7.4 (Ubuntu/Linaro 4.7.4-2ubuntu1) ) #766 SMP PREEMPT Tue Jul 21 22:12:16 KST 2015 [0.00] CPU: ARMv7 Processor [410fc073] revision 3 (ARMv7), cr=10c5387d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine model: Hardkernel Odroid XU3 Lite [0.00] cma: Reserved 64 MiB at 0xba80 [0.00] Memory policy: Data cache writealloc [0.00] Samsung CPU ID: 0xe5422001 [0.00] Running under secure firmware. [0.00] PERCPU: Embedded 11 pages/cpu @ee77f000 s15040 r8192 d21824 u45056 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 513040 [0.00] Kernel command line: console=tty1 console=ttySAC2,115200n8 root=/dev/mmcblk0p1 rootwait rw smsc95xx.macaddr=00:1e:06:61:7a:93 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 1957712K/2058240K available (6176K kernel code, 314K rwdata, 2232K rodata, 412K init, 8223K bss, 34992K reserved, 65536K cma-reserved, 1230848K highmem) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xffc0 - 0xfff0 (3072 kB) [0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] pkmap : 0xbfe0 - 0xc000 ( 2 MB) [0.00] modules : 0xbf00 - 0xbfe0 ( 14 MB) [0.00] .text : 0xc0008000 - 0xc083e2e8 (8409 kB) [0.00] .init : 0xc083f000 - 0xc08a6000 ( 412 kB) [0.00] .data : 0xc08a6000 - 0xc08f4b68 ( 315 kB) [0.00].bss : 0xc08f7000 - 0xc10fef60 (8224 kB) [0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=8, Nodes=1 [0.00] Running RCU self tests [0.00] Preemptible hierarchical RCU implementation. [0.00] RCU lockdep checking is enabled. [0.00] Additional per-CPU info printed with stalls. [0.00] Build-time adjustment of leaf fanout to 32. [0.00] NR_IRQS:16 nr_irqs:16 16 [0.00] GIC physical location is 0x10481000 [0.00] L2C: failed to init: -19 [0.00] Switching to timer-based delay loop, resolution 41ns [0.00] clocksource: mct-frc: mask: 0x max_cycles: 0x, max_idle_ns: 79635851949 ns [0.08] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns [0.000986] Console: colour dummy device 80x30 [0.003960] console [tty1] enabled [0.004000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar [0.004063] ... MAX_LOCKDEP_SUBCLASSES: 8 [0.004102] ... MAX_LOCK_DEPTH: 48 [0.004140] ... MAX_LOCKDEP_KEYS:8191 [0.004179] ... CLASSHASH_SIZE: 4096 [0.004218] ... MAX_LOCKDEP_ENTRIES: 32768 [0.004258] ... MAX_LOCKDEP_CHAINS: 65536 [0.004297] ... CHAINHASH_SIZE: 32768 [0.004336] memory used by lock dependency info: 5167 kB [0.004379] per task-struct memory footprint: 1536 bytes [0.004471] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=12) [0.004557] pid_max: default: 32768 minimum: 301 [0.005348] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.005410] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.008857] CPU: Testing write buffer coherency: ok [
