Re: regressions in linux-next?

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

 



On 04/24/2014 11:17 AM, Tony Lindgren wrote:
> * Nishanth Menon <nm@xxxxxx> [140424 08:47]:
>> On 04/24/2014 10:40 AM, Tony Lindgren wrote:
>>> * Nishanth Menon <nm@xxxxxx> [140424 08:25]:
>>>> On Thu, Apr 24, 2014 at 10:16 AM, Kevin Hilman <khilman@xxxxxxxxxx> wrote:
>>>>> Linus Walleij <linus.walleij@xxxxxxxxxx> writes:
>>>>>
>>>>>> On Tue, Apr 22, 2014 at 5:52 PM, Javier Martinez Canillas
>>>>>> <javier@xxxxxxxxxxxx> wrote:
>> [...]
>>>>>> We even tried to get an Innovator to boot just to be able to refactor
>>>>>> OMAP stuff but fell short on some special JTAG reflash snag so
>>>>>> we are dependent on maintainers to help out here :-/
>>>>>
>>>>> Unfortunately, my OMAP1 (omap5912/OSK[1]) died last year and I haven't been
>>>>> able to get it booting again.  I wonder if Spectrum Digital still has
>>>>> these available?  Their websites[1] says "call for price."
>>>>>
>>>>> Kevin
>>>>>
>>>>> [1] http://www.spectrumdigital.com/product_info.php?products_id=39
>>>>
>>>>
>>>> Perhaps dumb question: but are there folks who really care about omap1
>>>> boot anymore in upstream? should it be time to deprecate it - say for
>>>> 3.17 or so?
>>>
>>> Why? There are people still using omap1 and it works just fine. And
>>> in general the maintenance work needed for omap1 is really minimal.
>>>
>>> And in the GPIO case the issue was also discovered on new TI boards.
>>>
>>
>> I mean, yeah - hobby usage is nice.. but there is maintenance burden
>> when it comes to ensuring generic drivers such as timers, gpio etc.. I
>> am not saying we cannot maintain it, but if there are no strong
>> reasons why to keep it alive, it kinda reduces the scope of
>> modifications as kernel frameworks evolve to be generic. The OMAP1
>> generation of processors based boards are so hard to get and go
>> running that developer access to these boards slow things down as well.
> 
> It's not a burden by any means like I said. And like I said, the
> drivers should work just fine no matter what the data source.
> 
> Having the platform_data around actually forces us to fix up the
> drivers so they work in the standard Linux way. So it's really the
> mixed state of drivers that are the issue here.

:) fair enough. I guess this question dies for the time being at least.

> 
>> I understand that "strong reasons to keep it alive" is pretty
>> subjective in nature.. but just throwing the thought out here.
> 
> Strong reasons as in people are using it. There just isn't any
> stronger reason available in Linux land.
> 
> Or what do you think is a "stronger reason" then? Merging random

The trigger was that even at TI, OMAP1s are hard to get to, in fact, I
do not of one person in TI who seems to have a functioning OMAP1
platform - and context of my question came from that background and
noticing others going through similar pain as well. Will continue to
look around.

> corporate snapshots of kernel code upstream from some hacked up
> kernel tree where the code has never even been even tested with
> the mainline kernel and is not usable for any available product?
> I don't think so :)

Thanks for the flame :D. "evil vendor" kernels have a purpose to serve
and I guess we know why they exist - even though we might not agree
with many of the reasonings or the way things are done there. I, for
one, will refuse to get into a flame about it :D.

We are all believers in upstream code functioning with all available
platforms we can get our hands on - if that was not our objective, we
at TI would never have spend money and effort trying to get automated
test environments for boards that corporate may not see much sense in
it. It is part of our continued commitment to working together as a
single Linux community - yep, we are not perfect or maybe even "good
enough", but we always strive to improve.

-- 
Regards,
Nishanth Menon
--
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