Re: Tegra DRM device tree bindings

Re: Tegra DRM device tree bindings

[Hiroshi Doyu]

Hi Thierry,

On Tue, 26 Jun 2012 12:55:13 +0200
Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:

> * PGP Signed by an unknown key
> 
> Hi,
> 
> while I haven't got much time to work on the actual code right now, I
> think it might still be useful if we could get the device tree binding
> to a point where everybody is happy with it. That'll also save me some
> time once I get to writing the code because I won't have to redo it over
> again. =)
> 
> So here's the current proposal:
> 
> 	host1x {
> 		compatible = "nvidia,tegra20-host1x", "simple-bus";
> 		reg = <0x50000000 0x00024000>;
> 		interrupts = <0 64 0x04   /* cop syncpt */
> 			      0 65 0x04   /* mpcore syncpt */
> 			      0 66 0x04   /* cop general */
> 			      0 67 0x04>; /* mpcore general */
> 
> 		#address-cells = <1>;
> 		#size-cells = <1>;
> 
> 		ranges = <0x54000000 0x54000000 0x04000000>;
> 
> 		status = "disabled";
> 
> 		gart = <&gart>;
...
> output and hooks up a static EDID block with the LVDS output. There is
> also a carveout property which might be a better replacement for the
> "crippled" GART on Tegra20. Alternatively the CMA might work just as
> well instead.
> 
> The Plutux can be described like this:
> 
> 	host1x {
> 		carveout = <0x0e000000 0x02000000>;

As discussed in the following ML thread previously, the necessary info
related to the "gart" would be got from the standard IOMMU API(or
something above layers, DMABUF or TTM?). So I don't think that we need
to refer to "gart" and "carveout" here in the end.

http://lists.linuxfoundation.org/pipermail/iommu/2012-June/004266.html

Re: Tegra DRM device tree bindings

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2106 bytes --]

On Tue, Jun 26, 2012 at 04:02:24PM +0300, Hiroshi Doyu wrote:
> Hi Thierry,
> 
> On Tue, 26 Jun 2012 12:55:13 +0200
> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> 
> > * PGP Signed by an unknown key
> > 
> > Hi,
> > 
> > while I haven't got much time to work on the actual code right now, I
> > think it might still be useful if we could get the device tree binding
> > to a point where everybody is happy with it. That'll also save me some
> > time once I get to writing the code because I won't have to redo it over
> > again. =)
> > 
> > So here's the current proposal:
> > 
> > 	host1x {
> > 		compatible = "nvidia,tegra20-host1x", "simple-bus";
> > 		reg = <0x50000000 0x00024000>;
> > 		interrupts = <0 64 0x04   /* cop syncpt */
> > 			      0 65 0x04   /* mpcore syncpt */
> > 			      0 66 0x04   /* cop general */
> > 			      0 67 0x04>; /* mpcore general */
> > 
> > 		#address-cells = <1>;
> > 		#size-cells = <1>;
> > 
> > 		ranges = <0x54000000 0x54000000 0x04000000>;
> > 
> > 		status = "disabled";
> > 
> > 		gart = <&gart>;
> ...
> > output and hooks up a static EDID block with the LVDS output. There is
> > also a carveout property which might be a better replacement for the
> > "crippled" GART on Tegra20. Alternatively the CMA might work just as
> > well instead.
> > 
> > The Plutux can be described like this:
> > 
> > 	host1x {
> > 		carveout = <0x0e000000 0x02000000>;
> 
> As discussed in the following ML thread previously, the necessary info
> related to the "gart" would be got from the standard IOMMU API(or
> something above layers, DMABUF or TTM?). So I don't think that we need
> to refer to "gart" and "carveout" here in the end.
> 
> http://lists.linuxfoundation.org/pipermail/iommu/2012-June/004266.html

Yes, if IOMMU or some layer above can provide the same information, then
that is certainly better than explicitly referencing it in the DT.

I'm not sure I understand how information about the carveout would be
obtained from the IOMMU API, though.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

RE: Tegra DRM device tree bindings

[Mark Zhang]

> > On Tue, 26 Jun 2012 12:55:13 +0200
> > Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> >
> > > > Old Signed by an unknown key
> > >
> > > Hi,
> > >
> > > while I haven't got much time to work on the actual code right now,
> > > I think it might still be useful if we could get the device tree
> > > binding to a point where everybody is happy with it. That'll also
> > > save me some time once I get to writing the code because I won't
> > > have to redo it over again. =)
> > >
> > > So here's the current proposal:
> > >
> > > 	host1x {
> > > 		compatible = "nvidia,tegra20-host1x", "simple-bus";
> > > 		reg = <0x50000000 0x00024000>;
> > > 		interrupts = <0 64 0x04   /* cop syncpt */
> > > 			      0 65 0x04   /* mpcore syncpt */
> > > 			      0 66 0x04   /* cop general */
> > > 			      0 67 0x04>; /* mpcore general */
> > >
> > > 		#address-cells = <1>;
> > > 		#size-cells = <1>;
> > >
> > > 		ranges = <0x54000000 0x54000000 0x04000000>;
> > >
> > > 		status = "disabled";
> > >
> > > 		gart = <&gart>;
> > ...
> > > output and hooks up a static EDID block with the LVDS output. There
> > > is also a carveout property which might be a better replacement for
> > > the "crippled" GART on Tegra20. Alternatively the CMA might work
> > > just as well instead.
> > >
> > > The Plutux can be described like this:
> > >
> > > 	host1x {
> > > 		carveout = <0x0e000000 0x02000000>;
> >
> > As discussed in the following ML thread previously, the necessary info
> > related to the "gart" would be got from the standard IOMMU API(or
> > something above layers, DMABUF or TTM?). So I don't think that we need
> > to refer to "gart" and "carveout" here in the end.
> >
> > http://lists.linuxfoundation.org/pipermail/iommu/2012-June/004266.html
> 
> Yes, if IOMMU or some layer above can provide the same information, then that
> is certainly better than explicitly referencing it in the DT.
> 
> I'm not sure I understand how information about the carveout would be
> obtained from the IOMMU API, though.

I think that can be similar with current gart implementation. Define carveout as: 

carveout {
        compatible = "nvidia,tegra20-carveout";
        size = <0x10000000>;
};

Then create a file such like "tegra-carveout.c" to get these definitions and register itself as platform device's iommu instance.

> 
> Thierry
> 
> * Unknown Key
> * 0x7F3EB3A1

Re: Tegra DRM device tree bindings

[Stephen Warren]

On 06/26/2012 07:46 PM, Mark Zhang wrote:
>>> On Tue, 26 Jun 2012 12:55:13 +0200
>>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
...
>> I'm not sure I understand how information about the carveout would be
>> obtained from the IOMMU API, though.
> 
> I think that can be similar with current gart implementation. Define carveout as: 
> 
> carveout {
>         compatible = "nvidia,tegra20-carveout";
>         size = <0x10000000>;
> };
> 
> Then create a file such like "tegra-carveout.c" to get these definitions and register itself as platform device's iommu instance.

The carveout isn't a HW object, so it doesn't seem appropriate to define
a DT node to represent it.

RE: Tegra DRM device tree bindings

[Mark Zhang]

> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> >>> On Tue, 26 Jun 2012 12:55:13 +0200
> >>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> ...
> >> I'm not sure I understand how information about the carveout would be
> >> obtained from the IOMMU API, though.
> >
> > I think that can be similar with current gart implementation. Define carveout as:
> >
> > carveout {
> >         compatible = "nvidia,tegra20-carveout";
> >         size = <0x10000000>;
> > };
> >
> > Then create a file such like "tegra-carveout.c" to get these definitions and
> register itself as platform device's iommu instance.
> 
> The carveout isn't a HW object, so it doesn't seem appropriate to define a DT
> node to represent it.
> --

Yes. But I think it's better to export the size of carveout as a configurable item.
So we need to define this somewhere. How about define carveout as a property of gart?

> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body
> of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

Re: Tegra DRM device tree bindings

[Stephen Warren]

On 06/26/2012 08:32 PM, Mark Zhang wrote:
>> On 06/26/2012 07:46 PM, Mark Zhang wrote:
>>>>> On Tue, 26 Jun 2012 12:55:13 +0200
>>>>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
>> ...
>>>> I'm not sure I understand how information about the carveout would be
>>>> obtained from the IOMMU API, though.
>>>
>>> I think that can be similar with current gart implementation. Define carveout as:
>>>
>>> carveout {
>>>         compatible = "nvidia,tegra20-carveout";
>>>         size = <0x10000000>;
>>> };
>>>
>>> Then create a file such like "tegra-carveout.c" to get these definitions and
>> register itself as platform device's iommu instance.
>>
>> The carveout isn't a HW object, so it doesn't seem appropriate to define a DT
>> node to represent it.
> 
> Yes. But I think it's better to export the size of carveout as a configurable item.
> So we need to define this somewhere. How about define carveout as a property of gart?

There already exists a way of preventing Linux from using certain chunks
of memory; the /memreserve/ syntax. From a brief look at the dtc source,
it looks like /memreserve/ entries can have labels, which implies that a
property in the GART node could refer to the /memreserve/ entry by
phandle in order to know what memory regions to use.

Re: Tegra DRM device tree bindings

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]

On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> On 06/26/2012 08:32 PM, Mark Zhang wrote:
> >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> >>>>> On Tue, 26 Jun 2012 12:55:13 +0200
> >>>>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> >> ...
> >>>> I'm not sure I understand how information about the carveout would be
> >>>> obtained from the IOMMU API, though.
> >>>
> >>> I think that can be similar with current gart implementation. Define carveout as:
> >>>
> >>> carveout {
> >>>         compatible = "nvidia,tegra20-carveout";
> >>>         size = <0x10000000>;
> >>> };
> >>>
> >>> Then create a file such like "tegra-carveout.c" to get these definitions and
> >> register itself as platform device's iommu instance.
> >>
> >> The carveout isn't a HW object, so it doesn't seem appropriate to define a DT
> >> node to represent it.
> > 
> > Yes. But I think it's better to export the size of carveout as a configurable item.
> > So we need to define this somewhere. How about define carveout as a property of gart?
> 
> There already exists a way of preventing Linux from using certain chunks
> of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> it looks like /memreserve/ entries can have labels, which implies that a
> property in the GART node could refer to the /memreserve/ entry by
> phandle in order to know what memory regions to use.

Wasn't the whole point of using a carveout supposed to be a replacement
for the GART? As such I'd think the carveout should rather be a property
of the host1x device.

AIUI what we want to do is have a large contiguous region of memory that
a central component (host1x) manages as a pool from which clients (DRM,
V4L, ...) can allocate buffers as needed. Since all of this memory will
be contiguous anyway there isn't much use for the GART anymore.

But maybe I'm misunderstanding.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

RE: Tegra DRM device tree bindings

[Mark Zhang]

> On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > >>>>> On Tue, 26 Jun 2012 12:55:13 +0200 Thierry Reding
> > >>>>> <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > >> ...
> > >>>> I'm not sure I understand how information about the carveout
> > >>>> would be obtained from the IOMMU API, though.
> > >>>
> > >>> I think that can be similar with current gart implementation. Define
> carveout as:
> > >>>
> > >>> carveout {
> > >>>         compatible = "nvidia,tegra20-carveout";
> > >>>         size = <0x10000000>;
> > >>> };
> > >>>
> > >>> Then create a file such like "tegra-carveout.c" to get these
> > >>> definitions and
> > >> register itself as platform device's iommu instance.
> > >>
> > >> The carveout isn't a HW object, so it doesn't seem appropriate to
> > >> define a DT node to represent it.
> > >
> > > Yes. But I think it's better to export the size of carveout as a configurable item.
> > > So we need to define this somewhere. How about define carveout as a
> property of gart?
> >
> > There already exists a way of preventing Linux from using certain
> > chunks of memory; the /memreserve/ syntax. From a brief look at the
> > dtc source, it looks like /memreserve/ entries can have labels, which
> > implies that a property in the GART node could refer to the
> > /memreserve/ entry by phandle in order to know what memory regions to use.
> 
> Wasn't the whole point of using a carveout supposed to be a replacement for the
> GART? As such I'd think the carveout should rather be a property of the host1x
> device.
> 
> AIUI what we want to do is have a large contiguous region of memory that a
> central component (host1x) manages as a pool from which clients (DRM, V4L, ...)
> can allocate buffers as needed. Since all of this memory will be contiguous
> anyway there isn't much use for the GART anymore.
> 

I have the same understanding. We don't need GART anymore if carveout is enabled.
I'm thinking that why we need to define a property and reference to global 
/memreserve/ in GART or HOST1X node?
We can just define a label for /memreserve/, so we can distinguish these memory 
reservations already in codes.

> But maybe I'm misunderstanding.
> 
> Thierry
> 
> * Unknown Key
> * 0x7F3EB3A1

Re: Tegra DRM device tree bindings

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 1648 bytes --]

On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> On 06/26/2012 08:32 PM, Mark Zhang wrote:
> >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> >>>>> On Tue, 26 Jun 2012 12:55:13 +0200
> >>>>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> >> ...
> >>>> I'm not sure I understand how information about the carveout would be
> >>>> obtained from the IOMMU API, though.
> >>>
> >>> I think that can be similar with current gart implementation. Define carveout as:
> >>>
> >>> carveout {
> >>>         compatible = "nvidia,tegra20-carveout";
> >>>         size = <0x10000000>;
> >>> };
> >>>
> >>> Then create a file such like "tegra-carveout.c" to get these definitions and
> >> register itself as platform device's iommu instance.
> >>
> >> The carveout isn't a HW object, so it doesn't seem appropriate to define a DT
> >> node to represent it.
> > 
> > Yes. But I think it's better to export the size of carveout as a configurable item.
> > So we need to define this somewhere. How about define carveout as a property of gart?
> 
> There already exists a way of preventing Linux from using certain chunks
> of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> it looks like /memreserve/ entries can have labels, which implies that a
> property in the GART node could refer to the /memreserve/ entry by
> phandle in order to know what memory regions to use.

That doesn't work, unfortunately. The /memreserve/ label isn't even
stored in the DTB. Even DTC throws an error when you try to reference
the /memreserve/ by label.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 190 bytes --]

_______________________________________________
iommu mailing list
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: Tegra DRM device tree bindings

[Lucas Stach]

Hi all,

I'm not sure what your exact plans are for the direction in which the
DRM driver should head, as I'm still a bit out of the loop as many of
those matters were only discussed internally at NVIDIA or with some NDA
developers. But I'll still try to get into the discussion.

Am Mittwoch, den 27.06.2012, 07:14 +0200 schrieb Thierry Reding:
> On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > >>>>> On Tue, 26 Jun 2012 12:55:13 +0200
> > >>>>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > >> ...
> > >>>> I'm not sure I understand how information about the carveout would be
> > >>>> obtained from the IOMMU API, though.
> > >>>
> > >>> I think that can be similar with current gart implementation. Define carveout as:
> > >>>
> > >>> carveout {
> > >>>         compatible = "nvidia,tegra20-carveout";
> > >>>         size = <0x10000000>;
> > >>> };
> > >>>
> > >>> Then create a file such like "tegra-carveout.c" to get these definitions and
> > >> register itself as platform device's iommu instance.
> > >>
> > >> The carveout isn't a HW object, so it doesn't seem appropriate to define a DT
> > >> node to represent it.
> > > 
> > > Yes. But I think it's better to export the size of carveout as a configurable item.
> > > So we need to define this somewhere. How about define carveout as a property of gart?
> > 
> > There already exists a way of preventing Linux from using certain chunks
> > of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> > it looks like /memreserve/ entries can have labels, which implies that a
> > property in the GART node could refer to the /memreserve/ entry by
> > phandle in order to know what memory regions to use.
> 
> Wasn't the whole point of using a carveout supposed to be a replacement
> for the GART? As such I'd think the carveout should rather be a property
> of the host1x device.
> 
In my understanding carveout is neither a hardware nor software
component. It's just a somewhat special pool of memory. As I pointed out
in one of the older mails, carveout can not completely replace GART.
While normal allocations for graphics use should be done contiguous,
GART allows us to link normal scattered sysram buffers into GPU address
space, which is a nice thing to have.
IMHO if carveout is to be used exclusively by the GPU (i.e. the DRM
driver) it should be a property of the host1x device.

> AIUI what we want to do is have a large contiguous region of memory that
> a central component (host1x) manages as a pool from which clients (DRM,
> V4L, ...) can allocate buffers as needed. Since all of this memory will
> be contiguous anyway there isn't much use for the GART anymore.
> 
I think this is the wrong way to go. Having a special memory pool
managed by some driver adds one more allocator to the kernel, which is
clearly not desirable. If we want a special mem region for GPU use, we
should not share this memory pool with other components.

But if we want a mem region for contig allocations used by many
components, which seems to be consensus here, CMA is the way to go. In
this case I think we don't want to bother with the carveout property at
all at the DRM driver level. Such a shared mem region managed by CMA
should be defined at a higher level of the device tree.

Thanks,
Lucas

Re: Tegra DRM device tree bindings

[Hiroshi Doyu]

On Tue, 26 Jun 2012 16:00:33 +0200
Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:

> * PGP Signed by an unknown key
> 
> On Tue, Jun 26, 2012 at 04:02:24PM +0300, Hiroshi Doyu wrote:
> > Hi Thierry,
> > 
> > On Tue, 26 Jun 2012 12:55:13 +0200
> > Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > 
> > > > Old Signed by an unknown key
> > > 
> > > Hi,
> > > 
> > > while I haven't got much time to work on the actual code right now, I
> > > think it might still be useful if we could get the device tree binding
> > > to a point where everybody is happy with it. That'll also save me some
> > > time once I get to writing the code because I won't have to redo it over
> > > again. =)
> > > 
> > > So here's the current proposal:
> > > 
> > > 	host1x {
> > > 		compatible = "nvidia,tegra20-host1x", "simple-bus";
> > > 		reg = <0x50000000 0x00024000>;
> > > 		interrupts = <0 64 0x04   /* cop syncpt */
> > > 			      0 65 0x04   /* mpcore syncpt */
> > > 			      0 66 0x04   /* cop general */
> > > 			      0 67 0x04>; /* mpcore general */
> > > 
> > > 		#address-cells = <1>;
> > > 		#size-cells = <1>;
> > > 
> > > 		ranges = <0x54000000 0x54000000 0x04000000>;
> > > 
> > > 		status = "disabled";
> > > 
> > > 		gart = <&gart>;
> > ...
> > > output and hooks up a static EDID block with the LVDS output. There is
> > > also a carveout property which might be a better replacement for the
> > > "crippled" GART on Tegra20. Alternatively the CMA might work just as
> > > well instead.
> > > 
> > > The Plutux can be described like this:
> > > 
> > > 	host1x {
> > > 		carveout = <0x0e000000 0x02000000>;
> > 
> > As discussed in the following ML thread previously, the necessary info
> > related to the "gart" would be got from the standard IOMMU API(or
> > something above layers, DMABUF or TTM?). So I don't think that we need
> > to refer to "gart" and "carveout" here in the end.
> > 
> > http://lists.linuxfoundation.org/pipermail/iommu/2012-June/004266.html
> 
> Yes, if IOMMU or some layer above can provide the same information, then
> that is certainly better than explicitly referencing it in the DT.
> 
> I'm not sure I understand how information about the carveout would be
> obtained from the IOMMU API, though.

I think that there are 2 cases:

  (1) discontiguous memory with IOMMU
  (2) contiguous memory without IOMMU(called "carveout" in general?)

For (1), the necessary info should be passed via IOMMU API as
mentioned in the previous reply, like DT->{GART,SMMU}->IOMMU->DRM.

  [PATCH 0/5] IOMMU: Make IOMMU-API ready for GART-like hardware
    https://lkml.org/lkml/2012/1/19/170

For (2), although memory is mostly anonymous one, we may need to know
how much to allocate, where we only need "size". This size is not from
h/w feature, but it depends on the system load/usage. So I think that
this size can be passed from kernel command line? For exmaple, we can
specify how much contiguous memory is necessary with putting
"coherent_pool=??M" in the kernel command line as below:

	coherent_pool=nn[KMG]	[ARM,KNL]
			Sets the size of memory pool for coherent, atomic dma
			allocations.

Re: Tegra DRM device tree bindings

[Hiroshi Doyu]

On Wed, 27 Jun 2012 04:32:07 +0200
Mark Zhang <markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:

> > On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > >>> On Tue, 26 Jun 2012 12:55:13 +0200
> > >>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > ...
> > >> I'm not sure I understand how information about the carveout would be
> > >> obtained from the IOMMU API, though.
> > >
> > > I think that can be similar with current gart implementation. Define carveout as:
> > >
> > > carveout {
> > >         compatible = "nvidia,tegra20-carveout";
> > >         size = <0x10000000>;
> > > };
> > >
> > > Then create a file such like "tegra-carveout.c" to get these definitions and
> > register itself as platform device's iommu instance.
> > 
> > The carveout isn't a HW object, so it doesn't seem appropriate to define a DT
> > node to represent it.
> > --
> 
> Yes. But I think it's better to export the size of carveout as a configurable item.
> So we need to define this somewhere. How about define carveout as a property of gart?

I agree that the carveout size should be configurable. But it may not be related to gart.

Re: Tegra DRM device tree bindings

[Hiroshi Doyu]

On Wed, 27 Jun 2012 04:48:18 +0200
Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:

> On 06/26/2012 08:32 PM, Mark Zhang wrote:
> >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> >>>>> On Tue, 26 Jun 2012 12:55:13 +0200
> >>>>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> >> ...
> >>>> I'm not sure I understand how information about the carveout would be
> >>>> obtained from the IOMMU API, though.
> >>>
> >>> I think that can be similar with current gart implementation. Define carveout as:
> >>>
> >>> carveout {
> >>>         compatible = "nvidia,tegra20-carveout";
> >>>         size = <0x10000000>;
> >>> };
> >>>
> >>> Then create a file such like "tegra-carveout.c" to get these definitions and
> >> register itself as platform device's iommu instance.
> >>
> >> The carveout isn't a HW object, so it doesn't seem appropriate to define a DT
> >> node to represent it.
> > 
> > Yes. But I think it's better to export the size of carveout as a configurable item.
> > So we need to define this somewhere. How about define carveout as a property of gart?
> 
> There already exists a way of preventing Linux from using certain chunks
> of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> it looks like /memreserve/ entries can have labels, which implies that a
> property in the GART node could refer to the /memreserve/ entry by
> phandle in order to know what memory regions to use.

I think that we don't need the starting address for carveout but we
need its size. carveout memory is just anonymous physically
continguous buffer.

Re: Tegra DRM device tree bindings

[Hiroshi Doyu]

On Wed, 27 Jun 2012 07:14:18 +0200
Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:

> * PGP Signed by an unknown key
> 
> On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > >>>>> On Tue, 26 Jun 2012 12:55:13 +0200
> > >>>>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > >> ...
> > >>>> I'm not sure I understand how information about the carveout would be
> > >>>> obtained from the IOMMU API, though.
> > >>>
> > >>> I think that can be similar with current gart implementation. Define carveout as:
> > >>>
> > >>> carveout {
> > >>>         compatible = "nvidia,tegra20-carveout";
> > >>>         size = <0x10000000>;
> > >>> };
> > >>>
> > >>> Then create a file such like "tegra-carveout.c" to get these definitions and
> > >> register itself as platform device's iommu instance.
> > >>
> > >> The carveout isn't a HW object, so it doesn't seem appropriate to define a DT
> > >> node to represent it.
> > > 
> > > Yes. But I think it's better to export the size of carveout as a configurable item.
> > > So we need to define this somewhere. How about define carveout as a property of gart?
> > 
> > There already exists a way of preventing Linux from using certain chunks
> > of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> > it looks like /memreserve/ entries can have labels, which implies that a
> > property in the GART node could refer to the /memreserve/ entry by
> > phandle in order to know what memory regions to use.
> 
> Wasn't the whole point of using a carveout supposed to be a replacement
> for the GART?

Mostly agree. IIUC, we use both carveout/gart allocated buffers in
android/tegra2.

>As such I'd think the carveout should rather be a property
> of the host1x device.

Rather than introducing a new property, how about using
"coherent_pool=??M" in the kernel command line if necessary? I think
that this carveout size depends on the system usage/load.

> AIUI what we want to do is have a large contiguous region of memory that
> a central component (host1x) manages as a pool from which clients (DRM,
> V4L, ...) can allocate buffers as needed. Since all of this memory will
> be contiguous anyway there isn't much use for the GART anymore.

Right.

I'd think that the amount of contiguous resion might depend on the
system usage/load.

Re: Tegra DRM device tree bindings

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 2564 bytes --]

On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote:
> On Wed, 27 Jun 2012 07:14:18 +0200
> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> 
> > * PGP Signed by an unknown key
> > 
> > On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > > >>>>> On Tue, 26 Jun 2012 12:55:13 +0200
> > > >>>>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > > >> ...
> > > >>>> I'm not sure I understand how information about the carveout would be
> > > >>>> obtained from the IOMMU API, though.
> > > >>>
> > > >>> I think that can be similar with current gart implementation. Define carveout as:
> > > >>>
> > > >>> carveout {
> > > >>>         compatible = "nvidia,tegra20-carveout";
> > > >>>         size = <0x10000000>;
> > > >>> };
> > > >>>
> > > >>> Then create a file such like "tegra-carveout.c" to get these definitions and
> > > >> register itself as platform device's iommu instance.
> > > >>
> > > >> The carveout isn't a HW object, so it doesn't seem appropriate to define a DT
> > > >> node to represent it.
> > > > 
> > > > Yes. But I think it's better to export the size of carveout as a configurable item.
> > > > So we need to define this somewhere. How about define carveout as a property of gart?
> > > 
> > > There already exists a way of preventing Linux from using certain chunks
> > > of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> > > it looks like /memreserve/ entries can have labels, which implies that a
> > > property in the GART node could refer to the /memreserve/ entry by
> > > phandle in order to know what memory regions to use.
> > 
> > Wasn't the whole point of using a carveout supposed to be a replacement
> > for the GART?
> 
> Mostly agree. IIUC, we use both carveout/gart allocated buffers in
> android/tegra2.
> 
> >As such I'd think the carveout should rather be a property
> > of the host1x device.
> 
> Rather than introducing a new property, how about using
> "coherent_pool=??M" in the kernel command line if necessary? I think
> that this carveout size depends on the system usage/load.

I was hoping that we could get away with using the CMA and perhaps
initialize it based on device tree content. I agree that the carveout
size depends on the use-case, but I still think it makes sense to
specify it on a per-board basis.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Tegra DRM device tree bindings

[Hiroshi Doyu]

On Wed, 27 Jun 2012 16:08:10 +0200
Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:

> * PGP Signed by an unknown key
> 
> On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote:
> > On Wed, 27 Jun 2012 07:14:18 +0200
> > Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > 
> > > > Old Signed by an unknown key
> > > 
> > > On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > > > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > > > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > > > >>>>> On Tue, 26 Jun 2012 12:55:13 +0200
> > > > >>>>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > > > >> ...
> > > > >>>> I'm not sure I understand how information about the carveout would be
> > > > >>>> obtained from the IOMMU API, though.
> > > > >>>
> > > > >>> I think that can be similar with current gart implementation. Define carveout as:
> > > > >>>
> > > > >>> carveout {
> > > > >>>         compatible = "nvidia,tegra20-carveout";
> > > > >>>         size = <0x10000000>;
> > > > >>> };
> > > > >>>
> > > > >>> Then create a file such like "tegra-carveout.c" to get these definitions and
> > > > >> register itself as platform device's iommu instance.
> > > > >>
> > > > >> The carveout isn't a HW object, so it doesn't seem appropriate to define a DT
> > > > >> node to represent it.
> > > > > 
> > > > > Yes. But I think it's better to export the size of carveout as a configurable item.
> > > > > So we need to define this somewhere. How about define carveout as a property of gart?
> > > > 
> > > > There already exists a way of preventing Linux from using certain chunks
> > > > of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> > > > it looks like /memreserve/ entries can have labels, which implies that a
> > > > property in the GART node could refer to the /memreserve/ entry by
> > > > phandle in order to know what memory regions to use.
> > > 
> > > Wasn't the whole point of using a carveout supposed to be a replacement
> > > for the GART?
> > 
> > Mostly agree. IIUC, we use both carveout/gart allocated buffers in
> > android/tegra2.
> > 
> > >As such I'd think the carveout should rather be a property
> > > of the host1x device.
> > 
> > Rather than introducing a new property, how about using
> > "coherent_pool=??M" in the kernel command line if necessary? I think
> > that this carveout size depends on the system usage/load.
> 
> I was hoping that we could get away with using the CMA and perhaps
> initialize it based on device tree content. I agree that the carveout
> size depends on the use-case, but I still think it makes sense to
> specify it on a per-board basis.

DRM driver doesn't know if it uses CMA or not, because DRM only uses
DMA API. I think that "coherent_pool" can be used only when the amount
of contiguous memory is short in your system. Otherwise even unnecessary.

Could you explain a bit more why you want carveout size on per-board basis?

Re: Tegra DRM device tree bindings

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 3984 bytes --]

On Wed, Jun 27, 2012 at 05:29:14PM +0300, Hiroshi Doyu wrote:
> On Wed, 27 Jun 2012 16:08:10 +0200
> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> 
> > * PGP Signed by an unknown key
> > 
> > On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote:
> > > On Wed, 27 Jun 2012 07:14:18 +0200
> > > Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > > 
> > > > > Old Signed by an unknown key
> > > > 
> > > > On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > > > > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > > > > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > > > > >>>>> On Tue, 26 Jun 2012 12:55:13 +0200
> > > > > >>>>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > > > > >> ...
> > > > > >>>> I'm not sure I understand how information about the carveout would be
> > > > > >>>> obtained from the IOMMU API, though.
> > > > > >>>
> > > > > >>> I think that can be similar with current gart implementation. Define carveout as:
> > > > > >>>
> > > > > >>> carveout {
> > > > > >>>         compatible = "nvidia,tegra20-carveout";
> > > > > >>>         size = <0x10000000>;
> > > > > >>> };
> > > > > >>>
> > > > > >>> Then create a file such like "tegra-carveout.c" to get these definitions and
> > > > > >> register itself as platform device's iommu instance.
> > > > > >>
> > > > > >> The carveout isn't a HW object, so it doesn't seem appropriate to define a DT
> > > > > >> node to represent it.
> > > > > > 
> > > > > > Yes. But I think it's better to export the size of carveout as a configurable item.
> > > > > > So we need to define this somewhere. How about define carveout as a property of gart?
> > > > > 
> > > > > There already exists a way of preventing Linux from using certain chunks
> > > > > of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> > > > > it looks like /memreserve/ entries can have labels, which implies that a
> > > > > property in the GART node could refer to the /memreserve/ entry by
> > > > > phandle in order to know what memory regions to use.
> > > > 
> > > > Wasn't the whole point of using a carveout supposed to be a replacement
> > > > for the GART?
> > > 
> > > Mostly agree. IIUC, we use both carveout/gart allocated buffers in
> > > android/tegra2.
> > > 
> > > >As such I'd think the carveout should rather be a property
> > > > of the host1x device.
> > > 
> > > Rather than introducing a new property, how about using
> > > "coherent_pool=??M" in the kernel command line if necessary? I think
> > > that this carveout size depends on the system usage/load.
> > 
> > I was hoping that we could get away with using the CMA and perhaps
> > initialize it based on device tree content. I agree that the carveout
> > size depends on the use-case, but I still think it makes sense to
> > specify it on a per-board basis.
> 
> DRM driver doesn't know if it uses CMA or not, because DRM only uses
> DMA API.

So how is the DRM supposed to allocate buffers? Does it call the
dma_alloc_from_contiguous() function to do that? I can see how it is
used by arm_dma_ops but how does it end up in the driver?

> I think that "coherent_pool" can be used only when the amount of
> contiguous memory is short in your system. Otherwise even unnecessary.
> 
> Could you explain a bit more why you want carveout size on per-board basis?

In the ideal case I would want to not have a carveout size at all.
However there may be situations where you need to make sure some driver
can allocate a given amount of memory. Having to specify this using a
kernel command-line parameter is cumbersome because it may require
changes to the bootloader or whatever. So if you know that a particular
board always needs 128 MiB of carveout, then it makes sense to specify
it on a per-board basis.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 190 bytes --]

