From: FUJITA Tomonori on
On Wed, 21 Jul 2010 20:50:26 -0700
Zach Pfeffer <zpfeffer(a)codeaurora.org> wrote:

> On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote:
> > On Tue, 13 Jul 2010 10:02:23 +0100
> >
> > Zach Pfeffer said this new VCM infrastructure can be useful for
> > video4linux. However, I don't think we need 3,000-lines another
> > abstraction layer to solve video4linux's issue nicely.
>
> Its only 3000 lines because I haven't converted the code to use
> function pointers.

The main point is adding a new abstraction that don't provide the huge
benefit.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Russell King - ARM Linux on
On Wed, Jul 21, 2010 at 08:50:26PM -0700, Zach Pfeffer wrote:
> On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote:
> > On Tue, 13 Jul 2010 10:02:23 +0100
> >
> > Zach Pfeffer said this new VCM infrastructure can be useful for
> > video4linux. However, I don't think we need 3,000-lines another
> > abstraction layer to solve video4linux's issue nicely.
>
> Its only 3000 lines because I haven't converted the code to use
> function pointers.

I don't understand - you've made this claim a couple of times. I
can't see how converting the code to use function pointers (presumably
to eliminate those switch statements) would reduce the number of lines
of code.

Please explain (or show via new patches) how does converting this to
function pointers significantly reduce the number of lines of code.

We might then be able to put just _one_ of these issues to bed.

> Getting back to the point. There is no API that can handle large
> buffer allocation and sharing with low-level attribute control for
> virtual address spaces outside the CPU.

I think we've dealt with the attribute issue to death now. Shall we
repeat it again?

> The DMA API et al. take a CPU centric view of virtual space
> management, sharing has to be explicitly written and external virtual
> space management is left up to device driver writers.

I think I've also shown that not to be the case with example code.

The code behind the DMA API can be changed on a per-device basis
(currently on ARM we haven't supported that because no one's asked
for it yet) so that it can support multiple IOMMUs even of multiple
different types.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Zach Pfeffer on
On Thu, Jul 22, 2010 at 08:51:51AM +0100, Russell King - ARM Linux wrote:
> On Wed, Jul 21, 2010 at 08:50:26PM -0700, Zach Pfeffer wrote:
> > On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote:
> > > On Tue, 13 Jul 2010 10:02:23 +0100
> > >
> > > Zach Pfeffer said this new VCM infrastructure can be useful for
> > > video4linux. However, I don't think we need 3,000-lines another
> > > abstraction layer to solve video4linux's issue nicely.
> >
> > Its only 3000 lines because I haven't converted the code to use
> > function pointers.
>
> I don't understand - you've made this claim a couple of times. I
> can't see how converting the code to use function pointers (presumably
> to eliminate those switch statements) would reduce the number of lines
> of code.
>
> Please explain (or show via new patches) how does converting this to
> function pointers significantly reduce the number of lines of code.
>
> We might then be able to put just _one_ of these issues to bed.

Aye. Its getting worked on. Once its done I'll push it.

>
> > Getting back to the point. There is no API that can handle large
> > buffer allocation and sharing with low-level attribute control for
> > virtual address spaces outside the CPU.
>
> I think we've dealt with the attribute issue to death now. Shall we
> repeat it again?

I think the only point of agreement is that all mappings must have
compatible attributes, the issue of multiple mappings is still
outstanding, as is needing more fine grained control of the attributes
of a set of compatible mappings (I still need to digest your examples
a little).

>
> > The DMA API et al. take a CPU centric view of virtual space
> > management, sharing has to be explicitly written and external virtual
> > space management is left up to device driver writers.
>
> I think I've also shown that not to be the case with example code.
>
> The code behind the DMA API can be changed on a per-device basis
> (currently on ARM we haven't supported that because no one's asked
> for it yet) so that it can support multiple IOMMUs even of multiple
> different types.

I'm seeing that now. As I become more familiar with the DMA API the
way forward may become more clear to me. I certainly appreciate the
time you've spent discussing things and the code examples you've
listed. For example, it fairly clear how I can use a scatter list to
describe a mapping of big buffers. I can start down this path and see
what shakes out.

>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo(a)kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont(a)kvack.org"> email(a)kvack.org </a>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Zach Pfeffer on
On Thu, Jul 22, 2010 at 01:47:36PM +0900, FUJITA Tomonori wrote:
> On Wed, 21 Jul 2010 20:50:26 -0700
> Zach Pfeffer <zpfeffer(a)codeaurora.org> wrote:
>
> > On Wed, Jul 14, 2010 at 10:59:43AM +0900, FUJITA Tomonori wrote:
> > > On Tue, 13 Jul 2010 10:02:23 +0100
> > >
> > > Zach Pfeffer said this new VCM infrastructure can be useful for
> > > video4linux. However, I don't think we need 3,000-lines another
> > > abstraction layer to solve video4linux's issue nicely.
> >
> > Its only 3000 lines because I haven't converted the code to use
> > function pointers.
>
> The main point is adding a new abstraction that don't provide the huge
> benefit.

I disagree. In its current form the API may not be appropriate for
inclusion into the kernel, but it provides a common framework for
handling a class of problems that have been solved many times in the
kernel: large buffer management, IOMMU interoperation and fine grained
mapping control.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/