On 08/11/10 13:27, Tony Lindgren wrote:
> * Premi, Sanjeev <[email protected]> [100811 12:45]:
>   
>>> -----Original Message-----
>>> From: [email protected] 
>>> [mailto:[email protected]] On Behalf Of Tony Lindgren
>>> Sent: Wednesday, August 11, 2010 2:50 PM
>>> To: Igor Grinberg
>>> Cc: Stanley.Miao; [email protected]
>>> Subject: Re: [PATCH] OMAP2: Fix a cpu type check problem.
>>>
>>> * Igor Grinberg <[email protected]> [100810 17:25]:
>>>       
>>>> On 08/10/10 15:36, Stanley.Miao wrote:
>>>>         
>>>>> cpu_is_omap3517() and cpu_is_omap3505() are the subgroups 
>>>>>           
>>> of cpu_is_omap34xx(),
>>>       
>>>>> so we should check cpu_is_omap3517() and 
>>>>>           
>>> cpu_is_omap3505() first, then check
>>>       
>>>>> cpu_is_omap34xx().
>>>>>
>>>>> Signed-off-by: Stanley.Miao <[email protected]>
>>>>>   
>>>>>           
>>>> Tested-by: Igor Grinberg <[email protected]>
>>>>
>>>> I've just ran into this yesterday evening.
>>>> Having a patch for this on the next day made me :)
>>>> Tested on AM3517.
>>>>         
>>> Can you please describe what breaks so we can merge this as a fix?
>>>
>>>       
>> cpu_is_34xx() will be true for all OMAP3 based devices including
>> AM3517. So, if we want to perform operations specific to AM3517, the
>> check for AM3517 should be done first else you match for 34xx would
>> return true; and you wouldn't go far enough to check for am3517.
>>     
> Understood, but we need some concrete error like "otherwise booting
> xyz board fails with non-working USB" or similar.
>   

Otherwise, All AM35XX (Sitara) clocks do not get registered and device
drivers
(ti_hecc, etc...) that depend on those clocks are failing to get the
clock and
end up with non working device.

> Tony
>
>   

-- 
Regards,
Igor.

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

Reply via email to