Re: [PATCH] omap3: Prevent SDRC deadlock when L3 is changing frequency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 16, 2010 at 4:40 AM, Paul Walmsley <paul@xxxxxxxxx> wrote:
> On Wed, 15 Sep 2010, Tony Lindgren wrote:
>
>> * Paul Walmsley <paul@xxxxxxxxx> [100915 12:07]:
>> > >
>> > > This change has been commited to both TI's android 2.6.29 and 2.6.32 kernels.
>> > > The commits can be viewed here:
>> > > http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=5679c7b1142f3cc2b9285181d53f6b40c4d0296d
>> > > http://git.omapzoom.org/?p=kernel/omap.git;a=commit;h=cf16e57823575d98e9d5165aa7a498ffb751c940
>> > >
>> > > This patch has been rebased on the latest linux-omap tree and tested on
>> > > Kevin Hilman's pm branch.
>>
>> Sounds like a very important fix. But also a good example of how
>> messed up things are with the TI Linux kernel development.
>>
>> Why has this fix it been sitting in some TI internal tree since
>> Fri, 12 Mar 2010?
>

Er, the Mar 12 commit date is misleading - it's likely a customer-internal
tree. It was committed to a TI internal tree 29 June/15 July, and sent to the
list within a week of the second revision.

The people who discovered this are on customer support - we spend
a significant amount of time solving bugs like these, but have very
little gap before the next big one strikes. We work tight production
schedules, getting products out and only just have enough time to
inform internal teams, but not enough to check if these fixes apply
to internal trees (mainline is far far away) and get them there.

(FWIW, Jon's been responsible for discovering and fixing more bugs
on OMAP than almost anyone else I know.)

For this specific patch, I'm not sure if other TI PM teams even
knew about the existence of this patch until end-June.



> About two months of it is my fault, since it was posted to l-o on July 21.
> But all the time between 12 March and 21 July is up to TI to answer.
> This really could have been a useful patch for certain vendors to have
> that are using CORE DVFS on their currently-shipping OMAP3 devices.

Sure, and I'm certain those other vendors have an equal number of critical
bug fixes sitting in their own trees, which they steadfastly refuse to
share with
other competing vendors until their own products are out. (I have specific
examples in mind, but don't want to start another flame war).

Grow up - when a bug is discovered in the field, people are not likely to
share with others in the interest of their own product timelines. While
this may overall be less beneficial for everyone, that is indeed how many
think and work.

>
>> This same bug has been patched in three different trees? But not in
>> the mainline kernel?
>>
>> And this is happening all the time with the TI fixes.
>
> Yeah.

OMAP4 has been demonstrably different - almost every single patch
reaches mainline almost as soon as it is discovered. We had new
silicon woken up with near-mainline code, and new boards supported
in mainline even before the number of boards were in the mid-double digits.

We're working very hard to keep things this way - give us a break. Stop
inciting flame wars. A little support and understanding on your part
would go a long way.

- Anand
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux