Prev: ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
Next: crypto / device-mapper regression.
From: Daniel Walker on 1 Jul 2010 19:00
On Fri, 2010-07-02 at 08:36 +1000, Dave Airlie wrote:
> On Fri, Jul 2, 2010 at 8:10 AM, Dave Airlie <airlied(a)gmail.com> wrote:
> > Now this is just my opinion as maintainer of the drm, and doesn't
> > reflect anyone or any official policy, I've also no idea if Linus
> > agrees or not.
> >
> > We are going to start to see a number of companies in the embedded
> > space submitting 3D drivers for mobile devices to the kernel. I'd like
> > to clarify my position once so they don't all come asking the same
> > questions.
> >
> > If you aren't going to create an open userspace driver (either MIT or
> > LGPL) then don't waste time submitting a kernel driver to me.

If , for whatever reason, you changed you mind on this what sort of
connection between kernel and userspace would these components use?

I ask only because I think UIO hold most (if not all) the driver in
userspace .. So you would have to use some other interface if you wanted
a more half and half solution ..

Daniel

--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Walker on 1 Jul 2010 19:30
On Fri, 2010-07-02 at 08:57 +1000, Dave Airlie wrote:
> On Fri, Jul 2, 2010 at 8:51 AM, Daniel Walker <dwalker(a)codeaurora.org> wrote:
> > On Fri, 2010-07-02 at 08:36 +1000, Dave Airlie wrote:
> >> On Fri, Jul 2, 2010 at 8:10 AM, Dave Airlie <airlied(a)gmail.com> wrote:
> >> > Now this is just my opinion as maintainer of the drm, and doesn't
> >> > reflect anyone or any official policy, I've also no idea if Linus
> >> > agrees or not.
> >> >
> >> > We are going to start to see a number of companies in the embedded
> >> > space submitting 3D drivers for mobile devices to the kernel. I'd like
> >> > to clarify my position once so they don't all come asking the same
> >> > questions.
> >> >
> >> > If you aren't going to create an open userspace driver (either MIT or
> >> > LGPL) then don't waste time submitting a kernel driver to me.
> >
> > If , for whatever reason, you changed you mind on this what sort of
> > connection between kernel and userspace would these components use?
> >
> > I ask only because I think UIO hold most (if not all) the driver in
> > userspace .. So you would have to use some other interface if you wanted
> > a more half and half solution ..
> >
>
> The thing is UIO doesn't solve the problem 3D graphics drivers need to
> solve. Which is we need to let unprivileged users access the graphics
> device in an efficient manner, hence why DRI/DRM exists. Now I think
> the tegra guys have done some evil hacks with a userspace daemon to
> replace the kernel functionality, so all they have in-kernel is a
> framebuffer device, since they can't really get away with shipping the
> binary nvidia driver linked to the kernel in a real device. So all
> their userspace closed bits talk to the daemon running as root with
> direct access to the lowlevel hw.

Oh, man .. It seems like any driver model that straddles userspace and
kernel space is kind of asking for trouble (my opinion anyway)..

Would you accept a userspace component that supported some subset of the
features ? You would have a kernel space driver, and userspace both open
source and GPL'd , but the userspace component wouldn't support ever
feature available .. Then the company would be free to make another
proprietary userspace with more features based off the open source one.

Daniel
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Dave Airlie on 1 Jul 2010 22:50
On Thu, 2010-07-01 at 20:42 -0400, Timothy Meade wrote:
> ---------- Forwarded message ----------

