Following a discussion we had on the Freescale BSP, I started a tree at http://git.linaro.org/gitweb?p=people/arnd/imx.git%3Ba=summary that has the same contents as the tree on the freescale git server, but splits them into six branches at this time, though the number should increase.
The current split is
* master -- an octopus merge of all the other branches, identical to the BSP 381 patches total 1286 files changed, 882747 insertions(+), 2932 deletions(-)
* drv-mxc -- all drivers in the new drivers/mxc/ directory and new drivers in drivers/char/, as these typically introduce new user ABIs that need very careful review. 23 patches 189 files changed, 97215 insertions(+), 0 deletions(-)
* amd-gpu -- a single but huge driver for the GPU. As is normally the case with GPU drivers, we can expect long discussions before it will get considered for mainline 4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
* ath -- another single driver that is rather large, for the ath6km wifi controller. Split out because it is not owned by freescale. 4 patches 169 files changed, 94561 insertions(+), 0 deletions(-)
* other-subsys -- device drivers for existing subsystems. These should be largely uncontroversial, because they don't introduce new ABIs and the code looks clean enough for a straight- forward inclusion through the respective subsystem maintainers. Someone still needs to go through these and split them up by subsystem and separate new drivers from patches to existing drivers where needed. 159 patches 445 files changed, 270318 insertions(+), 959 deletions(-)
* arch -- everything in the arch/arm, directory, this will go through review on the linux-arm-kernel mailing list. This also needs to be split up further into smaller branches. 179 patches 378 files changed, 140275 insertions(+), 1991 deletions(-)
* external -- patches that look unrelated to the rest, and are probably backported from patches that already went upstream. 9 patches 7 files changed, 37 insertions(+), 32 deletions(-)
Arnd
On Sun, Dec 12, 2010 at 5:41 AM, Arnd Bergmann arnd@arndb.de wrote:
Following a discussion we had on the Freescale BSP, I started a tree at http://git.linaro.org/gitweb?p=people/arnd/imx.git%3Ba=summary that has the same contents as the tree on the freescale git server,
Arnd,
This is very useful analysis. Just to make sure, are you referring to the linux-2.6-imx.git on
http://opensource.freescale.com/git
And the release of rel_imx_2.6.35_10.10.01?
but splits them into six branches at this time, though the number should increase.
The current split is
- master -- an octopus merge of all the other branches, identical to
the BSP 381 patches total 1286 files changed, 882747 insertions(+), 2932 deletions(-)
- drv-mxc -- all drivers in the new drivers/mxc/ directory and new drivers
in drivers/char/, as these typically introduce new user ABIs that need very careful review. 23 patches 189 files changed, 97215 insertions(+), 0 deletions(-)
- amd-gpu -- a single but huge driver for the GPU. As is normally the
case with GPU drivers, we can expect long discussions before it will get considered for mainline 4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
- ath -- another single driver that is rather large, for the ath6km
wifi controller. Split out because it is not owned by freescale. 4 patches 169 files changed, 94561 insertions(+), 0 deletions(-)
- other-subsys -- device drivers for existing subsystems. These should
be largely uncontroversial, because they don't introduce new ABIs and the code looks clean enough for a straight- forward inclusion through the respective subsystem maintainers. Someone still needs to go through these and split them up by subsystem and separate new drivers from patches to existing drivers where needed. 159 patches 445 files changed, 270318 insertions(+), 959 deletions(-)
- arch -- everything in the arch/arm, directory, this will go through
review on the linux-arm-kernel mailing list. This also needs to be split up further into smaller branches. 179 patches 378 files changed, 140275 insertions(+), 1991 deletions(-)
- external -- patches that look unrelated to the rest, and are probably
backported from patches that already went upstream. 9 patches 7 files changed, 37 insertions(+), 32 deletions(-)
Arnd
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Sunday 12 December 2010 05:11:37 Eric Miao wrote:
On Sun, Dec 12, 2010 at 5:41 AM, Arnd Bergmann arnd@arndb.de wrote:
Following a discussion we had on the Freescale BSP, I started a tree at http://git.linaro.org/gitweb?p=people/arnd/imx.git%3Ba=summary that has the same contents as the tree on the freescale git server,
This is very useful analysis. Just to make sure, are you referring to the linux-2.6-imx.git on
http://opensource.freescale.com/git
And the release of rel_imx_2.6.35_10.10.01?
Yes, that's the one I used.
Arnd
May I ask if a final report will be posted to wiki?
Thanks Yves
From: linaro-dev-bounces@lists.linaro.org [mailto:linaro-dev-bounces@lists.linaro.org] On Behalf Of Eric Miao Sent: Saturday, December 11, 2010 10:12 PM To: Arnd Bergmann Cc: Dave Martin; linaro-dev@lists.linaro.org Subject: Re: Freescale Linux BSP review
On Sun, Dec 12, 2010 at 5:41 AM, Arnd Bergmann arnd@arndb.de wrote:
Following a discussion we had on the Freescale BSP, I started a tree at http://git.linaro.org/gitweb?p=people/arnd/imx.git%3Ba=summary that has the same contents as the tree on the freescale git server,
Arnd,
This is very useful analysis. Just to make sure, are you referring to the linux-2.6-imx.git on
http://opensource.freescale.com/git
And the release of rel_imx_2.6.35_10.10.01?
but splits them into six branches at this time, though the number should increase.
The current split is
- master -- an octopus merge of all the other branches, identical to the BSP
381 patches total 1286 files changed, 882747 insertions(+), 2932 deletions(-)
- drv-mxc -- all drivers in the new drivers/mxc/ directory and new drivers in drivers/char/, as these typically introduce new user ABIs that need very careful review.
23 patches 189 files changed, 97215 insertions(+), 0 deletions(-)
- amd-gpu -- a single but huge driver for the GPU. As is normally the case with GPU drivers, we can expect long discussions before it will get considered for mainline
4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
- ath -- another single driver that is rather large, for the ath6km wifi controller. Split out because it is not owned by freescale.
4 patches 169 files changed, 94561 insertions(+), 0 deletions(-)
- other-subsys -- device drivers for existing subsystems. These should be largely uncontroversial, because they don't introduce new ABIs and the code looks clean enough for a straight- forward inclusion through the respective subsystem maintainers. Someone still needs to go through these and split them up by subsystem and separate new drivers from patches to existing drivers where needed.
159 patches 445 files changed, 270318 insertions(+), 959 deletions(-)
- arch -- everything in the arch/arm, directory, this will go through review on the linux-arm-kernel mailing list. This also needs to be split up further into smaller branches.
179 patches 378 files changed, 140275 insertions(+), 1991 deletions(-)
- external -- patches that look unrelated to the rest, and are probably backported from patches that already went upstream.
9 patches 7 files changed, 37 insertions(+), 32 deletions(-)
Arnd
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Hi,
On Wed, Dec 15, 2010 at 9:06 PM, Vandervennet Yves-R55763 R55763@freescale.com wrote:
May I ask if a final report will be posted to wiki?
Yes, that's certainly the intention.
I'm happy to summarise this thread, but since I'm on holiday now it may not happen until January. Do you need something to be posted sooner?
Cheers ---Dave
Dave,
Nope, January is fine.
Yves
From: Dave Martin [mailto:dave.martin@linaro.org] Sent: Wednesday, December 15, 2010 3:24 PM To: Vandervennet Yves-R55763 Cc: Arnd Bergmann; linaro-dev@lists.linaro.org Subject: Re: Freescale Linux BSP review
Hi,
On Wed, Dec 15, 2010 at 9:06 PM, Vandervennet Yves-R55763 R55763@freescale.com wrote:
May I ask if a final report will be posted to wiki?
Yes, that's certainly the intention.
I'm happy to summarise this thread, but since I'm on holiday now it may not happen until January. Do you need something to be posted sooner?
Cheers ---Dave
On Wednesday 15 December 2010 22:27:24 Vandervennet Yves-R55763 wrote:
On Wed, Dec 15, 2010 at 9:06 PM, Vandervennet Yves-R55763 R55763@freescale.com wrote:
May I ask if a final report will be posted to wiki?
Yes, that's certainly the intention. I'm happy to summarise this thread, but since I'm on holiday now it may not happen until January.
FWIW, I think the most important feedback in my opinion is to split up the tree like I have started. Please go on that way and split it up further, and don't keep adding patches to the big pile any more. I've seen some significant parts getting posted for inclusion, so at the very least, these parts need to be in separate branches as they when in, so it becomes at least possible to keep dragging along the other patches to versions that have parts merged.
Where is the team working on the BSP located? If some people are in Austin, I can meet them on Jan 7th on my way to the sprint, since I'm planning to spend some time there.
Arnd
BTW: Yves, something is badly misconfigured in your email client (HTML, quoting, your name, ...). please fix that.
On 11 December 2010 22:41, Arnd Bergmann arnd@arndb.de wrote:
* amd-gpu -- a single but huge driver for the GPU. As is normally the
case with GPU drivers, we can expect long discussions before it will get considered for mainline4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
Just out of curiosity, following the discussion between Dave Airlie and Codeaurora this summer re GPU driver shims.
Is the AMD GPU exposing all functionality in its kernel driver or is there some userspace blob somewhere with lots of e.g. GL goodies?
Yours, Linus Walleij
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij linus.walleij@linaro.orgwrote:
On 11 December 2010 22:41, Arnd Bergmann arnd@arndb.de wrote:
- amd-gpu -- a single but huge driver for the GPU. As is normally the
case with GPU drivers, we can expect long discussions before it will get considered for mainline4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
Just out of curiosity, following the discussion between Dave Airlie and Codeaurora this summer re GPU driver shims.
Is the AMD GPU exposing all functionality in its kernel driver or is there some userspace blob somewhere with lots of e.g. GL goodies?
All the functionality for the kernel driver of AMD GPU Z430/Z160 (now belongs to Qualcom) is exposed. But we need accompanied userspace library to call these functionality (buffer management, command submission, ...).
Yours, Linus Walleij
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij linus.walleij@linaro.orgwrote:
On 11 December 2010 22:41, Arnd Bergmann arnd@arndb.de wrote:
- amd-gpu -- a single but huge driver for the GPU. As is normally the
case with GPU drivers, we can expect long discussions before it will get considered for mainline4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
Just out of curiosity, following the discussion between Dave Airlie and Codeaurora this summer re GPU driver shims.
Is the AMD GPU exposing all functionality in its kernel driver or is there some userspace blob somewhere with lots of e.g. GL goodies?
All the functionality for the kernel driver of AMD GPU Z430/Z160 (now belongs to Qualcom) is exposed. But we need accompanied userspace library to call these functionality (buffer management, command submission, ...).
Who owns these components? If it's closed source, the only options we have are lobbying for complete release of the specs for a reimplementation or reverse-engineering the drivers, which may at least get easier with a user space driver than it would be with a kernel driver.
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.
Arnd
On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann arnd@arndb.de wrote:
On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij linus.walleij@linaro.orgwrote:
On 11 December 2010 22:41, Arnd Bergmann arnd@arndb.de wrote:
- amd-gpu -- a single but huge driver for the GPU. As is normally the
case with GPU drivers, we can expect long discussions before it will get considered for mainline 4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
Just out of curiosity, following the discussion between Dave Airlie and Codeaurora this summer re GPU driver shims.
Is the AMD GPU exposing all functionality in its kernel driver or is there some userspace blob somewhere with lots of e.g. GL goodies?
All the functionality for the kernel driver of AMD GPU Z430/Z160 (now belongs to Qualcom) is exposed. But we need accompanied userspace library to call these functionality (buffer management, command submission, ...).
Who owns these components? If it's closed source, the only options we have are lobbying for complete release of the specs for a reimplementation or reverse-engineering the drivers, which may at least get easier with a user space driver than it would be with a kernel driver.
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.
Arnd
From a quick look it also seems that the API exposed to userspace
would allow easy abuse of the GPU to access any system ram. There is a reason we do expensive command checking in the other amd gpu driver (drivers/gpu/drm/radeon/*cs.c files)
Cheers, Jerome
On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse j.glisse@gmail.com wrote:
On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann arnd@arndb.de wrote:
On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <
linus.walleij@linaro.org>wrote:
On 11 December 2010 22:41, Arnd Bergmann arnd@arndb.de wrote:
- amd-gpu -- a single but huge driver for the GPU. As is normally the
case with GPU drivers, we can expect long discussions before it will get considered for mainline4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
Just out of curiosity, following the discussion between Dave Airlie and Codeaurora this summer re GPU driver shims.
Is the AMD GPU exposing all functionality in its kernel driver or is there some userspace blob somewhere with lots of e.g. GL goodies?
All the functionality for the kernel driver of AMD GPU Z430/Z160 (now belongs to Qualcom) is exposed. But we need accompanied userspace
library to
call these functionality (buffer management, command submission, ...).
Who owns these components? If it's closed source, the only options we have are lobbying for complete release of the specs for a
reimplementation
or reverse-engineering the drivers, which may at least get easier with a user space driver than it would be with a kernel driver.
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.
ArndFrom a quick look it also seems that the API exposed to userspace would allow easy abuse of the GPU to access any system ram. There is a reason we do expensive command checking in the other amd gpu driver (drivers/gpu/drm/radeon/*cs.c files)
No, the memory used by the GPU is reserved at boot time, so I think there is no such a problem.
Cheers, Jerome
On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou jammy.zhou@linaro.org wrote:
On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse j.glisse@gmail.com wrote:
On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann arnd@arndb.de wrote:
On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij linus.walleij@linaro.orgwrote:
On 11 December 2010 22:41, Arnd Bergmann arnd@arndb.de wrote:
- amd-gpu -- a single but huge driver for the GPU. As is normally the
case with GPU drivers, we can expect long discussions before it will get considered for mainline 4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
Just out of curiosity, following the discussion between Dave Airlie and Codeaurora this summer re GPU driver shims.
Is the AMD GPU exposing all functionality in its kernel driver or is there some userspace blob somewhere with lots of e.g. GL goodies?
All the functionality for the kernel driver of AMD GPU Z430/Z160 (now belongs to Qualcom) is exposed. But we need accompanied userspace library to call these functionality (buffer management, command submission, ...).
Who owns these components? If it's closed source, the only options we have are lobbying for complete release of the specs for a reimplementation or reverse-engineering the drivers, which may at least get easier with a user space driver than it would be with a kernel driver.
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.
Arnd
From a quick look it also seems that the API exposed to userspace would allow easy abuse of the GPU to access any system ram. There is a reason we do expensive command checking in the other amd gpu driver (drivers/gpu/drm/radeon/*cs.c files)
No, the memory used by the GPU is reserved at boot time, so I think there is no such a problem.
Cheers, Jerome
This isn't about what's reserved, this is about GPU capacity, if the GPU is isolated through an IOMMU and the GPU can't reprogram it then fine. But if not, then it's easy to abuse packet to reprogram the GPU GART (either by reprogramming GART register or by overwritting GART table) to point to any system ram.
Cheers, Jerome
On Tue, Dec 14, 2010 at 10:06 AM, Jerome Glisse j.glisse@gmail.com wrote:
On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou jammy.zhou@linaro.org wrote:
On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse j.glisse@gmail.com
wrote:
On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann arnd@arndb.de wrote:
On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij linus.walleij@linaro.orgwrote:
On 11 December 2010 22:41, Arnd Bergmann arnd@arndb.de wrote:
- amd-gpu -- a single but huge driver for the GPU. As is normally
the
> case with GPU drivers, we can expect long discussions > before it will get considered for mainline > 4 patches > 98 files changed, 278321 insertions(+), 0 deletions(-) >
Just out of curiosity, following the discussion between Dave Airlie and Codeaurora this summer re GPU driver shims.
Is the AMD GPU exposing all functionality in its kernel driver or is there some userspace blob somewhere with lots of e.g. GL goodies?
All the functionality for the kernel driver of AMD GPU Z430/Z160 (now belongs to Qualcom) is exposed. But we need accompanied userspace library to call these functionality (buffer management, command submission,
...).
Who owns these components? If it's closed source, the only options we have are lobbying for complete release of the specs for a reimplementation or reverse-engineering the drivers, which may at least get easier with a user space driver than it would be with a kernel driver.
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.
ArndFrom a quick look it also seems that the API exposed to userspace would allow easy abuse of the GPU to access any system ram. There is a reason we do expensive command checking in the other amd gpu driver (drivers/gpu/drm/radeon/*cs.c files)
No, the memory used by the GPU is reserved at boot time, so I think there
is
no such a problem.
Cheers, Jerome
This isn't about what's reserved, this is about GPU capacity, if the GPU is isolated through an IOMMU and the GPU can't reprogram it then fine. But if not, then it's easy to abuse packet to reprogram the GPU GART (either by reprogramming GART register or by overwritting GART table) to point to any system ram.
For non-PCI GPU in embedded world, there is no GART concept. Besides, the GPU MMU is disabled currently for some hardware problem.
Cheers, Jerome
On Mon, Dec 13, 2010 at 9:30 PM, Jammy Zhou jammy.zhou@linaro.org wrote:
On Tue, Dec 14, 2010 at 10:06 AM, Jerome Glisse j.glisse@gmail.com wrote:
On Mon, Dec 13, 2010 at 9:04 PM, Jammy Zhou jammy.zhou@linaro.org wrote:
On Tue, Dec 14, 2010 at 12:11 AM, Jerome Glisse j.glisse@gmail.com wrote:
On Mon, Dec 13, 2010 at 10:18 AM, Arnd Bergmann arnd@arndb.de wrote:
On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij linus.walleij@linaro.orgwrote:
> On 11 December 2010 22:41, Arnd Bergmann arnd@arndb.de wrote: > > * amd-gpu -- a single but huge driver for the GPU. As is normally > the >> case with GPU drivers, we can expect long discussions >> before it will get considered for mainline >> 4 patches >> 98 files changed, 278321 insertions(+), 0 deletions(-) >> > > Just out of curiosity, following the discussion between Dave > Airlie > and Codeaurora this summer re GPU driver shims. > > Is the AMD GPU exposing all functionality in its kernel driver or > is there some userspace blob somewhere with lots of e.g. GL > goodies? > All the functionality for the kernel driver of AMD GPU Z430/Z160 (now belongs to Qualcom) is exposed. But we need accompanied userspace library to call these functionality (buffer management, command submission, ...).
Who owns these components? If it's closed source, the only options we have are lobbying for complete release of the specs for a reimplementation or reverse-engineering the drivers, which may at least get easier with a user space driver than it would be with a kernel driver.
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.
Arnd
From a quick look it also seems that the API exposed to userspace would allow easy abuse of the GPU to access any system ram. There is a reason we do expensive command checking in the other amd gpu driver (drivers/gpu/drm/radeon/*cs.c files)
No, the memory used by the GPU is reserved at boot time, so I think there is no such a problem.
Cheers, Jerome
This isn't about what's reserved, this is about GPU capacity, if the GPU is isolated through an IOMMU and the GPU can't reprogram it then fine. But if not, then it's easy to abuse packet to reprogram the GPU GART (either by reprogramming GART register or by overwritting GART table) to point to any system ram.
For non-PCI GPU in embedded world, there is no GART concept. Besides, the GPU MMU is disabled currently for some hardware problem.
In a weird way you lucky ;)
Cheers, Jerome Glisse
On Mon, Dec 13, 2010 at 11:18 PM, Arnd Bergmann arnd@arndb.de wrote:
On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij <linus.walleij@linaro.org wrote:
On 11 December 2010 22:41, Arnd Bergmann arnd@arndb.de wrote:
- amd-gpu -- a single but huge driver for the GPU. As is normally the
case with GPU drivers, we can expect long discussions before it will get considered for mainline4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
Just out of curiosity, following the discussion between Dave Airlie and Codeaurora this summer re GPU driver shims.
Is the AMD GPU exposing all functionality in its kernel driver or is there some userspace blob somewhere with lots of e.g. GL goodies?
All the functionality for the kernel driver of AMD GPU Z430/Z160 (now belongs to Qualcom) is exposed. But we need accompanied userspace library
to
call these functionality (buffer management, command submission, ...).
Who owns these components? If it's closed source, the only options we have are lobbying for complete release of the specs for a reimplementation or reverse-engineering the drivers, which may at least get easier with a user space driver than it would be with a kernel driver.
The user space library is closed source, and it is owned by Qualcomm.
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 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 there any legal issue for this?)
Arnd
On Tue, Dec 14, 2010 at 9:59 AM, Jammy Zhou jammy.zhou@linaro.org wrote:
On Mon, Dec 13, 2010 at 11:18 PM, Arnd Bergmann arnd@arndb.de wrote:
On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij linus.walleij@linaro.orgwrote:
On 11 December 2010 22:41, Arnd Bergmann arnd@arndb.de wrote:
- amd-gpu -- a single but huge driver for the GPU. As is normally the
case with GPU drivers, we can expect long discussions before it will get considered for mainline 4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
Just out of curiosity, following the discussion between Dave Airlie and Codeaurora this summer re GPU driver shims.
Is the AMD GPU exposing all functionality in its kernel driver or is there some userspace blob somewhere with lots of e.g. GL goodies?
All the functionality for the kernel driver of AMD GPU Z430/Z160 (now belongs to Qualcom) is exposed. But we need accompanied userspace library to call these functionality (buffer management, command submission, ...).
Who owns these components? If it's closed source, the only options we have are lobbying for complete release of the specs for a reimplementation or reverse-engineering the drivers, which may at least get easier with a user space driver than it would be with a kernel driver.
The user space library is closed source, and it is owned by Qualcomm.
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 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 there any legal issue for this?)
I think so, there's normally a rule if free redistribution is allowed or not, even it's closed source.
Arnd
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
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 there any legal issue for this?)
I think so, there's normally a rule if free redistribution is allowed or not, even it's closed source.
Binary is named libgsl.so and conflicts with GNU Scientific Library package. I noticed it ~month ago when played with 2d/3d acceleration for EfikaMX Smartbook (i.mx515) and shared that info with Genesi (vendor of netbook). They sent that information to Freescale so library will be renamed.
Regards,
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 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 there any legal issue for this?)
I think so, there's normally a rule if free redistribution is allowed or not, even it's closed source.
Well, it can be in the hardware pack, I guess, but I don't think we should even consider including the driver in the Linaro kernel:
The rule is that we only include code that is on an upstream track (i.e. merged in an -rc or -next release), which this one clearly is not at the moment, as Dave Airlie has made quite clear.
We could have a git tree containing all the questionable graphics drivers (amd, sgx, mali) that rely on proprietary user space libraries, and allow these to be built against the Linaro kernel, but it needs to be quite clear that this is in not part of our project.
Arnd
On Tue, Dec 14, 2010 at 1:18 AM, Arnd Bergmann arnd@arndb.de wrote:
On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij linus.walleij@linaro.orgwrote:
On 11 December 2010 22:41, Arnd Bergmann arnd@arndb.de wrote:
- amd-gpu -- a single but huge driver for the GPU. As is normally the
case with GPU drivers, we can expect long discussions before it will get considered for mainline 4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
Just out of curiosity, following the discussion between Dave Airlie and Codeaurora this summer re GPU driver shims.
Is the AMD GPU exposing all functionality in its kernel driver or is there some userspace blob somewhere with lots of e.g. GL goodies?
All the functionality for the kernel driver of AMD GPU Z430/Z160 (now belongs to Qualcom) is exposed. But we need accompanied userspace library to call these functionality (buffer management, command submission, ...).
Who owns these components? If it's closed source, the only options we have are lobbying for complete release of the specs for a reimplementation or reverse-engineering the drivers, which may at least get easier with a user space driver than it would be with a kernel driver.
Yeah even with the open kernel bits it makes no sense to upstream if they never release the userspace, since a GPU stack is a hw to sw interface stack you can't design a 3D userspace driver without having control of the kernel userspace interface, so setting an ABI in stone for something that forces anyone doing future development down a strict path is of no benefit.
Dave.
On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann arnd@arndb.de wrote:
On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij linus.walleij@linaro.orgwrote:
On 11 December 2010 22:41, Arnd Bergmann arnd@arndb.de wrote:
- amd-gpu -- a single but huge driver for the GPU. As is normally the
case with GPU drivers, we can expect long discussions before it will get considered for mainline 4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
Just out of curiosity, following the discussion between Dave Airlie and Codeaurora this summer re GPU driver shims.
Is the AMD GPU exposing all functionality in its kernel driver or is there some userspace blob somewhere with lots of e.g. GL goodies?
All the functionality for the kernel driver of AMD GPU Z430/Z160 (now belongs to Qualcom) is exposed. But we need accompanied userspace library to call these functionality (buffer management, command submission, ...).
Who owns these components? If it's closed source, the only options we have are lobbying for complete release of the specs for a reimplementation or reverse-engineering the drivers, which may at least get easier with a user space driver than it would be with a kernel driver.
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.
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 the kernel driver itself; this memory area is set internally by the platform device resource.. As such (on the i.MX515 at least) the top 64MB of memory reserved for the GPU is the only memory you need to worry about, and any "corruption" will be limited to invalid API usage which is also checked with assertions and other protection mechanisms. Any other "unsecured" memory location such as system RAM cannot be affected as the GPU MMU will not write or read any other memory than the defined resource. It is not an outside possibility that you may abuse the GPU to corrupt graphics RAM... but you can do that with any GPU even with security checks.
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 important part. The userspace library is closed because it is proprietary; and I think it is well outside Linaro's remit to lobby for opensourcing of proprietary code simply to meet an esoteric and needless demand for source code access (as it stands, you can get source code access by signing the usual plethora of NDAs with the appropriate vendor, as Genesi has done). It is my understanding that Freescale/AMD and Qualcomm maintain seperate forks of the driver and do not cooperate on development, and in any case, Linaro does not include Qualcomm anyway, therefore it is also to my understanding that this discussion is also beyond Linaro's remit.
Can't we all just be happy that we actually have 3D drivers?
On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey matt@genesi-usa.com wrote:
On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann arnd@arndb.de wrote:
On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij linus.walleij@linaro.orgwrote:
On 11 December 2010 22:41, Arnd Bergmann arnd@arndb.de wrote:
- amd-gpu -- a single but huge driver for the GPU. As is normally the
case with GPU drivers, we can expect long discussions before it will get considered for mainline 4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
Just out of curiosity, following the discussion between Dave Airlie and Codeaurora this summer re GPU driver shims.
Is the AMD GPU exposing all functionality in its kernel driver or is there some userspace blob somewhere with lots of e.g. GL goodies?
All the functionality for the kernel driver of AMD GPU Z430/Z160 (now belongs to Qualcom) is exposed. But we need accompanied userspace library to call these functionality (buffer management, command submission, ...).
Who owns these components? If it's closed source, the only options we have are lobbying for complete release of the specs for a reimplementation or reverse-engineering the drivers, which may at least get easier with a user space driver than it would be with a kernel driver.
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.
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 the kernel driver itself; this memory area is set internally by the platform device resource.. As such (on the i.MX515 at least) the top 64MB of memory reserved for the GPU is the only memory you need to worry about, and any "corruption" will be limited to invalid API usage which is also checked with assertions and other protection mechanisms. Any other "unsecured" memory location such as system RAM cannot be affected as the GPU MMU will not write or read any other memory than the defined resource. It is not an outside possibility that you may abuse the GPU to corrupt graphics RAM... but you can do that with any GPU even with security checks.
Security check of radeon GPU are advance enough to even catch and forbid overwriting other process video memory (this is more or less true depending on the generation you are looking at).
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 important part. The userspace library is closed because it is proprietary; and I think it is well outside Linaro's remit to lobby for opensourcing of proprietary code simply to meet an esoteric and needless demand for source code access (as it stands, you can get source code access by signing the usual plethora of NDAs with the appropriate vendor, as Genesi has done). It is my understanding that Freescale/AMD and Qualcomm maintain seperate forks of the driver and do not cooperate on development, and in any case, Linaro does not include Qualcomm anyway, therefore it is also to my understanding that this discussion is also beyond Linaro's remit.
Can't we all just be happy that we actually have 3D drivers?
So here you are advocating that we should accept any open source code inside the kernel just because it's open source and we love open source ? This is not how i understand the linux kernel project, we should not accept any open source driver that just add new api that we can't audit, test or understand. From my point of view any driver & new API should be introduced to support open source userspace. If GPU manufacturer don't want to open source their stack that's their issue but they should live with the pain of not having upstream kernel either. I believe, here i am just reformulating Dave point.
Cheers, Jerome Glisse
On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse j.glisse@gmail.com wrote:
On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey matt@genesi-usa.com wrote:
On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann arnd@arndb.de wrote:
On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij linus.walleij@linaro.orgwrote:
On 11 December 2010 22:41, Arnd Bergmann arnd@arndb.de wrote:
- amd-gpu -- a single but huge driver for the GPU. As is normally the
case with GPU drivers, we can expect long discussions before it will get considered for mainline 4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
Just out of curiosity, following the discussion between Dave Airlie and Codeaurora this summer re GPU driver shims.
Is the AMD GPU exposing all functionality in its kernel driver or is there some userspace blob somewhere with lots of e.g. GL goodies?
All the functionality for the kernel driver of AMD GPU Z430/Z160 (now belongs to Qualcom) is exposed. But we need accompanied userspace library to call these functionality (buffer management, command submission, ...).
Who owns these components? If it's closed source, the only options we have are lobbying for complete release of the specs for a reimplementation or reverse-engineering the drivers, which may at least get easier with a user space driver than it would be with a kernel driver.
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.
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 the kernel driver itself; this memory area is set internally by the platform device resource.. As such (on the i.MX515 at least) the top 64MB of memory reserved for the GPU is the only memory you need to worry about, and any "corruption" will be limited to invalid API usage which is also checked with assertions and other protection mechanisms. Any other "unsecured" memory location such as system RAM cannot be affected as the GPU MMU will not write or read any other memory than the defined resource. It is not an outside possibility that you may abuse the GPU to corrupt graphics RAM... but you can do that with any GPU even with security checks.
Security check of radeon GPU are advance enough to even catch and forbid overwriting other process video memory (this is more or less true depending on the generation you are looking at).
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 important part. The userspace library is closed because it is proprietary; and I think it is well outside Linaro's remit to lobby for opensourcing of proprietary code simply to meet an esoteric and needless demand for source code access (as it stands, you can get source code access by signing the usual plethora of NDAs with the appropriate vendor, as Genesi has done). It is my understanding that Freescale/AMD and Qualcomm maintain seperate forks of the driver and do not cooperate on development, and in any case, Linaro does not include Qualcomm anyway, therefore it is also to my understanding that this discussion is also beyond Linaro's remit.
Can't we all just be happy that we actually have 3D drivers?
So here you are advocating that we should accept any open source code inside the kernel just because it's open source and we love open source ? This is not how i understand the linux kernel project, we should not accept any open source driver that just add new api that we can't audit, test or understand. From my point of view any driver & new API should be introduced to support open source userspace. If GPU manufacturer don't want to open source their stack that's their issue but they should live with the pain of not having upstream kernel either. I believe, here i am just reformulating Dave point.
The code may need improvement but that's no reason to run around saying everything needs to be open sourced, and that the solution is in fact to reverse engineer the thing rather than accept it as the current solution. Given how long nouveau and later Radeon card support has taken in real life, even with full documentation from AMD, I seriously doubt Linaro are going to be the ones to somehow make the world change for OpenSource embedded GPU graphics. Linaro doesn't exist just to spend all their time undermining the status quo for the sake of it.
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 lives now, Qualcomm have it in their upstream, Freescale have it in their upstream, Linaro are going to fetch from that. It doesn't need to go all the way to stable, because people can compile their own kernels if they want (and Linaro is there provide the source to do that with the best interoperability with the silicon vendors' chips as possible).
Well, good luck reverse engineering the GPU in the next 5 years, because I suspect that is how long it is going to take.
I would love to see someone actually, physically prove that using the libraries provided by vendors (Freescale's BSP, or from Genesi or so) and the kernel driver committed, that you CAN actually cause rampant, unsecured graphical corruption, before a discussion goes around to those vendors about spending the next 6 months mired in legal work trying to find all the potential IP sources and seek approval to publish that code as opensource or perform rewrites. So far I don't see that, just a "I'm fairly sure" from a trusted person. This is not peer review, it's pure opinion. Go see how well you can break it, submit a bug report, the vendors might fix it in the closed source libraries or publish a kernel driver update to suit your needs.
On Mon, Dec 20, 2010 at 12:41 PM, Matt Sealey matt@genesi-usa.com wrote:
On Mon, Dec 20, 2010 at 11:17 AM, Jerome Glisse j.glisse@gmail.com wrote:
On Mon, Dec 20, 2010 at 11:18 AM, Matt Sealey matt@genesi-usa.com wrote:
On Mon, Dec 13, 2010 at 9:18 AM, Arnd Bergmann arnd@arndb.de wrote:
On Monday 13 December 2010, Jammy Zhou wrote:
On Mon, Dec 13, 2010 at 4:45 AM, Linus Walleij linus.walleij@linaro.orgwrote:
On 11 December 2010 22:41, Arnd Bergmann arnd@arndb.de wrote:
- amd-gpu -- a single but huge driver for the GPU. As is normally the
> case with GPU drivers, we can expect long discussions > before it will get considered for mainline > 4 patches > 98 files changed, 278321 insertions(+), 0 deletions(-) >
Just out of curiosity, following the discussion between Dave Airlie and Codeaurora this summer re GPU driver shims.
Is the AMD GPU exposing all functionality in its kernel driver or is there some userspace blob somewhere with lots of e.g. GL goodies?
All the functionality for the kernel driver of AMD GPU Z430/Z160 (now belongs to Qualcom) is exposed. But we need accompanied userspace library to call these functionality (buffer management, command submission, ...).
Who owns these components? If it's closed source, the only options we have are lobbying for complete release of the specs for a reimplementation or reverse-engineering the drivers, which may at least get easier with a user space driver than it would be with a kernel driver.
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.
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 the kernel driver itself; this memory area is set internally by the platform device resource.. As such (on the i.MX515 at least) the top 64MB of memory reserved for the GPU is the only memory you need to worry about, and any "corruption" will be limited to invalid API usage which is also checked with assertions and other protection mechanisms. Any other "unsecured" memory location such as system RAM cannot be affected as the GPU MMU will not write or read any other memory than the defined resource. It is not an outside possibility that you may abuse the GPU to corrupt graphics RAM... but you can do that with any GPU even with security checks.
Security check of radeon GPU are advance enough to even catch and forbid overwriting other process video memory (this is more or less true depending on the generation you are looking at).
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 important part. The userspace library is closed because it is proprietary; and I think it is well outside Linaro's remit to lobby for opensourcing of proprietary code simply to meet an esoteric and needless demand for source code access (as it stands, you can get source code access by signing the usual plethora of NDAs with the appropriate vendor, as Genesi has done). It is my understanding that Freescale/AMD and Qualcomm maintain seperate forks of the driver and do not cooperate on development, and in any case, Linaro does not include Qualcomm anyway, therefore it is also to my understanding that this discussion is also beyond Linaro's remit.
Can't we all just be happy that we actually have 3D drivers?
So here you are advocating that we should accept any open source code inside the kernel just because it's open source and we love open source ? This is not how i understand the linux kernel project, we should not accept any open source driver that just add new api that we can't audit, test or understand. From my point of view any driver & new API should be introduced to support open source userspace. If GPU manufacturer don't want to open source their stack that's their issue but they should live with the pain of not having upstream kernel either. I believe, here i am just reformulating Dave point.
The code may need improvement but that's no reason to run around saying everything needs to be open sourced, and that the solution is in fact to reverse engineer the thing rather than accept it as the current solution. Given how long nouveau and later Radeon card support has taken in real life, even with full documentation from AMD, I seriously doubt Linaro are going to be the ones to somehow make the world change for OpenSource embedded GPU graphics. Linaro doesn't exist just to spend all their time undermining the status quo for the sake of it.
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 lives now, Qualcomm have it in their upstream, Freescale have it in their upstream, Linaro are going to fetch from that. It doesn't need to go all the way to stable, because people can compile their own kernels if they want (and Linaro is there provide the source to do that with the best interoperability with the silicon vendors' chips as possible).
I was just expressing my opinion on upstream, if i see this driver showing up on lkml i will reply with a nak and explain why (pretty much same argument as here). I don't have any authority on linux kernel but as far as i understand it, it's about reviewing what's gets in, so i hope my review opinion would matter (what ever the out come is).
Well, good luck reverse engineering the GPU in the next 5 years, because I suspect that is how long it is going to take.
It's not that hard, it's time consuming and painfull. The time needed depends on how much people are working on it and how much time those people have to work on it.
I would love to see someone actually, physically prove that using the libraries provided by vendors (Freescale's BSP, or from Genesi or so) and the kernel driver committed, that you CAN actually cause rampant, unsecured graphical corruption, before a discussion goes around to those vendors about spending the next 6 months mired in legal work trying to find all the potential IP sources and seek approval to publish that code as opensource or perform rewrites. So far I don't see that, just a "I'm fairly sure" from a trusted person. This is not peer review, it's pure opinion. Go see how well you can break it, submit a bug report, the vendors might fix it in the closed source libraries or publish a kernel driver update to suit your needs.
The point here is that we can't prove it or be confidant that it's very unlikely or even impossible without the specifications, so before we can have any certainty about this we would either need the specification or reverse engineer it. Note that i haven't even bothered looking at that driver, i only looked at other qualcom gpu and voiced my concern on them (i was given reasonable technical answer on those concern by the way).
For me, no kernel open source driver should be accepted upstream without open source userspace. So if a company want to push upstream an open source kernel driver they have to consider either waiting 5 years for reverse engineering (taking your estimation and assuming some one reverse engineer). Or actually try to look at those IP and see what they can do. Some GPU company (AMD, Intel) have proven that you can actually review IP and do open source driver, they likely won't disclose how much it cost them but it seems they think it's worth it. I hope others GPU company will starts thinking about that.
Cheers, Jerome Glisse Cheers, Jerome Glisse
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 lives now, Qualcomm have it in their upstream, Freescale have it in their upstream, Linaro are going to fetch from that. It doesn't need to go all the way to stable, because people can compile their own kernels if they want (and Linaro is there provide the source to do that with the best interoperability with the silicon vendors' chips as possible).
I was just expressing my opinion on upstream, if i see this driver showing up on lkml i will reply with a nak and explain why (pretty much same argument as here). I don't have any authority on linux kernel but as far as i understand it, it's about reviewing what's gets in, so i hope my review opinion would matter (what ever the out come is).
There is a broad agreement on disallowing new kernel to userspace interfaces in the upstream kernel unless there is an application using it that is both open source and considered useful.
I don't think Linaro as a group takes a position or should take a position on closed source user space at all -- we just don't need to bother with it because we have enough work to do on free components. However, we have a policy on kernel code and that is as I mentioned before that we don't take code unless it's about to go upstream. In this case, upstream doesn't take the driver, so Linaro won't either.
Arnd
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 are useless without a magic proprietary library.
There are lots of reasons for refusing such code
- Legality questions - Testability - Security - Risk of locking us to proprietary interfaces when we can't change the user one
and more
Alan
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 the kernel driver itself; this memory area is set internally by the platform device resource.. As such (on the i.MX515 at least) the top 64MB of memory reserved for the GPU is the only memory you need to worry about, and any "corruption" will be limited to invalid API usage which is also checked with assertions and other protection mechanisms. Any other "unsecured" memory location such as system RAM cannot be affected as the GPU MMU will not write or read any other memory than the defined resource. It is not an outside possibility that you may abuse the GPU to corrupt graphics RAM... but you can do that with any GPU even with security checks.
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 important part. The userspace library is closed because it is proprietary; and I think it is well outside Linaro's remit to lobby for opensourcing of proprietary code simply to meet an esoteric and needless demand for source code access (as it stands, you can get source code access by signing the usual plethora of NDAs with the appropriate vendor, as Genesi has done). It is my understanding that Freescale/AMD and Qualcomm maintain seperate forks of the driver and do not cooperate on development, and in any case, Linaro does not include Qualcomm anyway, therefore it is also to my understanding that this discussion is also beyond Linaro's remit.
Can't we all just be happy that we actually have 3D drivers?
Can't you just use Windows? why bother with open source at all if you are willing to give up.
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.
I will accept kernel code to initialise chips, set modes, do all that, I won't accept new ioctl interfaces to userspace that cannot be validated and have no use other than to serve the closed user blob. The reason for this is the burden of maintaining the code/interfaces falls onto the kernel community when we accept code. Now if we can no longer validate that the interfaces work without running a binary blob or we cannot change the interfaces without having to lobby some other entity to change their blob then maintaining that code in the upstream kernel is pointless.
I have no problem with closed 3D drivers I just want the manufacturers to understand that if you want to go down that path you get to keep both halves.
Dave.
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 derivative work is a legal not a technical one and if the kernel and user space cannot be used except together and one half depends on GPL elements I hope your lawyers have reviewed it carefully. I have never given anyone permission to link my GPL kernel contributions with anything but GPL code, modular or otherwise, except according to the derivative work rules laid down by the GPL (and indeed by the boundaries placed on copyright law).
Alan
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 concerned that the definition of a derivative work is a legal not a technical one and if the kernel and user space cannot be used except together and one half depends on GPL elements I hope your lawyers have reviewed it carefully. I have never given anyone permission to link my GPL kernel contributions with anything but GPL code, modular or otherwise, except according to the derivative work rules laid down by the GPL (and indeed by the boundaries placed on copyright law).
but it can be circumvented by writing GPL driver which will act as 'glue logic' inbetween userspace driver and which will work in kernel space?
technically then driver would be GPL, except it's closed parts which will be ran in userspace... or can you forbid usage of certain closed userspace components with kernel?
p.s. let's skip for now discussion who "should" write such driver, as i understand anyone can do it anyway.
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 that join them.
As a copyright holder on the kernel I'll also remind the people concerned that the definition of a derivative work is a legal not a technical one and if the kernel and user space cannot be used except together and one half depends on GPL elements I hope your lawyers have reviewed it carefully. I have never given anyone permission to link my GPL kernel contributions with anything but GPL code, modular or otherwise, except according to the derivative work rules laid down by the GPL (and indeed by the boundaries placed on copyright law).
but it can be circumvented by writing GPL driver which will act as 'glue logic' inbetween userspace driver and which will work in kernel space?
technically then driver would be GPL, except it's closed parts which will be ran in userspace... or can you forbid usage of certain closed userspace components with kernel?
Anyone can try shipping this and risk a lawsuit, and all copyright holders of the kernel can try suing people that distribute such code. Most sensible people stay out of both the shipping questionable code and the suing part, but apparently the entire mobile phone industry is already doing both, so we can just wait and see if anyone has deep enough pockets to bring this up in court first ;-).
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 license you want against that interface.
Arnd
On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann arnd@arndb.de 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 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 derivative work is a legal not a technical one and if the kernel and user space cannot be used except together and one half depends on GPL elements I hope your lawyers have reviewed it carefully. I have never given anyone permission to link my GPL kernel contributions with anything but GPL code, modular or otherwise, except according to the derivative work rules laid down by the GPL (and indeed by the boundaries placed on copyright law).
but it can be circumvented by writing GPL driver which will act as 'glue logic' inbetween userspace driver and which will work in kernel space?
technically then driver would be GPL, except it's closed parts which will be ran in userspace... or can you forbid usage of certain closed userspace components with kernel?
Anyone can try shipping this and risk a lawsuit, and all copyright holders of the kernel can try suing people that distribute such code. Most sensible people stay out of both the shipping questionable code and the suing part, but apparently the entire mobile phone industry is already doing both, so we can just wait and see if anyone has deep enough pockets to bring this up in court first ;-).
Nobody will because it is unenforcable.
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" clause can actually be manipulated to basically disavow closed source code from having to be published as open source if it interfaces with the standard operating system components. It is meant to protect software developers from having to bundle a gigabyte of kernel and compiler code with their 100 line app that uses an ioctl, but legally it works against the GPL in this way. It is what means AMD, nVidia, Intel (hi Alan), and others can produce binary code and binary executables that run on opensource kernels (wireless regulatory daemon in the early days) basically with impunity.
You may think it's a horrible idea, and from a technical perspective it is, but from a legal perspective.. it's not a problem.
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 license you want against that interface.
Yes, this is basically it: the problem here is that Alan is stipulating that as a copyright holder in the kernel he has a big problem with merging the code, but in fact as the merge proposal only includes GPL code, nobody has a leg to stand on except on moral grounds, and policy grounds. There is no legal issue here. It is not going into mainline, fair enough. What I am curious about is why did Linaro push it to dri-devel in the first place? I think the concept of taking a driver from a BSP and then just FLINGING it at mainline is not responsible in the first place. Isn't it enough to go into the Linaro tree, discretely and quietly? Then we can have a discussion about what to do about it within Linaro.
Frankly, this discussion (besides the sidetrack to the non-existant legal issues) did pop up a major problem in the possibility of unifying the IPU, dual GPU and other graphics subsystem frameworks on the i.MX processor line, and potentially others too (TI's LCDC and PVR graphics) in that DRM/DRI security policy will forbid them (in the form of David Arlie complaining) from sharing the same memory area, MMUs on or off. This actually means all 2D, 2D acceleration, 3D acceleration and DMA between the units requires bounce buffers and some overly complicated memory copying between memory areas for them to interoperate. I think TI hit this problem trying to get a texture from the DSP to the GPU to render it to a texture and came up with an awful (closed source :) method of ioctls and so on to achieve it. I had an idea to solve it using DRM and GEM but it's been shot down in concept now... what's the point? It'll never get into mainline.
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 license you want against that interface.
Yes, this is basically it: the problem here is that Alan is stipulating that as a copyright holder in the kernel he has a big problem with merging the code, but in fact as the merge proposal only includes GPL code, nobody has a leg to stand on except on moral grounds, and policy grounds. There is no legal issue here. It is not going into mainline, fair enough. What I am curious about is why did Linaro push it to dri-devel in the first place? I think the concept of taking a driver from a BSP and then just FLINGING it at mainline is not responsible in the first place. Isn't it enough to go into the Linaro tree, discretely and quietly? Then we can have a discussion about what to do about it within Linaro.
That's not how Linaro works. I forwarded it to the DRI list to get technical input on what would be needed to have it merged in mainline. If things were looking better on this front, we could get it on track for mainline merging, and backport it into the Linaro tree as soon as it hits linux-next. This is obviously not going to happen unless we can find at least a subset of the code without legal problems that we can clean up enough for integration.
Frankly, this discussion (besides the sidetrack to the non-existant legal issues) did pop up a major problem in the possibility of unifying the IPU, dual GPU and other graphics subsystem frameworks on the i.MX processor line, and potentially others too (TI's LCDC and PVR graphics) in that DRM/DRI security policy will forbid them (in the form of David Arlie complaining) from sharing the same memory area, MMUs on or off. This actually means all 2D, 2D acceleration, 3D acceleration and DMA between the units requires bounce buffers and some overly complicated memory copying between memory areas for them to interoperate. I think TI hit this problem trying to get a texture from the DSP to the GPU to render it to a texture and came up with an awful (closed source :) method of ioctls and so on to achieve it. I had an idea to solve it using DRM and GEM but it's been shot down in concept now... what's the point? It'll never get into mainline.
Don't give up so early, there are a number of separate problems to solve here. As far as I understand, the desire among many people is to have the 3D acceleration hidden. Fine, so we can still do accelerated 2D with free drivers and shouldn't be bothered by the fact that we don't get 3D. There is a lot of work to do on proper 2D drivers and getting them into mainline still, so let's focus on that and do a proper implementation for as many chips as possible.
By the time that is done, we may well have one or more manufacturers willing to work with us on 3D support as well.
Arnd
On Wed, Dec 22, 2010 at 3:29 AM, Matt Sealey matt@genesi-usa.com wrote:
On Tue, Dec 21, 2010 at 5:50 AM, Arnd Bergmann arnd@arndb.de 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 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 derivative work is a legal not a technical one and if the kernel and user space cannot be used except together and one half depends on GPL elements I hope your lawyers have reviewed it carefully. I have never given anyone permission to link my GPL kernel contributions with anything but GPL code, modular or otherwise, except according to the derivative work rules laid down by the GPL (and indeed by the boundaries placed on copyright law).
but it can be circumvented by writing GPL driver which will act as 'glue logic' inbetween userspace driver and which will work in kernel space?
technically then driver would be GPL, except it's closed parts which will be ran in userspace... or can you forbid usage of certain closed userspace components with kernel?
Anyone can try shipping this and risk a lawsuit, and all copyright holders of the kernel can try suing people that distribute such code. Most sensible people stay out of both the shipping questionable code and the suing part, but apparently the entire mobile phone industry is already doing both, so we can just wait and see if anyone has deep enough pockets to bring this up in court first ;-).
Nobody will because it is unenforcable.
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" clause can actually be manipulated to basically disavow closed source code from having to be published as open source if it interfaces with the standard operating system components. It is meant to protect software developers from having to bundle a gigabyte of kernel and compiler code with their 100 line app that uses an ioctl, but legally it works against the GPL in this way. It is what means AMD, nVidia, Intel (hi Alan), and others can produce binary code and binary executables that run on opensource kernels (wireless regulatory daemon in the early days) basically with impunity.
You may think it's a horrible idea, and from a technical perspective it is, but from a legal perspective.. it's not a problem.
You should probably refrain from stating legal opinions around here, Alan stated there is a possible issue legally and you should talk to lawyers. I find his reasoning to be sane but no idea if its legal. The point you are missing (you seem to not think much before typing) is this:
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 system call exception since it states "normal system calls", so adding a driver to the kernel to expose a bunch of driver specific ioctls to allow the userspace 3D work blurs the lines sufficiently that you are into the domain of derived works and should call your lawyers.
Frankly, this discussion (besides the sidetrack to the non-existant legal issues) did pop up a major problem in the possibility of unifying the IPU, dual GPU and other graphics subsystem frameworks on the i.MX processor line, and potentially others too (TI's LCDC and PVR graphics) in that DRM/DRI security policy will forbid them (in the form of David Arlie complaining) from sharing the same memory area, MMUs on or off. This actually means all 2D, 2D acceleration, 3D acceleration and DMA between the units requires bounce buffers and some overly complicated memory copying between memory areas for them to interoperate. I think TI hit this problem trying to get a texture from the DSP to the GPU to render it to a texture and came up with an awful (closed source :) method of ioctls and so on to achieve it. I had an idea to solve it using DRM and GEM but it's been shot down in concept now... what's the point? It'll never get into mainline.
I never said the security policy would forbid anything, I said they need to prove that they've thought about these things and can prove they are secure, if this requires opening the code and/or documents then that is the way it is. The thing is if you require a userspace application with user privs to access these devices then you must stop the user from doing bad things, from my experience vendors give little concern for these issues until
a) upstream people point out the problem and refuse to merge b) they are used as the rootkit entry point.
Dave.
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 system call exception since it states "normal system calls", so adding a driver to the kernel to expose a bunch of driver specific ioctls to allow the userspace 3D work blurs the lines sufficiently that you are into the domain of derived works and should call your lawyers.
so any user-written (gpl compatible) driver which exposes new ioctls which allow other software to work (i.e. network driver allowing closed source software to send and recieve packets is illegal aswell?
it is getting confusing...
shall everyone hire lawyer prior to using any software under linux?
On Wed, Dec 22, 2010 at 11:54 AM, Piotr Gluszenia Slawinski curious@bwv190.internetdsl.tpnet.pl 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 derivative work of the kernel driver. You are not protected by the standard Linux system call exception since it states "normal system calls", so adding a driver to the kernel to expose a bunch of driver specific ioctls to allow the userspace 3D work blurs the lines sufficiently that you are into the domain of derived works and should call your lawyers.
so any user-written (gpl compatible) driver which exposes new ioctls which allow other software to work (i.e. network driver allowing closed source software to send and recieve packets is illegal aswell?
it is getting confusing...
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.
shall everyone hire lawyer prior to using any software under linux?
this is a peanut gallery comment, nobody mentioned using any software under linux here, we are talking about development of linux software.
Please read and understand before replying with pointless emails like this.
Dave.
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 you for claryfing , and for your time, excuse me my ignorance.
i think main reason of my confusion is lack of clear specification of the 'specifics'. discussion becomes plainly too complex and same development goes - code and strategies are developed before clarification of the specifics, then people try to explain how they interpreted law, and start to correct themselves, trying to drag the line to their side.
i think this wastes time of everyone , of which most loud group are users, and most opressed - developers, and excuse me i am making humorous comments to point that.
i also hope 3d drivers will finally be free, and not require people to use tools like hacked ndiswrapper.
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).
On 22 December 2010 09:51, Matt Sealey matt@genesi-usa.com 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 discussion ended up on phoronix.com [1], with an air of hostility towards Genesi and Matt for no good reason.
I don't know whose idea was that, but it's certainly of very bad taste and helps very little to the discussion. Matt poses real questions and issues we -as a company producing ARM products- face all the time. Admittedly the technical reasons for not including the kernel-space driver into mainline presented by Dave Airlie are correct and very down-to-earth. But IMHO, *this* should be the starting point to continue the discussion, instead of immediately rejecting this driver. Is there *any* way that problem posed by Dave could be solved, perhaps by throwing the ball to the ARM vendor companies to provide just a small extra part of the code needed to do API checks and therefore ensuring the kernel guys CAN actually do their work as they like?
As for the philosophical problems, well, I'm sure everyone here understands that the situation of ARM graphics in the kernel is in no way comparable to Intel or Nvidia/ATI chipsets, they had totally different starting points. ARM came from the embedded market where it thrived for many years with the exact same licensing rules that we all would like to abolish in just a few months, where at the same time we "swallowed" the fact that it took Intel and ATI/AMD - forget nvidia, nv-obfuscated driver IN the kernel for YEARS? really? - many years to accept mainline opensource development. And even Intel with all their experience made a complete mess of things using the latest cpus.
I *really* do appreciate Linaro and the effort from ARM and the relevant vendors towards open source enablement, and Genesi has proven that by donating ~50 ARM based netbooks and smarttops to Linaro developers at Linaro@UDS -and around ~40 units to other projects including Debian and Gentoo -and we intend to give more in the future. We know the process and how it works, just as well as everyone here does actually. But we also have to be pragmatic. An ARM based solution/product with no long-term support from the kernel side will find it very hard to survive indeed. I strongly believe that, half a solution is better than no solution, and it can also serve a purpose until a proper full solution appears. It also does show a leap of good faith from the FOSS side, and one which ARM companies will have to follow soon.
So, if by chance anyone really expects ARM licensees to do 180 degrees change in philosophy overnight, I obviously cannot speak for them, but IMHO, that is not bound to happen. It will probably happen in a few years but only by discussion and collaboration, seriously not by dealing with absolutes. Denying even the smallest step backwards from the side of the FOSS community is not a victory, it's a downright failure of the community side to actively support and push ARM -based devices as an alternative Linux desktop and portable solutions (netbook etc).
My 2c.
Konstantinos
[1]: http://www.phoronix.com/scan.php?page=news_item&px=ODk0NA
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 that of getting both open source and proprietary pieces of the BSPs to work really well together in products. That's really the focus of the Graphics WGs and the partner landing teams. This is a heavy lifting engineering job, and it will take time, but everyone is willing and hopeful of good results. Doing this will also help us have a reasoned discussion about where the open source and proprietary boundaries make sense.
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 part of their products. Let's face it, an awful lot of open source engineers are getting their mortgages paid by companies that make use of open source. No company invests in open source for philanthropic reasons; they understand that it is necessary for their businesses. The tricky problem is always in how ethical a company's usage is (and I use the word 'ethical' deliberately because this is wider than mere legal words smithing); whenever I give talks on GPL, I emphasise both the moral as well as the legal duties. In my experience, most companies struggle to understand open source when they first start to interact with it. It usually takes some open source zealots within the company to persuade their management of the right 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.
Dave
David Rusling, CTO http://www.linaro.org
Linaro Lockton House Clarendon Rd Cambridge CB2 8FH
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 part of their products. Let's face it, an awful lot of open source engineers are getting their mortgages paid by companies that make use of open source.
I cannot be in full agreement with the above statement. I think the reality is way more nuanced than that.
The truth of the matter is that Open Source came into existence without and despite involvement from the corporate world. And the very reason it started to attract interest from the corporate world is because of Open Source's superior quality and performance at a lower cost. Open Source would have existed even without companies using it as you would still have those Open Source activists using it themselves in your product, even without the help of the corporate money. The company involvement in Open Source did indeed accelerate its development by paying many people to work on it full time. But Open Source would still be there and still be in good shape even if corporate involvement didn't happen, just like it was before.
And this superior quality and performance characteristics of Open Source are not a coincidence. They are the first motives in a world which is not driven by monetary profits, unlike most if not all the proprietary alternatives. The people leading Open Source are driven by the technical excellence of their work and the recognition they get from their peers. Money is a far secondary motive, and in this age you can choose between different sources of sufficient money not to have to worry about it anymore and compromise too much on your primary motives when you already have a track record in this Open Source world.
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.
No company invests in open source for philanthropic reasons; they understand that it is necessary for their businesses. The tricky problem is always in how ethical a company's usage is (and I use the word 'ethical' deliberately because this is wider than mere legal words smithing); whenever I give talks on GPL, I emphasise both the moral as well as the legal duties. In my experience, most companies struggle to understand open source when they first start to interact with it. It usually takes some open source zealots within the company to persuade their management of the right 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.
Here I'm more in agreement with you. However this is again not the full picture.
Ethical or not, the first motive of a company is to make profits. If that was easy to get away with it, all that companies would do is simply to grab this body of source code for themselves and never contribute back. And a sizable number of companies, even some sizable companies, are doing just that. While this isn't going to kill Open Source, this certainly makes it weaker because this is contrary to that very first principle that made Open Source a success in the first place. Companies doing that are after the immediate monetary profit and not the technical excellence and performances.
But even when leaving the ethical aspect aside, it is not going to be profitable for companies in the long term to grab Open Source results and move it back to the legacy proprietary model. Doing that will be to their disadvantage when some other companies come along to compete on the market using Open Source to its fullest technical excellence and performance potential. Fortunately, a sizable number of companies, even sizable ones, did understand that already.
But... while some companies are struggling to understand how to interact with Open Source, the Open Source world still dash ahead without much concerns for corporate profits. As said above, those strange Open Source animals are motivated by the technical excellence of their work, and they're going to fight on that front against anything that might affect or prevent that goal. This is again why Open Source has always progressed even despite initial attempts to kill it from some corporations. So far, Linux has always been immune to monetary forces, whether those forces were against it or not. So it is fair to say that Open Source survival depends primarily on its technical advantages above anything else.
In conclusion: don't get surprised if technically inferior propositions, such as proprietary 3D libraries coupled with kernel-side interfaces, are met with strong or even vehement opposition. Some people will be sufficiently moderated to tell you that if you want to do such thing then you get to deal with it all yourself and that they are not interested in any accommodation that would help you. But it is clear that you will never get a consensus for supporting such technically inferior solution in the mainline tree, as from an Open Source point of view such a move simply makes no sense.
Accepting such things in mainline would weaken the very principle that as made Open source in general and Linux in particular such a success, while refusing it isn't going to affect the survival of Open Source anyway. The compromise here would be only in the corporate world's favor. And as the past history has shown in such cases, the Open Source way always ends up prevailing eventually, despite the lack of corporate assistance.
So, while I'm not overly optimistic about this issue, I wish those companies lobbying for the weakening of the Open Source principle could rethink and truly evaluate the economics and actual value their proposition has on their long term profits, given the fact that the Open Source community with lower monetary ambitions is highly unlikely to back down on that principle.
In the end, free has its price too.
Nicolas
On Wed, Dec 22, 2010 at 11:20 AM, Nicolas Pitre nicolas.pitre@linaro.org 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 would not exist without companies using open source as part of their products. Let's face it, an awful lot of open source engineers are getting their mortgages paid by companies that make use of open source.
I cannot be in full agreement with the above statement. I think the reality is way more nuanced than that.
The truth of the matter is that Open Source came into existence without and despite involvement from the corporate world. And the very reason it started to attract interest from the corporate world is because of Open Source's superior quality and performance at a lower cost. Open Source would have existed even without companies using it as you would still have those Open Source activists using it themselves in your product, even without the help of the corporate money. The company involvement in Open Source did indeed accelerate its development by paying many people to work on it full time. But Open Source would still be there and still be in good shape even if corporate involvement didn't happen, just like it was before.
Right but it didn't happen over night. Getting to this state took time and wasn't an immediate quality. Back in them thar early days it took a lot of figuring out, in some case with and some cases without the cooperation of the hardware types. How many years did I pine for token ring drivers.... sigh.
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.
This discussion is good, but for it to have a positive outcome, we need to turn the direction back to how we get to the end goal for arm 3D graphics. It's not probably going to happen at once with one patch that does what everyone wants. I think it's going to take graduated steps and some compromises.
Regards, Tom "We want great men who, when fortune frowns will not be discouraged." - Colonel Henry Knox w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com
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, if I may resume my conclusion to a few words, is that most Open Source folks don't care if you can't open your code for whatever reasons. That won't encourage them to compromise on their fundamental principle. It's up to those companies to balance the cost of maintaining their ad hoc proprietary stuff themselves vs the cost of opening up their code so it can be merged upstream.
This discussion is good, but for it to have a positive outcome, we need to turn the direction back to how we get to the end goal for arm 3D graphics.
Absolutely!
It's not probably going to happen at once with one patch that does what everyone wants. I think it's going to take graduated steps and some compromises.
Yes. However, as I said, those compromises may not come on the technical aspects of the kernel interfaces. Just like it is unlikely for companies to ever compromise on their profits. Any compromise touching any of those fundamental aspects for their respective parties is bound to always fail.
In other words, let's save ourselves some energy and give up on the idea that a kernel shim only for a binary only user space library is going to ever be accepted in mainline. This simply will never happen, period.
Nicolas
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 accumulation. Open Source community _already_ accumulated enough _capital_ in form of algorithms, implementations, social relations, experience, documentation and augmentation with education system .
it can survive just fine without corporate world, while logical relationship with organisations whole main purpose of existence is creating profit, is to gain profit from such relationship itself. otherwise it would be bit like Faust would just give his soul away completely free... and everyone knows it's not the point while dealing with devil.
i also understand reluctance of some people about such deals - despite huge gains , one can loose very important things, and end up escaping from small print obligations. sometimes it is better to make slower, but steady progress instead.
greetings.
On 22 December 2010 20:39, Piotr Gluszenia Slawinski curious@bwv190.internetdsl.tpnet.pl 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 this claim i want to remind the simple rule of capital accumulation. Open Source community _already_ accumulated enough _capital_ in form of algorithms, implementations, social relations, experience, documentation and augmentation with education system .
I'm sorry you've got it all wrong. Survive? Yes, certainly. Actually thrive and make a difference in the world without the corporate world? Definitely not. If you only care about the former that's fine, but have no illusion that we would even be having this discussion here were it not for the corporate world caring about Linux on ARM.
Konstantinos
On Wed, 22 Dec 2010, Konstantinos Margaritis wrote:
On 22 December 2010 20:39, Piotr Gluszenia Slawinski curious@bwv190.internetdsl.tpnet.pl 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 this claim i want to remind the simple rule of capital accumulation. Open Source community _already_ accumulated enough _capital_ in form of algorithms, implementations, social relations, experience, documentation and augmentation with education system .
I'm sorry you've got it all wrong. Survive? Yes, certainly. Actually thrive and make a difference in the world without the corporate world? Definitely not. If you only care about the former that's fine, but have no illusion that we would even be having this discussion here were it not for the corporate world caring about Linux on ARM.
Maybe. But corporations so far have played by the Open Source rules to make ARM Linux what it is. There was mutual benefits in that and ARM Linux did grew faster.
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.
Nicolas
On 22 December 2010 21:22, Nicolas Pitre nicolas.pitre@linaro.org 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.
DISCLAIMER: I'm also a Debian developer -have been since 1999 with a small 2y break- so I _do_ know the F/OSS community point of view. My goals have been always in promoting open source and free software solutions when and when not available. Right now open source solutions are _not_ available, and that is the problem.
I haven't reversed engineered any driver so I can't claim of knowledge in this matter. However I've been following closely other such projects like nouveau and it took them a _long_ time to get to this point here -which may be usable for many people, but it's not even at a beta state according to the Nouveau developers. Even if we assume the fact that 10 times more ARM F/OSS developers gather to reverse engineer the binary blobs, how long do you think it would take until a beta driver appears? 1 year? 2 years? And what will happen in the meantime?
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 problems don't end at the driver, rather the opposite.
Konstantinos
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 problems don't end at the driver, rather the opposite.
Again thats a short-term view. So we spend the effort to clean up the open kernel code, but the vendors want to keep the interface to userspace the same so the binary modules can keep functioning? How do we clean up insanities in the interfaces? How do we optimise the stack going forward?
Having the code in mainline won't help anyone who is any good at reverse engineering.
Dave.
On Wed, 22 Dec 2010, Konstantinos Margaritis wrote:
On 22 December 2010 21:22, Nicolas Pitre nicolas.pitre@linaro.org 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.
DISCLAIMER: I'm also a Debian developer -have been since 1999 with a small 2y break- so I _do_ know the F/OSS community point of view. My goals have been always in promoting open source and free software solutions when and when not available.
Good to know.
Right now open source solutions are _not_ available, and that is the problem.
Yes, everyone agrees. Well, I suppose.
That would be the first official statement to make. Do we really consider this a problem? Because most companies used to the proprietary model won't see a problem at all here, and therefore wouldn't consider any effort in the direction of open drivers a worthy goal. That would be the heart of any subsequent misunderstandings.
I'll let someone else with a bigger Linaro hat make that official statement though.
I haven't reversed engineered any driver so I can't claim of knowledge in this matter. However I've been following closely other such projects like nouveau and it took them a _long_ time to get to this point here -which may be usable for many people, but it's not even at a beta state according to the Nouveau developers. Even if we assume the fact that 10 times more ARM F/OSS developers gather to reverse engineer the binary blobs, how long do you think it would take until a beta driver appears? 1 year? 2 years? And what will happen in the meantime?
In the mean time some other company might see a nice opportunity to sidestep the competition by making its drivers fully open source. That's what happened with WIFI, resulting in the least expected company to finally open up its driver like all the others ended up doing. It must have been economically advantageous to them in the end (lower support costs, additional customer opportunities, etc.)
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 problems don't end at the driver, rather the opposite.
Problems don't end at the driver, they start there.
And those proprietary drivers exist and are being used already. But don't expect the mainline kernel to make accommodations for them. It is not economically viable for the Open Source community to accommodate proprietary drivers, irrespective of how loud you might advocate for that.
Nicolas
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 replace it with e.g. "technically"), and it's all the more true.
Xav
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 can remove the word "economically" from your sentence (or replace it with e.g. "technically"), and it's all the more true.
I used that word on purpose. Economic principles do exist in the Open Source world too. It is just not based on monetary profits.
Nicolas
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 support their market price drops significantly.
i really see no big deal here. it happened before with nvidia - don't you recall how much their hardware lost in it's value ? upgraded cards were given-away as buggy and unsupported in linux, and had very short-life in 2nd hand market. compare it to i.e. SGI machines which are still circulating and are valued, even though their opensource support is actually not so brilliant, and hardware performance even worse...
nowadays companies like ARM are again fishing in the same market - people who once invested big bucks in nvidia, are now thinking twice. and it's not really related with opensource - notice how many unsatisfied customers turned away from _proprietary_ solutions , tired with messy service packs, remote exploits, long-uncorrected bugs, and dropping of support for whole OS solutions, leaving users with expensive support options and unstable systems behind.
i think if new ARM/freescale products will not have decent opensource support now, they will not only loose opensource market, but will not get the profit from proprietary market basing on previous 'success' of similiar solutions due fact users simply learnt their lesson.
On 22 December 2010 20:39, Piotr Gluszenia Slawinski curious@bwv190.internetdsl.tpnet.pl 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 this claim i want to remind the simple rule of capital accumulation. Open Source community _already_ accumulated enough _capital_ in form of algorithms, implementations, social relations, experience, documentation and augmentation with education system .
I'm sorry you've got it all wrong. Survive? Yes, certainly. Actually thrive and make a difference in the world without the corporate world? Definitely not. If you only care about the former that's fine, but have no illusion that we would even be having this discussion here were it not for the corporate world caring about Linux on ARM.
survive, and serve. despite corporate entities, opensource projects do not just cease to exist once markets cut the profit down. this is where corporations loose big time in comparison to opensource.
thrive? come on, discussion starts about small, insignificant toys, and i repeat - insignificant toys. talking big about '3d in linux' as any priority sounds funny in world in which 99% of the tcp/ip routing is performed by opensource-based solutions, at both enterprise , and 'home' scale. while opensource display system has enough proprietary alternatives to choose from at low cost, point of developing it lies far beyond just cutting few pennies for ... toys. this can be done without opensource at all.
talking about opensource unable to survive without care of corporate world is also funny. current opensource politics allowed such growth thanx to proper politics when it came to dealing with corporate world. without opensource certain solutions would never propagate and become cost-effective to gain enough markets. so profit opensource gained from it is fair-earned, and comes from market itself, not from corporate world attitude. in other words - if certain corporations would not partake certain attitude, it would be done by other ones, or certain products would just never existed.
still _opensource_ would be same good as before, as notice development of certain algorithms and code was conducted in parallel, and also sponsored by university environments for solely research and educational purposes (to exclude any opensource-ideology driven motives) .
my 2 eurocents ;)
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 situation to occur in which it is in their own hardcore capitalist self interest to change.
In my experience open source usually mirrors standards in this. The leading vendors refuse to take part, the smaller vendors see the opportunity - often working together - and the bigger vendor eithers gets its backside kicked or does a sharp turn in the right direction.
That's the story of email, of the web, and is occuring currently in telephony and other areas.
It's also why folks like Dell deserve a lot more credit than they get for the success of Linux.
If its not commercially sensible it doesn't matter what the licensing says. They are corporations not charities, if it's not economically viable for them to manage it all themselves including new driver releases, legal risk, all their own review and keeping up with DRI then they have to decide which way to go - some go the "hit and run" approach ('not got kernel X then sorry but not our problem'), some do the work to support it release by release but don't go GPL (eg Nvidia), some open up, others just walk away.
Alan
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 (by never upstreaming it) tends not to be sustainable (although some companies still try). Proprietary code exists for all sorts of reasons, often a bogus belief in an intrinsic value. Graphics, in particular, is a very litigious world and also, the biggest cause of proprietary code, surely some link?
Back to the plot. Linaro is trying to help here, both in reducing non-optimal code forking and in helping its members work better with the open source communities. As I said in my earlier mail, this will take time. That said, I've seen enormous shifts within the ARM partnership already this year and look forward to more next year.
Merry Christmas / Happy Holidays to one and all. Dave
ps nice to see that you keep your old email address. Are you still in Wales?
On 23 Dec 2010, at 17:17, Alan Cox wrote:
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 situation to occur in which it is in their own hardcore capitalist self interest to change.
In my experience open source usually mirrors standards in this. The leading vendors refuse to take part, the smaller vendors see the opportunity - often working together - and the bigger vendor eithers gets its backside kicked or does a sharp turn in the right direction.
That's the story of email, of the web, and is occuring currently in telephony and other areas.
It's also why folks like Dell deserve a lot more credit than they get for the success of Linux.
If its not commercially sensible it doesn't matter what the licensing says. They are corporations not charities, if it's not economically viable for them to manage it all themselves including new driver releases, legal risk, all their own review and keeping up with DRI then they have to decide which way to go - some go the "hit and run" approach ('not got kernel X then sorry but not our problem'), some do the work to support it release by release but don't go GPL (eg Nvidia), some open up, others just walk away.
Alan
On Wed, Dec 22, 2010 at 6:02 AM, Konstantinos Margaritis markos@genesi-usa.com wrote:
On 22 December 2010 09:51, Matt Sealey matt@genesi-usa.com 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 discussion ended up on phoronix.com [1], with an air of hostility towards Genesi and Matt for no good reason.
I don't know whose idea was that, but it's certainly of very bad taste and helps very little to the discussion. Matt poses real questions and issues we -as a company producing ARM products- face all the time. Admittedly the technical reasons for not including the kernel-space driver into mainline presented by Dave Airlie are correct and very down-to-earth. But IMHO, *this* should be the starting point to continue the discussion, instead of immediately rejecting this driver. Is there *any* way that problem posed by Dave could be solved, perhaps by throwing the ball to the ARM vendor companies to provide just a small extra part of the code needed to do API checks and therefore ensuring the kernel guys CAN actually do their work as they like?
It's not enough to provide a toy program/library that just call into the new kernel API, you really need to provide a full open source use case that does achieve somethings using the new kernel API you are introducing. It's the only way we can possibly evaluate the new API.
Open source GPU kernel API are a pain to design and i can tell you that if i had liberty to change them i would do that a lot until finding the best one (nouveau is in happy situation here and they are more than right to wait until they are completely satisfied with the API before freezing it).
As for the philosophical problems, well, I'm sure everyone here understands that the situation of ARM graphics in the kernel is in no way comparable to Intel or Nvidia/ATI chipsets, they had totally different starting points. ARM came from the embedded market where it thrived for many years with the exact same licensing rules that we all would like to abolish in just a few months, where at the same time we "swallowed" the fact that it took Intel and ATI/AMD - forget nvidia, nv-obfuscated driver IN the kernel for YEARS? really? - many years to accept mainline opensource development. And even Intel with all their experience made a complete mess of things using the latest cpus.
No body is saying AMD or Intel were fast to jump into open source, doesn't mean that ARM ecosystem can't do it faster than AMD or Intel did.
I *really* do appreciate Linaro and the effort from ARM and the relevant vendors towards open source enablement, and Genesi has proven that by donating ~50 ARM based netbooks and smarttops to Linaro developers at Linaro@UDS -and around ~40 units to other projects including Debian and Gentoo -and we intend to give more in the future. We know the process and how it works, just as well as everyone here does actually. But we also have to be pragmatic. An ARM based solution/product with no long-term support from the kernel side will find it very hard to survive indeed. I strongly believe that, half a solution is better than no solution, and it can also serve a purpose until a proper full solution appears. It also does show a leap of good faith from the FOSS side, and one which ARM companies will have to follow soon.
So, if by chance anyone really expects ARM licensees to do 180 degrees change in philosophy overnight, I obviously cannot speak for them, but IMHO, that is not bound to happen. It will probably happen in a few years but only by discussion and collaboration, seriously not by dealing with absolutes. Denying even the smallest step backwards from the side of the FOSS community is not a victory, it's a downright failure of the community side to actively support and push ARM -based devices as an alternative Linux desktop and portable solutions (netbook etc).
My 2c.
Cheers, Jerome Glisse
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 carefully done for this reason.
You may think it's a horrible idea, and from a technical perspective it is, but from a legal perspective.. it's not a problem.
I would suggest you re-read the detail on derivative works, from a legal not a computer science point of view. You may want to read up on the history of the dispute between Next (the computing not the clothing firm) and the FSF with regards to the Objective C compiler.
Note also btw that the possibility of accidentally including general user space was a concern which is why there is a rider with the kernel COPYING file - for the standard syscall interfaces only. There is a difference between a derivative work and merely using an interface and there are lots of ways works can be derivative or not that usually surprise people who think in models around code. The fact these can work in weird and wonderous ways is one reason for that rider.
grounds, and policy grounds. There is no legal issue here. It is not
That is a point only a court of law can decide. It's something I do spend time discussing with lawyers and I have to say not one of them considers there to be no legal issue. The actual boundary for such things is extremely grey and ill defined in software, although there is a lot more caselaw in comparable other areas (anthologies and compilations versus for example music as film scores, or combining two pieces of music to make one tune)
concept now... what's the point? It'll never get into mainline.
Unless it is open sourced - ditto the various other things with the same problem - including things like the Intel PSB driver.
Alan
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 important part. The userspace library is closed because it is proprietary; and I think it is well outside Linaro's remit to lobby for opensourcing of proprietary code simply to meet an esoteric and needless demand for source code access (as it stands, you can get source code access by signing the usual plethora of NDAs with the appropriate vendor, as Genesi has done). It is my understanding that Freescale/AMD and Qualcomm maintain seperate forks of the driver and do not cooperate on development, and in any case, Linaro does not include Qualcomm anyway, therefore it is also to my understanding that this discussion is also beyond Linaro's remit.
Given that upstream policy is to refuse DRM components unless there's an open userspace consumer of the interface, whether or not this conversation has any purpose is entirely down to whether Linaro's kernel policy is to limit itself to upstreamable code or not. If Linaro's reference kernel is intended to include nothing but code that's on track to become mainline then asking whether there's any way these drivers can be merged is a useful question. If Linaro's reference kernel is intended to include whatever's necessary to get hardware working, upstream-suitable or otherwise, then there's not much point in worrying about it.
Dnia niedziela, 12 grudnia 2010 o 21:45:37 Linus Walleij napisał(a):
Is the AMD GPU exposing all functionality in its kernel driver or is there some userspace blob somewhere with lots of e.g. GL goodies?
There is libgsl.so which do glue between kernel and X11 driver. closed source.
Regards,
On Sun, Dec 12, 2010 at 5:41 AM, Arnd Bergmann arnd@arndb.de wrote:
Following a discussion we had on the Freescale BSP, I started a tree at http://git.linaro.org/gitweb?p=people/arnd/imx.git%3Ba=summary that has the same contents as the tree on the freescale git server, but splits them into six branches at this time, though the number should increase.
And in addition to Arnd's great analysis, by looking at the statistics of the differences as a whole based on each directory, here are some more insights:
NOTE: FSL's latest imx_2.6.35_10.10.01 release is based on v2.6.35.3.
1. arch/arm
$> git diff --shortstat v2.6.35.3.. arch/arm
378 files changed, 140310 insertions(+), 1969 deletions(-)
However, not all of these changes are i.MX 51 or i.MX 53 based,
$> git diff --dirstat v2.6.35.3.. arch/arm
10.2% arch/arm/configs/ 5.6% arch/arm/mach-mx23/include/mach/ 8.3% arch/arm/mach-mx23/ 5.2% arch/arm/mach-mx25/ 5.4% arch/arm/mach-mx28/include/mach/ 11.4% arch/arm/mach-mx28/ 5.6% arch/arm/mach-mx3/ 21.3% arch/arm/mach-mx5/ 10.7% arch/arm/plat-mxc/include/mach/ 3.9% arch/arm/plat-mxc/sdma/iapi/ 5.6% arch/arm/plat-mxc/ 6.0% arch/arm/plat-mxs/
Excluding arch/arm/configs, which we need to sort out a bit for a more structural Kconfig scheme
- the i.MX 5 related changes are basically:
arch/arm/mach-mx5/ 53 files changed, 31554 insertions(+), 1221 deletions(-) arch/arm/plat-mxc/ 109 files changed, 26618 insertions(+), 381 deletions(-)
- The number of total of patches involved in the above changes is 132:
$> git log --pretty=oneline 6d23f50.. arch/arm/mach-mx5 arch/arm/plat-mxc | wc -l 132
- Of all the changes to arch/arm/mach-mx5 and arch/arm/plat-mxc, some are more significant, esp. the files below:
arch/arm/mach-mx5/clock.c | 5098 ++ arch/arm/mach-mx5/clock_mx50.c | 3435 ++ arch/arm/plat-mxc/include/mach/pmic_audio.h | 2315 + arch/arm/plat-mxc/include/mach/pmic_convity.h | 873 + arch/arm/plat-mxc/include/mach/pmic_power.h | 1358 + arch/arm/plat-mxc/sdma/iapi/src/iapiHigh.c | 2750 + arch/arm/plat-mxc/sdma/sdma.c | 1551 +
However, the changes above are mostly trivial definitions.
- The change to generic ARM architecture code is actually not much, excluding those SoC specific, here's the summary:
arch/arm/Kconfig | 39 +- arch/arm/Makefile | 3 + arch/arm/boot/compressed/Makefile | 1 + arch/arm/boot/compressed/head.S | 53 + arch/arm/kernel/head.S | 31 +- arch/arm/kernel/setup.c | 10 +- arch/arm/mm/cache-l2x0.c | 34 + arch/arm/mm/proc-v6.S | 16 + arch/arm/tools/mach-types | 161 +-
The changes to above are relatively trivial, including an early patch of dynamic PHYS_OFFSET offset (not yet merged in mainline), Catalin's patch of partial low interrupt latency mode for ARM1136, enabling/disabling of L2 cache, and the change to mach-types as always.
- As a result, the components need love are highlighted below, some of the code should have already been merged since Amit pushed the first base port of i.MX 51:
* bus_freq.c [1] * clocks and devices * DMA * USB * SDMA
[1] it seems to be a workaround of having the bus frequency stays somewhere before suspend
For the peripheral driver specific changes, a preliminary scan resulted in a list of the drivers below:
- crypto driver (DCP) - PATA driver - Random Number Generator - One-Time-Programming Fuse - SIM controller - Internal Memory (IIM) - I2C master/slave - Keypad - Power Management IC (MC13892 and else?) - Camera Capture - OPL (An in-kernel software rotation library?) - IPU Post-Processing Unit - MMC - NAND - ADC - CAN Bus - Ethernet - InfraRed - RTC - UART (should have been supported already in mainline) - USB Host/Gadget/OTG - Framebuffer - EPD (E-Ink controller) ?? - Audio controller (AC97/SSI)
As Arnd has pointed out, the drivers/mxc/* directory contains those code that is very freescale specific and needs special love to get them into individual drivers, including the GPU driver.
And some of the drivers have two versions, one FSL version and one mainline version, we need to figure out and fill the gaps.
For those off-chip/on-board peripherals, below drivers need love:
- Si4702 (FM radio), there is driver already there supporting this in drivers/media/radio/si470x/ - hwmon (isl29003, max17135, mma7450) - MC9S08DZ60 Keypad module - MPR084 Touch Sensor Keypad module - TSC2007 (there is already support in upstream) - Various audio codecs
The off-chip peripherals are not necessary part of Freescale code , but needs to be there in our kernel for a complete support of the boards.
On Monday 13 December 2010, Eric Miao wrote:
However, not all of these changes are i.MX 51 or i.MX 53 based,
$> git diff --dirstat v2.6.35.3.. arch/arm
10.2% arch/arm/configs/ 5.6% arch/arm/mach-mx23/include/mach/ 8.3% arch/arm/mach-mx23/ 5.2% arch/arm/mach-mx25/ 5.4% arch/arm/mach-mx28/include/mach/ 11.4% arch/arm/mach-mx28/ 5.6% arch/arm/mach-mx3/ 21.3% arch/arm/mach-mx5/ 10.7% arch/arm/plat-mxc/include/mach/ 3.9% arch/arm/plat-mxc/sdma/iapi/ 5.6% arch/arm/plat-mxc/ 6.0% arch/arm/plat-mxs/
FWIW, I've split out the mach-mx23/mx28 and plat-mxs changes into another branch now. The mach-mx25/mx3/mx5 changes could probably be split up further as well, but that will be a bit harder because they all share infrastructure in plat-mxc.
More importantly, I think the sdma stuff needs to be split out from the rest, as this is likely more controversial. This will also be hard to do, since there are a number of changesets that touch both sdma and arch code.
Excluding arch/arm/configs, which we need to sort out a bit for a more structural Kconfig scheme
the i.MX 5 related changes are basically:
arch/arm/mach-mx5/ 53 files changed, 31554 insertions(+), 1221 deletions(-) arch/arm/plat-mxc/ 109 files changed, 26618 insertions(+), 381 deletions(-)
The plat-mxc changes are mostly, but not all i.MX5 specific. We need to be careful there.
Of all the changes to arch/arm/mach-mx5 and arch/arm/plat-mxc, some are more significant, esp. the files below:
arch/arm/mach-mx5/clock.c | 5098 ++ arch/arm/mach-mx5/clock_mx50.c | 3435 ++ arch/arm/plat-mxc/include/mach/pmic_audio.h | 2315 + arch/arm/plat-mxc/include/mach/pmic_convity.h | 873 + arch/arm/plat-mxc/include/mach/pmic_power.h | 1358 + arch/arm/plat-mxc/sdma/iapi/src/iapiHigh.c | 2750 + arch/arm/plat-mxc/sdma/sdma.c | 1551 +
However, the changes above are mostly trivial definitions.
SDMA as a whole is interesting. It would be worthwhile to find out how it fits in with the rest of the drivers and architecture, and what it would take to bring this upstream.
The change to generic ARM architecture code is actually not much, excluding those SoC specific, here's the summary:
arch/arm/Kconfig | 39 +- arch/arm/Makefile | 3 + arch/arm/boot/compressed/Makefile | 1 + arch/arm/boot/compressed/head.S | 53 + arch/arm/kernel/head.S | 31 +- arch/arm/kernel/setup.c | 10 +- arch/arm/mm/cache-l2x0.c | 34 + arch/arm/mm/proc-v6.S | 16 + arch/arm/tools/mach-types | 161 +-
The changes to above are relatively trivial, including an early patch of dynamic PHYS_OFFSET offset (not yet merged in mainline), Catalin's patch of partial low interrupt latency mode for ARM1136, enabling/disabling of L2 cache, and the change to mach-types as always.
I think all of these changes are upstream in one way or another.
And some of the drivers have two versions, one FSL version and one mainline version, we need to figure out and fill the gaps.
Good point, I had not realized this.
Arnd
On Sun, Dec 12, 2010 at 5:41 AM, Arnd Bergmann arnd@arndb.de wrote:
Following a discussion we had on the Freescale BSP, I started a tree at http://git.linaro.org/gitweb?p=people/arnd/imx.git%3Ba=summary that has the same contents as the tree on the freescale git server, but splits them into six branches at this time, though the number should increase.
The current split is
- master -- an octopus merge of all the other branches, identical to
the BSP 381 patches total 1286 files changed, 882747 insertions(+), 2932 deletions(-)
Arnd,
One other thing is Freescale's Android BSP has a kernel tree of more patches than this, and not all those additional patches are Android related. So they do have multiple versions of the kernel, and we may also need to figure out the best baseline for our evaluation.
- drv-mxc -- all drivers in the new drivers/mxc/ directory and new drivers
in drivers/char/, as these typically introduce new user ABIs that need very careful review. 23 patches 189 files changed, 97215 insertions(+), 0 deletions(-)
- amd-gpu -- a single but huge driver for the GPU. As is normally the
case with GPU drivers, we can expect long discussions before it will get considered for mainline 4 patches 98 files changed, 278321 insertions(+), 0 deletions(-)
- ath -- another single driver that is rather large, for the ath6km
wifi controller. Split out because it is not owned by freescale. 4 patches 169 files changed, 94561 insertions(+), 0 deletions(-)
- other-subsys -- device drivers for existing subsystems. These should
be largely uncontroversial, because they don't introduce new ABIs and the code looks clean enough for a straight- forward inclusion through the respective subsystem maintainers. Someone still needs to go through these and split them up by subsystem and separate new drivers from patches to existing drivers where needed. 159 patches 445 files changed, 270318 insertions(+), 959 deletions(-)
- arch -- everything in the arch/arm, directory, this will go through
review on the linux-arm-kernel mailing list. This also needs to be split up further into smaller branches. 179 patches 378 files changed, 140275 insertions(+), 1991 deletions(-)
- external -- patches that look unrelated to the rest, and are probably
backported from patches that already went upstream. 9 patches 7 files changed, 37 insertions(+), 32 deletions(-)
Arnd
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On Monday 20 December 2010 16:58:59 Eric Miao wrote:
One other thing is Freescale's Android BSP has a kernel tree of more patches than this, and not all those additional patches are Android related. So they do have multiple versions of the kernel, and we may also need to figure out the best baseline for our evaluation.
Very good point, I wasn't aware of that.
I would think that the best way forward here is to make the Android tree a superset of the regular tree, and then separate the changes from the Android tree into one extra branch.
Once that is done, the Android branch can be split up into strictly Android related changes and changes that should instead live in a different branch.
Arnd
-
Alan Cox -
Arnd Bergmann -
Dave Airlie -
Dave Martin -
David Rusling -
Eric Miao -
Jammy Zhou -
Jerome Glisse -
Konstantinos Margaritis -
Linus Walleij -
Marcin Juszkiewicz -
Matt Sealey -
Matthew Garrett -
Nicolas Pitre -
Piotr Gluszenia Slawinski -
Tom Gall -
Vandervennet Yves-R55763 -
Xavier Bestel