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 Fri, Jan 04, 2013 at 01:25:06PM -0700, 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
On Fri, Jan 04, 2013 at 01:25:06PM -0700, 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
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 01/07/2013 01:20 AM, Terje Bergström wrote:
> 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
>>>
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 and
On 01/07/2013 01:20 AM, Terje Bergström wrote:
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 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 and API when host1x creates dummy device and
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 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 and API when host1x creates dummy device and its
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 12/21/2012 01:57 AM, Arto Merilainen wrote:
> On 12/20/2012 07:14 PM, Stephen Warren wrote:
>>
>> What's wrong with just having each device ask the host1x (its parent)
>> for a pointer to the (dummy) tegradrm device. That seems extremely
>>
>
> We are talking about creating a dummy device
On 12/20/2012 07:14 PM, Stephen Warren wrote:
What's wrong with just having each device ask the host1x (its parent)
for a pointer to the (dummy) tegradrm device. That seems extremely
We are talking about creating a dummy device because:
- we need to give something for drm_platform_init(),
-
On 12/20/2012 07:14 PM, Stephen Warren wrote:
What's wrong with just having each device ask the host1x (its parent)
for a pointer to the (dummy) tegradrm device. That seems extremely
We are talking about creating a dummy device because:
- we need to give something for drm_platform_init(),
-
On 12/21/2012 01:57 AM, Arto Merilainen wrote:
On 12/20/2012 07:14 PM, Stephen Warren wrote:
What's wrong with just having each device ask the host1x (its parent)
for a pointer to the (dummy) tegradrm device. That seems extremely
We are talking about creating a dummy device because:
- we
On 21.12.2012 00:28, Stephen Warren wrote:
> On 12/20/2012 02:34 PM, Terje Bergström wrote:
>> On 20.12.2012 22:30, Thierry Reding wrote:
>>> The problem with your proposed solution is that, even any of Stephen's
>>> valid objections aside, it won't work. Once the tegra-drm module is
>>> unloaded,
On 12/20/2012 02:50 PM, Thierry Reding wrote:
> On Thu, Dec 20, 2012 at 11:34:26PM +0200, Terje Bergström wrote:
>> On 20.12.2012 22:30, Thierry Reding wrote:
>>> The problem with your proposed solution is that, even any of
>>> Stephen's valid objections aside, it won't work. Once the
>>>
On 12/20/2012 02:34 PM, Terje Bergström wrote:
> On 20.12.2012 22:30, Thierry Reding wrote:
>> The problem with your proposed solution is that, even any of Stephen's
>> valid objections aside, it won't work. Once the tegra-drm module is
>> unloaded, the driver's data will be left in the current
On Thu, Dec 20, 2012 at 11:34:26PM +0200, Terje Bergström wrote:
> On 20.12.2012 22:30, Thierry Reding wrote:
> > The problem with your proposed solution is that, even any of Stephen's
> > valid objections aside, it won't work. Once the tegra-drm module is
> > unloaded, the driver's data will be
On 20.12.2012 22:30, Thierry Reding wrote:
> The problem with your proposed solution is that, even any of Stephen's
> valid objections aside, it won't work. Once the tegra-drm module is
> unloaded, the driver's data will be left in the current state and the
> link to the dummy device will be lost.
On Thu, Dec 20, 2012 at 08:01:43PM +0200, Terje Bergström wrote:
> On 20.12.2012 19:55, Stephen Warren wrote:
> > So it's fine for the tegradrm driver to manipulate the tegradrm
> > (virtual) device's drvdata pointer.
> >
> > It's not fine for tegradrm to manipulate the drvdata pointer of other
>
On 20.12.2012 19:55, Stephen Warren wrote:
> So it's fine for the tegradrm driver to manipulate the tegradrm
> (virtual) device's drvdata pointer.
>
> It's not fine for tegradrm to manipulate the drvdata pointer of other
> devices; the host1x children. The drvdata pointer for other devices is
>
On 12/20/2012 10:46 AM, Terje Bergström wrote:
> On 20.12.2012 19:14, Stephen Warren wrote:
>> I'm not sure that sounds right. drvdata is something that a driver
>> should manage itself.
>>
>> What's wrong with just having each device ask the host1x (its parent)
>> for a pointer to the (dummy)
On 20.12.2012 19:14, Stephen Warren wrote:
> I'm not sure that sounds right. drvdata is something that a driver
> should manage itself.
>
> What's wrong with just having each device ask the host1x (its parent)
> for a pointer to the (dummy) tegradrm device. That seems extremely
> simple, and
On 12/20/2012 02:17 AM, Terje Bergström wrote:
> On 16.12.2012 14:16, Thierry Reding wrote:
>> Okay, so we're back on the topic of using globals. I need to assert
>> again that this is not an option. If we were to use globals, then we
>> could just as well leave out the dummy device and just do
On 16.12.2012 14:16, Thierry Reding wrote:
> Okay, so we're back on the topic of using globals. I need to assert
> again that this is not an option. If we were to use globals, then we
> could just as well leave out the dummy device and just do all of that in
> the tegra-drm driver's initialization
On 16.12.2012 14:16, Thierry Reding wrote:
Okay, so we're back on the topic of using globals. I need to assert
again that this is not an option. If we were to use globals, then we
could just as well leave out the dummy device and just do all of that in
the tegra-drm driver's initialization
On 12/20/2012 02:17 AM, Terje Bergström wrote:
On 16.12.2012 14:16, Thierry Reding wrote:
Okay, so we're back on the topic of using globals. I need to assert
again that this is not an option. If we were to use globals, then we
could just as well leave out the dummy device and just do all of
On 20.12.2012 19:14, Stephen Warren wrote:
I'm not sure that sounds right. drvdata is something that a driver
should manage itself.
What's wrong with just having each device ask the host1x (its parent)
for a pointer to the (dummy) tegradrm device. That seems extremely
simple, and doesn't
On 12/20/2012 10:46 AM, Terje Bergström wrote:
On 20.12.2012 19:14, Stephen Warren wrote:
I'm not sure that sounds right. drvdata is something that a driver
should manage itself.
What's wrong with just having each device ask the host1x (its parent)
for a pointer to the (dummy) tegradrm
On 20.12.2012 19:55, Stephen Warren wrote:
So it's fine for the tegradrm driver to manipulate the tegradrm
(virtual) device's drvdata pointer.
It's not fine for tegradrm to manipulate the drvdata pointer of other
devices; the host1x children. The drvdata pointer for other devices is
On Thu, Dec 20, 2012 at 08:01:43PM +0200, Terje Bergström wrote:
On 20.12.2012 19:55, Stephen Warren wrote:
So it's fine for the tegradrm driver to manipulate the tegradrm
(virtual) device's drvdata pointer.
It's not fine for tegradrm to manipulate the drvdata pointer of other
devices;
On 20.12.2012 22:30, Thierry Reding wrote:
The problem with your proposed solution is that, even any of Stephen's
valid objections aside, it won't work. Once the tegra-drm module is
unloaded, the driver's data will be left in the current state and the
link to the dummy device will be lost.
On Thu, Dec 20, 2012 at 11:34:26PM +0200, Terje Bergström wrote:
On 20.12.2012 22:30, Thierry Reding wrote:
The problem with your proposed solution is that, even any of Stephen's
valid objections aside, it won't work. Once the tegra-drm module is
unloaded, the driver's data will be left in
On 12/20/2012 02:34 PM, Terje Bergström wrote:
On 20.12.2012 22:30, Thierry Reding wrote:
The problem with your proposed solution is that, even any of Stephen's
valid objections aside, it won't work. Once the tegra-drm module is
unloaded, the driver's data will be left in the current state and
On 12/20/2012 02:50 PM, Thierry Reding wrote:
On Thu, Dec 20, 2012 at 11:34:26PM +0200, Terje Bergström wrote:
On 20.12.2012 22:30, Thierry Reding wrote:
The problem with your proposed solution is that, even any of
Stephen's valid objections aside, it won't work. Once the
tegra-drm module is
On 21.12.2012 00:28, Stephen Warren wrote:
On 12/20/2012 02:34 PM, Terje Bergström wrote:
On 20.12.2012 22:30, Thierry Reding wrote:
The problem with your proposed solution is that, even any of Stephen's
valid objections aside, it won't work. Once the tegra-drm module is
unloaded, the
On 17.12.2012 22:55, Stephen Warren wrote:
> On 12/16/2012 09:37 AM, Terje Bergström wrote:
> ...
>> ... Sure we could tell DC to ask its parent
>> (host1x), and call host1x driver with platform_device pointer found that
>> way, and host1x would return a pointer to tegradrm's data. Hanging the
>>
On 12/16/2012 09:37 AM, Terje Bergström wrote:
...
> ... Sure we could tell DC to ask its parent
> (host1x), and call host1x driver with platform_device pointer found that
> way, and host1x would return a pointer to tegradrm's data. Hanging the
> data onto host1x driver is just a more complicated
On 12/16/2012 09:37 AM, Terje Bergström wrote:
...
... Sure we could tell DC to ask its parent
(host1x), and call host1x driver with platform_device pointer found that
way, and host1x would return a pointer to tegradrm's data. Hanging the
data onto host1x driver is just a more complicated way
On 17.12.2012 22:55, Stephen Warren wrote:
On 12/16/2012 09:37 AM, Terje Bergström wrote:
...
... Sure we could tell DC to ask its parent
(host1x), and call host1x driver with platform_device pointer found that
way, and host1x would return a pointer to tegradrm's data. Hanging the
data onto
On 16.12.2012 14:16, Thierry Reding wrote:
> Okay, so we're back on the topic of using globals. I need to assert
> again that this is not an option. If we were to use globals, then we
> could just as well leave out the dummy device and just do all of that in
> the tegra-drm driver's initialization
On Fri, Dec 14, 2012 at 09:59:11PM +0200, Terje Bergström wrote:
> On 14.12.2012 18:21, Stephen Warren wrote:
> > On 12/13/2012 11:09 PM, Terje Bergström wrote:
> >> They want to get the global data by getting drvdata of their parent.
> >
> > There's no reason that /has/ to be so; they can get
On Fri, Dec 14, 2012 at 09:59:11PM +0200, Terje Bergström wrote:
On 14.12.2012 18:21, Stephen Warren wrote:
On 12/13/2012 11:09 PM, Terje Bergström wrote:
They want to get the global data by getting drvdata of their parent.
There's no reason that /has/ to be so; they can get any
On 16.12.2012 14:16, Thierry Reding wrote:
Okay, so we're back on the topic of using globals. I need to assert
again that this is not an option. If we were to use globals, then we
could just as well leave out the dummy device and just do all of that in
the tegra-drm driver's initialization
On 14.12.2012 18:21, Stephen Warren wrote:
> On 12/13/2012 11:09 PM, Terje Bergström wrote:
>> They want to get the global data by getting drvdata of their parent.
>
> There's no reason that /has/ to be so; they can get any information from
> wherever it is, rather than trying to require it to be
On 12/13/2012 11:09 PM, Terje Bergström wrote:
> On 13.12.2012 19:58, Stephen Warren wrote:
>> On 12/13/2012 01:57 AM, Thierry Reding wrote:
>>> After some more discussion with Stephen on IRC we came to the
>>> conclusion that the easiest might be to have tegra-drm call into
>>> host1x with
On 12/13/2012 11:09 PM, Terje Bergström wrote:
On 13.12.2012 19:58, Stephen Warren wrote:
On 12/13/2012 01:57 AM, Thierry Reding wrote:
After some more discussion with Stephen on IRC we came to the
conclusion that the easiest might be to have tegra-drm call into
host1x with something like:
On 14.12.2012 18:21, Stephen Warren wrote:
On 12/13/2012 11:09 PM, Terje Bergström wrote:
They want to get the global data by getting drvdata of their parent.
There's no reason that /has/ to be so; they can get any information from
wherever it is, rather than trying to require it to be
On 13.12.2012 19:58, Stephen Warren wrote:
> On 12/13/2012 01:57 AM, Thierry Reding wrote:
>> After some more discussion with Stephen on IRC we came to the
>> conclusion that the easiest might be to have tegra-drm call into
>> host1x with something like:
>>
>> void host1x_set_drm_device(struct
On Thu, Dec 13, 2012 at 10:58:55AM -0700, Stephen Warren wrote:
> On 12/13/2012 01:57 AM, Thierry Reding wrote:
> > On Thu, Dec 13, 2012 at 10:48:55AM +0200, Terje Bergström wrote:
> >> On 12.12.2012 18:08, Thierry Reding wrote:
> >>> I've briefly discussed this with Stephen on IRC because I
> >>>
On 12/13/2012 01:57 AM, Thierry Reding wrote:
> On Thu, Dec 13, 2012 at 10:48:55AM +0200, Terje Bergström wrote:
>> On 12.12.2012 18:08, Thierry Reding wrote:
>>> I've briefly discussed this with Stephen on IRC because I
>>> thought I had remembered him objecting to the idea of adding a
>>> dummy
On Thu, Dec 13, 2012 at 10:48:55AM +0200, Terje Bergström wrote:
> On 12.12.2012 18:08, Thierry Reding wrote:
> > I've briefly discussed this with Stephen on IRC because I thought I had
> > remembered him objecting to the idea of adding a dummy device just for
> > this purpose. It turns out,
On 12.12.2012 18:08, Thierry Reding wrote:
> I've briefly discussed this with Stephen on IRC because I thought I had
> remembered him objecting to the idea of adding a dummy device just for
> this purpose. It turns out, however, that what he didn't like was to add
> a dummy node to the DT just to
On 12.12.2012 18:08, Thierry Reding wrote:
I've briefly discussed this with Stephen on IRC because I thought I had
remembered him objecting to the idea of adding a dummy device just for
this purpose. It turns out, however, that what he didn't like was to add
a dummy node to the DT just to make
On Thu, Dec 13, 2012 at 10:48:55AM +0200, Terje Bergström wrote:
On 12.12.2012 18:08, Thierry Reding wrote:
I've briefly discussed this with Stephen on IRC because I thought I had
remembered him objecting to the idea of adding a dummy device just for
this purpose. It turns out, however,
On 12/13/2012 01:57 AM, Thierry Reding wrote:
On Thu, Dec 13, 2012 at 10:48:55AM +0200, Terje Bergström wrote:
On 12.12.2012 18:08, Thierry Reding wrote:
I've briefly discussed this with Stephen on IRC because I
thought I had remembered him objecting to the idea of adding a
dummy device just
On Thu, Dec 13, 2012 at 10:58:55AM -0700, Stephen Warren wrote:
On 12/13/2012 01:57 AM, Thierry Reding wrote:
On Thu, Dec 13, 2012 at 10:48:55AM +0200, Terje Bergström wrote:
On 12.12.2012 18:08, Thierry Reding wrote:
I've briefly discussed this with Stephen on IRC because I
thought I had
On 13.12.2012 19:58, Stephen Warren wrote:
On 12/13/2012 01:57 AM, Thierry Reding wrote:
After some more discussion with Stephen on IRC we came to the
conclusion that the easiest might be to have tegra-drm call into
host1x with something like:
void host1x_set_drm_device(struct host1x
On 12.12.2012 18:08, Thierry Reding wrote:
> I've briefly discussed this with Stephen on IRC because I thought I had
> remembered him objecting to the idea of adding a dummy device just for
> this purpose. It turns out, however, that what he didn't like was to add
> a dummy node to the DT just to
On Mon, Dec 10, 2012 at 01:42:45PM +0200, Terje Bergström wrote:
> On 05.12.2012 14:04, Thierry Reding wrote:
> > On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote:
> >> You're right in that binding to a sub-device is not a nice way. DRM
> >> framework just needs a "struct device" to
On Mon, Dec 10, 2012 at 01:42:45PM +0200, Terje Bergström wrote:
On 05.12.2012 14:04, Thierry Reding wrote:
On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote:
You're right in that binding to a sub-device is not a nice way. DRM
framework just needs a struct device to bind to.
On 12.12.2012 18:08, Thierry Reding wrote:
I've briefly discussed this with Stephen on IRC because I thought I had
remembered him objecting to the idea of adding a dummy device just for
this purpose. It turns out, however, that what he didn't like was to add
a dummy node to the DT just to make
On 05.12.2012 14:04, Thierry Reding wrote:
> On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote:
>> You're right in that binding to a sub-device is not a nice way. DRM
>> framework just needs a "struct device" to bind to. exynos seems to solve
>> this by introducing a virtual device
On 05.12.2012 14:04, Thierry Reding wrote:
On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote:
You're right in that binding to a sub-device is not a nice way. DRM
framework just needs a struct device to bind to. exynos seems to solve
this by introducing a virtual device and bind
On Wed, Dec 05, 2012 at 05:34:30PM +0100, Daniel Vetter wrote:
> On Wed, Dec 5, 2012 at 2:28 PM, Thierry Reding
> wrote:
> >> Imo that's worse, since now drm manages even more of the driver->hw
> >> binding process. In my dream world the drm driver just registers a
> >> normal driver at module
On Wed, Dec 5, 2012 at 2:28 PM, Thierry Reding
wrote:
>> Imo that's worse, since now drm manages even more of the driver->hw
>> binding process. In my dream world the drm driver just registers a
>> normal driver at module load time directly with whatever bus it's
>> interested in, and then, from
On 05.12.2012 14:04, Thierry Reding wrote:
> On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote:
> Yes, but there's more. For instance I went to great lengths to make sure
> there's no global data whatsoever. So all the data is bound to the
> host1x device in the current code. I know
On Wed, Dec 05, 2012 at 01:31:54PM +0100, Daniel Vetter wrote:
> On Wed, Dec 5, 2012 at 1:22 PM, Thierry Reding
> wrote:
> > Maybe something more elaborate could help, though. Suppose we add
> > functionality to DRM to instantiate a DRM device. We could call such a
> > function from the host1x
On Wed, Dec 5, 2012 at 1:22 PM, Thierry Reding
wrote:
> Maybe something more elaborate could help, though. Suppose we add
> functionality to DRM to instantiate a DRM device. We could call such a
> function from the host1x driver to add a device which the tegra-drm
> driver could bind to. This
On Wed, Dec 05, 2012 at 01:03:14PM +0100, Daniel Vetter wrote:
> On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström
> wrote:
> > You're right in that binding to a sub-device is not a nice way. DRM
> > framework just needs a "struct device" to bind to. exynos seems to solve
> > this by introducing
On Wed, Dec 5, 2012 at 1:03 PM, Daniel Vetter wrote:
> On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström
> wrote:
>> You're right in that binding to a sub-device is not a nice way. DRM
>> framework just needs a "struct device" to bind to. exynos seems to solve
>> this by introducing a virtual
On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote:
> On 05.12.2012 13:13, Thierry Reding wrote:
[...]
> > Oh well, at the time nobody from NVIDIA was involved so I wrote that
> > code in preparation for proper host1x support that I thought I would
> > have to add myself at some
On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström wrote:
> You're right in that binding to a sub-device is not a nice way. DRM
> framework just needs a "struct device" to bind to. exynos seems to solve
> this by introducing a virtual device and bind to that. I'm not sure if
> this is the best way,
Am Mittwoch, den 05.12.2012, 13:47 +0200 schrieb Terje Bergström:
[...]
>
> > The problem that this solves is that the DRM driver needs to be bound to
> > a specific platform device. None of the DRM subdevices are suitable
> > because they are only part of the whole DRM device. I think that
On 05.12.2012 13:13, Thierry Reding wrote:
> What I propose is to move the client registration code that is currently
> in drivers/gpu/drm/tegra/host1x.c to the host1x driver, which may or may
> not end up in drivers/gpu/host1x.
Ok.
>
>> host1x hardware access must be encapsulated in host1x
On Wed, Dec 05, 2012 at 12:10:50PM +0200, Terje Bergström wrote:
> On 05.12.2012 10:33, Thierry Reding wrote:
> > I've been thinking about this some more and came to the conclusion that
> > since we will already have a tight coupling between host1x and tegra-drm
> > we may just as well keep the
On 05.12.2012 10:33, Thierry Reding wrote:
> I've been thinking about this some more and came to the conclusion that
> since we will already have a tight coupling between host1x and tegra-drm
> we may just as well keep the client registration code in host1x. The way
> I imagine this to work would
On Mon, Nov 26, 2012 at 03:19:12PM +0200, Terje Bergstrom wrote:
> From: Arto Merilainen
>
> This patch removes the redundant host1x driver from tegradrm and
> makes necessary bindings to the separate host driver.
>
> This modification introduces a regression: Because there is no
> general
On Mon, Nov 26, 2012 at 03:19:12PM +0200, Terje Bergstrom wrote:
From: Arto Merilainen amerilai...@nvidia.com
This patch removes the redundant host1x driver from tegradrm and
makes necessary bindings to the separate host driver.
This modification introduces a regression: Because there is
On 05.12.2012 10:33, Thierry Reding wrote:
I've been thinking about this some more and came to the conclusion that
since we will already have a tight coupling between host1x and tegra-drm
we may just as well keep the client registration code in host1x. The way
I imagine this to work would be
On Wed, Dec 05, 2012 at 12:10:50PM +0200, Terje Bergström wrote:
On 05.12.2012 10:33, Thierry Reding wrote:
I've been thinking about this some more and came to the conclusion that
since we will already have a tight coupling between host1x and tegra-drm
we may just as well keep the client
On 05.12.2012 13:13, Thierry Reding wrote:
What I propose is to move the client registration code that is currently
in drivers/gpu/drm/tegra/host1x.c to the host1x driver, which may or may
not end up in drivers/gpu/host1x.
Ok.
host1x hardware access must be encapsulated in host1x driver
Am Mittwoch, den 05.12.2012, 13:47 +0200 schrieb Terje Bergström:
[...]
The problem that this solves is that the DRM driver needs to be bound to
a specific platform device. None of the DRM subdevices are suitable
because they are only part of the whole DRM device. I think that host1x
is
On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström tbergst...@nvidia.com wrote:
You're right in that binding to a sub-device is not a nice way. DRM
framework just needs a struct device to bind to. exynos seems to solve
this by introducing a virtual device and bind to that. I'm not sure if
this
On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote:
On 05.12.2012 13:13, Thierry Reding wrote:
[...]
Oh well, at the time nobody from NVIDIA was involved so I wrote that
code in preparation for proper host1x support that I thought I would
have to add myself at some point. I'm
On Wed, Dec 5, 2012 at 1:03 PM, Daniel Vetter dan...@ffwll.ch wrote:
On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström tbergst...@nvidia.com
wrote:
You're right in that binding to a sub-device is not a nice way. DRM
framework just needs a struct device to bind to. exynos seems to solve
this
On Wed, Dec 05, 2012 at 01:03:14PM +0100, Daniel Vetter wrote:
On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström tbergst...@nvidia.com
wrote:
You're right in that binding to a sub-device is not a nice way. DRM
framework just needs a struct device to bind to. exynos seems to solve
this by
On Wed, Dec 5, 2012 at 1:22 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
Maybe something more elaborate could help, though. Suppose we add
functionality to DRM to instantiate a DRM device. We could call such a
function from the host1x driver to add a device which the tegra-drm
On Wed, Dec 05, 2012 at 01:31:54PM +0100, Daniel Vetter wrote:
On Wed, Dec 5, 2012 at 1:22 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
Maybe something more elaborate could help, though. Suppose we add
functionality to DRM to instantiate a DRM device. We could call such a
On 05.12.2012 14:04, Thierry Reding wrote:
On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote:
Yes, but there's more. For instance I went to great lengths to make sure
there's no global data whatsoever. So all the data is bound to the
host1x device in the current code. I know many
On Wed, Dec 5, 2012 at 2:28 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
Imo that's worse, since now drm manages even more of the driver-hw
binding process. In my dream world the drm driver just registers a
normal driver at module load time directly with whatever bus it's
On Wed, Dec 05, 2012 at 05:34:30PM +0100, Daniel Vetter wrote:
On Wed, Dec 5, 2012 at 2:28 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
Imo that's worse, since now drm manages even more of the driver-hw
binding process. In my dream world the drm driver just registers a
normal
From: Arto Merilainen
This patch removes the redundant host1x driver from tegradrm and
makes necessary bindings to the separate host driver.
This modification introduces a regression: Because there is no
general framework for attaching separate devices into the
same address space, this patch
From: Arto Merilainen amerilai...@nvidia.com
This patch removes the redundant host1x driver from tegradrm and
makes necessary bindings to the separate host driver.
This modification introduces a regression: Because there is no
general framework for attaching separate devices into the
same
98 matches
Mail list logo