> Hello. I've been working with the developers on the htc-linux project
> and following the progress of Android on MSM devices closely for a few
> years. I've been excitied to see DRM/DRI replace PMEM and the Android
> specific interfaces be replaced with more Linux-like ones. The Xorg
> driver from Qualcomm uses this same interface for 2D and it's possible
> that Android will take the same approach, though it uses 3D and GLES
> as a type of abstraction layer for surfaceflinger. This allows for a
> closed 3D driver with an open command submission layer that is in
> itself not that different from the split for ATI devices using
> radeonhd. I say this because the alternative for these devices is a
> fully closed binary and secrecy surrounding the graphics layers that
> ensures that only the OS that ships with the device can ever really be
> used and preventing those non-coorporate developers as myself from
> utilising GPL code the way we want or even usuing are own cell phones
> (in this case). I would choose a fully open, X based OS even if that
> meant only having 2D drivers, but I know that Quic and others aren't
> going to develop just a (accelerated) 2D driver, not the kernel
> components or userspace but instead rely on the same GLES layer that
> Android uses, essentially making X and open environments a second
> class citizen on modern mobile hardware.

The thing is you are prevented from using the GPU the way you want,
telling you how to send commands and get irqs from a device but not
telling you what those commands means is limiting you. So you can use it
a framebuffer device, you can do that with a 500 line fbdev driver most
likely, we don't need the maintainer burden of the other 5000 lines of
code that are only in the driver to service some 3D userspace binary
blob.

The radeon example is pointless since all pieces in that system are open
even if AMD can't/won't disclose how certain parts of the GPU work, we
have access to nearly all the functionality, we control all the open
pieces and if someone reverse engineers it, AMD have to accept it.

There is no point supporting companies that give you a little bit of
information in exchange they want the support that being in a mainline
kernel gives. Its an unfair exchange of knowledge and time, and if they
claim they have to make a profit then its even more unfair.

Dave.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Piotr Gluszenia Slawinski on 1 Jul 2010 23:10
> There is no point supporting companies that give you a little bit of
> information in exchange they want the support that being in a mainline
> kernel gives. Its an unfair exchange of knowledge and time, and if they
> claim they have to make a profit then its even more unfair.

also, they seem to do it quite wrong way. i.e. much simpler would be to
just implement regular, open driver , and implement additional crypto
mechanism in chipset itself, allowing to use simple userspace program
sending certified keys allowing GPU to operate.
if key is not available and device/driver not paid/registered, then
GPU would simply lock itself , similiar to pre-paid designs from
company whose name should not be spoken aloud.

also certain functionality could be ordered with same chip structure,
i.e. framebuffer, unaccelerated 2d, accel 2d, 3d, etc.
with user buying proper 'entry level' pre-paid code set from manufacturer.

this would provide quite same functionality (profit), without impacting
open-source projects like Xorg with unnessesary complications.


--

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Howard Chu on 2 Jul 2010 01:00
Piotr Gluszenia Slawinski wrote:
>> There is no point supporting companies that give you a little bit of
>> information in exchange they want the support that being in a mainline
>> kernel gives. Its an unfair exchange of knowledge and time, and if they
>> claim they have to make a profit then its even more unfair.
>
> also, they seem to do it quite wrong way. i.e. much simpler would be to
> just implement regular, open driver , and implement additional crypto
> mechanism in chipset itself, allowing to use simple userspace program
> sending certified keys allowing GPU to operate.
> if key is not available and device/driver not paid/registered, then
> GPU would simply lock itself , similiar to pre-paid designs from
> company whose name should not be spoken aloud.
>
> also certain functionality could be ordered with same chip structure,
> i.e. framebuffer, unaccelerated 2d, accel 2d, 3d, etc.
> with user buying proper 'entry level' pre-paid code set from manufacturer.
>
> this would provide quite same functionality (profit), without impacting
> open-source projects like Xorg with unnessesary complications.

Pardon me for intruding in this discussion, but I'm astonished that you
actually find what you posted to be acceptable. If I pay for a piece of
hardware, I have the right to use it. Requiring certified keys before it
performs the function for which it was purchased is pure nonsense.

--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 |  Next  |  Last
Pages: 1 2
Prev: ARM: 6166/1: Proper prefetch abort handling on pre-ARMv6
Next: crypto / device-mapper regression.