Re: [linux-sunxi] Re: [RFC] mmc: core: Set clock before switching to highspeed mode.
On 7 September 2015 at 15:02, Hans de Goede <hdego...@redhat.com> wrote:
> Hi,
>
>
> On 06-09-15 16:47, Yousong Zhou wrote:
>>
>> On Sep 6, 2015 10:14 PM, "Shawn Lin" <shawn@rock-chips.com> wrote:
>>>
>>>
>>> 在 2015/9/6 20:09, Yousong Zhou 写道:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> On 6 September 2015 at 08:12, Shawn Lin <shawn@rock-chips.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 2015/9/5 22:58, Hans de Goede wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Shawn Lin,
>>>>>>
>>>>>> On 05-09-15 16:07, Shawn Lin wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2015/9/5 18:19, Yousong Zhou wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> A SD card with sunxi-mmc can fail with the following error message
>>>>>>>> (RCD for
>>>>>>>> response CRC error) when trying to switch to highspeed mode.
>>>>>>>> Setting
>>>>>>>> the bus
>>>>>>>> clock before the access mode switch fixed it.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> No, that's wrong!
>>>>>>>
>>>>>>> Before this card is switched to highspeed, it works under
>>>>>>> identification mode(From spec: bus clock <= 400KHz). How could you
>>>>>>> raise bus clock to higher clk rate which I _guess_ is 52MHz before
>>>>>>> you
>>>>>>> notify sd cards to run into highspeed mode?
>>>>>>>
>>>>>>> Althought it works for this card, this patch will not please the
>>>>>>> other
>>>>>>> cards that they might not reply CMDs any longer including the
>>>>>>> following CMD6.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks for the feedback, this is exactly why I asked Yousong Zhou to
>>>>>> take this
>>>>>> to the mmc list.
>>>>>>
>>>>>> So if this is not the proper fix for the problem that Yousong Zhou is
>>>>>> seeing, then
>>>>>> what might be the proper fix ?
>>>>>>
>>>>>
>>>>> From my knowledge of mmc, there hadn't have a way to deal with this
>>
>> "broken"
>>>>>
>>>>> case. In another word, IMO,it's ANTI-SPEC. We can't be too spec
>>
>> sometimes,
>>>>>
>>>>> but at least we shouldn't violate it.
>>>>>
>>>>
>>>> Maybe the fix is anti-spec. But the fact is that the card works on
>>>> many other platforms with the builtin card reader (not through an USB
>>>> adapter), including Mac OS X, my old Nokia Symbian phone, and Windows.
>>>>
>>>>>> Could it be that the sunxi-mmc is doing some things in the wrong order
>>>>>> when
>>>>>> changing the clock, or is this all under control of the mmc core ?
>>>>>>
>>>>>
>>>>> all of this is under control of the mmc core.
>>>>> So if Yongsong does want this card to work for any linux-based mmc
>>
>> stack, I
>>>>>
>>>>> guess something like that should be "better"?
>>>>>
>>>>> if (switch to HS fail) {
>>>>> set_bus_clk
>>>>> goto retry switch to HS
>>>>> }
>>>>>
>>>>> BUT...I admit it seems strange as well.
>>>>>
>>>>
>>>> The SD Specification (simplified version) says "If CRC error occurs on
>>>> the status data, the host should issue a power cycle.", so I guess the
>>>> above approach is anti-spec in some way :)
>>>>
>>>
>>> Right，I was guessing that way from your intention.
>>>
>>>
>>>> In case it may help debug this problem, I'd like to add that the card
>>>> previously worked fine with U-Boot before commit [1]. This can also
>>>> be confirmed by Debian Jessie installer image with which the old
Re: [linux-sunxi] Re: [RFC] mmc: core: Set clock before switching to highspeed mode.
Hi
On 7 September 2015 at 15:02, Hans de Goede <hdego...@redhat.com> wrote:
> Hi,
>
>
> On 06-09-15 16:47, Yousong Zhou wrote:
>>
>> On Sep 6, 2015 10:14 PM, "Shawn Lin" <shawn@rock-chips.com> wrote:
>>>
>>>
>>> 在 2015/9/6 20:09, Yousong Zhou 写道:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> On 6 September 2015 at 08:12, Shawn Lin <shawn@rock-chips.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 2015/9/5 22:58, Hans de Goede wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Hi Shawn Lin,
>>>>>>
>>>>>> On 05-09-15 16:07, Shawn Lin wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2015/9/5 18:19, Yousong Zhou wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> A SD card with sunxi-mmc can fail with the following error message
>>>>>>>> (RCD for
>>>>>>>> response CRC error) when trying to switch to highspeed mode.
>>>>>>>> Setting
>>>>>>>> the bus
>>>>>>>> clock before the access mode switch fixed it.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> No, that's wrong!
>>>>>>>
>>>>>>> Before this card is switched to highspeed, it works under
>>>>>>> identification mode(From spec: bus clock <= 400KHz). How could you
>>>>>>> raise bus clock to higher clk rate which I _guess_ is 52MHz before
>>>>>>> you
>>>>>>> notify sd cards to run into highspeed mode?
>>>>>>>
>>>>>>> Althought it works for this card, this patch will not please the
>>>>>>> other
>>>>>>> cards that they might not reply CMDs any longer including the
>>>>>>> following CMD6.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks for the feedback, this is exactly why I asked Yousong Zhou to
>>>>>> take this
>>>>>> to the mmc list.
>>>>>>
>>>>>> So if this is not the proper fix for the problem that Yousong Zhou is
>>>>>> seeing, then
>>>>>> what might be the proper fix ?
>>>>>>
>>>>>
>>>>> From my knowledge of mmc, there hadn't have a way to deal with this
>>
>> "broken"
>>>>>
>>>>> case. In another word, IMO,it's ANTI-SPEC. We can't be too spec
>>
>> sometimes,
>>>>>
>>>>> but at least we shouldn't violate it.
>>>>>
>>>>
>>>> Maybe the fix is anti-spec. But the fact is that the card works on
>>>> many other platforms with the builtin card reader (not through an USB
>>>> adapter), including Mac OS X, my old Nokia Symbian phone, and Windows.
>>>>
>>>>>> Could it be that the sunxi-mmc is doing some things in the wrong order
>>>>>> when
>>>>>> changing the clock, or is this all under control of the mmc core ?
>>>>>>
>>>>>
>>>>> all of this is under control of the mmc core.
>>>>> So if Yongsong does want this card to work for any linux-based mmc
>>
>> stack, I
>>>>>
>>>>> guess something like that should be "better"?
>>>>>
>>>>> if (switch to HS fail) {
>>>>> set_bus_clk
>>>>> goto retry switch to HS
>>>>> }
>>>>>
>>>>> BUT...I admit it seems strange as well.
>>>>>
>>>>
>>>> The SD Specification (simplified version) says "If CRC error occurs on
>>>> the status data, the host should issue a power cycle.", so I guess the
>>>> above approach is anti-spec in some way :)
>>>>
>>>
>>> Right，I was guessing that way from your intention.
>>>
>>>
>>>> In case it may help debug this problem, I'd like to add that the card
>>>> previously worked fine with U-Boot before commit [1]. This can also
>>>> be confirmed by Debian Jessie installer image with which t
Re: [linux-sunxi] Re: [RFC] mmc: core: Set clock before switching to highspeed mode.
>>> all of this is under control of the mmc core.
>>> So if Yongsong does want this card to work for any linux-based mmc stack,
>>> I
>>> guess something like that should be "better"?
>>>
>>> if (switch to HS fail) {
>>> set_bus_clk
>>> goto retry switch to HS
>>> }
>>>
>>> BUT...I admit it seems strange as well.
>>>
>>
>> The SD Specification (simplified version) says "If CRC error occurs on
>> the status data, the host should issue a power cycle.", so I guess the
>> above approach is anti-spec in some way :)
>>
>
> Right，I was guessing that way from your intention.
>
>> In case it may help debug this problem, I'd like to add that the card
>> previously worked fine with U-Boot before commit [1]. This can also
>> be confirmed by Debian Jessie installer image with which the old
>> U-Boot there worked fine while the kernel (3.16) did not.
>>
>> [1] sunxi: mmc: Properly setup mod-clk and clock sampling phases,
>>
>> http://git.denx.de/?p=u-boot.git;a=commit;h=fc3a832576ce7bb597b1823935bfb7dcca235c3c
>>
>
> Interesting... but that at least prove your patch is a workaround but not
> find the root cause.
>
> Anyway, look into commit-sha [1], can you have a test by restoring mod-clk
> and clock sampling phases before jump to kernel.
>
Maybe my statement about U-Boot commit [1] above was a little
ambiguous, sorry. I meant to say that with that commit applied,
U-Boot failed initialising the card the same way as the kernel, i.e.
response crc error.
The Debian Jessie installer image's U-Boot worked fine and booted the
kernel because it was before commit [1] happened. However after that
the 3.16 kernel failed initialising the card.
So, with commit [1], U-Boot failed right away without any chance at
all jumping to kernel.
OpenWrt ticket 20387 has more info about the U-Boot failure.
https://dev.openwrt.org/ticket/20387
Anyway, I have no idea what's the effect of those magic numbers on
"sampling phases". Never played with such things before :)
yousong
> I happended to fix some problems which seems *similar* to yours(but I'm not
> sure just from commit[1]'s msg):
>
> https://patchwork.kernel.org/patch/7119661/
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [RFC] mmc: core: Set clock before switching to highspeed mode.
On Sep 6, 2015 10:14 PM, "Shawn Lin" <shawn@rock-chips.com> wrote:
>
> 在 2015/9/6 20:09, Yousong Zhou 写道:
>>
>> Hi,
>>
>> On 6 September 2015 at 08:12, Shawn Lin <shawn@rock-chips.com> wrote:
>>>
>>> On 2015/9/5 22:58, Hans de Goede wrote:
>>>>
>>>>
>>>> Hi Shawn Lin,
>>>>
>>>> On 05-09-15 16:07, Shawn Lin wrote:
>>>>>
>>>>>
>>>>> On 2015/9/5 18:19, Yousong Zhou wrote:
>>>>>>
>>>>>>
>>>>>> A SD card with sunxi-mmc can fail with the following error message
>>>>>> (RCD for
>>>>>> response CRC error) when trying to switch to highspeed mode. Setting
>>>>>> the bus
>>>>>> clock before the access mode switch fixed it.
>>>>>
>>>>>
>>>>>
>>>>> No, that's wrong!
>>>>>
>>>>> Before this card is switched to highspeed, it works under
>>>>> identification mode(From spec: bus clock <= 400KHz). How could you
>>>>> raise bus clock to higher clk rate which I _guess_ is 52MHz before you
>>>>> notify sd cards to run into highspeed mode?
>>>>>
>>>>> Althought it works for this card, this patch will not please the other
>>>>> cards that they might not reply CMDs any longer including the
>>>>> following CMD6.
>>>>
>>>>
>>>>
>>>> Thanks for the feedback, this is exactly why I asked Yousong Zhou to
>>>> take this
>>>> to the mmc list.
>>>>
>>>> So if this is not the proper fix for the problem that Yousong Zhou is
>>>> seeing, then
>>>> what might be the proper fix ?
>>>>
>>>
>>> From my knowledge of mmc, there hadn't have a way to deal with this
"broken"
>>> case. In another word, IMO,it's ANTI-SPEC. We can't be too spec
sometimes,
>>> but at least we shouldn't violate it.
>>>
>>
>> Maybe the fix is anti-spec. But the fact is that the card works on
>> many other platforms with the builtin card reader (not through an USB
>> adapter), including Mac OS X, my old Nokia Symbian phone, and Windows.
>>
>>>> Could it be that the sunxi-mmc is doing some things in the wrong order
>>>> when
>>>> changing the clock, or is this all under control of the mmc core ?
>>>>
>>>
>>> all of this is under control of the mmc core.
>>> So if Yongsong does want this card to work for any linux-based mmc
stack, I
>>> guess something like that should be "better"?
>>>
>>> if (switch to HS fail) {
>>> set_bus_clk
>>> goto retry switch to HS
>>> }
>>>
>>> BUT...I admit it seems strange as well.
>>>
>>
>> The SD Specification (simplified version) says "If CRC error occurs on
>> the status data, the host should issue a power cycle.", so I guess the
>> above approach is anti-spec in some way :)
>>
>
> Right，I was guessing that way from your intention.
>
>
>> In case it may help debug this problem, I'd like to add that the card
>> previously worked fine with U-Boot before commit [1]. This can also
>> be confirmed by Debian Jessie installer image with which the old
>> U-Boot there worked fine while the kernel (3.16) did not.
>>
>> [1] sunxi: mmc: Properly setup mod-clk and clock sampling phases,
>>
http://git.denx.de/?p=u-boot.git;a=commit;h=fc3a832576ce7bb597b1823935bfb7dcca235c3c
>>
>
> Interesting... but that at least prove your patch is a workaround but not
find the root cause.
>
> Anyway, look into commit-sha [1], can you have a test by restoring
mod-clk and clock sampling phases before jump to kernel.
>
Maybe my statement about U-Boot commit [1] above was a little ambiguous,
sorry. I meant to say that with that commit applied, U-Boot failed
initialising the card the same way as the kernel, i.e. response crc error.
The Debian Jessie installer image's U-Boot worked fine and booted the
kernel because it was before commit [1] happened. However after that the
3.16 kernel failed initialising the card.
So, with commit [1], U-Boot failed right away without any chance at all
jumping to kernel.
OpenWrt ticket 20387 has more info about the U-Boot failure.
https://dev.openwrt.org/ticket/20387
Anyway, I have no idea what's the effect of those magic numbers on
"sampling phases". Never played with such things before :)
> I happended to fix some problems which seems *similar* to yours(but I'm
not sure just from commit[1]'s msg):
>
> https://patchwork.kernel.org/patch/7119661/
>
>> Cheers
>>
>> yousong
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>
>
> --
> Best Regards
> Shawn Lin
>
> --
> You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [RFC] mmc: core: Set clock before switching to highspeed mode.
Hi,
On 6 September 2015 at 08:12, Shawn Lin <shawn@rock-chips.com> wrote:
> On 2015/9/5 22:58, Hans de Goede wrote:
>>
>> Hi Shawn Lin,
>>
>> On 05-09-15 16:07, Shawn Lin wrote:
>>>
>>> On 2015/9/5 18:19, Yousong Zhou wrote:
>>>>
>>>> A SD card with sunxi-mmc can fail with the following error message
>>>> (RCD for
>>>> response CRC error) when trying to switch to highspeed mode. Setting
>>>> the bus
>>>> clock before the access mode switch fixed it.
>>>
>>>
>>> No, that's wrong!
>>>
>>> Before this card is switched to highspeed, it works under
>>> identification mode(From spec: bus clock <= 400KHz). How could you
>>> raise bus clock to higher clk rate which I _guess_ is 52MHz before you
>>> notify sd cards to run into highspeed mode?
>>>
>>> Althought it works for this card, this patch will not please the other
>>> cards that they might not reply CMDs any longer including the
>>> following CMD6.
>>
>>
>> Thanks for the feedback, this is exactly why I asked Yousong Zhou to
>> take this
>> to the mmc list.
>>
>> So if this is not the proper fix for the problem that Yousong Zhou is
>> seeing, then
>> what might be the proper fix ?
>>
>
> From my knowledge of mmc, there hadn't have a way to deal with this "broken"
> case. In another word, IMO,it's ANTI-SPEC. We can't be too spec sometimes,
> but at least we shouldn't violate it.
>
Maybe the fix is anti-spec. But the fact is that the card works on
many other platforms with the builtin card reader (not through an USB
adapter), including Mac OS X, my old Nokia Symbian phone, and Windows.
>> Could it be that the sunxi-mmc is doing some things in the wrong order
>> when
>> changing the clock, or is this all under control of the mmc core ?
>>
>
> all of this is under control of the mmc core.
> So if Yongsong does want this card to work for any linux-based mmc stack, I
> guess something like that should be "better"?
>
> if (switch to HS fail) {
> set_bus_clk
> goto retry switch to HS
> }
>
> BUT...I admit it seems strange as well.
>
The SD Specification (simplified version) says "If CRC error occurs on
the status data, the host should issue a power cycle.", so I guess the
above approach is anti-spec in some way :)
In case it may help debug this problem, I'd like to add that the card
previously worked fine with U-Boot before commit [1]. This can also
be confirmed by Debian Jessie installer image with which the old
U-Boot there worked fine while the kernel (3.16) did not.
[1] sunxi: mmc: Properly setup mod-clk and clock sampling phases,
http://git.denx.de/?p=u-boot.git;a=commit;h=fc3a832576ce7bb597b1823935bfb7dcca235c3c
Cheers
yousong
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [RFC] mmc: core: Set clock before switching to highspeed mode.
A SD card with sunxi-mmc can fail with the following error message (RCD for response CRC error) when trying to switch to highspeed mode. Setting the bus clock before the access mode switch fixed it. [1.112060] mmc0: host does not support reading read-only switch, assuming write-enable [1.120203] ehci-platform 1c1c000.usb: irq 31, io mem 0x01c1c000 [1.126527] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 6, RD RCE !! [1.132388] sunxi-mmc 1c0f000.mmc: data error, sending stop command [1.139451] sunxi-mmc 1c0f000.mmc: send stop command failed [1.145056] mmc0: error -110 whilst initialising SD card [1.150424] ehci-platform 1c1c000.usb: USB 2.0 started, EHCI 1.00 [1.156533] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 1, RTO !! Signed-off-by: Yousong Zhou <yszhou4t...@gmail.com> --- drivers/mmc/core/sd.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c index 4e7366a..402a8db 100644 --- a/drivers/mmc/core/sd.c +++ b/drivers/mmc/core/sd.c @@ -366,6 +366,11 @@ int mmc_sd_switch_hs(struct mmc_card *card) return -ENOMEM; } + /* +* Set bus frequency to match highspeed mode. +*/ + mmc_set_clock(card->host, mmc_sd_get_max_clock(card)); + err = mmc_sd_switch(card, 1, 0, 1, status); if (err) goto out; @@ -969,11 +974,6 @@ static int mmc_sd_init_card(struct mmc_host *host, u32 ocr, goto free_card; /* -* Set bus speed. -*/ - mmc_set_clock(host, mmc_sd_get_max_clock(card)); - - /* * Switch to wider bus (if supported). */ if ((host->caps & MMC_CAP_4_BIT_DATA) && -- 1.7.10.4 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Regression in uboot mmc code causing boot failure.
Hi, On 1 September 2015 at 00:07, Hans de Goede <hdego...@redhat.com> wrote: > Hi, > > On 30-08-15 10:30, Yousong Zhou wrote: >> >> Hi >> >> In an OpenWrt ticket [1] I reported two issues encountered by 2 SD >> cards of mine. >> >> One of them failed with `error reading clusters` when reading a uImage >> file of size about 2MB. This issue happened after we switch from DMA >> transfer to `mmc_trans_data_by_cpu()`. It is caused by fixed 2 >> seconds timeout without considering the transfer size. A fixed was >> just posted [2] in OpenWrt-devel list. >> >> The other card failed at the SPL stage with `spl: mmc init failed with >> error: -19`. That -19 is defined as macro TIMEOUT in U-Boot and it is >> comparable to -110 in Linux kernel defined as ETIMEOUT. This problem >> happened after we switch the clock divider from the >> controller-internal one to mod0-clock (commit fc3a832 "sunxi: mmc: >> Properly setup mod-clk and clock sampling phases"). Actually TIMEOUT >> is not the root cause here. It is caused by >> SUNXI_MMC_RINT_RESP_CRC_ERROR when trying to switch the card to >> highspeed mode. Unfortunately I am not familiar with sunxi clock >> system enough to provide a fix for this. >> >> More details can be found in the ticket description in link [1] >> >> [1] https://dev.openwrt.org/ticket/20387 >> [2] http://patchwork.ozlabs.org/patch/512163/ > > > Thanks for the patch I've merged it into my sunxi u-boot tree, > and send a pullreq for merging it into u-boot master. > > As for the other issue I've no idea what is going on there. I just made a fix for that issue. It worked both for U-Boot and Linux. The approach is that we change the bus frequency to 52MHz before (instead of after) the access change. Well, the patch needs to be applied on the core code. I am not sure of the possible side effects on other cards... Patch attached for both U-Boot and Linux. Regards yousong -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. 134-mmc-core-Set-clock-before-switching-to-highspeed-mod.patch Description: Binary data 0001-mmc-add-debug-message-on-failure-of-switching-to-hig.patch Description: Binary data 0002-mmc-set-clock-speed-before-switching-to-highspeed.patch Description: Binary data
Re: [linux-sunxi] Re: Allwinner joins Linaro Digital Home Group, commits to open source chip support
On 5 March 2014 00:10, jonsm...@gmail.com jonsm...@gmail.com wrote: On Tue, Mar 4, 2014 at 3:12 AM, Yousong Zhou yszhou4t...@gmail.com wrote: On 4 March 2014 08:46, jonsm...@gmail.com jonsm...@gmail.com wrote: Let's hope this translates to full corporate support for upstreaming to mainline. Just curious, do current member companies of Linaro push full support for their chips into mainline Linux? I mean, are most parts of those chips full functional with open source drivers? I know the open source GPU support is far from good, but to what extent is upstreaming support to mainline part of Linaro's object? AFAIK no member of Linaro has provided GPU driver source for the kernel. But don't hold companies like Allwinner responsible for this. Almost all ARM CPUs use GPU designs provided either by ARM, Inc or Imagination Technologies. Those two companies refuse to provide the source for their GPU drivers. Allwinner doesn't have any options here - all of the GPU designs they can pick from are controlled by companies that are closed source. The official excuse for closed source GPU drivers is that GPUs are a patent minefield. By opening the source the patent trolls would gain access to information that would let them file a bunch of annoying lawsuits. But in the last year or two both Intel and AMD have overcome this fear and open sourced their GPU implementations. Neither company received a tidal wave of GPU related lawsuits. Recently I signed a NDA for a non-GPU chip. Gone are the days of single page NDA. This one had over twenty pages of dense legalize all of which was aimed at keeping me from using any of the information disclosed in a lawsuit against the vendor. So it took two months of messing around with legal to get access to the datasheets for this chip. An hour after I was able to see the full datasheet I determined that we couldn't use the chip. Gigantic waste of time. We went with a TI chip. Publicly available datasheets and app notes for the TI chip contain more useful info than what I got out of the NDA loving company. Not knowing these information before and can be counted as another bunch of reasons why patents are bad. I tend to think Linaro as a place for the ARM world to standardize things and upstreaming code to the Linux kernel is just a by-product. Thanks, Jon. yousong -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
