On Tue, Jan 24, 2012 at 1:53 AM, Cousson, Benoit <b-cousson@xxxxxx> wrote:
> + Mike
>
> On 1/19/2012 12:39 AM, Ameya Palande wrote:
>>
>> Signed-off-by: Ameya Palande<ameya.palande@xxxxxx>
>
>
> Assuming that you will re-send with Kevin's comment taken into account, the
> fix is indeed very valid.
>
> Acked-by: Benoit Cousson <b-cousson@xxxxxx>
>
>> ---
>> arch/arm/mach-omap2/clock44xx_data.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/clock44xx_data.c
>> b/arch/arm/mach-omap2/clock44xx_data.c
>> index 08e86d7..053cc15 100644
>> --- a/arch/arm/mach-omap2/clock44xx_data.c
>> +++ b/arch/arm/mach-omap2/clock44xx_data.c
>> @@ -953,8 +953,8 @@ static struct dpll_data dpll_usb_dd = {
>> .modes = (1<< DPLL_LOW_POWER_BYPASS) | (1<<
>> DPLL_LOCKED),
>> .autoidle_reg = OMAP4430_CM_AUTOIDLE_DPLL_USB,
>> .idlest_reg = OMAP4430_CM_IDLEST_DPLL_USB,
>> - .mult_mask = OMAP4430_DPLL_MULT_MASK,
>> - .div1_mask = OMAP4430_DPLL_DIV_MASK,
>> + .mult_mask = OMAP4430_DPLL_MULT_USB_MASK,
>> + .div1_mask = OMAP4430_DPLL_DIV_0_7_MASK,
>
>
> We were wrongly assuming that all DPLLs were using the same mask, which
> cannot be the case for the USB DPLL since that one has a higher max
> multiplier and max divider than the other ones (4095/256 instead of
> 2047/128).
>
> For Mike and Paul,
>
> It is indeed a bug in the clock generator script.
This DPLL does have some quirks. Rajendra recently solved a bug where
.clkdm was not set for this DPLL since it is in the L3INIT clkdm, not
an always-on clkdm, so that must also be taken into account in the
data generation.
Regards,
Mike
>
> Regards,
> Benoit
--
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
