On 23.05.2014 17:40, Alex Courbot wrote:
> On 05/23/2014 06:59 PM, Lucas Stach wrote:
> So after checking with more knowledgeable people, it turns out this is
> the expected behavior on ARM and BAR regions should be mapped uncached
> on GK20A. All the more reasons to avoid using the BAR at all.
On 01.05.2014 07:49, Alexandre Courbot wrote:
> Agreed. Besides I hope the day won't come where we have to go through
> 2 layers of memory translation for the GPU...
That's actually the method of operation that gives us the best
performance. GPU likes big pages, and without IOMMU translation
On 09.04.2014 15:39, Thierry Reding wrote:
> From: Thierry Reding
>
> The version of the drm_tegra_submit structure that was merged all the
> way back in 3.10 contains a pad field that was originally intended to
> properly pad the following __u64 field. Unfortunately it seems like a
> different
On 07.04.2014 11:41, Thierry Reding wrote:
> On Mon, Apr 07, 2014 at 11:34:22AM +0300, Terje Bergstr?m wrote:
>> On 07.04.2014 11:18, Thierry Reding wrote:
>>> If I understand correctly there's no immediate need for this to go to
>>> stable kernels, nor for it to be queued for 3.15, right? That is
On 07.04.2014 11:18, Thierry Reding wrote:
> If I understand correctly there's no immediate need for this to go to
> stable kernels, nor for it to be queued for 3.15, right? That is the
> potential extra write isn't causing any harm on actual hardware, is it?
>
> In that case I'll queue this up
On 05.04.2014 01:31, Stephen Warren wrote:
> From: Stephen Warren
>
> diff --git a/drivers/gpu/host1x/hw/intr_hw.c b/drivers/gpu/host1x/hw/intr_hw.c
> index db9017adfe2b..498b37e39058 100644
> --- a/drivers/gpu/host1x/hw/intr_hw.c
> +++ b/drivers/gpu/host1x/hw/intr_hw.c
> @@ -47,7 +47,7 @@
On 01.04.2014 23:10, Stephen Warren wrote:
> diff --git a/drivers/gpu/host1x/hw/intr_hw.c b/drivers/gpu/host1x/hw/intr_hw.c
> index db9017adfe2b..17407b2de2bf 100644
> --- a/drivers/gpu/host1x/hw/intr_hw.c
> +++ b/drivers/gpu/host1x/hw/intr_hw.c
> @@ -47,7 +47,7 @@ static irqreturn_t
On 07.01.2014 22:03, Erik Faye-Lund wrote:
> When patching gathers, we don't need to check against
> gathers with lower indices than the current one, as
> they are guaranteed to already have been handled.
>
> Signed-off-by: Erik Faye-Lund
> ---
>
> Here's a trivial optimization I have been
On 15.11.2013 22:53, Stephen Warren wrote:
> From: Stephen Warren
>
> This series implements a common reset framework driver for Tegra, and
> updates all relevant Tegra drivers to use it. It also removes the custom
> DMA bindings and replaced them with the standard DMA DT bindings.
>
>
On 14.10.2013 15:21, Arto Merilainen wrote:
> The host1x driver uses currently syncpoints statically from host1x point of
> view. If we do a wait inside a job, it always has a constant value to wait.
> host1x supports also doing relative syncpoint waits with respect to syncpoint
> bases. This
On 21.10.2013 08:38, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Add the missing clk_disable_unprepare() before return
> from gr2d_probe() in the error handling case.
>
> Signed-off-by: Wei Yongjun
> ---
> drivers/gpu/drm/tegra/gr2d.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git
On 21.10.2013 08:37, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Add the missing clk_disable_unprepare() before return
> from host1x_probe() in the error handling case.
>
> Signed-off-by: Wei Yongjun
> ---
> drivers/gpu/host1x/dev.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
On 16.10.2013 11:48, Thierry Reding wrote:
> On Tue, Oct 15, 2013 at 09:19:18AM -0600, Stephen Warren wrote:
>> Taking advantage of new functionality isn't the issue. The issue is
>> whether a driver that was written purely to the spec of Tegra20 can
>> successfully operate on the HW. If it can't,
On 14.10.2013 21:14, Stephen Warren wrote:
On 10/14/2013 08:00 AM, Thierry Reding wrote:
Yes, as long as the device tree files includes the most specific
value in the compatible this should still be possible. So we'd have
this:
gr2d@5414 { compatible = nvida,tegra114-gr2d,
On 12.10.2013 14:24, Thierry Reding wrote:
Yeah, I don't like very much how this is currently done. I mean about
half of this is actually duplicate code because of the static inline
functions used for register defines. As discussed elsewhere this was
originally meant to be used for coverage
On 12.10.2013 01:43, Stephen Warren wrote:
On 10/07/2013 02:34 AM, Thierry Reding wrote:
The gr2d hardware in Tegra114 is compatible with that of Tegra20 and
Tegra30. No functionaly changes are required.
Similarly here, if the HW is 100% backwards-compatible, there's no need
to add compatible
On 08.10.2013 09:27, Arto Merilainen wrote:
This series adds runtime pm support for host1x, gr2d and dc. It retains the
current behaviour if CONFIG_PM_RUNTIME is not enabled.
The gr2d clock is enabled when a new job is submitted and disabled when
the work is done. Due to parent-child
On 07.10.2013 11:34, Thierry Reding wrote:
Most of the included files are either not required or already included
by some other header file.
What's the general policy? I personally feel that each source file
should #include all the header files it needs, and should not rely on
header files
On 07.10.2013 11:34, Thierry Reding wrote:
The Tegra DRM driver currently uses some infrastructure to defer the DRM
core initialization until all required devices have registered. The same
infrastructure can potentially be used by any other driver that requires
more than a single sub-device of
On 04.10.2013 23:18, Erik Faye-Lund wrote:
The num_relocs count are passed to the kernel per job, not per gather.
For multi-gather jobs, we would previously fail if there were relocs in
other gathers aside from the first one.
Fix this by simply moving the check until all gathers have been
On 07.10.2013 15:14, Thierry Reding wrote:
* PGP Signed by an unknown key
On Mon, Oct 07, 2013 at 01:34:44PM +0200, Erik Faye-Lund wrote:
On Mon, Oct 7, 2013 at 10:34 AM, Thierry Reding
thierry.red...@gmail.com wrote:
Rework the address table code for the host1x firewall. The previous
On 07.10.2013 16:05, Erik Faye-Lund wrote:
On Mon, Oct 7, 2013 at 2:52 PM, Terje Bergström tbergst...@nvidia.com wrote:
AND 0xff is necessary, because the same registers are mirrored in
multiple contexts. AND removes the offset coming from context, and
leaves just the plain register offset
On 07.10.2013 16:02, Erik Faye-Lund wrote:
So the question is really how the hardware treats writes to
non-existent registers. My guess would be that they are simply not
recorded, and if that's the case it doesn't matter what we do. And
doing an unconditional AND is faster than doing a
On 28.08.2013 16:18, Thierry Reding wrote:
> I think that's not all. I have local patches that also introduce a v2 of
> host1x, because the number of syncpoints is different. There may also be
> other differences, but Terje might be more qualified to answer that.
Tegra4 host1x has an extra
On 28.08.2013 16:18, Thierry Reding wrote:
I think that's not all. I have local patches that also introduce a v2 of
host1x, because the number of syncpoints is different. There may also be
other differences, but Terje might be more qualified to answer that.
Tegra4 host1x has an extra
On 23.07.2013 21:01, Wolfram Sang wrote:
> diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
> index 01097da..9ffece6 100644
> --- a/drivers/gpu/host1x/drm/hdmi.c
> +++ b/drivers/gpu/host1x/drm/hdmi.c
> @@ -1248,9 +1248,6 @@ static int tegra_hdmi_probe(struct
On 23.07.2013 21:01, Wolfram Sang wrote:
diff --git a/drivers/gpu/host1x/drm/hdmi.c b/drivers/gpu/host1x/drm/hdmi.c
index 01097da..9ffece6 100644
--- a/drivers/gpu/host1x/drm/hdmi.c
+++ b/drivers/gpu/host1x/drm/hdmi.c
@@ -1248,9 +1248,6 @@ static int tegra_hdmi_probe(struct platform_device
On 11.06.2013 15:09, Daniel Vetter wrote:
> Maybe it wasn't clear, but -EAGAIN does _not_ resubmit work. -EAGAIN
> is used to restart the ioctl if we had to kick a thread (to make sure
> it doesn't hold any locks), e.g. for a blocking wait on oustanding
> rendering. The codepaths taken work
On 11.06.2013 15:09, Daniel Vetter wrote:
Maybe it wasn't clear, but -EAGAIN does _not_ resubmit work. -EAGAIN
is used to restart the ioctl if we had to kick a thread (to make sure
it doesn't hold any locks), e.g. for a blocking wait on oustanding
rendering. The codepaths taken work exactly as
On 11.06.2013 14:00, Daniel Vetter wrote:
> We don't use the EAGAIN ioctl restarting to resubmit the batchbuffer
> which blew up the gpu (that one has been submitted already in a
> different ioctl call), but to be able to restart the ioctl after the
> reset has completed: We need to kick every
On 10.06.2013 23:43, Thierry Reding wrote:
> Can you post the corresponding wrappers to make it easier to discuss
> them? If they just wrap runtime PM calls then they don't solve the
> locality problems that Terje brought up.
I don't think the wrappers are applicable here. They're there in
On 10.06.2013 23:43, Thierry Reding wrote:
Can you post the corresponding wrappers to make it easier to discuss
them? If they just wrap runtime PM calls then they don't solve the
locality problems that Terje brought up.
I don't think the wrappers are applicable here. They're there in
On 11.06.2013 14:00, Daniel Vetter wrote:
We don't use the EAGAIN ioctl restarting to resubmit the batchbuffer
which blew up the gpu (that one has been submitted already in a
different ioctl call), but to be able to restart the ioctl after the
reset has completed: We need to kick every thread
On 29.05.2013 13:26, Arto Merilainen wrote:
> This patch series fixes two issues in the host1x driver: First, the
> command buffer validation routine had vulnerabilities that were not
> detected in earlier testing. Second, the return codes of some
> functions were misleading or completely missing.
On 29.05.2013 13:26, Arto Merilainen wrote:
This patch series fixes two issues in the host1x driver: First, the
command buffer validation routine had vulnerabilities that were not
detected in earlier testing. Second, the return codes of some
functions were misleading or completely missing.
On 27.05.2013 18:45, Thierry Reding wrote:
> On Mon, May 27, 2013 at 07:19:28PM +0530, Mayuresh Kulkarni wrote:
>> +#ifdef CONFIG_PM_RUNTIME
>> +static int host1x_runtime_suspend(struct device *dev)
>> +{
>> +struct host1x *host;
>> +
>> +host = dev_get_drvdata(dev);
>> +if
On 27.05.2013 18:45, Thierry Reding wrote:
On Mon, May 27, 2013 at 07:19:28PM +0530, Mayuresh Kulkarni wrote:
+#ifdef CONFIG_PM_RUNTIME
+static int host1x_runtime_suspend(struct device *dev)
+{
+struct host1x *host;
+
+host = dev_get_drvdata(dev);
+if (IS_ERR_OR_NULL(host))
On 22.03.2013 16:54, Thierry Reding wrote:
> On Fri, Mar 22, 2013 at 04:34:00PM +0200, Terje Bergstrom wrote:
>> This set of patches adds support for Tegra20 and Tegra30 host1x and
>> 2D. It is based on linux-next-20130322 with RTC fixes applied.
(...)
> For the series:
>
> Reviewed-by: Thierry
On 22.03.2013 16:54, Thierry Reding wrote:
On Fri, Mar 22, 2013 at 04:34:00PM +0200, Terje Bergstrom wrote:
This set of patches adds support for Tegra20 and Tegra30 host1x and
2D. It is based on linux-next-20130322 with RTC fixes applied.
(...)
For the series:
Reviewed-by: Thierry Reding
On 15.03.2013 14:13, Thierry Reding wrote:
> Also you now create a lookup table (or bitfield actually) as we
> discussed but you still pass around a function to check the lookup table
> against. What I originally intended was to not pass a function around at
> all but directly use the lookup
On 15.03.2013 14:13, Thierry Reding wrote:
Also you now create a lookup table (or bitfield actually) as we
discussed but you still pass around a function to check the lookup table
against. What I originally intended was to not pass a function around at
all but directly use the lookup
On 15.03.2013 14:13, Thierry Reding wrote:
> On Wed, Mar 13, 2013 at 02:36:26PM +0200, Terje Bergstrom wrote:
> [...]
>> diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
> [...]
>> +static inline struct host1x_drm_context *tegra_drm_get_context(
>> +
On 15.03.2013 14:13, Thierry Reding wrote:
On Wed, Mar 13, 2013 at 02:36:26PM +0200, Terje Bergstrom wrote:
[...]
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
[...]
+static inline struct host1x_drm_context *tegra_drm_get_context(
+
On 11.03.2013 09:18, Thierry Reding wrote:
> This sound a bit over-engineered at this point in time. DRM is currently
> the only user. Is anybody working on any non-DRM drivers that would use
> this?
Well, this contains beginning of that:
On 08.03.2013 22:43, Thierry Reding wrote:
> A bo is just a buffer object, so I don't see why the name shouldn't
> be used. The name is in no way specific to DRM or GEM. But the point
> that I was trying to make was that there is nothing to suggest that
> we couldn't use drm_gem_object as the
On 08.03.2013 22:43, Thierry Reding wrote:
A bo is just a buffer object, so I don't see why the name shouldn't
be used. The name is in no way specific to DRM or GEM. But the point
that I was trying to make was that there is nothing to suggest that
we couldn't use drm_gem_object as the
On 11.03.2013 09:18, Thierry Reding wrote:
This sound a bit over-engineered at this point in time. DRM is currently
the only user. Is anybody working on any non-DRM drivers that would use
this?
Well, this contains beginning of that:
On 26.02.2013 11:48, Terje Bergstr?m wrote:
> On 25.02.2013 17:24, Thierry Reding wrote:
>> You use two different styles to indent the function parameters. You
>> might want to stick to one, preferably aligning them with the first
>> parameter on the first line.
>
> I've generally favored "two
On 26.02.2013 11:48, Terje Bergström wrote:
On 25.02.2013 17:24, Thierry Reding wrote:
You use two different styles to indent the function parameters. You
might want to stick to one, preferably aligning them with the first
parameter on the first line.
I've generally favored two tabs
On 25.02.2013 17:24, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Jan 15, 2013 at 01:43:59PM +0200, Terje Bergstrom wrote:
> [...]
>> diff --git a/drivers/gpu/host1x/Kconfig b/drivers/gpu/host1x/Kconfig
>> index e89fb2b..57680a6 100644
>> --- a/drivers/gpu/host1x/Kconfig
>>
On 11.02.2013 01:08, Thierry Reding wrote:
> Are the syncpoints incremented even if the VBLANK interrupts are turned
> off? If that's the case they could indeed be used as a hardware counter
> rather than the fake approach used right now.
>
> Maybe we should leave the code as it is right now and
On 10.02.2013 22:44, Thierry Reding wrote:
> On Sun, Feb 10, 2013 at 04:42:53PM -0800, Terje Bergstr?m wrote:
>> You're right about performance. We already saw quite a bad performance
>> hit with the current firewall, so we'll need to worry about performance
>> later.
>
> I guess the additional
On 10.02.2013 22:44, Thierry Reding wrote:
On Sun, Feb 10, 2013 at 04:42:53PM -0800, Terje Bergström wrote:
You're right about performance. We already saw quite a bad performance
hit with the current firewall, so we'll need to worry about performance
later.
I guess the additional overhead
On 07.02.2013 23:07, Thierry Reding wrote:
> On Wed, Feb 06, 2013 at 01:23:17PM -0800, Terje Bergstr?m wrote:
That's the security firewall. It walks through each submit, and ensures
that each register write that writes an address, goes through the host1x
reloc mechanism. This way
On 07.02.2013 23:07, Thierry Reding wrote:
On Wed, Feb 06, 2013 at 01:23:17PM -0800, Terje Bergström wrote:
That's the security firewall. It walks through each submit, and ensures
that each register write that writes an address, goes through the host1x
reloc mechanism. This way user space
On 05.02.2013 01:54, Thierry Reding wrote:
> On Mon, Feb 04, 2013 at 09:17:45PM -0800, Terje Bergstr?m wrote:
>> Yeah, it's actually working around the host1x duplicate naming.
>> host1x_syncpt_get takes struct host1x as parameter, but that's different
>> host1x than in this code.
>
> So maybe a
On 05.02.2013 01:15, Thierry Reding wrote:
> On Mon, Feb 04, 2013 at 08:41:25PM -0800, Terje Bergstr?m wrote:
>> This is used by debugfs code to direct to debugfs, and
>> nvhost_debug_dump() to send via printk.
>
> Yes, that was precisely my point. Why bother providing the same data via
> several
On 06.02.2013 12:38, Thierry Reding wrote:
> On Wed, Feb 06, 2013 at 12:29:26PM -0800, Terje Bergstr?m wrote:
>> This was done purely, because I'm hiding the struct size from the
>> caller. If the caller needs to allocate, I need to expose the struct in
>> a header, not just a forward declaration.
On 05.02.2013 00:42, Thierry Reding wrote:
> On Mon, Feb 04, 2013 at 08:29:08PM -0800, Terje Bergstr?m wrote:
>> host1x_get_host() actually needs that, so this #include should've also
>> been in previous patch.
>
> No need to if you pass struct device * instead. You might need
> linux/device.h
On 04.02.2013 23:43, Thierry Reding wrote:
> My point was that you could include the call to host1x_syncpt_reset()
> within host1x_syncpt_init(). That will keep unneeded code out of the
> host1x_probe() function. Also you don't want to use the syncpoints
> uninitialized, right?
Of course, sorry,
On 04.02.2013 23:43, Thierry Reding wrote:
My point was that you could include the call to host1x_syncpt_reset()
within host1x_syncpt_init(). That will keep unneeded code out of the
host1x_probe() function. Also you don't want to use the syncpoints
uninitialized, right?
Of course, sorry, I
On 05.02.2013 00:42, Thierry Reding wrote:
On Mon, Feb 04, 2013 at 08:29:08PM -0800, Terje Bergström wrote:
host1x_get_host() actually needs that, so this #include should've also
been in previous patch.
No need to if you pass struct device * instead. You might need
linux/device.h instead
On 06.02.2013 12:38, Thierry Reding wrote:
On Wed, Feb 06, 2013 at 12:29:26PM -0800, Terje Bergström wrote:
This was done purely, because I'm hiding the struct size from the
caller. If the caller needs to allocate, I need to expose the struct in
a header, not just a forward declaration.
I
On 05.02.2013 01:15, Thierry Reding wrote:
On Mon, Feb 04, 2013 at 08:41:25PM -0800, Terje Bergström wrote:
This is used by debugfs code to direct to debugfs, and
nvhost_debug_dump() to send via printk.
Yes, that was precisely my point. Why bother providing the same data via
several output
On 05.02.2013 01:54, Thierry Reding wrote:
On Mon, Feb 04, 2013 at 09:17:45PM -0800, Terje Bergström wrote:
Yeah, it's actually working around the host1x duplicate naming.
host1x_syncpt_get takes struct host1x as parameter, but that's different
host1x than in this code.
So maybe a better
On 04.02.2013 04:56, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Jan 15, 2013 at 01:44:04PM +0200, Terje Bergstrom wrote:
> [...]
>> diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
>> @@ -270,7 +274,29 @@ static int tegra_drm_unload(struct
On 04.02.2013 03:26, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Jan 15, 2013 at 01:44:03PM +0200, Terje Bergstrom wrote:
>> Add a driver alias gr2d for Tegra 2D device, and assign a duplicate
>> of 2D clock to that driver alias.
>>
>> Signed-off-by: Terje Bergstrom
>> ---
On 04.02.2013 03:08, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Jan 15, 2013 at 01:44:01PM +0200, Terje Bergstrom wrote:
> [...]
>> diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
>> index 697d49a..ffc8bf1 100644
>> --- a/drivers/gpu/host1x/Makefile
On 04.02.2013 03:03, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Jan 15, 2013 at 01:44:00PM +0200, Terje Bergstrom wrote:
>> diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c
> [...]
>> +static pid_t host1x_debug_null_kickoff_pid;
>> +unsigned int
On 04.02.2013 02:30, Thierry Reding wrote:
> On Tue, Jan 15, 2013 at 01:43:58PM +0200, Terje Bergstrom wrote:
> [...]
>> diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
> [...]
>> @@ -95,7 +96,6 @@ static int host1x_probe(struct platform_device *dev)
>>
>> /* set common
On 04.02.2013 01:09, Thierry Reding wrote:
> On Tue, Jan 15, 2013 at 01:43:57PM +0200, Terje Bergstrom wrote:
>> Add host1x, the driver for host1x and its client unit 2D.
>
> Maybe this could be a bit more verbose. Perhaps describe what host1x is.
Sure. I could just steal the paragraph from
On 04.02.2013 01:09, Thierry Reding wrote:
On Tue, Jan 15, 2013 at 01:43:57PM +0200, Terje Bergstrom wrote:
Add host1x, the driver for host1x and its client unit 2D.
Maybe this could be a bit more verbose. Perhaps describe what host1x is.
Sure. I could just steal the paragraph from Stephen:
On 04.02.2013 02:30, Thierry Reding wrote:
On Tue, Jan 15, 2013 at 01:43:58PM +0200, Terje Bergstrom wrote:
[...]
diff --git a/drivers/gpu/host1x/dev.c b/drivers/gpu/host1x/dev.c
[...]
@@ -95,7 +96,6 @@ static int host1x_probe(struct platform_device *dev)
/* set common host1x device
On 04.02.2013 03:03, Thierry Reding wrote:
* PGP Signed by an unknown key
On Tue, Jan 15, 2013 at 01:44:00PM +0200, Terje Bergstrom wrote:
diff --git a/drivers/gpu/host1x/debug.c b/drivers/gpu/host1x/debug.c
[...]
+static pid_t host1x_debug_null_kickoff_pid;
+unsigned int
On 04.02.2013 03:08, Thierry Reding wrote:
* PGP Signed by an unknown key
On Tue, Jan 15, 2013 at 01:44:01PM +0200, Terje Bergstrom wrote:
[...]
diff --git a/drivers/gpu/host1x/Makefile b/drivers/gpu/host1x/Makefile
index 697d49a..ffc8bf1 100644
--- a/drivers/gpu/host1x/Makefile
+++
On 04.02.2013 03:26, Thierry Reding wrote:
* PGP Signed by an unknown key
On Tue, Jan 15, 2013 at 01:44:03PM +0200, Terje Bergstrom wrote:
Add a driver alias gr2d for Tegra 2D device, and assign a duplicate
of 2D clock to that driver alias.
Signed-off-by: Terje Bergstrom
On 04.02.2013 04:56, Thierry Reding wrote:
* PGP Signed by an unknown key
On Tue, Jan 15, 2013 at 01:44:04PM +0200, Terje Bergstrom wrote:
[...]
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
@@ -270,7 +274,29 @@ static int tegra_drm_unload(struct drm_device *drm)
On 15.01.2013 03:43, Terje Bergstrom wrote:
> This set of patches adds support for Tegra20 and Tegra30 host1x and
> 2D. It is based on linux-next-20130114. The set was regenerated with
> git format-patch -M.
>
> The fifth version merges DRM and host1x drivers into one driver. This
> allowed
On 15.01.2013 03:43, Terje Bergstrom wrote:
This set of patches adds support for Tegra20 and Tegra30 host1x and
2D. It is based on linux-next-20130114. The set was regenerated with
git format-patch -M.
The fifth version merges DRM and host1x drivers into one driver. This
allowed moving
On 22.01.2013 21:59, Mario Kleiner wrote:
> The current swap scheduling is based on having an accurate software
> vblank counter. Atm. that counter is maintained in software, incremented
> during vblank irq. At irq off -> on transition we need a hw counter to
> reinitialize. And there is a
On 22.01.2013 11:48, Lucas Stach wrote:
> I think the test suite is enough to fulfil the formal requirement of
> having a working userspace. But still it would be nice to have at least
> some simple accel functions working in the DDX. Maybe just to see on how
> well the current design integrates
On 22.01.2013 11:31, Thierry Reding wrote:
> I'm not quite sure if I remember correctly, but I think David mentioned
> something along the lines of requiring a working userspace that can be
> used to test the DRM interfaces as a prerequisite to getting this kind
> of code merged.
That's why we
On 22.01.2013 11:15, Lucas Stach wrote:
> But even if I get this out real soon, I'm not really comfortable with
> speeding things to 3.9. I would like to review the userspace side of
> thing a lot more thoroughly, before committing to the interface. But
> maybe this can also happen in the 3.9 RC
On 15.01.2013 13:43, Terje Bergstrom wrote:
> This set of patches adds support for Tegra20 and Tegra30 host1x and
> 2D. It is based on linux-next-20130114. The set was regenerated with
> git format-patch -M.
I have pushed both the kernel patches and libdrm changes to
git at
On 14.01.2013 18:06, Thierry Reding wrote:
> +static int tegra_dc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer
> *fb,
> + struct drm_pending_vblank_event *event)
> +{
> + struct tegra_framebuffer *newfb = to_tegra_fb(fb);
> + struct tegra_dc *dc =
On 14.01.2013 18:06, Thierry Reding wrote:
+static int tegra_dc_page_flip(struct drm_crtc *crtc, struct drm_framebuffer
*fb,
+ struct drm_pending_vblank_event *event)
+{
+ struct tegra_framebuffer *newfb = to_tegra_fb(fb);
+ struct tegra_dc *dc =
On 15.01.2013 13:43, Terje Bergstrom wrote:
This set of patches adds support for Tegra20 and Tegra30 host1x and
2D. It is based on linux-next-20130114. The set was regenerated with
git format-patch -M.
I have pushed both the kernel patches and libdrm changes to
On 22.01.2013 11:15, Lucas Stach wrote:
But even if I get this out real soon, I'm not really comfortable with
speeding things to 3.9. I would like to review the userspace side of
thing a lot more thoroughly, before committing to the interface. But
maybe this can also happen in the 3.9 RC
On 22.01.2013 11:31, Thierry Reding wrote:
I'm not quite sure if I remember correctly, but I think David mentioned
something along the lines of requiring a working userspace that can be
used to test the DRM interfaces as a prerequisite to getting this kind
of code merged.
That's why we have
On 22.01.2013 11:48, Lucas Stach wrote:
I think the test suite is enough to fulfil the formal requirement of
having a working userspace. But still it would be nice to have at least
some simple accel functions working in the DDX. Maybe just to see on how
well the current design integrates into
On 22.01.2013 21:59, Mario Kleiner wrote:
The current swap scheduling is based on having an accurate software
vblank counter. Atm. that counter is maintained in software, incremented
during vblank irq. At irq off - on transition we need a hw counter to
reinitialize. And there is a timeout
On 15.01.2013 20:44, Stephen Warren wrote:
> On 01/15/2013 04:26 AM, Terje Bergstrom wrote:
>> Add a driver alias gr2d for Tegra 2D device, and assign a duplicate
>> of 2D clock to that driver alias.
>
> FYI on this one patch - it won't be applied to the Tegra tree until
> after Prashant's common
On 15.01.2013 20:44, Stephen Warren wrote:
>> diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c
>> b/arch/arm/mach-tegra/board-dt-tegra20.c
>
>> +OF_DEV_AUXDATA("nvidia,tegra20-gr2d", 0x5414, "gr2d", NULL),
>
> I assume the only reason to add AUXDATA is to give the device a specific
>
On 15.01.2013 20:44, Stephen Warren wrote:
On 01/15/2013 04:26 AM, Terje Bergstrom wrote:
Add a driver alias gr2d for Tegra 2D device, and assign a duplicate
of 2D clock to that driver alias.
FYI on this one patch - it won't be applied to the Tegra tree until
after Prashant's common clock
On 15.01.2013 13:30, Thierry Reding wrote:
> Sorry for not getting back to you on this earlier. I just remembered
> this thread when I saw Terje's latest patch series.
>
> I agree that having everything in one location will make things a lot
> easier, even if it means we have to add the tegra-drm
On 15.01.2013 20:44, Stephen Warren wrote:
diff --git a/arch/arm/mach-tegra/board-dt-tegra20.c
b/arch/arm/mach-tegra/board-dt-tegra20.c
+OF_DEV_AUXDATA(nvidia,tegra20-gr2d, 0x5414, gr2d, NULL),
I assume the only reason to add AUXDATA is to give the device a specific
name, which
On 04.01.2013 22:25, Stephen Warren wrote:
> On 01/04/2013 03:09 AM, Terje Bergstr?m wrote:
> ...
>> I think we have now two ways to go forward with cons and pros:
>> 1) Keep host1x and tegra-drm as separate driver
>>+ Code almost done
>>- we need dummy device and dummy driver
>>-
On 04.01.2013 22:25, Stephen Warren wrote:
On 01/04/2013 03:09 AM, Terje Bergström wrote:
...
I think we have now two ways to go forward with cons and pros:
1) Keep host1x and tegra-drm as separate driver
+ Code almost done
- we need dummy device and dummy driver
- extra code
On 21.12.2012 23:19, Stephen Warren wrote:
> I see the situation more like:
>
> * There's host1x hardware.
>
> * There's a low-level driver just for host1x itself; the host1x driver.
>
> * There's a high-level driver for the entire host1x complex of devices.
> That is tegradrm. There may be
On 21.12.2012 23:19, Stephen Warren wrote:
I see the situation more like:
* There's host1x hardware.
* There's a low-level driver just for host1x itself; the host1x driver.
* There's a high-level driver for the entire host1x complex of devices.
That is tegradrm. There may be more
1 - 100 of 256 matches
Mail list logo
