On Fri, Jul 06, 2012 at 01:59:13PM -0600, Stephen Warren wrote:
> On 07/05/2012 06:15 AM, Thierry Reding wrote:
> > Here's a new proposal that should address all issues collected
> > during the discussion of the previous one:
> >
> > From tegra20.dtsi:
> ...
>
> At a quick glance, that all seems
On Fri, Jul 06, 2012 at 01:59:13PM -0600, Stephen Warren wrote:
On 07/05/2012 06:15 AM, Thierry Reding wrote:
Here's a new proposal that should address all issues collected
during the discussion of the previous one:
From tegra20.dtsi:
...
At a quick glance, that all seems pretty
On 07/05/2012 06:15 AM, Thierry Reding wrote:
> Here's a new proposal that should address all issues collected
> during the discussion of the previous one:
>
> From tegra20.dtsi:
...
At a quick glance, that all seems pretty reasonable now.
> One problem I've come across when trying to get some
g
> Subject: Re: Tegra DRM device tree bindings
>
> * PGP Signed by an unknown key
>
> Here's a new proposal that should address all issues collected during the
> discussion of the previous one:
>
> From tegra20.dtsi:
>
> host1x {
> c
On 07/05/2012 06:15 AM, Thierry Reding wrote:
Here's a new proposal that should address all issues collected
during the discussion of the previous one:
From tegra20.dtsi:
...
At a quick glance, that all seems pretty reasonable now.
One problem I've come across when trying to get some
Here's a new proposal that should address all issues collected during
the discussion of the previous one:
Here's a new proposal that should address all issues collected during
the discussion of the previous one:
From tegra20.dtsi:
host1x {
compatible = nvidia,tegra20-host1x, simple-bus;
reg = 0x5000 0x00024000;
interrupts = 0 65 0x04 /*
From: linux-tegra-ow...@vger.kernel.org [mailto:linux-tegra-
ow...@vger.kernel.org] On Behalf Of Thierry Reding
Sent: Thursday, July 05, 2012 8:15 PM
To: linux-te...@vger.kernel.org
Cc: devicetree-disc...@lists.ozlabs.org; dri-devel@lists.freedesktop.org
Subject: Re: Tegra DRM device tree
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
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
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
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
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 wrote:
> >
> >>> I think that "coherent_pool" can be used only when the amount of
> >>> contiguous memory is short in your
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
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
>
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
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
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.red...@avionic-design.de wrote:
I think that coherent_pool can be used only when the amount of
contiguous memory is
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
> > 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
> 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
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
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
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
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
>
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
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
On Wed, Jun 27, 2012 at 11:49:43AM -0600, Stephen Warren wrote:
> On 06/26/2012 11:07 PM, Thierry Reding wrote:
> > On Tue, Jun 26, 2012 at 04:48:14PM -0600, Stephen Warren wrote:
> ...
> > I actually like what you proposed above a lot, so if you don't
> > mind either way I'll go with that
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),
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 wrote:
> > >
> > > > * PGP Signed by an
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
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
On 06/28/2012 12:18 AM, Hiroshi Doyu wrote:
> On Wed, 27 Jun 2012 16:44:14 +0200
> Thierry Reding 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
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 wrote:
>
> > > > > > Rather than introducing a new property, how about using
> > > > > > "coherent_pool=??M" in the kernel command line if necessary? I think
> > > >
On Wed, 27 Jun 2012 20:02:46 +0200
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
On Wed, 27 Jun 2012 19:56:35 +0200
Stephen Warren 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.
On Wed, 27 Jun 2012 16:44:14 +0200
Thierry Reding 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
Hi Lucas,
On Wed, 27 Jun 2012 17:59:55 +0200
Lucas Stach 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
On 06/26/2012 11:07 PM, Thierry Reding wrote:
On Tue, Jun 26, 2012 at 04:48:14PM -0600, Stephen Warren wrote:
...
I actually like what you proposed above a lot, so if you don't
mind either way I'll go with that proposal. Keeping the connector
nodes as children of the outputs has the advantage
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
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
Hi Lucas,
On Wed, 27 Jun 2012 17:59:55 +0200
Lucas Stach d...@lynxeye.de 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
On Wed, 27 Jun 2012 16:44:14 +0200
Thierry Reding thierry.red...@avionic-design.de 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
On Wed, 27 Jun 2012 19:56:35 +0200
Stephen Warren swar...@wwwdotorg.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
On Wed, 27 Jun 2012 20:02:46 +0200
Stephen Warren swar...@wwwdotorg.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),
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.red...@avionic-design.de wrote:
*
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
On Wed, Jun 27, 2012 at 11:49:43AM -0600, Stephen Warren wrote:
On 06/26/2012 11:07 PM, Thierry Reding wrote:
On Tue, Jun 26, 2012 at 04:48:14PM -0600, Stephen Warren wrote:
...
I actually like what you proposed above a lot, so if you don't
mind either way I'll go with that proposal.
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
On 06/28/2012 12:18 AM, Hiroshi Doyu wrote:
On Wed, 27 Jun 2012 16:44:14 +0200
Thierry Reding thierry.red...@avionic-design.de 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
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
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
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
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
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
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 d...@lynxeye.de wrote:
Rather than introducing a new property, how about using
coherent_pool=??M in the kernel command line if necessary? I think
that
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 wrote:
> >
> > > * PGP Signed by an unknown key
> > >
> > > On Wed, Jun 27, 2012 at 03:59:07PM +0300,
On Wed, 27 Jun 2012 16:08:10 +0200
Thierry Reding 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 wrote:
> >
> > > > Old Signed by an unknown key
> > >
> > > On Tue, Jun 26,
On Wed, Jun 27, 2012 at 05:29:14PM +0300, Hiroshi Doyu wrote:
> On Wed, 27 Jun 2012 16:08:10 +0200
> Thierry Reding 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
On Wed, Jun 27, 2012 at 03:59:07PM +0300, Hiroshi Doyu wrote:
> On Wed, 27 Jun 2012 07:14:18 +0200
> Thierry Reding 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
On Wed, 27 Jun 2012 07:14:18 +0200
Thierry Reding 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
On Wed, 27 Jun 2012 04:48:18 +0200
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 wrote:
> >> ...
> I'm not sure I understand how information about the
On Wed, 27 Jun 2012 04:32:07 +0200
Mark Zhang wrote:
> > On 06/26/2012 07:46 PM, Mark Zhang wrote:
> > >>> On Tue, 26 Jun 2012 12:55:13 +0200
> > >>> Thierry Reding wrote:
> > ...
> > >> I'm not sure I understand how information about the carveout would be
> > >> obtained from the IOMMU API,
On Tue, 26 Jun 2012 16:00:33 +0200
Thierry Reding 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 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
> > > wrote:
> > >> ...
> > I'm not sure I understand how
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,
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
On 06/26/2012 11:07 PM, Thierry Reding wrote:
> On Tue, Jun 26, 2012 at 04:48:14PM -0600, Stephen Warren wrote:
...
> I actually like what you proposed above a lot, so if you don't
> mind either way I'll go with that proposal. Keeping the connector
> nodes as children of the outputs has the
> On 06/26/2012 07:46 PM, Mark Zhang wrote:
> >>> On Tue, 26 Jun 2012 12:55:13 +0200
> >>> Thierry Reding 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
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
> > On Tue, 26 Jun 2012 12:55:13 +0200
> > Thierry Reding 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
On 26.06.2012 20:46, Stephen Warren wrote:
> I'd certainly like to see some upstream discussion re: why exactly we
> have a custom bus type here. What does it do that a regular platform bus
> doesn't do? Are those features something that would be generally useful
> to add to the existing platform
On Wed, Jun 27, 2012 at 09:13:52AM +0300, Terje Bergstr?m wrote:
> On 26.06.2012 20:46, Stephen Warren wrote:
>
> > I'd certainly like to see some upstream discussion re: why exactly we
> > have a custom bus type here. What does it do that a regular platform bus
> > doesn't do? Are those features
On 26.06.2012 22:31, Thierry Reding wrote:
> Okay, I see. Does the same apply to the COP interrupts of the host1x
> node in your opinion? I don't know if it makes sense to describe
> something that's not reachable from the CPU. Yet it is defined in the
> GIC.
Hi,
I wasn't sure so I had to
On 26.06.2012 22:38, Stephen Warren wrote:
> I would assume this can safely be inferred from the compatible value;
> nvidia,tegra20-host1x v.s. nvidia,tegra30-host1x, and so there's no
> need to represent this in DT. I would assume (and it's certainly just
> an assumption) that there are numerous
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 wrote:
> >> ...
> I'm not sure I understand how information about the
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 wrote:
> >> ...
> I'm not sure I understand how information about the
On Tue, Jun 26, 2012 at 04:48:14PM -0600, Stephen Warren wrote:
> On 06/26/2012 01:51 PM, Thierry Reding wrote:
> > On Tue, Jun 26, 2012 at 12:10:42PM -0600, Stephen Warren wrote:
> >> On 06/26/2012 04:55 AM, Thierry Reding wrote:
> >>> Hi,
> >>>
> >>> while I haven't got much time to work on the
On 06/26/2012 01:51 PM, Thierry Reding wrote:
On Tue, Jun 26, 2012 at 12:10:42PM -0600, Stephen Warren wrote:
On 06/26/2012 04:55 AM, Thierry Reding wrote:
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
On 06/26/2012 07:46 PM, Mark Zhang wrote:
On Tue, 26 Jun 2012 12:55:13 +0200
Thierry Reding thierry.red...@avionic-design.de 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
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.red...@avionic-design.de wrote:
...
I'm not sure I understand how information about the carveout would be
obtained from the IOMMU API, though.
I
On 26.06.2012 22:38, Stephen Warren wrote:
I would assume this can safely be inferred from the compatible value;
nvidia,tegra20-host1x v.s. nvidia,tegra30-host1x, and so there's no
need to represent this in DT. I would assume (and it's certainly just
an assumption) that there are numerous
On 26.06.2012 22:31, Thierry Reding wrote:
Okay, I see. Does the same apply to the COP interrupts of the host1x
node in your opinion? I don't know if it makes sense to describe
something that's not reachable from the CPU. Yet it is defined in the
GIC.
Hi,
I wasn't sure so I had to check
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.red...@avionic-design.de wrote:
...
I'm not sure I understand how information
On 26.06.2012 20:46, Stephen Warren wrote:
I'd certainly like to see some upstream discussion re: why exactly we
have a custom bus type here. What does it do that a regular platform bus
doesn't do? Are those features something that would be generally useful
to add to the existing platform
On Wed, Jun 27, 2012 at 09:13:52AM +0300, Terje Bergström wrote:
On 26.06.2012 20:46, Stephen Warren wrote:
I'd certainly like to see some upstream discussion re: why exactly we
have a custom bus type here. What does it do that a regular platform bus
doesn't do? Are those features
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.red...@avionic-design.de 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
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.red...@avionic-design.de 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
On Tue, 26 Jun 2012 16:00:33 +0200
Thierry Reding thierry.red...@avionic-design.de 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.red...@avionic-design.de wrote:
On Wed, 27 Jun 2012 04:32:07 +0200
Mark Zhang ma...@nvidia.com wrote:
On 06/26/2012 07:46 PM, Mark Zhang wrote:
On Tue, 26 Jun 2012 12:55:13 +0200
Thierry Reding thierry.red...@avionic-design.de wrote:
...
I'm not sure I understand how information about the carveout would be
On Wed, 27 Jun 2012 04:48:18 +0200
Stephen Warren swar...@nvidia.com 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.red...@avionic-design.de wrote:
...
I'm not sure I understand how
On Wed, 27 Jun 2012 07:14:18 +0200
Thierry Reding thierry.red...@avionic-design.de 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
On Wed, 27 Jun 2012 16:08:10 +0200
Thierry Reding thierry.red...@avionic-design.de 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.red...@avionic-design.de wrote:
Old
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.red...@avionic-design.de wrote:
* PGP Signed by an unknown key
On Wed, Jun 27, 2012 at
On Tue, Jun 26, 2012 at 12:10:42PM -0600, Stephen Warren wrote:
> On 06/26/2012 04:55 AM, Thierry Reding wrote:
> > 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
On Tue, Jun 26, 2012 at 11:46:42AM -0600, Stephen Warren wrote:
> On 06/26/2012 07:01 AM, Terje Bergstr?m wrote:
> > On 26.06.2012 13:55, Thierry Reding wrote:
> ...
> >> An alternative would be to call of_platform_populate() from the host1x
>
> [alternative to making the host1x node contain
On Tue, Jun 26, 2012 at 11:43:38AM -0600, Stephen Warren wrote:
> On 06/26/2012 07:41 AM, Thierry Reding wrote:
> > On Tue, Jun 26, 2012 at 04:01:05PM +0300, Terje Bergstr?m wrote:
> >> On 26.06.2012 13:55, Thierry Reding wrote:
> ...
> >>> status = "disabled";
> >>>
> >>> gart = <>;
> >>>
> >>>
On Tue, Jun 26, 2012 at 11:41:43AM -0600, Stephen Warren wrote:
> On 06/26/2012 08:02 AM, Terje Bergstr?m wrote:
> > On 26.06.2012 16:41, Thierry Reding wrote:
> >
> >> On Tue, Jun 26, 2012 at 04:01:05PM +0300, Terje Bergstr?m wrote:
> >>> We also assign certain host1x common resources per device
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 wrote:
>> ...
I'm not sure I understand how information about the carveout would be
obtained from the IOMMU API, though.
>>>
>>> I think
On 06/26/2012 07:46 PM, Mark Zhang wrote:
>>> On Tue, 26 Jun 2012 12:55:13 +0200
>>> Thierry Reding 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
1 - 100 of 133 matches
Mail list logo
