Alan,
I still stand by my assertion that educating companies as to the
realities and philosophies of open source is better than threatening them.
Your analogy of open source as a standard, a practical de facto standard
written in a programming language is a good one.Forking code (
> way to behave. The best way to get companies to change their behaviour is
> to find them and support them. Making threatening GPL noises in email does
> not help them in any way.
I would disagree based on years of history.
The best way to get a company to change behaviour is for a situati
> The GPLv2 is written such that the "if you're interfacing the kernel
> or compiler you don't need to opensource that bit with your app"
I would suggest you re-read the license. It says nothing of the sort.
Indeed the gcc compiler licensing for the compiler support library is
actually rather care
On Mon, Dec 20, 2010 at 10:18:21AM -0600, Matt Sealey wrote:
> Ownership of the code is dependent on who licensed it. I do not think
> Linaro need be so concerned over opensourcing or reimplementing
> drivers. The fact that the kernel driver is open source as it is, and
> this is by far the most im
Alan,
I still stand by my assertion that educating companies as to the
realities and philosophies of open source is better than threatening them.
Your analogy of open source as a standard, a practical de facto standard
written in a programming language is a good one.Forking code (
> way to behave. The best way to get companies to change their behaviour is
> to find them and support them. Making threatening GPL noises in email does
> not help them in any way.
I would disagree based on years of history.
The best way to get a company to change behaviour is for a situati
> The GPLv2 is written such that the "if you're interfacing the kernel
> or compiler you don't need to opensource that bit with your app"
I would suggest you re-read the license. It says nothing of the sort.
Indeed the gcc compiler licensing for the compiler support library is
actually rather care
On Mon, Dec 20, 2010 at 10:18:21AM -0600, Matt Sealey wrote:
> Ownership of the code is dependent on who licensed it. I do not think
> Linaro need be so concerned over opensourcing or reimplementing
> drivers. The fact that the kernel driver is open source as it is, and
> this is by far the most im
>
> I'm not advocating that closed source drivers be included in the
> kernel, but IMHO,
> having an open kernel-space driver would also help the reverse engineering
> process at the same time as allowing common users as well as developers to
> use and test any 3D applications -don't forget that 3D
Le mercredi 22 d?cembre 2010 ? 15:29 -0500, Nicolas Pitre a ?crit :
> It is
> not economically viable for the Open Source community to accommodate
> proprietary drivers, irrespective of how loud you might advocate for
> that.
I think you can remove the word "economically" from your sentence (or
On 22 December 2010 21:22, Nicolas Pitre wrote:
> Having accommodations in the kernel for proprietary drivers is not a
> mutual benefit anymore. ?That might be hard to understand from your
> point of view, but the incentives in the Open Source communities aren't
> based on commercial results.
DIS
> it would take until a beta driver appears? 1 year? 2 years? And what will
> happen
> in the meantime?
plainly.some other company will take over the market, and sell products
with open drivers available.
in meantime arm devices can still be used for i.e. dataloggers, especially
without linux su
> On 22 December 2010 20:39, Piotr Gluszenia Slawinski
> wrote:
>>> So to say that the corporate world might need to consider Open Source to
>>> be competitive and survive, but the reverse is not true i.e. Open Source
>>> doesn't _require_ the corporate world to survive.
>>
>> i agree with it full
On 22 December 2010 20:39, Piotr Gluszenia Slawinski
wrote:
>> So to say that the corporate world might need to consider Open Source to
>> be competitive and survive, but the reverse is not true i.e. Open Source
>> doesn't _require_ the corporate world to survive.
>
> i agree with it fully, and to
> So to say that the corporate world might need to consider Open Source to
> be competitive and survive, but the reverse is not true i.e. Open Source
> doesn't _require_ the corporate world to survive.
i agree with it fully, and to support this claim i want to remind the
simple rule of capital acc
On Thu, 23 Dec 2010, Xavier Bestel wrote:
> Le mercredi 22 d?cembre 2010 ? 15:29 -0500, Nicolas Pitre a ?crit :
> > It is
> > not economically viable for the Open Source community to accommodate
> > proprietary drivers, irrespective of how loud you might advocate for
> > that.
>
> I think you
On Thu, 23 Dec 2010, Xavier Bestel wrote:
> Le mercredi 22 décembre 2010 à 15:29 -0500, Nicolas Pitre a écrit :
> > It is
> > not economically viable for the Open Source community to accommodate
> > proprietary drivers, irrespective of how loud you might advocate for
> > that.
>
> I think you
Le mercredi 22 décembre 2010 à 15:29 -0500, Nicolas Pitre a écrit :
> It is
> not economically viable for the Open Source community to accommodate
> proprietary drivers, irrespective of how loud you might advocate for
> that.
I think you can remove the word "economically" from your sentence (or
On Wed, 22 Dec 2010, Konstantinos Margaritis wrote:
> On 22 December 2010 21:22, Nicolas Pitre wrote:
> > Having accommodations in the kernel for proprietary drivers is not a
> > mutual benefit anymore. ?That might be hard to understand from your
> > point of view, but the incentives in the Open
On Wed, 22 Dec 2010, Konstantinos Margaritis wrote:
> On 22 December 2010 20:39, Piotr Gluszenia Slawinski
> wrote:
> >> So to say that the corporate world might need to consider Open Source to
> >> be competitive and survive, but the reverse is not true i.e. Open Source
> >> doesn't _require_ th
On Wed, Dec 22, 2010 at 6:02 AM, Konstantinos Margaritis
wrote:
> On 22 December 2010 09:51, Matt Sealey wrote:
>> Okay I hereby refrain from legal comments.
>>
>> In any case, this code has passed legal at Freescale and AMD *AND*
>> Qualcomm. It would not be GPL if it has not been vetted (and it
On Wed, 22 Dec 2010, Tom Gall wrote:
> The very important part of this whole discussion is getting arm Linux and it's
> 3d driver situation so it TOO is the best.
>
> Right now it's not and pointing to other elements of the system and saying
> "it's great" is besides the point.
My whole point, i
On 22 December 2010 09:51, Matt Sealey wrote:
> Okay I hereby refrain from legal comments.
>
> In any case, this code has passed legal at Freescale and AMD *AND*
> Qualcomm. It would not be GPL if it has not been vetted (and it took
> them a year to get to this point).
It appears that this discus
On Wed, Dec 22, 2010 at 11:54 AM, Piotr Gluszenia Slawinski
wrote:
>> you have two pieces of code, a userspace 3D *driver* (not
>> application), and a kernel driver talking to the hw, if the userspace
>> 3D driver cannot exist without the kernel driver, it could very well
>> be considered a deriva
it would take until a beta driver appears? 1 year? 2 years? And what will happen
in the meantime?
plainly.some other company will take over the market, and sell products
with open drivers available.
in meantime arm devices can still be used for i.e. dataloggers, especially
without linux suppor
On Wed, 22 Dec 2010, Konstantinos Margaritis wrote:
> On 22 December 2010 21:22, Nicolas Pitre wrote:
> > Having accommodations in the kernel for proprietary drivers is not a
> > mutual benefit anymore. That might be hard to understand from your
> > point of view, but the incentives in the Open
On 22 December 2010 20:39, Piotr Gluszenia Slawinski
wrote:
So to say that the corporate world might need to consider Open Source to
be competitive and survive, but the reverse is not true i.e. Open Source
doesn't _require_ the corporate world to survive.
i agree with it fully, and to support
On Wed, 22 Dec 2010, David Rusling wrote:
> Now for a bit of a rant. Personally, I have a deep and abiding
> respect for open source (for me, it's the key social invention of the
> internet age), however I also recognise that it would not exist
> without companies using open source as pa
>
> I'm not advocating that closed source drivers be included in the
> kernel, but IMHO,
> having an open kernel-space driver would also help the reverse engineering
> process at the same time as allowing common users as well as developers to
> use and test any 3D applications -don't forget that 3D
Konstantinos,
thanks, I agree with your thoughts. My approach has been to accept
small steps in the right direction and encourage reasoned discussion. I also
think that Linaro's main function is as a place where all the moving parts can
collaborate.Right now, the GPU 'problem' is
On 22 December 2010 21:22, Nicolas Pitre wrote:
> Having accommodations in the kernel for proprietary drivers is not a
> mutual benefit anymore. That might be hard to understand from your
> point of view, but the incentives in the Open Source communities aren't
> based on commercial results.
DIS
On Wed, Dec 22, 2010 at 11:20 AM, Nicolas Pitre
wrote:
> On Wed, 22 Dec 2010, David Rusling wrote:
>
>> ? ? ? Now for a bit of a rant. ?Personally, I have a deep and abiding
>> respect for open source (for me, it's the key social invention of the
>> internet age), however I also recognise that it
On Wed, Dec 22, 2010 at 3:29 AM, Matt Sealey wrote:
> On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann wrote:
>> On Tuesday 21 December 2010 03:17:40 Piotr Gluszenia Slawinski wrote:
>>> On Mon, 20 Dec 2010, Alan Cox wrote:
>>>
>>> >> My point which people keep missing is that graphics stacks are a
On Wed, 22 Dec 2010, Konstantinos Margaritis wrote:
> On 22 December 2010 20:39, Piotr Gluszenia Slawinski
> wrote:
> >> So to say that the corporate world might need to consider Open Source to
> >> be competitive and survive, but the reverse is not true i.e. Open Source
> >> doesn't _require_ th
On 22 December 2010 20:39, Piotr Gluszenia Slawinski
wrote:
>> So to say that the corporate world might need to consider Open Source to
>> be competitive and survive, but the reverse is not true i.e. Open Source
>> doesn't _require_ the corporate world to survive.
>
> i agree with it fully, and to
So to say that the corporate world might need to consider Open Source to
be competitive and survive, but the reverse is not true i.e. Open Source
doesn't _require_ the corporate world to survive.
i agree with it fully, and to support this claim i want to remind the
simple rule of capital accumul
On Wed, Dec 22, 2010 at 11:20 AM, Nicolas Pitre
wrote:
> On Wed, 22 Dec 2010, David Rusling wrote:
>
>> Now for a bit of a rant. Personally, I have a deep and abiding
>> respect for open source (for me, it's the key social invention of the
>> internet age), however I also recognise that it
On Wed, Dec 22, 2010 at 6:02 AM, Konstantinos Margaritis
wrote:
> On 22 December 2010 09:51, Matt Sealey wrote:
>> Okay I hereby refrain from legal comments.
>>
>> In any case, this code has passed legal at Freescale and AMD *AND*
>> Qualcomm. It would not be GPL if it has not been vetted (and it
On Wed, 22 Dec 2010, Tom Gall wrote:
> The very important part of this whole discussion is getting arm Linux and it's
> 3d driver situation so it TOO is the best.
>
> Right now it's not and pointing to other elements of the system and saying
> "it's great" is besides the point.
My whole point, i
On Wed, 22 Dec 2010, David Rusling wrote:
> Now for a bit of a rant. Personally, I have a deep and abiding
> respect for open source (for me, it's the key social invention of the
> internet age), however I also recognise that it would not exist
> without companies using open source as pa
Konstantinos,
thanks, I agree with your thoughts. My approach has been to accept
small steps in the right direction and encourage reasoned discussion. I also
think that Linaro's main function is as a place where all the moving parts can
collaborate.Right now, the GPU 'problem' is
On 22 December 2010 09:51, Matt Sealey wrote:
> Okay I hereby refrain from legal comments.
>
> In any case, this code has passed legal at Freescale and AMD *AND*
> Qualcomm. It would not be GPL if it has not been vetted (and it took
> them a year to get to this point).
It appears that this discus
> You need to read before replying.
>
> If the interface is a generic interface that any software can use then
> its fine, when the interface is a specific interface for a specific
> closed userspace driver it becomes questionable.
>
> Again you are thinking general case when we are talking specifi
> you have two pieces of code, a userspace 3D *driver* (not
> application), and a kernel driver talking to the hw, if the userspace
> 3D driver cannot exist without the kernel driver, it could very well
> be considered a derivative work of the kernel driver. You are not
> protected by the standard
Okay I hereby refrain from legal comments.
In any case, this code has passed legal at Freescale and AMD *AND*
Qualcomm. It would not be GPL if it has not been vetted (and it took
them a year to get to this point).
--
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
On Tue, Dec 21, 2
Okay I hereby refrain from legal comments.
In any case, this code has passed legal at Freescale and AMD *AND*
Qualcomm. It would not be GPL if it has not been vetted (and it took
them a year to get to this point).
--
Matt Sealey
Product Development Analyst, Genesi USA, Inc.
On Tue, Dec 21, 2
On Tuesday 21 December 2010 18:29:56 Matt Sealey wrote:
> > The only thing that is currently being enforced is that no interfaces enter
> > the mainline kernel that rely on closed source user space. Once something
> > is merged in mainline, you are generally free to write code under any
> > licens
You need to read before replying.
If the interface is a generic interface that any software can use then
its fine, when the interface is a specific interface for a specific
closed userspace driver it becomes questionable.
Again you are thinking general case when we are talking specifics.
thank
On Wed, Dec 22, 2010 at 11:54 AM, Piotr Gluszenia Slawinski
wrote:
>> you have two pieces of code, a userspace 3D *driver* (not
>> application), and a kernel driver talking to the hw, if the userspace
>> 3D driver cannot exist without the kernel driver, it could very well
>> be considered a deriva
you have two pieces of code, a userspace 3D *driver* (not
application), and a kernel driver talking to the hw, if the userspace
3D driver cannot exist without the kernel driver, it could very well
be considered a derivative work of the kernel driver. You are not
protected by the standard Linux sys
On Wed, Dec 22, 2010 at 3:29 AM, Matt Sealey wrote:
> On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann wrote:
>> On Tuesday 21 December 2010 03:17:40 Piotr Gluszenia Slawinski wrote:
>>> On Mon, 20 Dec 2010, Alan Cox wrote:
>>>
>>> >> My point which people keep missing is that graphics stacks are a
On Tuesday 21 December 2010 03:17:40 Piotr Gluszenia Slawinski wrote:
> On Mon, 20 Dec 2010, Alan Cox wrote:
>
> >> My point which people keep missing is that graphics stacks are a
> >> single entity, that span kernel and userspace, one cannot exist
> >> without the other, and there are interfaces
On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann wrote:
> On Tuesday 21 December 2010 03:17:40 Piotr Gluszenia Slawinski wrote:
>> On Mon, 20 Dec 2010, Alan Cox wrote:
>>
>> >> My point which people keep missing is that graphics stacks are a
>> >> single entity, that span kernel and userspace, one c
On Tuesday 21 December 2010 18:29:56 Matt Sealey wrote:
> > The only thing that is currently being enforced is that no interfaces enter
> > the mainline kernel that rely on closed source user space. Once something
> > is merged in mainline, you are generally free to write code under any
> > licens
On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann wrote:
> On Tuesday 21 December 2010 03:17:40 Piotr Gluszenia Slawinski wrote:
>> On Mon, 20 Dec 2010, Alan Cox wrote:
>>
>> >> My point which people keep missing is that graphics stacks are a
>> >> single entity, that span kernel and userspace, one c
>
> The concerns about host memory access via the GPU driver are valid but
> unnecessary. The GPU MMU directly intervenes on memory access and can
> only modify memory space allocated to the GPU resource - getting data
> into this memory requires some extreme manual intervention if not done
> by th
On Tuesday 21 December 2010 03:17:40 Piotr Gluszenia Slawinski wrote:
> On Mon, 20 Dec 2010, Alan Cox wrote:
>
> >> My point which people keep missing is that graphics stacks are a
> >> single entity, that span kernel and userspace, one cannot exist
> >> without the other, and there are interfaces
On Mon, 20 Dec 2010, Alan Cox wrote:
>> My point which people keep missing is that graphics stacks are a
>> single entity, that span kernel and userspace, one cannot exist
>> without the other, and there are interfaces that join them.
>
> As a copyright holder on the kernel I'll also remind the pe
On Monday 20 December 2010 19:07:30 Jerome Glisse wrote:
> > I also do not think that it is at all kernel policy to disallow kernel
> > drivers which do not have opensource userspace components. In fact,
> > Linus Torvalds begs to differ on this matter. The fact of the matter
> > is that the driver
> I also do not think that it is at all kernel policy to disallow kernel
> drivers which do not have opensource userspace components. In fact,
Wrong. The PVR graphics (as used by some Intel embedded for example) is
also not in the kernel for the same reason, ditto some sensor and GPS
devices which
> My point which people keep missing is that graphics stacks are a
> single entity, that span kernel and userspace, one cannot exist
> without the other, and there are interfaces that join them.
As a copyright holder on the kernel I'll also remind the people concerned
that the definition of a deri
On Mon, 20 Dec 2010, Alan Cox wrote:
My point which people keep missing is that graphics stacks are a
single entity, that span kernel and userspace, one cannot exist
without the other, and there are interfaces that join them.
As a copyright holder on the kernel I'll also remind the people conc
On Mon, Dec 20, 2010 at 12:41 PM, Matt Sealey wrote:
> On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse wrote:
>> On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey wrote:
>>> On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann wrote:
On Monday 13 December 2010, Jammy Zhou wrote:
> On Mon, Dec 13
On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey wrote:
> On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann wrote:
>> On Monday 13 December 2010, Jammy Zhou wrote:
>>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij >> linaro.org>wrote:
>>>
>>> > On 11 December 2010 22:41, Arnd Bergmann wrote:
>>> >
>>
> I also do not think that it is at all kernel policy to disallow kernel
> drivers which do not have opensource userspace components. In fact,
Wrong. The PVR graphics (as used by some Intel embedded for example) is
also not in the kernel for the same reason, ditto some sensor and GPS
devices which
> My point which people keep missing is that graphics stacks are a
> single entity, that span kernel and userspace, one cannot exist
> without the other, and there are interfaces that join them.
As a copyright holder on the kernel I'll also remind the people concerned
that the definition of a deri
>
> The concerns about host memory access via the GPU driver are valid but
> unnecessary. The GPU MMU directly intervenes on memory access and can
> only modify memory space allocated to the GPU resource - getting data
> into this memory requires some extreme manual intervention if not done
> by th
On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse wrote:
> On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey wrote:
>> On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann wrote:
>>> On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij >>> linaro.org>wrote:
On Monday 20 December 2010 19:07:30 Jerome Glisse wrote:
> > I also do not think that it is at all kernel policy to disallow kernel
> > drivers which do not have opensource userspace components. In fact,
> > Linus Torvalds begs to differ on this matter. The fact of the matter
> > is that the driver
On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann wrote:
> On Monday 13 December 2010, Jammy Zhou wrote:
>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij > linaro.org>wrote:
>>
>> > On 11 December 2010 22:41, Arnd Bergmann wrote:
>> >
>> > * amd-gpu -- a single but huge driver for the GPU. As is no
On Mon, Dec 20, 2010 at 12:41 PM, Matt Sealey wrote:
> On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse wrote:
>> On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey wrote:
>>> On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann wrote:
On Monday 13 December 2010, Jammy Zhou wrote:
> On Mon, Dec 13
On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse wrote:
> On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey wrote:
>> On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann wrote:
>>> On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij
wrote:
> On
On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey wrote:
> On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann wrote:
>> On Monday 13 December 2010, Jammy Zhou wrote:
>>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij
>>> wrote:
>>>
>>> > On 11 December 2010 22:41, Arnd Bergmann wrote:
>>> >
>>> > * amd
On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann wrote:
> On Monday 13 December 2010, Jammy Zhou wrote:
>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij
>> wrote:
>>
>> > On 11 December 2010 22:41, Arnd Bergmann wrote:
>> >
>> > * amd-gpu -- a single but huge driver for the GPU. As is normally th
On Tue, Dec 14, 2010 at 1:18 AM, Arnd Bergmann wrote:
> On Monday 13 December 2010, Jammy Zhou wrote:
>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij > linaro.org>wrote:
>>
>> > On 11 December 2010 22:41, Arnd Bergmann wrote:
>> >
>> > * amd-gpu -- a single but huge driver for the GPU. As is no
On Tuesday 14 December 2010, Eric Miao wrote:
> >>
> >> Until there is a solution with an open source user space part, I would
> >> suggest that the driver better be dropped from the Freescale BSP and
> >> we should at least not waste time reviewing it.
> >
> > I think it is beneficial for us to in
On Tue, Dec 14, 2010 at 9:59 AM, Jammy Zhou wrote:
>
>
> On Mon, Dec 13, 2010 at 11:18 PM, Arnd Bergmann wrote:
>>
>> On Monday 13 December 2010, Jammy Zhou wrote:
>> > On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij
>> > wrote:
>> >
>> > > On 11 December 2010 22:41, Arnd Bergmann wrote:
>> > >
>
On Tue, Dec 14, 2010 at 10:06 AM, Jerome Glisse wrote:
> On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou wrote:
> >
> >
> > On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse
> wrote:
> >>
> >> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann wrote:
> >> > On Monday 13 December 2010, Jammy Zhou wrote:
On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse wrote:
> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann wrote:
> > On Monday 13 December 2010, Jammy Zhou wrote:
> >> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <
> linus.walleij at linaro.org>wrote:
> >>
> >> > On 11 December 2010 22:41, Arnd
Dnia wtorek, 14 grudnia 2010 o 03:35:20 Eric Miao napisa?(a):
> > I think it is beneficial for us to integrate the kernel part into our
> > Linaro tree, so that we can build/use it together with the kernel image.
> > As for the user space libraries, how about adding them into the hwpack?
> > (Is th
On Mon, Dec 13, 2010 at 11:18 PM, Arnd Bergmann wrote:
> On Monday 13 December 2010, Jammy Zhou wrote:
> > On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij >wrote:
> >
> > > On 11 December 2010 22:41, Arnd Bergmann wrote:
> > >
> > > * amd-gpu -- a single but huge driver for the GPU. As is normal
Dnia wtorek, 14 grudnia 2010 o 03:35:20 Eric Miao napisał(a):
> > I think it is beneficial for us to integrate the kernel part into our
> > Linaro tree, so that we can build/use it together with the kernel image.
> > As for the user space libraries, how about adding them into the hwpack?
> > (Is th
On Tuesday 14 December 2010, Eric Miao wrote:
> >>
> >> Until there is a solution with an open source user space part, I would
> >> suggest that the driver better be dropped from the Freescale BSP and
> >> we should at least not waste time reviewing it.
> >
> > I think it is beneficial for us to in
On Tue, Dec 14, 2010 at 1:18 AM, Arnd Bergmann wrote:
> On Monday 13 December 2010, Jammy Zhou wrote:
>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij
>> wrote:
>>
>> > On 11 December 2010 22:41, Arnd Bergmann wrote:
>> >
>> > * amd-gpu -- a single but huge driver for the GPU. As is normally th
On Tue, Dec 14, 2010 at 9:59 AM, Jammy Zhou wrote:
>
>
> On Mon, Dec 13, 2010 at 11:18 PM, Arnd Bergmann wrote:
>>
>> On Monday 13 December 2010, Jammy Zhou wrote:
>> > On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij
>> > wrote:
>> >
>> > > On 11 December 2010 22:41, Arnd Bergmann wrote:
>> > >
>
On Tue, Dec 14, 2010 at 10:06 AM, Jerome Glisse wrote:
> On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou wrote:
> >
> >
> > On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse
> wrote:
> >>
> >> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann wrote:
> >> > On Monday 13 December 2010, Jammy Zhou wrote:
On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse wrote:
> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann wrote:
> > On Monday 13 December 2010, Jammy Zhou wrote:
> >> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <
> linus.wall...@linaro.org>wrote:
> >>
> >> > On 11 December 2010 22:41, Arnd Be
On Mon, Dec 13, 2010 at 11:18 PM, Arnd Bergmann wrote:
> On Monday 13 December 2010, Jammy Zhou wrote:
> > On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij >wrote:
> >
> > > On 11 December 2010 22:41, Arnd Bergmann wrote:
> > >
> > > * amd-gpu -- a single but huge driver for the GPU. As is normal
On Mon, Dec 13, 2010 at 9:30 PM, Jammy Zhou wrote:
>
>
> On Tue, Dec 14, 2010 at 10:06 AM, Jerome Glisse wrote:
>>
>> On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou wrote:
>> >
>> >
>> > On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse
>> > wrote:
>> >>
>> >> On Mon, Dec 13, 2010 at 10:18 AM, Arnd
On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou wrote:
>
>
> On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse wrote:
>>
>> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann wrote:
>> > On Monday 13 December 2010, Jammy Zhou wrote:
>> >> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij
>> >> wrote:
>> >>
On Mon, Dec 13, 2010 at 9:30 PM, Jammy Zhou wrote:
>
>
> On Tue, Dec 14, 2010 at 10:06 AM, Jerome Glisse wrote:
>>
>> On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou wrote:
>> >
>> >
>> > On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse
>> > wrote:
>> >>
>> >> On Mon, Dec 13, 2010 at 10:18 AM, Arnd
On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou wrote:
>
>
> On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse wrote:
>>
>> On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann wrote:
>> > On Monday 13 December 2010, Jammy Zhou wrote:
>> >> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij
>> >> wrote:
>> >>
On Monday 13 December 2010, Jammy Zhou wrote:
> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij linaro.org>wrote:
>
> > On 11 December 2010 22:41, Arnd Bergmann wrote:
> >
> > * amd-gpu -- a single but huge driver for the GPU. As is normally the
> >> case with GPU drivers, we can expe
On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann wrote:
> On Monday 13 December 2010, Jammy Zhou wrote:
>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij > linaro.org>wrote:
>>
>> > On 11 December 2010 22:41, Arnd Bergmann wrote:
>> >
>> > * amd-gpu -- a single but huge driver for the GPU. As is n
On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann wrote:
> On Monday 13 December 2010, Jammy Zhou wrote:
>> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij
>> wrote:
>>
>> > On 11 December 2010 22:41, Arnd Bergmann wrote:
>> >
>> > * amd-gpu -- a single but huge driver for the GPU. As is normally t
On Monday 13 December 2010, Jammy Zhou wrote:
> On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij
> wrote:
>
> > On 11 December 2010 22:41, Arnd Bergmann wrote:
> >
> > * amd-gpu -- a single but huge driver for the GPU. As is normally the
> >> case with GPU drivers, we can expect long d
96 matches
Mail list logo
