Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init

On 5/27/2011 1:24 AM, Hilman, Kevin wrote: Nishanth Menon writes: From: Moiz Sonasath For OMAP4460, GPIO-7 of bank1 is used for controling the TPS modes, hence GPIO1 should not be reset during init as reset will cause the TPS voltage to drop to 0.9 V. ouch. I knew one of these days somethi

Re: [PATCH/RFC 0/4] OMAP: PM debug: remove register dump, misc cleanups

On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman wrote: > Inspired by Jean's work to move PM code to modules, I decided it's > time to remove a bunch of ugly and difficult to maintain code from PM > debug. Indeed this code is a spaghetti mess and makes pm-debug difficult to be modularized. > The mai

Re: [PATCH/RFC 1/4] OMAP3: PM debug: remove sleep_while_idle feature

On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman wrote: > Remove the OMAP-specific PM debug 'sleep_while_idle' feature which is > currently available as an OMAP-specific debugfs entry. > > This duplicates existing ARM-generic functionality available as a > boot-time option using the boot cmdline opti

[PATCHv2 0/2] Some omap_device/hwmod/pwrdomain patches

I came up with these patches while implementing pm runtime adaptation for DSS driver. I'm not quite sure on who's turf they belong, or do they even belong together, but here they are anyway. get_context_loss_count patch was discussed on l-o with Kevin. The omap_device_reset patch I made as some p

[PATCHv2 1/2] OMAP: change get_context_loss_count ret value to int

get_context_loss_count functions return context loss count as u32, and zero means an error. However, zero is also returned when context has never been lost and could also be returned when the context loss count has wrapped and goes to zero. Change the functions to return an int, with negative valu

[PATCHv2 2/2] OMAP: add omap_device_reset()

Add omap_device_reset() function which can be used to reset the hwmods associated with the given platform device. Signed-off-by: Tomi Valkeinen --- arch/arm/plat-omap/include/plat/omap_device.h |1 + arch/arm/plat-omap/omap_device.c | 23 +++ 2 files change

Re: [PATCH 08/13] OMAP2+: PM: provide the next timer event API to PM modules

On Fri, May 27, 2011 at 1:00 AM, Kevin Hilman wrote: > jean.pi...@newoldbits.com writes: > >> From: Jean Pihet >> >> Provide omap_pm_tick_nohz_get_sleep_length_us so that the code >> from the OMAP PM modules can use it. >> >> Signed-off-by: Jean Pihet > > This patch is doing more than mentioned

Re: [PATCH 09/13] OMAP2+: PM: export suspend_set_ops to PM modules

On Fri, May 27, 2011 at 1:09 AM, Kevin Hilman wrote: > jean.pi...@newoldbits.com writes: > >> From: Jean Pihet >> >> Export the suspend_set_ops API as omap_pm_suspend_set_ops in the pm >> generic code, under CONFIG_SUSPEND. >> >> Note -hack warning-: since the 'suspend_valid_only_mem' function is

Re: [PATCH 2/2] GPIO: OMAP: move to drivers/gpio

On Fri, May 27, 2011 at 1:35 AM, Grant Likely wrote: > On Fri, May 20, 2011 at 03:41:08PM +0200, Kevin Hilman wrote: >> Move OMAP GPIO driver to drivers/gpio.  Builds whenever >> CONFIG_ARCH_OMAP=y. >> >> Signed-off-by: Kevin Hilman > > Patch unfortunately doesn't apply cleanly to Linus' tree.  T

Error while rotating LCD fb - detected fb_set_par error, error code: -22

Hi, I am using a omap3530 based board. I am trying to rotate the LCD using*/sys/class/graphics/fb0/rotate*. The rotation works only for 0 degree and 270 degrees. When trying to rotate for 90 or 180 de

Re: [PATCH] ARM: OMAP: Get rid of section mismatch warnings

* Russell King - ARM Linux [110526 16:51]: > On Thu, May 26, 2011 at 06:37:32AM -0700, Tony Lindgren wrote: > > * Santosh Shilimkar [110526 05:56]: > > > On 5/26/2011 6:30 PM, Silesh C V wrote: > > > >Get rid of the following and 8 other similar section mismatch > > > >warnings > > > > > > > I se

