From: Daniel Vetter <daniel@ffwll.ch>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Kamil Lulko <kamil.lulko@gmail.com>
Subject: Re: No more new fbdev drivers, please
Date: Fri, 25 Sep 2015 18:44:07 +0000 [thread overview]
Message-ID: <20150925184407.GD3383@phenom.ffwll.local> (raw)
In-Reply-To: <5605479A.2020903@ti.com>
On Fri, Sep 25, 2015 at 04:09:46PM +0300, Tomi Valkeinen wrote:
>
>
> On 25/09/15 13:41, Kamil Lulko wrote:
> > Hi,
> >
> >> fbdev is (more or less) maintained, but it's a deprecated framework. All
> >> new Linux display drivers should be done on DRM.
> >
> > What about no-mmu platforms? DRM has a big fat MMU dependency in the
> > kconfig, is there a way to write DRM driver for such devices?
>
> I guess not.
>
> Then again, I don't see why DRM would have a hard dependency to MMU, if
> the work is done to make DRM work optionally without MMU. How much work
> that is, I have no idea.
We have plenty drivers in drm without hw mmu, and yeah there's probably no
reason at all why the drm subsystem has a hard depency on cpu MMUs. Might
be some #ifdef fallout that needs to be done, but there shouldn't be
anything fundamental. Maybe the old dri1 days code has something, but
that's all historical cruft anyway.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Kamil Lulko <kamil.lulko@gmail.com>
Subject: Re: No more new fbdev drivers, please
Date: Fri, 25 Sep 2015 20:44:07 +0200 [thread overview]
Message-ID: <20150925184407.GD3383@phenom.ffwll.local> (raw)
In-Reply-To: <5605479A.2020903@ti.com>
On Fri, Sep 25, 2015 at 04:09:46PM +0300, Tomi Valkeinen wrote:
>
>
> On 25/09/15 13:41, Kamil Lulko wrote:
> > Hi,
> >
> >> fbdev is (more or less) maintained, but it's a deprecated framework. All
> >> new Linux display drivers should be done on DRM.
> >
> > What about no-mmu platforms? DRM has a big fat MMU dependency in the
> > kconfig, is there a way to write DRM driver for such devices?
>
> I guess not.
>
> Then again, I don't see why DRM would have a hard dependency to MMU, if
> the work is done to make DRM work optionally without MMU. How much work
> that is, I have no idea.
We have plenty drivers in drm without hw mmu, and yeah there's probably no
reason at all why the drm subsystem has a hard depency on cpu MMUs. Might
be some #ifdef fallout that needs to be done, but there shouldn't be
anything fundamental. Maybe the old dri1 days code has something, but
that's all historical cruft anyway.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Kamil Lulko <kamil.lulko@gmail.com>,
Daniel Vetter <daniel@ffwll.ch>,
linux-kernel@vger.kernel.org, linux-fbdev@vger.kernel.org,
dri-devel@lists.freedesktop.org
Subject: Re: No more new fbdev drivers, please
Date: Fri, 25 Sep 2015 20:44:07 +0200 [thread overview]
Message-ID: <20150925184407.GD3383@phenom.ffwll.local> (raw)
In-Reply-To: <5605479A.2020903@ti.com>
On Fri, Sep 25, 2015 at 04:09:46PM +0300, Tomi Valkeinen wrote:
>
>
> On 25/09/15 13:41, Kamil Lulko wrote:
> > Hi,
> >
> >> fbdev is (more or less) maintained, but it's a deprecated framework. All
> >> new Linux display drivers should be done on DRM.
> >
> > What about no-mmu platforms? DRM has a big fat MMU dependency in the
> > kconfig, is there a way to write DRM driver for such devices?
>
> I guess not.
>
> Then again, I don't see why DRM would have a hard dependency to MMU, if
> the work is done to make DRM work optionally without MMU. How much work
> that is, I have no idea.
We have plenty drivers in drm without hw mmu, and yeah there's probably no
reason at all why the drm subsystem has a hard depency on cpu MMUs. Might
be some #ifdef fallout that needs to be done, but there shouldn't be
anything fundamental. Maybe the old dri1 days code has something, but
that's all historical cruft anyway.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
next prev parent reply other threads:[~2015-09-25 18:44 UTC|newest]
Thread overview: 97+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-24 12:27 No more new fbdev drivers, please Tomi Valkeinen
2015-09-24 12:27 ` Tomi Valkeinen
2015-09-24 12:27 ` Tomi Valkeinen
2015-09-24 12:46 ` Thomas Petazzoni
2015-09-24 12:46 ` Thomas Petazzoni
2015-09-24 15:21 ` Austin S Hemmelgarn
2015-09-24 15:21 ` Austin S Hemmelgarn
2015-09-24 15:38 ` Alex Deucher
2015-09-24 15:38 ` Alex Deucher
2015-09-24 15:38 ` Alex Deucher
2015-09-24 15:59 ` Daniel Vetter
2015-09-24 15:59 ` Daniel Vetter
2015-09-24 15:59 ` Daniel Vetter
2015-09-24 16:17 ` Austin S Hemmelgarn
2015-09-24 16:17 ` Austin S Hemmelgarn
2015-09-24 17:12 ` Ondrej Zary
2015-09-24 17:12 ` Ondrej Zary
2015-09-24 17:12 ` Ondrej Zary
2015-09-24 18:05 ` Daniel Vetter
2015-09-24 18:05 ` Daniel Vetter
2015-09-24 18:05 ` Daniel Vetter
2015-09-24 15:23 ` Daniel Vetter
2015-09-24 15:23 ` Daniel Vetter
2015-09-24 15:23 ` Daniel Vetter
2015-09-26 8:28 ` Geert Uytterhoeven
2015-09-26 8:28 ` Geert Uytterhoeven
2015-09-26 8:28 ` Geert Uytterhoeven
2015-09-26 17:07 ` Alex Deucher
2015-09-26 17:07 ` Alex Deucher
2015-09-26 17:07 ` Alex Deucher
2015-09-26 18:01 ` Geert Uytterhoeven
2015-09-26 18:01 ` Geert Uytterhoeven
2015-09-26 18:01 ` Geert Uytterhoeven
2015-09-26 18:13 ` David Herrmann
2015-09-26 18:13 ` David Herrmann
2015-09-26 18:13 ` David Herrmann
2015-09-26 18:46 ` Geert Uytterhoeven
2015-09-26 18:46 ` Geert Uytterhoeven
2015-09-26 18:46 ` Geert Uytterhoeven
2015-09-26 20:49 ` Rob Clark
2015-09-26 20:49 ` Rob Clark
2015-09-26 20:49 ` Rob Clark
2015-09-26 21:55 ` Dave Airlie
2015-09-26 21:55 ` Dave Airlie
2015-09-30 11:59 ` Emil Velikov
2015-09-30 11:59 ` Emil Velikov
2015-09-28 7:39 ` Gerd Hoffmann
2015-09-28 7:39 ` Gerd Hoffmann
2015-09-28 7:39 ` Gerd Hoffmann
2015-09-28 12:36 ` Daniel Vetter
2015-09-28 12:36 ` Daniel Vetter
2015-09-28 12:36 ` Daniel Vetter
2015-09-29 8:23 ` Gerd Hoffmann
2015-09-29 8:23 ` Gerd Hoffmann
2015-09-29 8:23 ` Gerd Hoffmann
2015-09-29 8:33 ` Laurent Pinchart
2015-09-29 8:33 ` Laurent Pinchart
2015-09-29 8:33 ` Laurent Pinchart
2015-09-28 20:52 ` Bernie Thompson
2015-09-29 7:05 ` Daniel Vetter
2015-09-29 7:05 ` Daniel Vetter
2015-09-29 7:05 ` Daniel Vetter
2015-09-28 20:56 ` Bernie Thompson
2015-09-28 20:56 ` Bernie Thompson
2015-09-25 8:49 ` Aaro Koskinen
2015-09-25 8:49 ` Aaro Koskinen
2015-09-25 11:00 ` Ondrej Zary
2015-09-25 11:00 ` Ondrej Zary
2015-09-25 11:00 ` Ondrej Zary
2015-09-25 10:41 ` Kamil Lulko
2015-09-25 10:41 ` Kamil Lulko
2015-09-25 13:09 ` Tomi Valkeinen
2015-09-25 13:09 ` Tomi Valkeinen
2015-09-25 13:09 ` Tomi Valkeinen
2015-09-25 18:44 ` Daniel Vetter [this message]
2015-09-25 18:44 ` Daniel Vetter
2015-09-25 18:44 ` Daniel Vetter
2015-09-26 9:03 ` Geert Uytterhoeven
2015-09-26 9:03 ` Geert Uytterhoeven
2015-09-26 9:03 ` Geert Uytterhoeven
2015-09-26 7:15 ` Sudip Mukherjee
2015-09-26 7:27 ` Sudip Mukherjee
2015-09-26 7:15 ` Sudip Mukherjee
2015-09-26 7:29 ` Ilia Mirkin
2015-09-26 7:29 ` Ilia Mirkin
2015-09-26 7:29 ` Ilia Mirkin
2015-09-27 13:09 ` Noralf Trønnes
2015-09-27 13:09 ` Noralf Trønnes
2015-09-27 16:08 ` Emil Velikov
2015-09-27 16:08 ` Emil Velikov
2015-09-27 16:08 ` Emil Velikov
2015-09-28 22:51 ` Noralf Trønnes
2015-09-28 22:51 ` Noralf Trønnes
2015-09-28 22:51 ` Noralf Trønnes
2015-09-29 7:07 ` Daniel Vetter
2015-09-29 7:07 ` Daniel Vetter
2015-09-29 7:07 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150925184407.GD3383@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=kamil.lulko@gmail.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tomi.valkeinen@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.