_______________________________________________
iommu mailing list
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: Tegra DRM device tree bindings

[Lucas Stach]

Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> On Wed, Jun 27, 2012 at 05:29:14PM +0300, Hiroshi Doyu wrote:
> > On Wed, 27 Jun 2012 16:08:10 +0200
> > Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > 
> > > * PGP Signed by an unknown key
> > > 
> > > On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote:
> > > > On Wed, 27 Jun 2012 07:14:18 +0200
> > > > Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > > > 
> > > > > > Old Signed by an unknown key
> > > > > 
> > > > > On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > > > > > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > > > > > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > > > > > >>>>> On Tue, 26 Jun 2012 12:55:13 +0200
> > > > > > >>>>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > > > > > >> ...
> > > > > > >>>> I'm not sure I understand how information about the carveout would be
> > > > > > >>>> obtained from the IOMMU API, though.
> > > > > > >>>
> > > > > > >>> I think that can be similar with current gart implementation. Define carveout as:
> > > > > > >>>
> > > > > > >>> carveout {
> > > > > > >>>         compatible = "nvidia,tegra20-carveout";
> > > > > > >>>         size = <0x10000000>;
> > > > > > >>> };
> > > > > > >>>
> > > > > > >>> Then create a file such like "tegra-carveout.c" to get these definitions and
> > > > > > >> register itself as platform device's iommu instance.
> > > > > > >>
> > > > > > >> The carveout isn't a HW object, so it doesn't seem appropriate to define a DT
> > > > > > >> node to represent it.
> > > > > > > 
> > > > > > > Yes. But I think it's better to export the size of carveout as a configurable item.
> > > > > > > So we need to define this somewhere. How about define carveout as a property of gart?
> > > > > > 
> > > > > > There already exists a way of preventing Linux from using certain chunks
> > > > > > of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> > > > > > it looks like /memreserve/ entries can have labels, which implies that a
> > > > > > property in the GART node could refer to the /memreserve/ entry by
> > > > > > phandle in order to know what memory regions to use.
> > > > > 
> > > > > Wasn't the whole point of using a carveout supposed to be a replacement
> > > > > for the GART?
> > > > 
> > > > Mostly agree. IIUC, we use both carveout/gart allocated buffers in
> > > > android/tegra2.
> > > > 
> > > > >As such I'd think the carveout should rather be a property
> > > > > of the host1x device.
> > > > 
> > > > Rather than introducing a new property, how about using
> > > > "coherent_pool=??M" in the kernel command line if necessary? I think
> > > > that this carveout size depends on the system usage/load.
> > > 
> > > I was hoping that we could get away with using the CMA and perhaps
> > > initialize it based on device tree content. I agree that the carveout
> > > size depends on the use-case, but I still think it makes sense to
> > > specify it on a per-board basis.
> > 
> > DRM driver doesn't know if it uses CMA or not, because DRM only uses
> > DMA API.
> 
> So how is the DRM supposed to allocate buffers? Does it call the
> dma_alloc_from_contiguous() function to do that? I can see how it is
> used by arm_dma_ops but how does it end up in the driver?
> 
As I said before the DMA API is not a good fit for graphics drivers.
Most of the DMA buffers used by graphics cores are long lived and big,
so we need a special pool to alloc from to avoid eating all contiguous
address space, as DMA API does not provide shrinker callbacks for
clients using large amount of memory.

> > I think that "coherent_pool" can be used only when the amount of
> > contiguous memory is short in your system. Otherwise even unnecessary.
> > 
> > Could you explain a bit more why you want carveout size on per-board basis?
> 
> In the ideal case I would want to not have a carveout size at all.
> However there may be situations where you need to make sure some driver
> can allocate a given amount of memory. Having to specify this using a
> kernel command-line parameter is cumbersome because it may require
> changes to the bootloader or whatever. So if you know that a particular
> board always needs 128 MiB of carveout, then it makes sense to specify
> it on a per-board basis.

If we go with CMA, this is a non-issue, as CMA allows to use the contig
area for normal allocations and only purges them if it really needs the
space for contig allocs.
> 
> Thierry

Re: Tegra DRM device tree bindings

[Stephen Warren]

On 06/27/2012 08:29 AM, Hiroshi Doyu wrote:
> Could you explain a bit more why you want carveout size on per-board basis?

Different boards have different amounts of memory, and are sometimes
targeted at different use-cases (e.g. server with simple display buffer,
vs. consumer-oriented device intended to play games with OpenGL
allocating lots of textures).

Re: Tegra DRM device tree bindings

[Stephen Warren]

On 06/27/2012 06:44 AM, Hiroshi Doyu wrote:
...
> I think that there are 2 cases:
> 
>   (1) discontiguous memory with IOMMU
>   (2) contiguous memory without IOMMU(called "carveout" in general?)
...
> For (2), although memory is mostly anonymous one, we may need to know
> how much to allocate, where we only need "size". This size is not from
> h/w feature, but it depends on the system load/usage. So I think that
> this size can be passed from kernel command line? For exmaple, we can
> specify how much contiguous memory is necessary with putting
> "coherent_pool=??M" in the kernel command line as below:
> 
> 	coherent_pool=nn[KMG]	[ARM,KNL]
> 			Sets the size of memory pool for coherent, atomic dma
> 			allocations.

I guess if that's the standard way of initializing CMA, then that's fine.

It'd be nice if there was a way to specify that from the DT too; that
way the user/distro/bootloader constructing the kernel command-line
wouldn't have to remember to add "random" (potentially
Tegra-/board-specific) extra arguments onto the command-line; the Tegra
command-line in the upstream kernel is quite clean right now, especially
compare to the enormous number of options we require downstream:-(

Re: Tegra DRM device tree bindings

[Hiroshi Doyu]

Hi Lucas,

On Wed, 27 Jun 2012 17:59:55 +0200
Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org> wrote:

> > > > > Rather than introducing a new property, how about using
> > > > > "coherent_pool=??M" in the kernel command line if necessary? I think
> > > > > that this carveout size depends on the system usage/load.
> > > > 
> > > > I was hoping that we could get away with using the CMA and perhaps
> > > > initialize it based on device tree content. I agree that the carveout
> > > > size depends on the use-case, but I still think it makes sense to
> > > > specify it on a per-board basis.
> > > 
> > > DRM driver doesn't know if it uses CMA or not, because DRM only uses
> > > DMA API.
> > 
> > So how is the DRM supposed to allocate buffers? Does it call the
> > dma_alloc_from_contiguous() function to do that? I can see how it is
> > used by arm_dma_ops but how does it end up in the driver?
> > 
> As I said before the DMA API is not a good fit for graphics drivers.
> Most of the DMA buffers used by graphics cores are long lived and big,
> so we need a special pool to alloc from to avoid eating all contiguous
> address space, as DMA API does not provide shrinker callbacks for
> clients using large amount of memory.

For contiguious address space shortage issue in DMA API, I think that
DMABUF framework can handle?

If so, is there any good example for DMABUF used in DRM?

Re: Tegra DRM device tree bindings

[Hiroshi Doyu]

On Wed, 27 Jun 2012 16:44:14 +0200
Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:

> > I think that "coherent_pool" can be used only when the amount of
> > contiguous memory is short in your system. Otherwise even unnecessary.
> > 
> > Could you explain a bit more why you want carveout size on per-board basis?
> 
> In the ideal case I would want to not have a carveout size at all.
> However there may be situations where you need to make sure some driver
> can allocate a given amount of memory. Having to specify this using a
> kernel command-line parameter is cumbersome because it may require
> changes to the bootloader or whatever. So if you know that a particular
> board always needs 128 MiB of carveout, then it makes sense to specify
> it on a per-board basis.

Hm...I could understand somewhat;) but DT can also specify "bootargs"
in dts file, which can support per-board-wide spec too, like the above
sum of carveout needed from all drivers. I just want to avoid
introducing a new parameter additionaly if we can make use of the
existing mechanism.

Re: Tegra DRM device tree bindings

[Hiroshi Doyu]

On Wed, 27 Jun 2012 19:56:35 +0200
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:

> On 06/27/2012 08:29 AM, Hiroshi Doyu wrote:
> > Could you explain a bit more why you want carveout size on per-board basis?
> 
> Different boards have different amounts of memory, and are sometimes
> targeted at different use-cases (e.g. server with simple display buffer,
> vs. consumer-oriented device intended to play games with OpenGL
> allocating lots of textures).

May I ask a bit? If the above requirement has been satisfied by one of
the kernel parameter in a commandline, wouldn't it be enough since DT
can also specify "bootargs"? Or using bootargs in dts isn't so encouraged?

Re: Tegra DRM device tree bindings

[Hiroshi Doyu]

On Wed, 27 Jun 2012 20:02:46 +0200
Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org> wrote:

> On 06/27/2012 06:44 AM, Hiroshi Doyu wrote:
> ...
> > I think that there are 2 cases:
> > 
> >   (1) discontiguous memory with IOMMU
> >   (2) contiguous memory without IOMMU(called "carveout" in general?)
> ...
> > For (2), although memory is mostly anonymous one, we may need to know
> > how much to allocate, where we only need "size". This size is not from
> > h/w feature, but it depends on the system load/usage. So I think that
> > this size can be passed from kernel command line? For exmaple, we can
> > specify how much contiguous memory is necessary with putting
> > "coherent_pool=??M" in the kernel command line as below:
> > 
> > 	coherent_pool=nn[KMG]	[ARM,KNL]
> > 			Sets the size of memory pool for coherent, atomic dma
> > 			allocations.
> 
> I guess if that's the standard way of initializing CMA, then that's fine.
> 
> It'd be nice if there was a way to specify that from the DT too; that
> way the user/distro/bootloader constructing the kernel command-line
> wouldn't have to remember to add "random" (potentially
> Tegra-/board-specific) extra arguments onto the command-line; the Tegra
> command-line in the upstream kernel is quite clean right now, especially
> compare to the enormous number of options we require downstream:-(

DT can specify the kernel command-line as "bootargs" in a dts file,
which can be modified after extracted on memory by bootloader.

Re: Tegra DRM device tree bindings

[Lucas Stach]

Am Donnerstag, den 28.06.2012, 09:06 +0300 schrieb Hiroshi Doyu:
> Hi Lucas,
> 
> On Wed, 27 Jun 2012 17:59:55 +0200
> Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org> wrote:
> 
> > > > > > Rather than introducing a new property, how about using
> > > > > > "coherent_pool=??M" in the kernel command line if necessary? I think
> > > > > > that this carveout size depends on the system usage/load.
> > > > > 
> > > > > I was hoping that we could get away with using the CMA and perhaps
> > > > > initialize it based on device tree content. I agree that the carveout
> > > > > size depends on the use-case, but I still think it makes sense to
> > > > > specify it on a per-board basis.
> > > > 
> > > > DRM driver doesn't know if it uses CMA or not, because DRM only uses
> > > > DMA API.
> > > 
> > > So how is the DRM supposed to allocate buffers? Does it call the
> > > dma_alloc_from_contiguous() function to do that? I can see how it is
> > > used by arm_dma_ops but how does it end up in the driver?
> > > 
> > As I said before the DMA API is not a good fit for graphics drivers.
> > Most of the DMA buffers used by graphics cores are long lived and big,
> > so we need a special pool to alloc from to avoid eating all contiguous
> > address space, as DMA API does not provide shrinker callbacks for
> > clients using large amount of memory.
> 
> For contiguious address space shortage issue in DMA API, I think that
> DMABUF framework can handle?
> 
No, DMABUF is only about sharing DMA buffers between different hardware
blocks. It has no address space management at all.

All DRM drivers manage their address space on their own, either through
GEM or TTM. On the desktop the main pool for contiguous memory is on
card VRAM or a area of system memory set aside for use by the DRM
driver. Having a carveout area only for DRM use would be the same thing,
but makes the split between graphics and system memory a bit unflexible.
Currently we have no sane way for integrating DRM memory managers with
the normal DMA API. There was some discussion about DMA pools and/or
shrinkers for DMA clients, but they have not led to any written code.

DMABUF only makes a limited integration between for example V4L and DRM
possible, so they can share buffers. But we still have the situation
that DRM devices allocate from their own pool, for explained reasons and
not use the standard DMA API.

Re: Tegra DRM device tree bindings

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 6111 bytes --]

