On 11.11.2014 06:29, Alexandre Courbot wrote:
> I think (after a quick look at devfreq's source) that you can avoid
> polling altogether if you set polling_ms to 0 in your
> devfreq_dev_profile instance. Then it is up to you to call
> update_devfreq() from your custom governor whenever it sees
On 11.11.2014 06:29, Alexandre Courbot wrote:
I think (after a quick look at devfreq's source) that you can avoid
polling altogether if you set polling_ms to 0 in your
devfreq_dev_profile instance. Then it is up to you to call
update_devfreq() from your custom governor whenever it sees fit.
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 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 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 you'd
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 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 kusmab...@gmail.com
---
Here's a trivial optimization I
On 15.11.2013 16:52, Steven Rostedt wrote:
> So let me get this straight. The recording of the cdma_push() data is
> slow, correct? What mapping are you talking about?
>
> trace_host1x_cdma_push(dev_name(cdma_to_channel(cdma)->dev),
> op1, op2);
>
>
On 15.11.2013 16:52, Steven Rostedt wrote:
So let me get this straight. The recording of the cdma_push() data is
slow, correct? What mapping are you talking about?
trace_host1x_cdma_push(dev_name(cdma_to_channel(cdma)-dev),
op1, op2);
#define
On 15.11.2013 06:48, Steven Rostedt wrote:
> I've been reviewing different users of tracepoints and I stumbled
> across this:
>
> drivers/gpu/host1x/cdma.c: host1x_cdma_push()
>
> if (host1x_debug_trace_cmdbuf)
> trace_host1x_cdma_push(dev_name(cdma_to_channel(cdma)->dev),
>
On 15.11.2013 06:48, Steven Rostedt wrote:
I've been reviewing different users of tracepoints and I stumbled
across this:
drivers/gpu/host1x/cdma.c: host1x_cdma_push()
if (host1x_debug_trace_cmdbuf)
trace_host1x_cdma_push(dev_name(cdma_to_channel(cdma)-dev),
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 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 allows
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 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 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
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 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 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 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.
>
>
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 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.
>
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
>
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 thi
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 sa
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
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
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 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 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 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:
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 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 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 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 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
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
On 21.12.2012 16:36, Thierry Reding wrote:
> On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote:
>> +static void tegra_drm_close(struct drm_device *drm, struct drm_file *filp)
>> +{
>> +
>> +}
>> +
>
> This can be removed, right?
Yes, done.
>
>> +static struct platform_driver
On 21.12.2012 16:36, Thierry Reding wrote:
On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote:
+static void tegra_drm_close(struct drm_device *drm, struct drm_file *filp)
+{
+
+}
+
This can be removed, right?
Yes, done.
+static struct platform_driver
On 21.12.2012 15:50, Lucas Stach wrote:
> Am Freitag, den 21.12.2012, 13:39 +0200 schrieb Terje Bergstrom:
>> Some of the issues left open:
>> * Register definitions still use static inline. There has been a
>>debate about code style versus ability to use compiler type
>>checking and code
On 03.01.2013 05:31, Mark Zhang wrote:
> Sorry I didn't get it. Yes, in current design, you can pin all mem
> handles in one time but I haven't found anything related with "locking
> only once per submit".
>
> My idea is:
> - remove "job->addr_phys"
> - assign "job->reloc_addr_phys" &
On 02.01.2013 11:31, Mark Zhang wrote:
> On 01/02/2013 05:31 PM, Terje Bergström wrote:
>> That's intentional. Writing a job to channel is atomic, so lock is taken
>> from host1x_cdma_begin() until host1x_cdma_end().
>>
>
> Okay. So can we consider that lock and unlock
On 28.12.2012 11:14, Mark Zhang wrote:
> diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
> index a936902..c3ded60 100644
> --- a/drivers/gpu/drm/tegra/gr2d.c
> +++ b/drivers/gpu/drm/tegra/gr2d.c
> @@ -131,6 +131,14 @@ static int gr2d_submit(struct tegra_drm_context
>
On 02.01.2013 09:40, Mark Zhang wrote:
> On 12/21/2012 07:39 PM, Terje Bergstrom wrote:
>> Add support for host1x client modules, and host1x channels to submit
>> work to the clients. The work is submitted in GEM CMA buffers, so
>> this patch adds support for them.
>>
>> Signed-off-by: Terje
On 22.12.2012 06:17, Steven Rostedt wrote:
> On Fri, 2012-12-21 at 13:39 +0200, Terje Bergstrom wrote:
>> +TRACE_EVENT(host1x_cdma_begin,
>> +TP_PROTO(const char *name),
>> +
>> +TP_ARGS(name),
>> +
>> +TP_STRUCT__entry(
>> +__field(const char *, name)
>> +),
>> +
>> +
On 26.12.2012 11:42, Mark Zhang wrote:
> diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
> index a936902..28954b3 100644
> --- a/drivers/gpu/drm/tegra/gr2d.c
> +++ b/drivers/gpu/drm/tegra/gr2d.c
> @@ -247,6 +247,10 @@ static int __devinit gr2d_probe(struct
>
On 26.12.2012 11:42, Mark Zhang wrote:
diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index a936902..28954b3 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -247,6 +247,10 @@ static int __devinit gr2d_probe(struct
platform_device
On 22.12.2012 06:17, Steven Rostedt wrote:
On Fri, 2012-12-21 at 13:39 +0200, Terje Bergstrom wrote:
+TRACE_EVENT(host1x_cdma_begin,
+TP_PROTO(const char *name),
+
+TP_ARGS(name),
+
+TP_STRUCT__entry(
+__field(const char *, name)
+),
+
+TP_fast_assign(
+
On 02.01.2013 09:40, Mark Zhang wrote:
On 12/21/2012 07:39 PM, Terje Bergstrom wrote:
Add support for host1x client modules, and host1x channels to submit
work to the clients. The work is submitted in GEM CMA buffers, so
this patch adds support for them.
Signed-off-by: Terje Bergstrom
On 28.12.2012 11:14, Mark Zhang wrote:
diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c
index a936902..c3ded60 100644
--- a/drivers/gpu/drm/tegra/gr2d.c
+++ b/drivers/gpu/drm/tegra/gr2d.c
@@ -131,6 +131,14 @@ static int gr2d_submit(struct tegra_drm_context
*context,
On 02.01.2013 11:31, Mark Zhang wrote:
On 01/02/2013 05:31 PM, Terje Bergström wrote:
That's intentional. Writing a job to channel is atomic, so lock is taken
from host1x_cdma_begin() until host1x_cdma_end().
Okay. So can we consider that lock and unlock this mutex in the function
which
On 03.01.2013 05:31, Mark Zhang wrote:
Sorry I didn't get it. Yes, in current design, you can pin all mem
handles in one time but I haven't found anything related with locking
only once per submit.
My idea is:
- remove job-addr_phys
- assign job-reloc_addr_phys job-gather_addr_phys
On 21.12.2012 15:50, Lucas Stach wrote:
Am Freitag, den 21.12.2012, 13:39 +0200 schrieb Terje Bergstrom:
Some of the issues left open:
* Register definitions still use static inline. There has been a
debate about code style versus ability to use compiler type
checking and code coverage
On 21.12.2012 23:19, Stephen Warren wrote:
> * 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 high-level drivers in the future
>
On 21.12.2012 23:19, Stephen Warren wrote:
* 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 high-level drivers in the future
(e.g.
On 28.12.2012 23:21, Thierry Reding wrote:
> Instead of going over this back and forth, I've decided to rewrite this
> patch from scratch the way I think it should be done. Maybe that'll make
> things clearer. I haven't tested it on real hardware yet because I don't
> have access over the
On 28.12.2012 23:21, Thierry Reding wrote:
Instead of going over this back and forth, I've decided to rewrite this
patch from scratch the way I think it should be done. Maybe that'll make
things clearer. I haven't tested it on real hardware yet because I don't
have access over the holidays,
On 21.12.2012 16:36, Thierry Reding wrote:
> On Fri, Dec 21, 2012 at 01:39:21PM +0200, Terje Bergstrom wrote:
>> +static struct platform_driver tegra_drm_platform_driver = {
>> +.driver = {
>> +.name = "tegradrm",
>
> This should be "tegra-drm" to match the module name.
We've
On 21.12.2012 15:50, Lucas Stach wrote:
> This has to be resolved before merging. Personally I'm in favour of
> keeping reg access patterns close to what is done in other parts of the
> kernel.
I haven't so far received comments from too many people, so that's why I
left it as is.
>> * Uses
1 - 100 of 218 matches
Mail list logo
