For device pads which have OMAP_DEVICE_PAD_WAKEUP set (which means they
are wakeup capable) enable the IO-daisy wakeup capability.
During re-muxing avoid direct write with val as this can disturb if any
mux done at bootloader level so read the pad then write back.
Also add a api to fetch the wake-
For device pads which have OMAP_DEVICE_PAD_WAKEUP set (which means they
are wakeup capable) enable the IO-daisy wakeup capability.
During re-muxing avoid direct write with val as this can disturb if any
mux done at bootloader level so read the pad then write back.
Also add an API to fetch the wake
Govind,
Couple of minor comments.
On Mon, Feb 28, 2011 at 20:09, Govindraj.R wrote:
> For device pads which have OMAP_DEVICE_PAD_WAKEUP set (which means they
> are wakeup capable) enable the IO-daisy wakeup capability.
> During re-muxing avoid direct write with val as this can disturb if any
> m
On Wed, Mar 2, 2011 at 10:19 AM, Varadarajan, Charulatha wrote:
> Govind,
>
> Couple of minor comments.
>
> On Mon, Feb 28, 2011 at 20:09, Govindraj.R wrote:
>> For device pads which have OMAP_DEVICE_PAD_WAKEUP set (which means they
>> are wakeup capable) enable the IO-daisy wakeup capability.
>>
Hi Govindraj,
"Govindraj.R" writes:
> For device pads which have OMAP_DEVICE_PAD_WAKEUP set (which means they
> are wakeup capable) enable the IO-daisy wakeup capability.
> During re-muxing avoid direct write with val as this can disturb if any
> mux done at bootloader level so read the pad then
"Govindraj.R" writes:
> For device pads which have OMAP_DEVICE_PAD_WAKEUP set (which means they
> are wakeup capable) enable the IO-daisy wakeup capability.
> During re-muxing avoid direct write with val as this can disturb if any
> mux done at bootloader level so read the pad then write back.
>
Kevin Hilman writes:
> "Govindraj.R" writes:
[...]
>> /* Assumes the calling function takes care of locking */
>> void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
>> {
>> @@ -342,6 +365,9 @@ void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8
>> state)
>>
> On Sat, Mar 5, 2011 at 7:27 AM, Kevin Hilman wrote:
> Kevin Hilman writes:
>
>> "Govindraj.R" writes:
>
> [...]
>
>>> /* Assumes the calling function takes care of locking */
>>> void omap_hwmod_mux(struct omap_hwmod_mux_info *hmux, u8 state)
>>> {
>>> @@ -342,6 +365,9 @@ void omap_hwmod_mu
On Sat, Mar 5, 2011 at 5:24 AM, Kevin Hilman wrote:
> Hi Govindraj,
>
> "Govindraj.R" writes:
>
>> For device pads which have OMAP_DEVICE_PAD_WAKEUP set (which means they
>> are wakeup capable) enable the IO-daisy wakeup capability.
>> During re-muxing avoid direct write with val as this can dist
* Govindraj [110308 03:43]:
>
> I am not sure whether now we can control read/writes to pad_mux from any
> driver
> interface and I think we have to go through mux framework for any
> read/writes to mux.
Sure, the drivers should not mess with those registers directly.
> with this I cant contro
Tony Lindgren writes:
> * Govindraj [110308 03:43]:
>>
>> I am not sure whether now we can control read/writes to pad_mux from any
>> driver
>> interface and I think we have to go through mux framework for any
>> read/writes to mux.
>
> Sure, the drivers should not mess with those registers di
Hi
On Tue, 8 Mar 2011, Kevin Hilman wrote:
> Tony Lindgren writes:
>
> > * Govindraj [110308 03:43]:
> >>
> >> I am not sure whether now we can control read/writes to pad_mux from any
> >> driver
> >> interface and I think we have to go through mux framework for any
> >> read/writes to mux.
By the way, if your patch relies on OMAP_DEVICE_PAD_IDLE, you should
probably sync up with Sricharan, who is apparently planning to remove that
flag:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg46296.html
- Paul
--
To unsubscribe from this list: send the line "unsubscribe lin
Govindraj writes:
> Module level wakeup doesn't seem to work and only
> way it seem to wakeup is through using resume_idle
> from sram_idle.
Have you verified if the module wakeups themselves are not working, or
just that the wakeup is not propagating to a device IRQ?
As a quick test, I did a s
On Wed, Mar 9, 2011 at 12:51 AM, Paul Walmsley wrote:
>
> By the way, if your patch relies on OMAP_DEVICE_PAD_IDLE, you should
> probably sync up with Sricharan, who is apparently planning to remove that
> flag:
>
currently I am dependent on OMAP_DEVICE_PAD_WAKEUP flag.
I am not using OMAP_DEVICE
On Wed, Mar 9, 2011 at 6:44 AM, Kevin Hilman wrote:
> Govindraj writes:
>
>> Module level wakeup doesn't seem to work and only
>> way it seem to wakeup is through using resume_idle
>> from sram_idle.
>
> Have you verified if the module wakeups themselves are not working, or
> just that the wakeup
16 matches
Mail list logo