On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> > On Wed, Jun 27, 2012 at 05:29:14PM +0300, Hiroshi Doyu wrote:
> > > On Wed, 27 Jun 2012 16:08:10 +0200
> > > Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > > 
> > > > * PGP Signed by an unknown key
> > > > 
> > > > On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote:
> > > > > On Wed, 27 Jun 2012 07:14:18 +0200
> > > > > Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > > > > 
> > > > > > > Old Signed by an unknown key
> > > > > > 
> > > > > > On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > > > > > > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > > > > > > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > > > > > > >>>>> On Tue, 26 Jun 2012 12:55:13 +0200
> > > > > > > >>>>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > > > > > > >> ...
> > > > > > > >>>> I'm not sure I understand how information about the carveout would be
> > > > > > > >>>> obtained from the IOMMU API, though.
> > > > > > > >>>
> > > > > > > >>> I think that can be similar with current gart implementation. Define carveout as:
> > > > > > > >>>
> > > > > > > >>> carveout {
> > > > > > > >>>         compatible = "nvidia,tegra20-carveout";
> > > > > > > >>>         size = <0x10000000>;
> > > > > > > >>> };
> > > > > > > >>>
> > > > > > > >>> Then create a file such like "tegra-carveout.c" to get these definitions and
> > > > > > > >> register itself as platform device's iommu instance.
> > > > > > > >>
> > > > > > > >> The carveout isn't a HW object, so it doesn't seem appropriate to define a DT
> > > > > > > >> node to represent it.
> > > > > > > > 
> > > > > > > > Yes. But I think it's better to export the size of carveout as a configurable item.
> > > > > > > > So we need to define this somewhere. How about define carveout as a property of gart?
> > > > > > > 
> > > > > > > There already exists a way of preventing Linux from using certain chunks
> > > > > > > of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> > > > > > > it looks like /memreserve/ entries can have labels, which implies that a
> > > > > > > property in the GART node could refer to the /memreserve/ entry by
> > > > > > > phandle in order to know what memory regions to use.
> > > > > > 
> > > > > > Wasn't the whole point of using a carveout supposed to be a replacement
> > > > > > for the GART?
> > > > > 
> > > > > Mostly agree. IIUC, we use both carveout/gart allocated buffers in
> > > > > android/tegra2.
> > > > > 
> > > > > >As such I'd think the carveout should rather be a property
> > > > > > of the host1x device.
> > > > > 
> > > > > Rather than introducing a new property, how about using
> > > > > "coherent_pool=??M" in the kernel command line if necessary? I think
> > > > > that this carveout size depends on the system usage/load.
> > > > 
> > > > I was hoping that we could get away with using the CMA and perhaps
> > > > initialize it based on device tree content. I agree that the carveout
> > > > size depends on the use-case, but I still think it makes sense to
> > > > specify it on a per-board basis.
> > > 
> > > DRM driver doesn't know if it uses CMA or not, because DRM only uses
> > > DMA API.
> > 
> > So how is the DRM supposed to allocate buffers? Does it call the
> > dma_alloc_from_contiguous() function to do that? I can see how it is
> > used by arm_dma_ops but how does it end up in the driver?
> > 
> As I said before the DMA API is not a good fit for graphics drivers.
> Most of the DMA buffers used by graphics cores are long lived and big,
> so we need a special pool to alloc from to avoid eating all contiguous
> address space, as DMA API does not provide shrinker callbacks for
> clients using large amount of memory.

I recall you mentioning TTM as a better alternative several times in the
past. How does it fit in with this? Does it have the capability of using
a predefined chunk of contiguous memory as a pool to allocate from?

One problem that all of these solutions don't address is that not all
devices below host1x are DRM related. At least for the CSI and VI blocks
I expect there to be V4L2 drivers eventually, so what we really need is
to manage allocations outside of the DRM. host1x is the most logical
choice here.

Perhaps we can put host1x code somewhere below drivers/gpu (mm
subdirectory?), drivers/memory or perhaps some other or new location
that could eventually host similar drivers for other SoCs.

Then again, maybe it'd be easier for now to put everything below the
drivers/gpu/drm/tegra directory and cross that bridge when we get to it.

> > > I think that "coherent_pool" can be used only when the amount of
> > > contiguous memory is short in your system. Otherwise even unnecessary.
> > > 
> > > Could you explain a bit more why you want carveout size on per-board basis?
> > 
> > In the ideal case I would want to not have a carveout size at all.
> > However there may be situations where you need to make sure some driver
> > can allocate a given amount of memory. Having to specify this using a
> > kernel command-line parameter is cumbersome because it may require
> > changes to the bootloader or whatever. So if you know that a particular
> > board always needs 128 MiB of carveout, then it makes sense to specify
> > it on a per-board basis.
> 
> If we go with CMA, this is a non-issue, as CMA allows to use the contig
> area for normal allocations and only purges them if it really needs the
> space for contig allocs.

CMA certainly sounds like the most simple approach. While it may not be
suited for 3D graphics or multimedia processing later on, I think we
could use it at a starting point to get basic framebuffer and X support
up and running. We can always move to something more advanced like TTM
later.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Tegra DRM device tree bindings

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 1649 bytes --]

On Wed, Jun 27, 2012 at 12:02:46PM -0600, Stephen Warren wrote:
> On 06/27/2012 06:44 AM, Hiroshi Doyu wrote:
> ...
> > I think that there are 2 cases:
> > 
> >   (1) discontiguous memory with IOMMU
> >   (2) contiguous memory without IOMMU(called "carveout" in general?)
> ...
> > For (2), although memory is mostly anonymous one, we may need to know
> > how much to allocate, where we only need "size". This size is not from
> > h/w feature, but it depends on the system load/usage. So I think that
> > this size can be passed from kernel command line? For exmaple, we can
> > specify how much contiguous memory is necessary with putting
> > "coherent_pool=??M" in the kernel command line as below:
> > 
> > 	coherent_pool=nn[KMG]	[ARM,KNL]
> > 			Sets the size of memory pool for coherent, atomic dma
> > 			allocations.
> 
> I guess if that's the standard way of initializing CMA, then that's fine.
> 
> It'd be nice if there was a way to specify that from the DT too; that
> way the user/distro/bootloader constructing the kernel command-line
> wouldn't have to remember to add "random" (potentially
> Tegra-/board-specific) extra arguments onto the command-line; the Tegra
> command-line in the upstream kernel is quite clean right now, especially
> compare to the enormous number of options we require downstream:-(

Looking at Documentation/kernel-parameters.txt it seems the canonical
way to initialize CMA is using the "cma" kernel command-line parameter.
For device tree we could extend the "chosen" node to include something
like "carveout = <0x04000000>;". Or "contiguous-memory" or whatever.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 190 bytes --]

_______________________________________________
iommu mailing list
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: Tegra DRM device tree bindings

[Stephen Warren]

On 06/28/2012 12:18 AM, Hiroshi Doyu wrote:
> On Wed, 27 Jun 2012 16:44:14 +0200
> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> 
>>> I think that "coherent_pool" can be used only when the amount of
>>> contiguous memory is short in your system. Otherwise even unnecessary.
>>>
>>> Could you explain a bit more why you want carveout size on per-board basis?
>>
>> In the ideal case I would want to not have a carveout size at all.
>> However there may be situations where you need to make sure some driver
>> can allocate a given amount of memory. Having to specify this using a
>> kernel command-line parameter is cumbersome because it may require
>> changes to the bootloader or whatever. So if you know that a particular
>> board always needs 128 MiB of carveout, then it makes sense to specify
>> it on a per-board basis.
> 
> Hm...I could understand somewhat;) but DT can also specify "bootargs"
> in dts file, which can support per-board-wide spec too, like the above
> sum of carveout needed from all drivers. I just want to avoid
> introducing a new parameter additionaly if we can make use of the
> existing mechanism.

The bootargs in the DT file is usually provided by (over-written by) the
bootloader. If we start requiring lots of random kernel command-line
arguments, that makes it more effort for the user of the bootloader
(e.g. distribution bootloader scripts, etc.) to create the kernel
command-line. I'd prefer to avoid that as much as possible. That said,
using a standardized command-line option that is (or will be) used by
all (ARM?) SoCs for the same purpose is reasonable, because there's
commonality there.

Re: Tegra DRM device tree bindings

[Stephen Warren]

On 06/28/2012 05:12 AM, Thierry Reding wrote:
> On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
>> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
...
>>> In the ideal case I would want to not have a carveout size at
>>> all. However there may be situations where you need to make
>>> sure some driver can allocate a given amount of memory. Having
>>> to specify this using a kernel command-line parameter is
>>> cumbersome because it may require changes to the bootloader or
>>> whatever. So if you know that a particular board always needs
>>> 128 MiB of carveout, then it makes sense to specify it on a
>>> per-board basis.
>> 
>> If we go with CMA, this is a non-issue, as CMA allows to use the
>> contig area for normal allocations and only purges them if it
>> really needs the space for contig allocs.
> 
> CMA certainly sounds like the most simple approach. While it may
> not be suited for 3D graphics or multimedia processing later on, I
> think we could use it at a starting point to get basic framebuffer
> and X support up and running. We can always move to something more
> advanced like TTM later.

I thought the whole purpose of CMA was to act as the infra-structure
to provide buffers to 3D, camera, etc. in particular allowing sharing
of buffers between them. In other words, isn't CMA the memory manager?
If there's some deficiency with CMA for 3D graphics, it seems like
that should be raised with those designing CMA. Or, am I way off base
with my expectations of CMA?

Re: Tegra DRM device tree bindings

[Lucas Stach]

Hi Thierry,

Am Donnerstag, den 28.06.2012, 13:12 +0200 schrieb Thierry Reding:
> On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
> > Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> > > On Wed, Jun 27, 2012 at 05:29:14PM +0300, Hiroshi Doyu wrote:
> > > > On Wed, 27 Jun 2012 16:08:10 +0200
> > > > Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > > > 
> > > > > * PGP Signed by an unknown key
> > > > > 
> > > > > On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote:
> > > > > > On Wed, 27 Jun 2012 07:14:18 +0200
> > > > > > Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > > > > > 
> > > > > > > > Old Signed by an unknown key
> > > > > > > 
> > > > > > > On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > > > > > > > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > > > > > > > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > > > > > > > >>>>> On Tue, 26 Jun 2012 12:55:13 +0200
> > > > > > > > >>>>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > > > > > > > >> ...
> > > > > > > > >>>> I'm not sure I understand how information about the carveout would be
> > > > > > > > >>>> obtained from the IOMMU API, though.
> > > > > > > > >>>
> > > > > > > > >>> I think that can be similar with current gart implementation. Define carveout as:
> > > > > > > > >>>
> > > > > > > > >>> carveout {
> > > > > > > > >>>         compatible = "nvidia,tegra20-carveout";
> > > > > > > > >>>         size = <0x10000000>;
> > > > > > > > >>> };
> > > > > > > > >>>
> > > > > > > > >>> Then create a file such like "tegra-carveout.c" to get these definitions and
> > > > > > > > >> register itself as platform device's iommu instance.
> > > > > > > > >>
> > > > > > > > >> The carveout isn't a HW object, so it doesn't seem appropriate to define a DT
> > > > > > > > >> node to represent it.
> > > > > > > > > 
> > > > > > > > > Yes. But I think it's better to export the size of carveout as a configurable item.
> > > > > > > > > So we need to define this somewhere. How about define carveout as a property of gart?
> > > > > > > > 
> > > > > > > > There already exists a way of preventing Linux from using certain chunks
> > > > > > > > of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> > > > > > > > it looks like /memreserve/ entries can have labels, which implies that a
> > > > > > > > property in the GART node could refer to the /memreserve/ entry by
> > > > > > > > phandle in order to know what memory regions to use.
> > > > > > > 
> > > > > > > Wasn't the whole point of using a carveout supposed to be a replacement
> > > > > > > for the GART?
> > > > > > 
> > > > > > Mostly agree. IIUC, we use both carveout/gart allocated buffers in
> > > > > > android/tegra2.
> > > > > > 
> > > > > > >As such I'd think the carveout should rather be a property
> > > > > > > of the host1x device.
> > > > > > 
> > > > > > Rather than introducing a new property, how about using
> > > > > > "coherent_pool=??M" in the kernel command line if necessary? I think
> > > > > > that this carveout size depends on the system usage/load.
> > > > > 
> > > > > I was hoping that we could get away with using the CMA and perhaps
> > > > > initialize it based on device tree content. I agree that the carveout
> > > > > size depends on the use-case, but I still think it makes sense to
> > > > > specify it on a per-board basis.
> > > > 
> > > > DRM driver doesn't know if it uses CMA or not, because DRM only uses
> > > > DMA API.
> > > 
> > > So how is the DRM supposed to allocate buffers? Does it call the
> > > dma_alloc_from_contiguous() function to do that? I can see how it is
> > > used by arm_dma_ops but how does it end up in the driver?
> > > 
> > As I said before the DMA API is not a good fit for graphics drivers.
> > Most of the DMA buffers used by graphics cores are long lived and big,
> > so we need a special pool to alloc from to avoid eating all contiguous
> > address space, as DMA API does not provide shrinker callbacks for
> > clients using large amount of memory.
> 
> I recall you mentioning TTM as a better alternative several times in the
> past. How does it fit in with this? Does it have the capability of using
> a predefined chunk of contiguous memory as a pool to allocate from?
> 
> One problem that all of these solutions don't address is that not all
> devices below host1x are DRM related. At least for the CSI and VI blocks
> I expect there to be V4L2 drivers eventually, so what we really need is
> to manage allocations outside of the DRM. host1x is the most logical
> choice here.

I think you are right here. We might want to move all those
buffer/memory management in the host1x code and provide contig memory to
the host1x clients from there.

TTM has the ability to manage a chunk of memory for contig allocations.
Also I think TTM does not depend too heavily on DRM, so we may even be
able to use TTM as the general allocator for host1x clients, including
VI and others. The more advanced stuff in TTM like swapping and moving
buffers might be a bit of overkill for simple stuff like V4L, where you
basically just want something like: "give me a contig buffer and pin it
in address space so it won't ever move", but it should do no harm.

> 
> Perhaps we can put host1x code somewhere below drivers/gpu (mm
> subdirectory?), drivers/memory or perhaps some other or new location
> that could eventually host similar drivers for other SoCs.
> 
> Then again, maybe it'd be easier for now to put everything below the
> drivers/gpu/drm/tegra directory and cross that bridge when we get to it.
> 
> > > > I think that "coherent_pool" can be used only when the amount of
> > > > contiguous memory is short in your system. Otherwise even unnecessary.
> > > > 
> > > > Could you explain a bit more why you want carveout size on per-board basis?
> > > 
> > > In the ideal case I would want to not have a carveout size at all.
> > > However there may be situations where you need to make sure some driver
> > > can allocate a given amount of memory. Having to specify this using a
> > > kernel command-line parameter is cumbersome because it may require
> > > changes to the bootloader or whatever. So if you know that a particular
> > > board always needs 128 MiB of carveout, then it makes sense to specify
> > > it on a per-board basis.
> > 
> > If we go with CMA, this is a non-issue, as CMA allows to use the contig
> > area for normal allocations and only purges them if it really needs the
> > space for contig allocs.
> 
> CMA certainly sounds like the most simple approach. While it may not be
> suited for 3D graphics or multimedia processing later on, I think we
> could use it at a starting point to get basic framebuffer and X support
> up and running. We can always move to something more advanced like TTM
> later.
> 
> Thierry

Re: Tegra DRM device tree bindings

[Lucas Stach]

Am Donnerstag, den 28.06.2012, 10:51 -0600 schrieb Stephen Warren:
> On 06/28/2012 05:12 AM, Thierry Reding wrote:
> > On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
> >> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> ...
> >>> In the ideal case I would want to not have a carveout size at
> >>> all. However there may be situations where you need to make
> >>> sure some driver can allocate a given amount of memory. Having
> >>> to specify this using a kernel command-line parameter is
> >>> cumbersome because it may require changes to the bootloader or
> >>> whatever. So if you know that a particular board always needs
> >>> 128 MiB of carveout, then it makes sense to specify it on a
> >>> per-board basis.
> >> 
> >> If we go with CMA, this is a non-issue, as CMA allows to use the
> >> contig area for normal allocations and only purges them if it
> >> really needs the space for contig allocs.
> > 
> > CMA certainly sounds like the most simple approach. While it may
> > not be suited for 3D graphics or multimedia processing later on, I
> > think we could use it at a starting point to get basic framebuffer
> > and X support up and running. We can always move to something more
> > advanced like TTM later.
> 
> I thought the whole purpose of CMA was to act as the infra-structure
> to provide buffers to 3D, camera, etc. in particular allowing sharing
> of buffers between them. In other words, isn't CMA the memory manager?
> If there's some deficiency with CMA for 3D graphics, it seems like
> that should be raised with those designing CMA. Or, am I way off base
> with my expectations of CMA?
> 
CMA is just a way of providing large contiguous address space blocks in
a dynamic fashion. The problem CMA solves is: we have a system with
relatively low amounts of sysmem (like 512MB), now to ensure we can
always get large contiguous buffers for use by GPU or VIDEO blocks, we
need to set aside a relatively large contiguous pool (like 128MB). So we
are stealing 128MB of memory from the system while we may or may not use
it, which is bad.
Now CMA allows to say: I may need 128MB of contig space, but the system
is free to use it as normal memory as long as I don't really need it. If
the space is really needed, CMA purges pages from the area and may even
swap them out. So yes CMA is a memory allocator for contig memory.

TTM though solves more advanced matters, like buffer synchronisation
between 3D and 2D block of hardware or syncing buffer access between GPU
and CPU.
One of the most interesting things of TTM is the ability to purge the
GPU DMA buffers to scattered sysmem or even swap them out, if they are
not currently used by the GPU. It then makes sure to move them in the
contig space again when the GPU really needs them and fix up the GPU
command stream with the new buffer address.

IMHO the best solution would be to use CMA as a flexible replacement of
the static carveout area and put TTM on top of this to solve the needs
of graphics drivers. We certainly don't want to reinvent the wheel
inside CMA. We have solutions for all those things in the kernel right
now, we just have to glue them together in a sane way.

Thanks,
Lucas

Re: Tegra DRM device tree bindings

[Stephen Warren]

On 06/28/2012 11:19 AM, Lucas Stach wrote:
...
> CMA is just a way of providing large contiguous address space blocks in
> a dynamic fashion. ...
> 
> TTM though solves more advanced matters, like buffer synchronisation
> between 3D and 2D block of hardware ...
> 
> IMHO the best solution would be to use CMA as a flexible replacement of
> the static carveout area and put TTM on top of this ...

Ah right, thanks for the explanation. That makes sense to me now.

Re: Tegra DRM device tree bindings

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 1134 bytes --]

On Thu, Jun 28, 2012 at 11:33:56AM -0600, Stephen Warren wrote:
> On 06/28/2012 11:19 AM, Lucas Stach wrote:
> ...
> > CMA is just a way of providing large contiguous address space blocks in
> > a dynamic fashion. ...
> > 
> > TTM though solves more advanced matters, like buffer synchronisation
> > between 3D and 2D block of hardware ...
> > 
> > IMHO the best solution would be to use CMA as a flexible replacement of
> > the static carveout area and put TTM on top of this ...
> 
> Ah right, thanks for the explanation. That makes sense to me now.

Okay. I think that resolves the last open issue. I'll try to get some
more work done on the DT and corresponding code soonish.

For those who don't know yet I've requested the creation of a project
on freedesktop.org for Tegra graphics drivers[0]. I plan to have the DRM
code hosted there once the project has been approved. Furthermore if we
ever get to write a corresponding X driver it can be hosted there as
well. We should also use the wiki for coordination once things get
started.

Thierry

[0]: https://bugs.freedesktop.org/show_bug.cgi?id=51505

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 190 bytes --]

_______________________________________________
iommu mailing list
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

RE: Tegra DRM device tree bindings

[Mark Zhang]

