Re: [PATCH] ARM: dts: exynos: Increase minimal ACLK400_DISP1 frequency on Exynos542x

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Mar 19, 2019 at 02:26:01PM +0100, Marek Szyprowski wrote:
> ACLK400_DISP1 bus feeds some internal buses of the display subsystem, some
> of which are also related to TV/Mixer hardware modules. When that bus
> is set to 120MHz, Exynos Mixer is not able to properly handle two XRGB
> display planes at FullHD-60MHz. DMA underrun happens, which in turn might
> result in reading data out of the configured buffer, what causes IOMMU
> page fault and kernel panic.
> 
> This change fixes the following IOMMU fault, observed, when 2 Mixer planes
> were enabled:
> 
> exynos-sysmmu 14650000.sysmmu: 14450000.mixer: PAGE FAULT occurred at 0x20fe9000
> ------------[ cut here ]------------
> kernel BUG at ../drivers/iommu/exynos-iommu.c:450!
> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
> Modules linked in:
> CPU: 5 PID: 0 Comm: swapper/5 Not tainted 5.0.0-00003-g1b03088168ea #149
> Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> PC is at exynos_sysmmu_irq+0x1c0/0x264
> LR is at lock_is_held_type+0x44/0x64
> ...
> 
> Reported-by: Marian Mihailescu <mihailescu2m@xxxxxxxxx>
> Fixes: 5d99cc59a3c6 ("ARM: dts: exynos: Move Exynos5250 and Exynos5420 nodes under soc")
> Fixes: b04a62d3ade3 ("ARM: dts: exynos: Add bus nodes using VDD_INT for Exynos542x SoC")
> Signed-off-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
> ---
>  arch/arm/boot/dts/exynos5420.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/exynos5420.dtsi b/arch/arm/boot/dts/exynos5420.dtsi
> index aaff15880761..250f4d7182e0 100644
> --- a/arch/arm/boot/dts/exynos5420.dtsi
> +++ b/arch/arm/boot/dts/exynos5420.dtsi
> @@ -1294,7 +1294,7 @@
>  			compatible = "operating-points-v2";
>  
>  			opp00 {
> -				opp-hz = /bits/ 64 <120000000>;
> +				opp-hz = /bits/ 64 <150000000>;

Some time ago we talked about all these changes on IRC. I understand
that implementing proper QoS (or fix devfreq/PPMU events to properly
indicate busy mixer) might be a big task so let's go with this
workaround. However how about adding a TODO comment about reason of
bumping the frequency?

Best regards,
Krzysztof




[Index of Archives]     [Linux SoC Development]     [Linux Rockchip Development]     [Linux for Synopsys ARC Processors]    
  • [Linux on Unisoc (RDA Micro) SoCs]     [Linux Actions SoC]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Linux SCSI]     [Yosemite News]

  •   Powered by Linux