Re: [PATCH] ARM: OMAP: Get rid of section mismatch warnings

* Igor Grinberg [110526 17:05]: > On 05/26/11 16:37, Tony Lindgren wrote: > > > * Santosh Shilimkar [110526 05:56]: > >> On 5/26/2011 6:30 PM, Silesh C V wrote: > >>> Get rid of the following and 8 other similar section mismatch > >>> warnings > >>> > >> I send this [1] patch a month back. It's

Re: [GIT PULL] omap updates for 2.6.40

* Tony Lindgren [110527 09:29]: > * Koen Kooi [110526 19:02]: > > > > Op 26 mei 2011, om 13:39 heeft Tony Lindgren het volgende geschreven: > > > > > Hi Linus, > > > > > > Please pull omap updates for this merge window from: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/lin

Re: [PATCH] free rev gpios when they are read, so others can read them later

Hi Tasslehoff, On 05/26/11 22:59, Tasslehoff Kjappfot wrote: > A script of mine that reads the rev gpios on the beagleboard started failing > when I upgraded to .37, since board-omap3beagle.c doesn´t free the rev gpios > after using them. > > Signed-off-by: Tasslehoff Kjappfot > --- > arch/arm/

Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init

On 5/27/2011 9:26 AM, Govindraj wrote: On Fri, May 27, 2011 at 12:40 PM, Cousson, Benoit mailto:b-cous...@ti.com>> wrote: On 5/27/2011 1:24 AM, Hilman, Kevin wrote: Nishanth Menonmailto:n...@ti.com>> writes: From: Moiz Sonasathmailto:m-sonas...@ti.com>> F

Re: [GIT PULL] omap updates for 2.6.40

Op 27 mei 2011, om 13:04 heeft Tony Lindgren het volgende geschreven: > * Tony Lindgren [110527 09:29]: >> * Koen Kooi [110526 19:02]: >>> >>> Op 26 mei 2011, om 13:39 heeft Tony Lindgren het volgende geschreven: >>> Hi Linus, Please pull omap updates for this merge window fro

Re: [PATCHv2 2/2] OMAP: add omap_device_reset()

Hi Tomi, On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote: Add omap_device_reset() function which can be used to reset the hwmods associated with the given platform device. We've never exposed it because we are trying to avoid that any driver play with asynchronous HW reset. That can lead to undef

[PATCH v2] OMAP3: beagle: add support for beagleboard xM revision C

The USB enable GPIO has been inverted again and the USER button moved. Future revisions will now fall back to xM rev C instead of unknown. Signed-off-by: Koen Kooi --- Changes since v1: * updated against mainline to take Igors gpio cleanup into account * removed xM rev B checks,

Re: [PATCHv2 2/2] OMAP: add omap_device_reset()

On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote: > Hi Tomi, > > On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote: > > Add omap_device_reset() function which can be used to reset the hwmods > > associated with the given platform device. > > We've never exposed it because we are trying to avoid

Re: [PATCH v2] OMAP3: beagle: add support for beagleboard xM revision C

Hi Koen, Please CC LAKML for patches like this, otherwise Tony, will have to post all of them before pull requesting. On 05/27/11 15:40, Koen Kooi wrote: > The USB enable GPIO has been inverted again and the USER button moved. > > Future revisions will now fall back to xM rev C instead of un

[PATCH] OMAP3: beagle: add support for beagleboard xM revision C

The USB enable GPIO has been inverted again and the USER button moved Signed-off-by: Koen Kooi --- Changes since v2: * fixed indentation error checkpatch missed Changes since v1: * updated against mainline to take Igors gpio cleanup into account * removed xM rev B checks, no boards w

Re: [PATCH] OMAP3: beagle: add support for beagleboard xM revision C

That was meant to say '[PATCH v3]', sorry about that. Op 27 mei 2011, om 15:32 heeft Koen Kooi het volgende geschreven: > The USB enable GPIO has been inverted again and the USER button moved > > Signed-off-by: Koen Kooi > --- > Changes since v2: >* fixed indentation error checkpatch missed

Re: [PATCH v2] OMAP3: beagle: add support for beagleboard xM revision C

Op 27 mei 2011, om 15:20 heeft Igor Grinberg het volgende geschreven: > Hi Koen, > > > Please CC LAKML for patches like this, > > otherwise Tony, will have to post all of them before pull requesting. > > > > On 05/27/11 15:40, Koen Kooi wrote: > >> The USB enable GPIO has been inverted aga

Re: Error while rotating LCD fb - detected fb_set_par error, error code: -22

On Friday 27 May 2011 03:40 PM, Mohamed Thalib H wrote: Hi, I am using a omap3530 based board. I am trying to rotate the LCD using*/sys/class/graphics/fb0/rotate*. The rotation works only for 0 degree

Re: [PATCHv2 2/2] OMAP: add omap_device_reset()

On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote: On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote: Hi Tomi, On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote: Add omap_device_reset() function which can be used to reset the hwmods associated with the given platform device. We've never exposed i

Re: [PATCHv2 2/2] OMAP: add omap_device_reset()

On 5/27/2011 8:13 PM, Cousson, Benoit wrote: On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote: On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote: Hi Tomi, On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote: Add omap_device_reset() function which can be used to reset the hwmods associated with the

Re: [PATCH 0/3] Some omap_device/hwmod/pwrdomain patches