> Am Donnerstag, den 28.06.2012, 10:51 -0600 schrieb Stephen Warren:
> > On 06/28/2012 05:12 AM, Thierry Reding wrote:
> > > On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
> > >> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> > ...
> > >>> In the ideal case I would want to not have a carveout size at all.
> > >>> However there may be situations where you need to make sure some
> > >>> driver can allocate a given amount of memory. Having to specify
> > >>> this using a kernel command-line parameter is cumbersome because
> > >>> it may require changes to the bootloader or whatever. So if you
> > >>> know that a particular board always needs
> > >>> 128 MiB of carveout, then it makes sense to specify it on a
> > >>> per-board basis.
> > >>
> > >> If we go with CMA, this is a non-issue, as CMA allows to use the
> > >> contig area for normal allocations and only purges them if it
> > >> really needs the space for contig allocs.
> > >
> > > CMA certainly sounds like the most simple approach. While it may not
> > > be suited for 3D graphics or multimedia processing later on, I think
> > > we could use it at a starting point to get basic framebuffer and X
> > > support up and running. We can always move to something more
> > > advanced like TTM later.
> >
> > I thought the whole purpose of CMA was to act as the infra-structure
> > to provide buffers to 3D, camera, etc. in particular allowing sharing
> > of buffers between them. In other words, isn't CMA the memory manager?
> > If there's some deficiency with CMA for 3D graphics, it seems like
> > that should be raised with those designing CMA. Or, am I way off base
> > with my expectations of CMA?
> >
> CMA is just a way of providing large contiguous address space blocks in a dynamic
> fashion. The problem CMA solves is: we have a system with relatively low
> amounts of sysmem (like 512MB), now to ensure we can always get large
> contiguous buffers for use by GPU or VIDEO blocks, we need to set aside a
> relatively large contiguous pool (like 128MB). So we are stealing 128MB of
> memory from the system while we may or may not use it, which is bad.
> Now CMA allows to say: I may need 128MB of contig space, but the system is free
> to use it as normal memory as long as I don't really need it. If the space is really
> needed, CMA purges pages from the area and may even swap them out. So yes
> CMA is a memory allocator for contig memory.
> 
> TTM though solves more advanced matters, like buffer synchronisation between
> 3D and 2D block of hardware or syncing buffer access between GPU and CPU.
> One of the most interesting things of TTM is the ability to purge the GPU DMA
> buffers to scattered sysmem or even swap them out, if they are not currently
> used by the GPU. It then makes sure to move them in the contig space again
> when the GPU really needs them and fix up the GPU command stream with the
> new buffer address.
> 
> IMHO the best solution would be to use CMA as a flexible replacement of the
> static carveout area and put TTM on top of this to solve the needs of graphics
> drivers. We certainly don't want to reinvent the wheel inside CMA. We have
> solutions for all those things in the kernel right now, we just have to glue them
> together in a sane way.
> 

That is a great explanation. So could you explain what's the relation between IOMMU api 
and TTM(or GEM)? 
Terje said DMABUF api sits on top of IOMMU api. So for normal device drivers(such as drm), 
can forget iommu apis, just use dmabuf api is OK. If so, I wanna know does 
TTM/GEM and IOMMU are related? Or TTM/GEM uses dmabuf apis which calls iommu api 
to do memory allocation/mapping?


> Thanks,
> Lucas
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body
> of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

RE: Tegra DRM device tree bindings

[Mark Zhang]

> > Am Donnerstag, den 28.06.2012, 10:51 -0600 schrieb Stephen Warren:
> > > On 06/28/2012 05:12 AM, Thierry Reding wrote:
> > > > On Wed, Jun 27, 2012 at 05:59:55PM +0200, Lucas Stach wrote:
> > > >> Am Mittwoch, den 27.06.2012, 16:44 +0200 schrieb Thierry Reding:
> > > ...
> > > >>> In the ideal case I would want to not have a carveout size at all.
> > > >>> However there may be situations where you need to make sure some
> > > >>> driver can allocate a given amount of memory. Having to specify
> > > >>> this using a kernel command-line parameter is cumbersome because
> > > >>> it may require changes to the bootloader or whatever. So if you
> > > >>> know that a particular board always needs
> > > >>> 128 MiB of carveout, then it makes sense to specify it on a
> > > >>> per-board basis.
> > > >>
> > > >> If we go with CMA, this is a non-issue, as CMA allows to use the
> > > >> contig area for normal allocations and only purges them if it
> > > >> really needs the space for contig allocs.
> > > >
> > > > CMA certainly sounds like the most simple approach. While it may
> > > > not be suited for 3D graphics or multimedia processing later on, I
> > > > think we could use it at a starting point to get basic framebuffer
> > > > and X support up and running. We can always move to something more
> > > > advanced like TTM later.
> > >
> > > I thought the whole purpose of CMA was to act as the infra-structure
> > > to provide buffers to 3D, camera, etc. in particular allowing
> > > sharing of buffers between them. In other words, isn't CMA the memory
> manager?
> > > If there's some deficiency with CMA for 3D graphics, it seems like
> > > that should be raised with those designing CMA. Or, am I way off
> > > base with my expectations of CMA?
> > >
> > CMA is just a way of providing large contiguous address space blocks
> > in a dynamic fashion. The problem CMA solves is: we have a system with
> > relatively low amounts of sysmem (like 512MB), now to ensure we can
> > always get large contiguous buffers for use by GPU or VIDEO blocks, we
> > need to set aside a relatively large contiguous pool (like 128MB). So
> > we are stealing 128MB of memory from the system while we may or may not
> use it, which is bad.
> > Now CMA allows to say: I may need 128MB of contig space, but the
> > system is free to use it as normal memory as long as I don't really
> > need it. If the space is really needed, CMA purges pages from the area
> > and may even swap them out. So yes CMA is a memory allocator for contig
> memory.
> >
> > TTM though solves more advanced matters, like buffer synchronisation
> > between 3D and 2D block of hardware or syncing buffer access between GPU
> and CPU.
> > One of the most interesting things of TTM is the ability to purge the
> > GPU DMA buffers to scattered sysmem or even swap them out, if they are
> > not currently used by the GPU. It then makes sure to move them in the
> > contig space again when the GPU really needs them and fix up the GPU
> > command stream with the new buffer address.
> >
> > IMHO the best solution would be to use CMA as a flexible replacement
> > of the static carveout area and put TTM on top of this to solve the
> > needs of graphics drivers. We certainly don't want to reinvent the
> > wheel inside CMA. We have solutions for all those things in the kernel
> > right now, we just have to glue them together in a sane way.
> >
> 
> That is a great explanation. So could you explain what's the relation between
> IOMMU api and TTM(or GEM)?
> Terje said DMABUF api sits on top of IOMMU api. So for normal device
> drivers(such as drm), can forget iommu apis, just use dmabuf api is OK. If so, I
> wanna know does TTM/GEM and IOMMU are related? Or TTM/GEM uses
> dmabuf apis which calls iommu api to do memory allocation/mapping?
>  

Sorry for my stupid question. DMA mapping api sits on top of IOMMU api, not DMABUF.
DMABUF is used to share buffers.
So please ignore what I said.

> > Thanks,
> > Lucas
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-tegra"
> > in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo
> > info at http://vger.kernel.org/majordomo-info.html

Re: Tegra DRM device tree bindings

[Terje Bergström]

On 28.06.2012 20:19, Lucas Stach wrote:
> TTM though solves more advanced matters, like buffer synchronisation
> between 3D and 2D block of hardware or syncing buffer access between GPU
> and CPU.
> One of the most interesting things of TTM is the ability to purge the
> GPU DMA buffers to scattered sysmem or even swap them out, if they are
> not currently used by the GPU. It then makes sure to move them in the
> contig space again when the GPU really needs them and fix up the GPU
> command stream with the new buffer address.

We preferably should choose dma_buf as a common interface towards
buffers. That way whatever we choose as the memory manager, all dma_buf
aware drivers will be able to use buffers allocated by other drivers.

We probably need to accommodate multiple memory managers to take care of
legacy and new drivers. If V4L2 and DRM projects all move to dma_buf, we
have the possibility to do zero-copy video without forcing everybody to
use the same memory manager.

As I understand, TTM is good for platforms where we have a separate
frame buffer memory, as is the case with most of the graphics cards. In
Tegra, graphics and CPU occupy the same memory, so I'm not sure if we
require the level of functionality that TTM provides. I guess the level
of functionality and the complexity that it brings is one reason why TTM
hasn't really caught on in the ARM world.

The synchronization primitives attached to TTM are slightly confusing.
At the bottom level, it's operations which need to be synchronized
between each other. That's the API level that we should to export from
kernel to user space. It's then up to libdrm level (or whatever is doing
the rendering in user space) to decide which operations it wants to have
completed before a buffer can be reused/read/passed on to the next stage.

Anyway, if we hide the memory manager behind dma_buf, we're free to muck
around with multiple of them and see what works best.

Terje

Re: Tegra DRM device tree bindings

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 4276 bytes --]

On Wed, Jun 27, 2012 at 10:13:56AM +0200, Lucas Stach wrote:
> Hi all,
> 
> I'm not sure what your exact plans are for the direction in which the
> DRM driver should head, as I'm still a bit out of the loop as many of
> those matters were only discussed internally at NVIDIA or with some NDA
> developers. But I'll still try to get into the discussion.
> 
> Am Mittwoch, den 27.06.2012, 07:14 +0200 schrieb Thierry Reding:
> > On Tue, Jun 26, 2012 at 08:48:18PM -0600, Stephen Warren wrote:
> > > On 06/26/2012 08:32 PM, Mark Zhang wrote:
> > > >> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > > >>>>> On Tue, 26 Jun 2012 12:55:13 +0200
> > > >>>>> Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > > >> ...
> > > >>>> I'm not sure I understand how information about the carveout would be
> > > >>>> obtained from the IOMMU API, though.
> > > >>>
> > > >>> I think that can be similar with current gart implementation. Define carveout as:
> > > >>>
> > > >>> carveout {
> > > >>>         compatible = "nvidia,tegra20-carveout";
> > > >>>         size = <0x10000000>;
> > > >>> };
> > > >>>
> > > >>> Then create a file such like "tegra-carveout.c" to get these definitions and
> > > >> register itself as platform device's iommu instance.
> > > >>
> > > >> The carveout isn't a HW object, so it doesn't seem appropriate to define a DT
> > > >> node to represent it.
> > > > 
> > > > Yes. But I think it's better to export the size of carveout as a configurable item.
> > > > So we need to define this somewhere. How about define carveout as a property of gart?
> > > 
> > > There already exists a way of preventing Linux from using certain chunks
> > > of memory; the /memreserve/ syntax. From a brief look at the dtc source,
> > > it looks like /memreserve/ entries can have labels, which implies that a
> > > property in the GART node could refer to the /memreserve/ entry by
> > > phandle in order to know what memory regions to use.
> > 
> > Wasn't the whole point of using a carveout supposed to be a replacement
> > for the GART? As such I'd think the carveout should rather be a property
> > of the host1x device.
> > 
> In my understanding carveout is neither a hardware nor software
> component. It's just a somewhat special pool of memory. As I pointed out
> in one of the older mails, carveout can not completely replace GART.
> While normal allocations for graphics use should be done contiguous,
> GART allows us to link normal scattered sysram buffers into GPU address
> space, which is a nice thing to have.

