Re: [PATCH v5 2/3] omap_twl: Prevent SR to enable for am3517/am3505 devices

[Kevin Hilman]

"Koyamangalath, Abhilash" <abhilash.kv@xxxxxx> writes:

> hi Kevin,
> Apologies for the delayed response, I was on vacation.
>
> On October 01, 2011 4:57 AM, Hilman, Kevin wrote:
>>
>> Abhilash,
>>
>> Kevin Hilman <khilman@xxxxxx> writes:
>>
>>> Abhilash K V <abhilash.kv@xxxxxx> writes:
>>>
>>>> From: Abhilash K V <abhilash.kv@xxxxxx>
>>>>
>>>> In case of AM3517 & AM3505, SmartReflex is not applicable so
>>>> we must not enable it. So omap3_twl_init() is now not called
>>>> when the processor does not support SR.
>>>
>>> This still isn't right.
>>>
>>> The reason to skip the TWL PMIC init is not because SR is not available
>>> (TWL PMICs are quite usable without SR).  The reason to skip TWL PMIC
>>> init is because the PMIC is not present.
> [Abhilash K V] yes, I understand now.
>>>
>>> Instead, we need to fix up the TWL/PMIC init so that TWL-specifics are
>>> only registered if a TWL driver is registered.
>>>
>>
>> Below is a test patch that is a first pass at implementing what I
>> suggested above.  I tested this (along with your patch 3/3) on a
>> 3430/n900 after removing the omap_pmic_init() call frome the board file.
> [Abhilash K V] I'll re-submit the patch with this change (i,e. if you've not already
> pulled it into your branch).

I haven't posted/merged this yet, but I will now that you've tested it.

Thanks.

>>
>> Can you let me know if this solves the problem you're seeing on
>> platforms that don't have TWL PMICs?
> [Abhilash K V] It should, I have validated on  am3517_evm

Thanks, will add a Tested-by from you.

>> After digging into this more, I'm increasingly aware that the way we're
>> managing the init of PMIC stuff is a mess.  Guess I need another round
>> of voltage layer cleanups to fix that up.
> [Abhilash K V] True, and to add to this, the changes required to support only 
> ONE voltage-domain for am35xx would be too many, I believe.

I don't see that part to be an obstacle.

Let's just be sure to use the clock, clockdomain, powerdomain &
voltagedomain data files to describe the hardware.  That is the only
scalable and maintainable way to support these devices.

Any core code changes to fix assumption's we've made that are now wrong
need to be raised and addressed.

Stated differently, we know we have assumptions in the PM core code that
may now be mistaken in light of these new AM3xxx devices.  Rather than
try to trick the core PM code into thinking these devices are "normal"
OMAP3/4 devices, let's fix those assumptions so we can properly support
the new devices.

Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/