Tomi Valkeinen writes: [...] > >> This isn't something in general that drivers should be aware of, so I'd >> rather not see this exposed to drivers (unless there's a real need.) > > Ok, I'll drop the patch. I don't think there's any need for this in DSS. > >> As soon as I finish the move to devi

Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init

Govindraj writes: > On Fri, May 27, 2011 at 12:40 PM, Cousson, Benoit wrote: > > On 5/27/2011 1:24 AM, Hilman, Kevin wrote: > > Nishanth Menon  writes: > > > From: Moiz Sonasath > > For OMAP4460, GPIO-7 of bank1 is used for controling > the TPS mod

Re: [PATCHv2 2/2] OMAP: add omap_device_reset()

On 5/27/2011 4:51 PM, Shilimkar, Santosh wrote: On 5/27/2011 8:13 PM, Cousson, Benoit wrote: On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote: On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote: Hi Tomi, On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote: Add omap_device_reset() function which can

Re: [PATCH/RFC 0/4] OMAP: PM debug: remove register dump, misc cleanups

Jean Pihet writes: > On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman wrote: >> Inspired by Jean's work to move PM code to modules, I decided it's >> time to remove a bunch of ugly and difficult to maintain code from PM >> debug. > Indeed this code is a spaghetti mess and makes pm-debug difficult t

Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init

Hi Kevin, On 5/27/2011 4:59 PM, Hilman, Kevin wrote: Govindraj writes: [...] uart->oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET; This is a hack (written by me) because the UART driver is not runtime PM adapted. When UART driver is runtime PM adapted, this will not be needed.

Re: [PATCHv2 2/2] OMAP: add omap_device_reset()

On 5/27/2011 8:30 PM, Cousson, Benoit wrote: On 5/27/2011 4:51 PM, Shilimkar, Santosh wrote: On 5/27/2011 8:13 PM, Cousson, Benoit wrote: On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote: On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote: Hi Tomi, On 5/27/2011 9:38 AM, Valkeinen, Tomi wrot

Re: [PATCH/RFC 1/4] OMAP3: PM debug: remove sleep_while_idle feature

Jean Pihet writes: > On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman wrote: >> Remove the OMAP-specific PM debug 'sleep_while_idle' feature which is >> currently available as an OMAP-specific debugfs entry. >> >> This duplicates existing ARM-generic functionality available as a >> boot-time option

Re: [PM-WIP_CPUFREQ][PATCH 0/6 V3] Cleanups for cpufreq

On Fri, May 27, 2011 at 1:26 AM, Santosh Shilimkar wrote: > On 5/27/2011 11:37 AM, Menon, Nishanth wrote: >> >> On Thu, May 26, 2011 at 22:06, Santosh Shilimkar >>  wrote: >>> >>> On 5/26/2011 11:40 PM, Kevin Hilman wrote: So here's a dumb question, being rather ignorant of CPUfreq on S

Re: [PATCH] OMAP: don't trace functions called from sched_clock

Tony, On Sun, May 8, 2011 at 14:51, Rabin Vincent wrote: > omap_readl() is used from the sched_clock() implementations and so must > be marked notrace to avoid recursion in ftrace.  Same thing with > mpu_read() for OMAP1. > > Signed-off-by: Rabin Vincent Comments on this patch? This is a bugfi

Re: [PATCH 2/2] GPIO: OMAP: move to drivers/gpio

Grant Likely writes: > On Fri, May 27, 2011 at 1:35 AM, Grant Likely > wrote: >> On Fri, May 20, 2011 at 03:41:08PM +0200, Kevin Hilman wrote: >>> Move OMAP GPIO driver to drivers/gpio.  Builds whenever >>> CONFIG_ARCH_OMAP=y. >>> >>> Signed-off-by: Kevin Hilman >> >> Patch unfortunately doesn

Re: [PATCH 00/14] GPIO: OMAP: first round of cleanup

Hi Grant, Grant Likely writes: > On Fri, May 20, 2011 at 05:14:43PM +0200, Kevin Hilman wrote: >> Start moving SoC-specific register handling out of the driver by passing >> in register offsets in via platform data. >> >> Also, move OMAP1 MPUIO IRQ handling over to genric IRQ chip. >> >> Appli

Re: [PATCH/RFC 1/4] OMAP3: PM debug: remove sleep_while_idle feature

On Fri, May 27, 2011 at 5:26 PM, Kevin Hilman wrote: > Jean Pihet writes: > >> On Fri, May 27, 2011 at 1:02 AM, Kevin Hilman wrote: >>> Remove the OMAP-specific PM debug 'sleep_while_idle' feature which is >>> currently available as an OMAP-specific debugfs entry. >>> >>> This duplicates existin

Re: [PATCH 2/2] GPIO: OMAP: move to drivers/gpio

Kevin Hilman writes: [...] > > OK, I rebased onto RMK's for-linus branch (already pulled by Linus), > which contained some other changes touching gpio.c.I also s/_/-/ in > the filename. > > Below is pull request. BTW, apologies for the ssh URL. I used it because I just pushed it, and wante

Re: [PATCHv2 2/2] OMAP: add omap_device_reset()

On Fri, 2011-05-27 at 16:43 +0200, Cousson, Benoit wrote: > On 5/27/2011 2:46 PM, Valkeinen, Tomi wrote: > > On Fri, 2011-05-27 at 14:38 +0200, Cousson, Benoit wrote: > >> Hi Tomi, > >> > >> On 5/27/2011 9:38 AM, Valkeinen, Tomi wrote: > >>> Add omap_device_reset() function which can be used to res

Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init

"Cousson, Benoit" writes: > Hi Kevin, > > On 5/27/2011 4:59 PM, Hilman, Kevin wrote: >> Govindraj writes: > > [...] > >>> uart->oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET; >>> >> >> This is a hack (written by me) because the UART driver is not runtime PM >> adapted. When UART driver

Re: [RFC][PATCH 3/9] OMAP4460: HWMOD: DO not reset GPIO1 during HWMOD init

"Cousson, Benoit" writes: [...] > In general we do not want to reset nor idle an IP that was potentially > already properly configured by bootloader or early Linux boot code. Actually, the opposite is true. The kernel should not make any assumptions about what the bootloader has or has not don

Re: [PATCH 2/2] GPIO: OMAP: move to drivers/gpio

On Fri, May 27, 2011 at 09:04:37AM -0700, Kevin Hilman wrote: > Kevin Hilman writes: > > [...] > > > > > OK, I rebased onto RMK's for-linus branch (already pulled by Linus), > > which contained some other changes touching gpio.c.I also s/_/-/ in > > the filename. > > > > Below is pull reques

Re: [PATCH] OMAP: don't trace functions called from sched_clock

Rabin Vincent writes: > omap_readl() is used from the sched_clock() implementations and so must > be marked notrace to avoid recursion in ftrace. Same thing with > mpu_read() for OMAP1. > > Signed-off-by: Rabin Vincent Acked-by: Kevin Hilman -- To unsubscribe from this list: send the line "un

Re: [PATCH] ARM: OMAP: Get rid of section mismatch warnings

Tony Lindgren writes: > * Russell King - ARM Linux [110526 16:51]: >> On Thu, May 26, 2011 at 06:37:32AM -0700, Tony Lindgren wrote: >> > * Santosh Shilimkar [110526 05:56]: >> > > On 5/26/2011 6:30 PM, Silesh C V wrote: >> > > >Get rid of the following and 8 other similar section mismatch >> >

boot hang using OMAP for-next + Russell's for-linus

FYI... I just found this, but won't be able to look into it until next week, so if anyone needs a weekend debug project... Using Tony's for-next branch, I'm able to boot an omap2plus_defconfig (+ busybox initramfs) kernel on my 3430/n900 just fine. I then tried to merge in Russell's for-linus br

Re: [PM-WIP_CPUFREQ][PATCH 0/6 V3] Cleanups for cpufreq

"Turquette, Mike" writes: > On Fri, May 27, 2011 at 1:26 AM, Santosh Shilimkar > wrote: >> On 5/27/2011 11:37 AM, Menon, Nishanth wrote: >>> >>> On Thu, May 26, 2011 at 22:06, Santosh Shilimkar >>>  wrote: On 5/26/2011 11:40 PM, Kevin Hilman wrote: > > So here's a dumb questio

Re: [PATCH pm_wip/voltdm_nm] ARM: OMAP: Explicitly mask VPVOLTAGE field

Hi Todd, Todd Poynor writes: > Reading the VPVOLTAGE field of PRM_VP_*_VOLTAGE registers currently > relies on a u32 -> u8 conversion to mask off the FORCEUPDATEWAIT field > in the upper bits. Make this explicit using the mask and shift symbols > already defined, added as new fields in struct o

[PATCH] PM: export suspend_set_ops, suspend_valid_only_mem

Some platforms wish to implement their PM core suspend code as modules. To do so, these functions need to be exported to modules. Reported-by: Jean Pihet Signed-off-by: Kevin Hilman --- Applies against v2.6.39 kernel/power/suspend.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)