Do you agree that this will likely not be a problem with a more or less
stupid framebuffer DRM driver? I recall you mention that in a 3D context
where the scattered buffers are for example geometry provided by OpenGL,
right?

I think we need to put some thoughts into that once we start to
implement more advanced features. At that point we may also want to
think about how to integrate that with TTM.

> IMHO if carveout is to be used exclusively by the GPU (i.e. the DRM
> driver) it should be a property of the host1x device.
> 
> > AIUI what we want to do is have a large contiguous region of memory that
> > a central component (host1x) manages as a pool from which clients (DRM,
> > V4L, ...) can allocate buffers as needed. Since all of this memory will
> > be contiguous anyway there isn't much use for the GART anymore.
> > 
> I think this is the wrong way to go. Having a special memory pool
> managed by some driver adds one more allocator to the kernel, which is
> clearly not desirable. If we want a special mem region for GPU use, we
> should not share this memory pool with other components.
> 
> But if we want a mem region for contig allocations used by many
> components, which seems to be consensus here, CMA is the way to go. In
> this case I think we don't want to bother with the carveout property at
> all at the DRM driver level. Such a shared mem region managed by CMA
> should be defined at a higher level of the device tree.

Okay, this pretty much matches what we've agreed on in another
subthread. CMA looks like the best option for now as it should
cover everything we need at present.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

Re: Tegra DRM device tree bindings

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 2467 bytes --]

On Fri, Jun 29, 2012 at 04:20:31PM +0300, Terje Bergström wrote:
> On 28.06.2012 20:19, Lucas Stach wrote:
> > TTM though solves more advanced matters, like buffer synchronisation
> > between 3D and 2D block of hardware or syncing buffer access between GPU
> > and CPU.
> > One of the most interesting things of TTM is the ability to purge the
> > GPU DMA buffers to scattered sysmem or even swap them out, if they are
> > not currently used by the GPU. It then makes sure to move them in the
> > contig space again when the GPU really needs them and fix up the GPU
> > command stream with the new buffer address.
> 
> We preferably should choose dma_buf as a common interface towards
> buffers. That way whatever we choose as the memory manager, all dma_buf
> aware drivers will be able to use buffers allocated by other drivers.
> 
> We probably need to accommodate multiple memory managers to take care of
> legacy and new drivers. If V4L2 and DRM projects all move to dma_buf, we
> have the possibility to do zero-copy video without forcing everybody to
> use the same memory manager.

I agree. Supporting DMA BUF also doesn't seem very difficult.

> As I understand, TTM is good for platforms where we have a separate
> frame buffer memory, as is the case with most of the graphics cards. In
> Tegra, graphics and CPU occupy the same memory, so I'm not sure if we
> require the level of functionality that TTM provides. I guess the level
> of functionality and the complexity that it brings is one reason why TTM
> hasn't really caught on in the ARM world.
> 
> The synchronization primitives attached to TTM are slightly confusing.
> At the bottom level, it's operations which need to be synchronized
> between each other. That's the API level that we should to export from
> kernel to user space. It's then up to libdrm level (or whatever is doing
> the rendering in user space) to decide which operations it wants to have
> completed before a buffer can be reused/read/passed on to the next stage.
> 
> Anyway, if we hide the memory manager behind dma_buf, we're free to muck
> around with multiple of them and see what works best.

Exactly. Other subthreads echo this as well. Using CMA seems the easiest
and most flexible for now but still covers everything we need. If it
turns out that it isn't suited for more advanced stuff once we start
supporting 3D then we can still opt for something like TTM.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 190 bytes --]

_______________________________________________
iommu mailing list
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: Tegra DRM device tree bindings

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 1958 bytes --]

On Thu, Jun 28, 2012 at 10:46:58AM -0600, Stephen Warren wrote:
> On 06/28/2012 12:18 AM, Hiroshi Doyu wrote:
> > On Wed, 27 Jun 2012 16:44:14 +0200
> > Thierry Reding <thierry.reding-RM9K5IK7kjKj5M59NBduVrNAH6kLmebB@public.gmane.org> wrote:
> > 
> >>> I think that "coherent_pool" can be used only when the amount of
> >>> contiguous memory is short in your system. Otherwise even unnecessary.
> >>>
> >>> Could you explain a bit more why you want carveout size on per-board basis?
> >>
> >> In the ideal case I would want to not have a carveout size at all.
> >> However there may be situations where you need to make sure some driver
> >> can allocate a given amount of memory. Having to specify this using a
> >> kernel command-line parameter is cumbersome because it may require
> >> changes to the bootloader or whatever. So if you know that a particular
> >> board always needs 128 MiB of carveout, then it makes sense to specify
> >> it on a per-board basis.
> > 
> > Hm...I could understand somewhat;) but DT can also specify "bootargs"
> > in dts file, which can support per-board-wide spec too, like the above
> > sum of carveout needed from all drivers. I just want to avoid
> > introducing a new parameter additionaly if we can make use of the
> > existing mechanism.
> 
> The bootargs in the DT file is usually provided by (over-written by) the
> bootloader. If we start requiring lots of random kernel command-line
> arguments, that makes it more effort for the user of the bootloader
> (e.g. distribution bootloader scripts, etc.) to create the kernel
> command-line. I'd prefer to avoid that as much as possible. That said,
> using a standardized command-line option that is (or will be) used by
> all (ARM?) SoCs for the same purpose is reasonable, because there's
> commonality there.

I propose we stick with the default CMA settings for now and see where
we end up. No need to jump the gun.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 190 bytes --]

_______________________________________________
iommu mailing list
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: Tegra DRM device tree bindings

[Lucas Stach]

Am Freitag, den 29.06.2012, 16:20 +0300 schrieb Terje Bergström:
> On 28.06.2012 20:19, Lucas Stach wrote:
> > TTM though solves more advanced matters, like buffer synchronisation
> > between 3D and 2D block of hardware or syncing buffer access between GPU
> > and CPU.
> > One of the most interesting things of TTM is the ability to purge the
> > GPU DMA buffers to scattered sysmem or even swap them out, if they are
> > not currently used by the GPU. It then makes sure to move them in the
> > contig space again when the GPU really needs them and fix up the GPU
> > command stream with the new buffer address.
> 
> We preferably should choose dma_buf as a common interface towards
> buffers. That way whatever we choose as the memory manager, all dma_buf
> aware drivers will be able to use buffers allocated by other drivers.
> 
> We probably need to accommodate multiple memory managers to take care of
> legacy and new drivers. If V4L2 and DRM projects all move to dma_buf, we
> have the possibility to do zero-copy video without forcing everybody to
> use the same memory manager.
> 
> As I understand, TTM is good for platforms where we have a separate
> frame buffer memory, as is the case with most of the graphics cards. In
> Tegra, graphics and CPU occupy the same memory, so I'm not sure if we
> require the level of functionality that TTM provides. I guess the level
> of functionality and the complexity that it brings is one reason why TTM
> hasn't really caught on in the ARM world.
> 
I understand that TTM looks like a big complex beast at first sight, but
trying to understand how it works avoids reinventing the wheel over and
over again. We still have to solve problems like cache invalidation,
synchronization and swap-out of dma buffers, which is a lot easier if we
go with a common framework. 

> The synchronization primitives attached to TTM are slightly confusing.
> At the bottom level, it's operations which need to be synchronized
> between each other. That's the API level that we should to export from
> kernel to user space. It's then up to libdrm level (or whatever is doing
> the rendering in user space) to decide which operations it wants to have
> completed before a buffer can be reused/read/passed on to the next stage.
> 
That's exactly the level we are providing to userspace from other
drivers using TTM like radeon or nouveau.

> Anyway, if we hide the memory manager behind dma_buf, we're free to muck
> around with multiple of them and see what works best.
> 
dma_buf at the current level is only a way to share buffers and does not
provide enough information about the buffer to be useful as an
abstraction level on top of multiple memory managers. But I agree that
we should try to get dma_buf integration right from the start, as the
zero-copy share a very useful thing to have.

Lucas

Re: Tegra DRM device tree bindings

[Lucas Stach]

Am Samstag, den 30.06.2012, 20:01 +0200 schrieb Thierry Reding:
> On Fri, Jun 29, 2012 at 04:20:31PM +0300, Terje Bergström wrote:
> > On 28.06.2012 20:19, Lucas Stach wrote:
> > > TTM though solves more advanced matters, like buffer synchronisation
> > > between 3D and 2D block of hardware or syncing buffer access between GPU
> > > and CPU.
> > > One of the most interesting things of TTM is the ability to purge the
> > > GPU DMA buffers to scattered sysmem or even swap them out, if they are
> > > not currently used by the GPU. It then makes sure to move them in the
> > > contig space again when the GPU really needs them and fix up the GPU
> > > command stream with the new buffer address.
> > 
> > We preferably should choose dma_buf as a common interface towards
> > buffers. That way whatever we choose as the memory manager, all dma_buf
> > aware drivers will be able to use buffers allocated by other drivers.
> > 
> > We probably need to accommodate multiple memory managers to take care of
> > legacy and new drivers. If V4L2 and DRM projects all move to dma_buf, we
> > have the possibility to do zero-copy video without forcing everybody to
> > use the same memory manager.
> 
> I agree. Supporting DMA BUF also doesn't seem very difficult.
> 
> > As I understand, TTM is good for platforms where we have a separate
> > frame buffer memory, as is the case with most of the graphics cards. In
> > Tegra, graphics and CPU occupy the same memory, so I'm not sure if we
> > require the level of functionality that TTM provides. I guess the level
> > of functionality and the complexity that it brings is one reason why TTM
> > hasn't really caught on in the ARM world.
> > 
> > The synchronization primitives attached to TTM are slightly confusing.
> > At the bottom level, it's operations which need to be synchronized
> > between each other. That's the API level that we should to export from
> > kernel to user space. It's then up to libdrm level (or whatever is doing
> > the rendering in user space) to decide which operations it wants to have
> > completed before a buffer can be reused/read/passed on to the next stage.
> > 
> > Anyway, if we hide the memory manager behind dma_buf, we're free to muck
> > around with multiple of them and see what works best.
> 
> Exactly. Other subthreads echo this as well. Using CMA seems the easiest
> and most flexible for now but still covers everything we need. If it
> turns out that it isn't suited for more advanced stuff once we start
> supporting 3D then we can still opt for something like TTM.
> 
As working code is the primary goal, I would say go for it. I still
think TTM is the way to go, even for simple things like a DRM
framebuffer driver, but as CMA and TTM won't collide in their goals it
should be easy to put TTM in there after we have something going with
CMA.

Lucas

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu