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 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 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
>>- extr
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 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
>>- extr
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 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 more
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 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
>
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 becau
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 becau
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 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 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(),
- d
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 le
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 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
> re
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
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
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 sta
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
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 sta
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 le
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 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 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) tegr
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
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
> re
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) tegr
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
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
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 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
>> d
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
>> d
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 w
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 w
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 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 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 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 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 somethi
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 somethi
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 host
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 host
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 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 d
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 m
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 d
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, howeve
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, howeve
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 m
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 m
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 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 m
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 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 an
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 an
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 loa
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 loa
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 m
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 i
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 dri
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 driv
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 woul
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 a
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 dev
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.
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 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 cli
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 b
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 frame
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 i
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 m
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 dri
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 woul
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 a
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 dev
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.
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 host1x
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 driv
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 cli
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 b
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 frame
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 rem
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 rem
98 matches
Mail list logo