Re: [PATCH 09/13] OMAP2+: PM: export suspend_set_ops to PM modules

Jean Pihet writes: > On Fri, May 27, 2011 at 1:09 AM, Kevin Hilman wrote: >> jean.pi...@newoldbits.com writes: >> >>> From: Jean Pihet >>> >>> Export the suspend_set_ops API as omap_pm_suspend_set_ops in the pm >>> generic code, under CONFIG_SUSPEND. >>> >>> Note -hack warning-: since the 'susp

Re: [PATCH] OMAP: don't trace functions called from sched_clock

Kevin Hilman writes: > Rabin Vincent writes: > >> omap_readl() is used from the sched_clock() implementations and so must >> be marked notrace to avoid recursion in ftrace. Same thing with >> mpu_read() for OMAP1. >> >> Signed-off-by: Rabin Vincent > > Acked-by: Kevin Hilman I also meant to

[PATCH pm_wip/voltdm_nm] OMAP: VP: Explicitly mask VPVOLTAGE field

Reading the VPVOLTAGE field of PRM_VP_*_VOLTAGE registers currently relies on a u32 -> u8 conversion to mask off the FORCEUPDATEWAIT field in the upper bits. Make this explicit using the mask symbol already defined, added as a new field in struct omap_vp_common. Signed-off-by: Todd Poynor --- V

[PATCH] OMAP: L3 interconnect: Error reporting cleanups

* Make variables static. * Define L3 TARG instance offsets, and read/write STDERRLOG registers relative to those offsets, rather than defining STDERRLOG_MAIN instance offsets and accessing other registers via offsets from that register. * Use ffs() to find error source from the L3_FLAGMUX_R