[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a2+wH_n6sKNOyzv7sGBuvYX++5ffahfz780WtKr3Bvj=A@mail.gmail.com>
Date: Thu, 1 Feb 2018 16:36:04 +0100
From: Arnd Bergmann <arnd@...db.de>
To: Maxime Ripard <maxime.ripard@...e-electrons.com>
Cc: Thierry Reding <thierry.reding@...il.com>,
Dave Martin <dave.martin@....com>,
Linus Walleij <linus.walleij@...aro.org>,
Yong Deng <yong.deng@...ewell.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Chen-Yu Tsai <wens@...e.org>,
"David S. Miller" <davem@...emloft.net>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Hans Verkuil <hans.verkuil@...co.com>,
Randy Dunlap <rdunlap@...radead.org>,
Stanimir Varbanov <stanimir.varbanov@...aro.org>,
Hugues Fruchet <hugues.fruchet@...com>,
Yannick Fertre <yannick.fertre@...com>,
Philipp Zabel <p.zabel@...gutronix.de>,
Benjamin Gaignard <benjamin.gaignard@...aro.org>,
Ramesh Shanmugasundaram <ramesh.shanmugasundaram@...renesas.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Rick Chang <rick.chang@...iatek.com>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-sunxi <linux-sunxi@...glegroups.com>, megous@...ous.com,
Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>
Subject: Re: [PATCH v6 2/2] media: V3s: Add support for Allwinner CSI.
On Thu, Feb 1, 2018 at 4:29 PM, Maxime Ripard
<maxime.ripard@...e-electrons.com> wrote:
> On Wed, Jan 31, 2018 at 10:37:37AM +0100, Arnd Bergmann wrote:
>> On Wed, Jan 31, 2018 at 8:29 AM, Maxime Ripard
>
>> I can think of a couple of other problems that may or may not be
>> relevant in the future that would require a more complex solution:
>>
>> - a device that is a bus master on more than one bus, e.g. a
>> DMA engine that can copy between the CPU address space and
>> another memory controller that is not visible to the CPU
>>
>> - a device that is connected to main memory both through an IOMMU
>> and directly through its parent bus, and the device itself is in
>> control over which of the two it uses (usually the IOMMU would
>> contol whether a device is bypassing translation)
>>
>> - a device that has a single DMA address space with some form
>> of non-linear mapping to one or more parent buses. Some of these
>> can be expressed using the parent's dma-ranges properties, but
>> our code currently only looks at the first entry in dma-ranges.
>
> As far as I know, we're in neither of these cases.
The point here was more about the general question of where we are
heading with the complexity of finding the right DMA settings. It's
already too complicated for anyone to fully understand what is
going on with DMA masks, offset, coherency etc when we look
at the existing DT bindings. Adding more complexity makes it
worse, so if anyone else is in need of a solution for the issues
above, we should try to accommodate their needs at the same time
to avoid adding more complexity now and again later on if we
can come up with a way that works for everyone now.
Arnd
Powered by blists - more mailing lists