From mboxrd@z Thu Jan 1 00:00:00 1970 From: Uwe =?iso-8859-1?Q?Kleine-K=F6nig?= Date: Fri, 27 Aug 2010 04:41:42 +0000 Subject: Re: [RFC][PATCH] add Message-Id: <20100827044142.GB31863@pengutronix.de> List-Id: References: <20100826182915S.fujita.tomonori@lab.ntt.co.jp> <20100826095311.GA13051@pengutronix.de> <20100826185938A.fujita.tomonori@lab.ntt.co.jp> In-Reply-To: <20100826185938A.fujita.tomonori@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: linux-arm-kernel@lists.infradead.org Hello, On Thu, Aug 26, 2010 at 07:00:24PM +0900, FUJITA Tomonori wrote: > On Thu, 26 Aug 2010 11:53:11 +0200 > Uwe Kleine-K=F6nig wrote: >=20 > > > > We have currently a number of boards broken in the mainline. They m= ust be=20 > > > > fixed for 2.6.36. I don't think the mentioned API will do this for = us. So,=20 > > > > as I suggested earlier, we need either this or my patch series > > > >=20 > > > > http://thread.gmane.org/gmane.linux.ports.sh.devel/8595 > > > >=20 > > > > for 2.6.36. > > >=20 > > > Why can't you revert a commit that causes the regression? > > >=20 > > > The related DMA API wasn't changed in 2.6.36-rc1. The DMA API is not > > > responsible for the regression. And the patchset even exnteds the > > > definition of the DMA API (dma_declare_coherent_memory). Such change > > > shouldn't applied after rc1. I think that DMA-API.txt says that > > > dma_declare_coherent_memory() handles coherent memory for a particular > > > device. It's not for the API that reserves coherent memory that can be > > > used for any device for a single device. > > The patch that made the problem obvious for ARM is > > 309caa9cc6ff39d261264ec4ff10e29489afc8f8 aka v2.6.36-rc1~591^2~2^4~12. > > So this went in before v2.6.36-rc1. One of the "architectures which > > similar restrictions" is x86 BTW. > >=20 > > And no, we won't revert 309caa9cc6ff39d261264ec4ff10e29489afc8f8 as it > > addresses a hardware restriction. >=20 > How these drivers were able to work without hitting the hardware restrict= ion? In my case the machine in question is an ARMv5, the hardware restriction is on ARMv6+ only. You could argue that so the breaking patch for arm should only break ARMv6, but I don't think this is sensible from a maintainers POV. We need an API that works independant of the machine that runs the code. And it's good to let developers that don't have the fu= ll range of machines supported by the kernel at hand notice when they introduce an incompatibility. Best regards Uwe --=20 Pengutronix e.K. | Uwe Kleine-K=F6nig | Industrial Linux Solutions | http://www.pengutronix.de/ |