Re: [PATCH] iommu: silence iommu group prints - Russell King

From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Laurentiu Tudor <laurentiu.tudor@nxp.com>
Cc: Diana Madalina Craciun <diana.craciun@nxp.com>,
	iommu@lists.linux-foundation.org,
	Ioana Ciornei <ioana.ciornei@nxp.com>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH] iommu: silence iommu group prints
Date: Wed, 4 Mar 2020 10:52:49 +0000	[thread overview]
Message-ID: <20200304105249.GA25745@shell.armlinux.org.uk> (raw)
In-Reply-To: <6dd33f8d-0eee-83ad-a257-878e9ef83721@nxp.com>

On Wed, Mar 04, 2020 at 12:33:14PM +0200, Laurentiu Tudor wrote:
> 
> 
> On 04.03.2020 12:07, Russell King - ARM Linux admin wrote:
> > On Wed, Mar 04, 2020 at 11:56:53AM +0200, Laurentiu Tudor wrote:
> > >  From 44ae46501b5379bd0890df87fd3827248626ed03 Mon Sep 17 00:00:00 2001
> > > From: Laurentiu Tudor <laurentiu.tudor@nxp.com>
> > > Date: Tue, 1 Oct 2019 16:22:48 +0300
> > > Subject: [PATCH 1/6] bus: fsl-mc: make mc work with smmu disable bypass on
> > > Content-Type: text/plain; charset="us-ascii"
> > > 
> > > Since this commit [1] booting kernel on MC based chips started to
> > > fail because this firmware starts before the kernel and as soon as
> > > SMMU is probed it starts to trigger contiguous faults.
> > 
> > I think you mean "continuous" here.
> 
> Yes, thanks.
> 
> > > This is a workaround that allows MC firmware to run with SMMU
> > > in disable bypass mode. It consists of the following steps:
> > >   1. pause the firmware at early boot to get a chance to setup SMMU
> > >   2. request direct mapping for MC device
> > >   3. resume the firmware
> > > The workaround relies on the fact that no state is lost when
> > > pausing / resuming firmware, as per the docs.
> > > With this patch, platforms with MC firmware can now boot without
> > > having to change the default config to set:
> > >    CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT=n
> > 
> > This alone is a definite improvement, and has been needed for a while.
> > Please submit this patch with an appropriate Fixes: tag so stable trees
> > can pick it up.
> 
> The thing is that probably this workaround will never make it in the kernel
> because it questionable to say the least, e.g. see [1]. My plan is to give
> this approach [2] a try sometime soon.
> 
> [1] https://patchwork.kernel.org/comment/23149049/
> [2] https://patchwork.kernel.org/cover/11279577/

So, if we want to reduce the iommu noise, we need to completely break
the ability to use a mainline kernel on the LX2160A.  This doesn't
seem practical nor sensible.  Someone has to give.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu