RE: [PATCH v5 03/14] ARM: OMAP2+: gpmc: driver migration helper

Hi Jon, This change is required only till driver migration of all platforms are done, after it, this hackish patch has to be reverted. This has been done so that existing interface will work for each patch of this series as well as till all boards are migrated. On Tue, Jun 12, 2012 at 02:00:21, H

RE: [PATCH v5 04/14] ARM: OMAP2+: gpmc: minimal driver support

Hi Jon, On Tue, Jun 12, 2012 at 02:13:22, Hunter, Jon wrote: > > + gpmc_revision = (l >> 4) & 0xf; > > Why are you only storing the major part of the rev? Why not keep both parts? Does having minor revision add any value ?, at least as of now, I do not see any. > > > + dev_info(gpmc_dev,

Re: [PATCH V2 1/2] arm/dts: OMAP2: Add support for OMAP2420 SDP

* Jon Hunter [120607 15:15]: > Simple DTS file for OMAP2420 SDP adding memory information to allow > device-tree > testing on an OMAP2420 SDP. > > Verified that kernel boots with DT using a simple RAMDISK file-system on > OMAP2420 SDP. I suspect this is the H4 board? If so, please rename it to

RE: [PATCH v5 05/14] ARM: OMAP2+: gpmc: resource creation helpers

Hi Jon, On Tue, Jun 12, 2012 at 02:27:09, Hunter, Jon wrote: > > +static __devinit int gpmc_setup_cs_mem(struct gpmc_cs_data *cs, > > + struct resource *res) > > + return 1; > > +} > > Nit-pick, CodingStyle chapter 16 states that 0 should be used for

Re: [PATCH 4/5] MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set

On 06/11/12 17:00, Zumeng Chen wrote: > A typo fix for this cosmetic change and mute a failed message from > a unnecessary setting of some parent clk for usbhs_omap on OMAP3EVM. > > Signed-off-by: Zumeng Chen > --- > drivers/mfd/omap-usb-host.c |4 +++- > 1 files changed, 3 insertions(+), 1

Re: [PATCH 5/5] Input: ads7846: set proper debounce time in driver level

On 06/12/12 05:49, Zumeng Chen wrote: > > > 2012/6/11 Igor Grinberg > > > Hi, > > This is input subsystem, add Dmitry and linux-input. > > On 06/11/12 17:00, Zumeng Chen wrote: > > If we don't set proper debouce time for ads7846, then there are

RE: [PATCH v5 06/14] ARM: OMAP2+: gpmc: CS configuration helper

Hi Jon, On Tue, Jun 12, 2012 at 03:13:02, Hunter, Jon wrote: > > +static void gpmc_setup_cs_config(unsigned cs, unsigned conf) > > +{ > > + u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1); > > Why is it necessary to read the register first? I thought you wanted to > get away from relying on boot

RE: [PATCH v5 08/14] ARM: OMAP2+: gpmc: bool type timing helper

Hi Jon, On Tue, Jun 12, 2012 at 03:57:45, Hunter, Jon wrote: > > + if (p->cycle2cyclesamecsen) > > + l |= GPMC_CONFIG6_CYCLE2CYCLESAMECSEN; > > + else > > + l &= ~GPMC_CONFIG6_CYCLE2CYCLESAMECSEN; > > + if (p->cycle2cyclediffcsen) > > + l |= GPMC_CONFIG6_CYCLE2

RE: [PATCH v5 09/14] ARM: OMAP2+: gpmc: holler if no configuration

Hi Jon, On Tue, Jun 12, 2012 at 04:00:20, Hunter, Jon wrote: > Nit, "holler" is slang. Just say WARN. It was a deliberate attempt to add human (or read humorous) touch Regards Afzal -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vg

RE: [PATCH v5 10/14] ARM: OMAP2+: gpmc: waitpin helper

Hi Jon, On Tue, Jun 12, 2012 at 04:29:09, Hunter, Jon wrote: > > +enum { > > + GPMC_WAITPIN_IDX0, > > + GPMC_WAITPIN_IDX1, > > + GPMC_WAITPIN_IDX2, > > + GPMC_WAITPIN_IDX3, > > + GPMC_NR_WAITPIN > > +}; > > Max number of wait pins is 3 for omap4/5. I know that we discussed this > in th

RE: [PATCH v5 12/14] ARM: OMAP2+: gpmc: cs reconfigure helper

Hi Jon, On Tue, Jun 12, 2012 at 04:34:33, Hunter, Jon wrote: > > On 06/11/2012 09:27 AM, Afzal Mohammed wrote: > > Helper for reconfiguring CS, peripheral that necessitated > > it was OneNAND. > > Why? I think you need to add more about why this was needed. Ok, I will describe more Regards Afz

Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support

On Mon, Jun 11, 2012 at 08:01:23PM +0100, Jon Hunter wrote: > Hi Will, Hello, > On 06/11/2012 12:39 PM, Will Deacon wrote: > > This looks better to me, so I took it for a spin on my 4460 (thanks > > Nicolas!) > > and noticed that only the cycle counter seems to tick -- the event counters > > alw

RE: [PATCH 00/10] Prepare for GPMC driver conversion (w.r.t MTD)

Hi Tony, Artem, On Thu, Jun 07, 2012 at 20:44:03, Mohammed, Afzal wrote: > > This series cleans up gpmc mtd interactions so that GPMC driver > > conversion which is going to happen shortly would happen smoothly > > by not creating much disturbance outside of arch/arm/*omap*/ > > > > This series,

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

Was there ever a conclussion to this discussion? I'm assuming this is unlikely to be fixed in 3.5? Cheers, Joe -Original Message- From: Jean Pihet To: Paul Walmsley , Tomi Valkeinen Cc: Joe Woodward , khil...@ti.com, Archit Taneja , linux-omap@vger.kernel.org Date: Fri, 25 May 2012 14

RE: [PATCH v2] ARM: OMAP2/3: hwmod data: add gpmc

Hi Paul, On Mon, Jun 11, 2012 at 18:45:03, Mohammed, Afzal wrote: > Add gpmc hwmod and associated interconnect data > > HWMOD_INIT_NO_RESET can be removed once kernel is updated to > configure GPMC for all peripherals. Currently many depend on > bootloader, this facility will be removed. > (featu

RE: [PATCH 0/3] Prepare for GPMC driver conversion

Hi Tony, On Mon, Jun 11, 2012 at 19:31:01, Mohammed, Afzal wrote: > Objective of this series is to make things easy for GPMC driver > conversion series by separating out more things from driver > conversion series. > > This series, > 1. Unifies NAND platform initialization functions > 2. Cleans

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

On Tue, 2012-06-12 at 11:15 +0100, Joe Woodward wrote: > Was there ever a conclussion to this discussion? > > I'm assuming this is unlikely to be fixed in 3.5? If by conclusion you mean full understanding and a proper fix, then no. But the patch 3568f2a46f2a73bab18c914df06afd98a97e0e0e (OMAPDSS:

RE: [PATCH v5 00/14] GPMC driver conversion

Hi Tony, On Mon, Jun 11, 2012 at 19:55:02, Mohammed, Afzal wrote: > Hi, > > This series is based on 3.5-rc1, and is dependent on [1,2,3] > > This series has been tested on omap3evm (smsc911x) rev G & C and > beagle board(nand) using patch series which is going to be posted > shortly (this series

Re: [RFC PATCH 0/3] usb: musb: add new phy driver

On Wed, May 30, 2012 at 08:04:23PM +0530, Kishon Vijay Abraham I wrote: > This series adds a new usb2 phy driver. The device for which is created > by the ocp2scp driver. This also uses control module driver. > > This series converts twl6030 as a comparator driver (previously it was > also the phy

Re: [PATCH 0/5] usb: musb: cleanup

On Tue, Jun 05, 2012 at 03:08:33PM +0530, Kishon Vijay Abraham I wrote: > Most part of this patch series was obtained by splitting > [RFC PATCH 2/3] usb: musb: omap glue: use omap-usb2 as the phy driver. > > TO DO: > * dt adaptation of musb omap glue, twl4030, twl6030. > * Use control module drive

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

-Original Message- From: Tomi Valkeinen To: Joe Woodward Cc: Jean Pihet , Paul Walmsley , khil...@ti.com, Archit Taneja , linux- o...@vger.kernel.org Date: Tue, 12 Jun 2012 13:37:04 +0300 Subject: Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5) > On Tue, 2012-06-12 at 11:15

Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

On Tue, 2012-06-12 at 11:50 +0100, Joe Woodward wrote: > -Original Message- > From: Tomi Valkeinen > To: Joe Woodward > Cc: Jean Pihet , Paul Walmsley , > khil...@ti.com, Archit Taneja , linux- > o...@vger.kernel.org > Date: Tue, 12 Jun 2012 13:37:04 +0300 > Subject: Re: v3.4-rc4 DSS PM

RE: Please help! AM35xx mm/slab.c BUG

Hi, On Fri, Jun 08, 2012 at 01:20:13, CF Adad wrote: > Thanks for your thoughts!  I may try fiddling a bit just to see if that helps. 5 series of patches for gpmc modifications [1-5] has been posted, In case it helps in resolving your issue, please let me know. You will have to use the new inte

RE: [PATCH v4-alt 3/6] ARM: OMAP3: hwmod data: add gpmc

Hi Tony, On Tue, May 22, 2012 at 22:12:15, Tony Lindgren wrote: > for these cases. Otherwise we'll be breaking old boards with smsc911x > where the timings for the FPGA controlling smsc911x are unknown. Were you actually referring to sdp boards that work with smc91x driver using 91c96 ? Regards

Re: suspend broken on 3.5-rc1?

On Friday 08 June 2012 06:46 PM, Rajendra Nayak wrote: On Friday 08 June 2012 06:35 PM, Tero Kristo wrote: On Fri, 2012-06-08 at 17:55 +0530, Rajendra Nayak wrote: On Friday 08 June 2012 04:26 PM, Tony Lindgren wrote: * Rajendra Nayak [120608 03:40]: Hi, I don;t seem to be able to get suspen

Re: [PATCH 1/2] ARM: OMAP2+: hwmod data: Fix the wrong clkdm assigned to PRCM modules

Hi Paul, On 6/11/2012 11:11 PM, Cousson, Benoit wrote: On 6/11/2012 7:26 PM, Paul Walmsley wrote: On Mon, 11 Jun 2012, Benoit Cousson wrote: The following commit (794b480a37e3d284d6ee7344d8a737ef60476ed5) was adding the PRCM IPs data for PRCM, CM, PRCM_MPU and SCRM. The clkdm entry are not th

RE: [PATCH v5 06/14] ARM: OMAP2+: gpmc: CS configuration helper

Hi Jon, On Tue, Jun 12, 2012 at 14:10:08, Mohammed, Afzal wrote: > > > + l |= conf & GPMC_CONFIG1_DEVICETYPE_NAND; > > > + l |= conf & GPMC_CONFIG1_DEVICESIZE_16; > > > > I can see that it works to use the above definitions as masks because of > > the possible values that can be programmed into

Re: Please help! AM35xx mm/slab.c BUG

Afzal, Thanks!  This set looks very interesting.  As I've been chasing this bug all week, I haven't had time to sync our build up to the latest tree.  So I'm still back at 3.4-rc6, and cannot directly patch this in a give it a try yet.  However, I'll certainly take a look as soon as I can.  My

[PATCHv3 00/20] ARM: OMAP4: device off support

Hi, V3 consists of following changes: - ordering of patches changed (enable off-mode as last patch) - rebased on top of 3.5-rc2 - rebased on top of Jean Pihet's functional power state code - omap-secure driver has now its own CPU PM notifier: * moved dummy wakeup dispatcher call from omap-mpuss

[PATCHv3 01/20] ARM: OMAP4: PM: powerdomain: Add HWSAR flag to L3INIT

From: Santosh Shilimkar L3INIT powerdomain has USB HOST and USB TLL modules which support hardware save-and-restore (HW SAR) mechanism. This patch updates the L3INIT power domain to mark them as capable of doing H/w save and restore and provides functions to do them explicitly. Note: Eventually,

[PATCHv3 02/20] ARM: OMAP4: powerdomain: update mpu / core off counters during device off

Currently device off does not have any counters / timers of its own and it is impossible to track the time spent in this state. In device off, MPU / CORE powerdomains enter OSWR, so normally the OSWR state times / counts are increased during device off. This patch adds a new field to the powerdoma

[PATCHv3 03/20] ARM: OMAP4: PM: add support for device off

On OMAP4+, device wide off-mode has its own enable mechanism in addition to powerdomain target states. This patch adds support for this on top of functional power states by overloading the OFF state for core pwrdm. On pwrdm level, the deepest power state supported by core pwrdm is OSWR. When user (

[PATCHv3 04/20] ARM: OMAP4: PM: update ROM return address for OSWR and OFF

From: Carlos Leija At wakeup from OFF/OSWR CPU1 will call secure HAL service through a local secure dispatcher with MMU off (from omap-headsmp.S), thus ROM will save a PA return address. Later in the wakeup, when SMC driver calls an RPC through omap4_secure_dispatcher (MMU is on now), ROM code wo

[PATCHv3 05/20] OMAP4: PM: clockdomain: workaround for l4_secure_clkdm HWSUP

From: Santosh Shilimkar On HS/EMU devices the modules from l4_secure_clkdm are used. Few modules from L4_SEC clockdomain are not accessible without putting l4_secure_clkdm in force software wakeup. Follow the recommended sequence across secure API calls. Signed-off-by: Santosh Shilimkar Signed

[PATCHv3 07/20] ARM: OMAP4: secure: add support for device off

If omap4 chip enters device off, complete secure context must be saved. This requires a separate secure HAL call. As device off mode is overloaded on top of functional core_pwrdm state, the code checks if core_pwrdm is entering off mode, and does the complete context save in that case. Otherwise th

[PATCHv3 06/20] ARM: OMAP4: secure: move GIC / wakeupgen save restore to secure CPU PM notifier

As secure driver now has CPU PM notifier, move the security involved tweaks from wakeupgen to here. This allows us to drop some runtime omap chip type checks away also, as wakeupgen CPU PM notifier is no longer needed at all on secure devices. Signed-off-by: Tero Kristo --- arch/arm/mach-omap2/o

[PATCHv3 08/20] ARM: OMAP4: PM: add MPUSS power domain device off support

This patch adds device off support for MPUSS power domain. Device off support is overloaded on top of core pwrdm functional OFF powerstate, so the code must check the next core powerstate and set the save_state status accordingly. Signed-off-by: Tero Kristo --- arch/arm/mach-omap2/omap-mpuss-low

[PATCHv3 09/20] ARM: OMAP4: PM: save/restore all DPLL settings in OFF mode

From: Rajendra Nayak SAR/ROM code restores only CORE DPLL to its original state post wakeup from OFF mode. The rest of the DPLL's in OMAP4 platform (MPU/IVA/ABE/USB/PER) are saved and restored here during an OFF transition. [n...@ti.com: minor cleanups] Signed-off-by: Nishanth Menon Signed-off-

[PATCHv3 12/20] ARM: OMAP4: PM: Work-around for ROM code BUG of IVAHD/TESLA

From: Santosh Shilimkar The ROM BUG is when MPU Domain OFF wake up sequence that can compromise IVA and Tesla execution. At wakeup from MPU OFF on HS device only (not GP device), when restoring the Secure RAM, the ROM Code reconfigures the clocks the same way it is done at Cold Reset. The IVAHD

[PATCHv3 13/20] ARM: OMAP4: PM: save/restore CM L3INSTR registers when MPU hits OSWR/OFF mode

From: Rajendra Nayak On HS devices on the way out of MPU OSWR and OFF ROM code wrongly overwrites the CM L3INSTR registers. So to avoid this, save them and restore on the way out from MPU OSWR/OFF. This errata applies to all HS/EMU versions of OMAP4. Signed-off-by: Rajendra Nayak Signed-off-by

[PATCHv3 15/20] ARM: OMAP4430: PM: workaround for DDR corruption on second CS

From: Santosh Shilimkar Work around for Errata ID: i632 "LPDDR2 Corruption After OFF Mode Transition When CS1 Is Used On EMIF" which impacts OMAP443x silicon The issue occurs when EMIF_SDRAM_CONFIG is restored first before EMIF_SDRAM_CONFIG_2 is not yet restored, the register configuration is not

[PATCHv3 10/20] ARM: OMAP4: PM: save/restore all CM1/2 settings in OFF mode

From: Rajendra Nayak Restore all CM1/2 module registers as they are lost in OFF mode. [n...@ti.com: minor clean ups] Signed-off-by: Nishanth Menon Signed-off-by: Rajendra Nayak Signed-off-by: Santosh Shilimkar Signed-off-by: Axel Haslam Signed-off-by: Tero Kristo --- arch/arm/mach-omap2/cm

[PATCHv3 11/20] ARM: OMAP4: PM: Add SAR backup support towards device OFF

Most of the device register contents are lost during device off. To resume properly from this, a special memory area called SAR RAM is maintained during device off, and its contents are restored to HW registers during wakeup. The register layout is fixed in SAR RAM. SAR is split into 4 banks with d

[PATCHv3 19/20] ARM: OMAP4: PM: enable off mode by default

System will now enter device off by default during suspend. Signed-off-by: Tero Kristo --- arch/arm/mach-omap2/pm44xx.c |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/pm44xx.c b/arch/arm/mach-omap2/pm44xx.c index 341655e..8054afc 100644 --- a/ar

[PATCHv3 17/20] ARM: OMAP4: put cpu1 back to sleep if no wake request

If AUX_CORE_BOOT0 does not indicate wakeup request for cpu1, put it back to off. This is needed during wakeup from device off to prevent cpu1 from being stuck indefinitely in the wakeup loop and also to prevent wakeup problem on GP chips with device off mode. Signed-off-by: Tero Kristo --- arch/

[PATCHv3 18/20] ARM: OMAP4460: wakeupgen: set GIC_CPU0 backup status flag always

Without this, CPU0 will crash in the ROM code during wakeup from device off. This patch also clears the GIC save area, to prevent ROM code from writing garbage to the GIC registers during wakeup. The actual GIC restore is done by kernel. This bug fix applies only to OMAP4460, it is fixed on OMAP44

[PATCHv3 16/20] TEMP: ARM: OMAP4: prevent voltage transitions

During device off, the off-mode voltage transitions are enabled on reset. Because the voltage control logic is not still completely functional for OMAP4, we must disable the voltage transitions for device off for now. This can only be done by disabling the I2C channel it seems. This patch does not

[PATCHv3 14/20] ARM: OMAP4: PM: Mark the PPI and SPI interrupts as non-secure for GP

From: Axel Haslam ROM code restores part of the GIC context during wakeup from device off mode from the SAR RAM. If the PPI and SPI interrupts are not marked as non-secure on GP chips, this crashes the device during wakeup, thus mark them as non-secure. Signed-off-by: Axel Haslam [t-kri...@ti.c

[PATCHv3 20/20] ARM: OMAP4430: PM: errata i625, WUGEN lost for GP devices after OFF mode

This patch implements errata i625. When coming back from device off mode, the Cortex-A9 WUGEN enable registers are not restored by ROM code. The work around disables device power OFF to maintain the proper register settings. The affected devices are OMAP4430GP ES2.0 to ES2.2. Based on work done b

Re: [PATCH 4/5] MFD: OMAP3EVM: USB: cosmetic fix to failed parent clk set

On 06/11/2012 09:30 PM, Zumeng Chen wrote: > > > 2012/6/11 Jon Hunter mailto:jon-hun...@ti.com>> > > > On 06/11/2012 09:00 AM, Zumeng Chen wrote: > > A typo fix for this cosmetic change and mute a failed message from > > a unnecessary setting of some parent clk for usbhs_omap on OM

Re: [PATCH V2 1/2] arm/dts: OMAP2: Add support for OMAP2420 SDP

On 06/12/2012 02:20 AM, Tony Lindgren wrote: > * Jon Hunter [120607 15:15]: >> Simple DTS file for OMAP2420 SDP adding memory information to allow >> device-tree >> testing on an OMAP2420 SDP. >> >> Verified that kernel boots with DT using a simple RAMDISK file-system on >> OMAP2420 SDP. > > I

RE: usage of sparse or other trick for improved type safety

Hi Tony, > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Friday, May 25, 2012 2:53 AM Thanks for quick input. Apologies on slow ack of it. > Before we had these frameworks in place it was often hard to debug when > something > did not work for some omaps. Things would just not work or w

Re: [RFC PATCH 0/5] omap: add ocp2scp as a misc driver

"ABRAHAM, KISHON VIJAY" writes: > Hi Kevin, Benoit, Paul, > > On Fri, Jun 1, 2012 at 2:16 AM, Arnd Bergmann wrote: >> On Thursday 31 May 2012, ABRAHAM, KISHON VIJAY wrote: >>> > I would mark the multiplexed device compatible with "simple-bus", which >>> > results in the child devices automatical

Re: [PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion

On 06/12/2012 01:16 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Tue, Jun 12, 2012 at 00:06:30, Hunter, Jon wrote: > >> I agree with getting rid of the first instance at the beginning of >> _set_async_mode, but why get rid of the above one? Are you assuming that >> by default it is in async mode

[PATCH RESEND] usb: otg: OMAP4: Fix the omap4430_phy_set_clk function

If the clocks are enabled and we want to enable them again omap4430_phy_set_clk disables them. Fix this - so now if we try to enable already enabled clocks it works correctly. Signed-off-by: Ruslan Bilovol --- arch/arm/mach-omap2/omap_phy_internal.c |2 +- 1 files changed, 1 insertions(+),

Re: [PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings

On 06/12/2012 01:37 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Tue, Jun 12, 2012 at 00:19:35, Hunter, Jon wrote: > >> What boards have been tested with this change? > > Beagle board, after applying all 5 series of patches, without all > patch series it can't be tested for beagle board as it d

Re: [PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD

On 06/12/2012 01:53 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Tue, Jun 12, 2012 at 01:26:29, Hunter, Jon wrote: > >>> + pdev = omap_device_build(name, -1, oh, pdata, >>> + sizeof(*pdata), NULL, 0, 0); >>> + if (IS_ERR(pdev)) { >>> + WARN(1, "Can'

Re: [PATCH v5 03/14] ARM: OMAP2+: gpmc: driver migration helper

On 06/12/2012 02:09 AM, Mohammed, Afzal wrote: > Hi Jon, > > This change is required only till driver migration of all platforms > are done, after it, this hackish patch has to be reverted. This has > been done so that existing interface will work for each patch of > this series as well as till a

Re: [PATCH v5 04/14] ARM: OMAP2+: gpmc: minimal driver support

On 06/12/2012 02:16 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Tue, Jun 12, 2012 at 02:13:22, Hunter, Jon wrote: > >>> + gpmc_revision = (l >> 4) & 0xf; >> >> Why are you only storing the major part of the rev? Why not keep both parts? > > Does having minor revision add any value ?, at least

Re: [PATCH v5 05/14] ARM: OMAP2+: gpmc: resource creation helpers

On 06/12/2012 03:30 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Tue, Jun 12, 2012 at 02:27:09, Hunter, Jon wrote: > >>> +static __devinit int gpmc_setup_cs_mem(struct gpmc_cs_data *cs, >>> + struct resource *res) > >>> + return 1; >>> +} >> >> Nit-pic

Re: [PATCH v5 06/14] ARM: OMAP2+: gpmc: CS configuration helper

On 06/12/2012 03:40 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Tue, Jun 12, 2012 at 03:13:02, Hunter, Jon wrote: > >>> +static void gpmc_setup_cs_config(unsigned cs, unsigned conf) >>> +{ >>> + u32 l = gpmc_cs_read_reg(cs, GPMC_CS_CONFIG1); >> >> Why is it necessary to read the register first

Re: [PATCH v5 06/14] ARM: OMAP2+: gpmc: CS configuration helper

On 06/12/2012 07:58 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Tue, Jun 12, 2012 at 14:10:08, Mohammed, Afzal wrote: > + l |= conf & GPMC_CONFIG1_DEVICETYPE_NAND; + l |= conf & GPMC_CONFIG1_DEVICESIZE_16; >>> >>> I can see that it works to use the above definitions as masks because

Re: [PATCH v5 09/14] ARM: OMAP2+: gpmc: holler if no configuration

On 06/12/2012 03:44 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Tue, Jun 12, 2012 at 04:00:20, Hunter, Jon wrote: > >> Nit, "holler" is slang. Just say WARN. > > It was a deliberate attempt to add human (or read humorous) touch I like that, but I wonder if it could confuse some :-) Jon -- To

Re: [PATCH v5 10/14] ARM: OMAP2+: gpmc: waitpin helper

On 06/12/2012 04:00 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Tue, Jun 12, 2012 at 04:29:09, Hunter, Jon wrote: > >>> +enum { >>> + GPMC_WAITPIN_IDX0, >>> + GPMC_WAITPIN_IDX1, >>> + GPMC_WAITPIN_IDX2, >>> + GPMC_WAITPIN_IDX3, >>> + GPMC_NR_WAITPIN >>> +}; >> >> Max number of wait pi

Re: [PATCH v5 10/14] ARM: OMAP2+: gpmc: waitpin helper

On 06/11/2012 09:27 AM, Afzal Mohammed wrote: > Helper for configuring waitpin. There are two parts to it; > configuring at CS level and the other at device level. > A device embedding multiple CS has been provided the > capability to use same waitpin (different waitpins has not > been supported a

Re: [PATCH v5 14/14] ARM: OMAP2+: gpmc: writeprotect helper

On 06/11/2012 09:27 AM, Afzal Mohammed wrote: > GPMC has a writeprotect pin that can be connected to > peripherals. If any CS wants to enable writeprotect, > writeprotect will be enabled, once CS configurations > are finished. I am still wondering if we should warn against multiple devices using

Re: [PATCH v5 07/14] ARM: OMAP2+: gpmc: time setting (register#) helper

On 06/11/2012 09:27 AM, Afzal Mohammed wrote: > Helper for setting GPMC timing by taking input as register values. When are the timings calculated? Why not just use the existing gpmc_cs_set_timings()? I guess I am not convinced that we need to have multiple formats to pass timings such as clock,

Re: [PATCH v5 01/14] ARM: OMAP2+: gpmc: platform definitions

On 06/11/2012 09:26 AM, Afzal Mohammed wrote: > gpmc driver platform definitions > > Signed-off-by: Afzal Mohammed > --- > arch/arm/plat-omap/include/plat/gpmc.h | 49 > > 1 file changed, 49 insertions(+) > > diff --git a/arch/arm/plat-omap/include/plat/gpmc

Re: [PATCH v5 04/14] ARM: OMAP2+: gpmc: minimal driver support

On 06/11/2012 09:26 AM, Afzal Mohammed wrote: > Create a minimal driver out of gpmc code. > Responsibilities handled by earlier gpmc > initialization is now achieved in probe. > > Signed-off-by: Afzal Mohammed > --- > arch/arm/mach-omap2/gpmc.c | 170 >

Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support

Hi Will, On 06/12/2012 04:28 AM, Will Deacon wrote: > On Mon, Jun 11, 2012 at 08:01:23PM +0100, Jon Hunter wrote: >> Hi Will, > > Hello, > >> On 06/11/2012 12:39 PM, Will Deacon wrote: >>> This looks better to me, so I took it for a spin on my 4460 (thanks >>> Nicolas!) >>> and noticed that onl

Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support

On Tue, Jun 12, 2012 at 10:17:16PM +0100, Jon Hunter wrote: > Hi Will, Hi Jon, > On 06/12/2012 04:28 AM, Will Deacon wrote: > > > > Well, I tried that and the results are pretty whacky: the event counters do > > indeed tick but interrupts only fire if I pin the perf task to CPU1! What's > > more

Re: [PATCH V2 01/10] ARM: PMU: Add runtime PM Support

On 06/12/2012 04:31 PM, Will Deacon wrote: > On Tue, Jun 12, 2012 at 10:17:16PM +0100, Jon Hunter wrote: >> Hi Will, > > Hi Jon, > >> On 06/12/2012 04:28 AM, Will Deacon wrote: >>> >>> Well, I tried that and the results are pretty whacky: the event counters do >>> indeed tick but interrupts only

[PATCH V3 0/2] arm/dts: Add OMAP2420 SDP support

This series fixes the OMAP2 interrupt controller binding and adds support for the OMAP2420H4 board. I have verified that the kernel boots with device-tree on this board. This series is based upon the linux-omap master branch (3.5-rc1). V3: Rename OMAP2420 SDP to OMAP2420H4 V2: Correct typo in cop

[PATCH V3 2/2] arm/dts: OMAP2: Fix interrupt controller binding

When booting with device-tree on an OMAP2420H4, the kernel is hanging when initialising the interrupts and following kernel dumps is seen ... [0.00] [ cut here ] [0.00] WARNING: at arch/arm/mach-omap2/irq.c:271 omap_intc_of_init+0x50/0xb4() [0.00] u

[PATCH V3 1/2] arm/dts: OMAP2: Add support for OMAP2420H4 Board

Simple DTS file for OMAP2420H4 board adding memory information to allow device-tree testing on an OMAP2420. OMAP2420H4 board has 64MB of RAM. Verified that kernel boots with DT using a simple RAMDISK file-system on OMAP2420H4. Signed-off-by: Jon Hunter --- arch/arm/boot/dts/omap2420-sdp.dts |

Re: [PATCH V3 0/2] arm/dts: Add OMAP2420 SDP support

On 06/12/2012 07:10 PM, Jon Hunter wrote: > This series fixes the OMAP2 interrupt controller binding and adds support for > the OMAP2420H4 board. I have verified that the kernel boots with device-tree > on this board. Oops! Forgot to change SDP to H4 in the $SUBJECT. However, should be correct el

Re: [PATCH V3 0/2] arm/dts: Add OMAP2420 SDP support

On 06/12/2012 07:13 PM, Jon Hunter wrote: > > On 06/12/2012 07:10 PM, Jon Hunter wrote: >> This series fixes the OMAP2 interrupt controller binding and adds support for >> the OMAP2420H4 board. I have verified that the kernel boots with device-tree >> on this board. > > Oops! Forgot to change SD

[RESEND PATCH V3 0/2] arm/dts: Add OMAP2420 H4 support

This series fixes the OMAP2 interrupt controller binding and adds support for the OMAP2420 H4 board. I have verified that the kernel boots with device-tree on this board. This series is based upon the linux-omap master branch (3.5-rc1). V3: Rename OMAP2420 SDP to OMAP2420 H4 V2: Correct typo in c

[RESEND PATCH V3 2/2] arm/dts: OMAP2: Fix interrupt controller binding

When booting with device-tree on an OMAP2420H4, the kernel is hanging when initialising the interrupts and following kernel dumps is seen ... [0.00] [ cut here ] [0.00] WARNING: at arch/arm/mach-omap2/irq.c:271 omap_intc_of_init+0x50/0xb4() [0.00] u

[RESEND PATCH V3 1/2] arm/dts: OMAP2: Add support for OMAP2420H4 Board

Simple DTS file for OMAP2420H4 board adding memory information to allow device-tree testing on an OMAP2420. OMAP2420H4 board has 64MB of RAM. Verified that kernel boots with DT using a simple RAMDISK file-system on OMAP2420H4. Signed-off-by: Jon Hunter --- arch/arm/boot/dts/omap2420-h4.dts |

[PATCH v2 0/5] ARM OMAP3530evm misc fixes for linux-omap

These patches fix misc problems when reflash ti-omap3530evm for master branch on Linux-omap. The series is based upon the latest linux-omap master branch from Tony (3.5-rc1). Changes vs V1: 1. NAND flash definition changes as Jon's comments. 2. Add more shortlog for VBUS switch from a kind peo

[PATCH V2 2/5] ARM: OMAP3EVM: Adding USB internal LDOs board file

From: Zumeng Chen EHCI PHY requires these regulators: EVM Rev >=E --> VAUX2 EVM Rev < E --> VUSB1V5, VUSB1V8 Adding USB internal LDOs (vusb1v5 & vusb1v8) and VAUX2 to omap3evm board file. Also removing vaux2_{1/2/3} supplies as they are not used on omap3 evm. But we need not t

[PATCH V2 3/5] ARM: omap3evm: enable VBUS switch for EHCI tranceiver

From: Zumeng Chen This was chosen by following the trace on the schematic from component U131 and U134 to the CPEN pin on the USB3320 device. TWL4030.GPIO2-...->(T2_GPIO2_3V3)U131-..>nUSB2_EN-..>U134-..>EXP_nUSB2_1V8 which starts EHCI tranceiver USB3320. This will set TWL4030.GPIO2 as output pi

[PATCH V2 1/5] ARM: OMAP3EVM: Add NAND flash definition

From: Zumeng Chen Signed-off-by: Vaibhav Hiremath Tested-by: Zumeng Chen --- arch/arm/mach-omap2/board-omap3evm.c | 39 ++ 1 files changed, 39 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3evm.c b/arch/arm/mach-omap2/board-omap3ev

[PATCH V2 4/5] ARM: OMAP3EVM: cosmetic fixes for parent clk set

From: Zumeng Chen Since set parent for dummy clock will dump failed message, so we can just ignore to mute it. Signed-off-by: Signed-off-by: Jon Hunter Signed-off-by: Zumeng Chen --- arch/arm/plat-omap/clock.c |4 drivers/mfd/omap-usb-host.c |2 +- 2 files changed, 5 insertions(

[PATCH V2 5/5] Input: ads7846: set proper debounce time in driver level

From: Zumeng Chen If we don't set proper debouce time for ads7846, then there are flooded interrupt counters of ads7846 responding to one time touch on screen, so the driver couldn't work well. And since most OMAP3 series boards pass NULL pointer of board_pdata to omap_ads7846_init, so it's more

RE: [PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings

Hi Jon, On Tue, Jun 12, 2012 at 23:06:53, Hunter, Jon wrote: > Should you at least warn, if you are going to over-write a value? Yes, that would be better except for too much logging, if Tony prefers that way I will add. Regards Afzal -- To unsubscribe from this list: send the line "unsubscrib

RE: [PATCH 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion

Hi Jon, On Tue, Jun 12, 2012 at 23:00:48, Hunter, Jon wrote: > On 06/12/2012 01:16 AM, Mohammed, Afzal wrote: > > With the existing code, set_async was done as part of set_sync, hence > > requiring GPMC to be configured twice after driver takes control, with > > your suggestion too, GPMC would ha

RE: [PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD

Hi Jon, On Tue, Jun 12, 2012 at 23:10:01, Hunter, Jon wrote: > On 06/12/2012 01:53 AM, Mohammed, Afzal wrote: > > On Tue, Jun 12, 2012 at 01:26:29, Hunter, Jon wrote: > >> My preference would be to store gpmc_l3_clk in the pdata and pass to > >> probe via the pdata. The aim would be to remove the

RE: [PATCH v5 03/14] ARM: OMAP2+: gpmc: driver migration helper

Hi Jon, On Tue, Jun 12, 2012 at 23:16:50, Hunter, Jon wrote: > Ok, I see that this is necessary until all boards are migrated. However, > please label with a FIXME to make it clear that this is to be removed. Ok, I will update this. Regards Afzal -- To unsubscribe from this list: send the line

RE: [PATCH v5 05/14] ARM: OMAP2+: gpmc: resource creation helpers

Hi Jon, On Tue, Jun 12, 2012 at 23:32:05, Hunter, Jon wrote: > Well looking at the function it seems that you either return an error > code or 1. So if you are never going to return anything other than 1 on > success it may as well be 0. Irq & memory resource creation functions returns number of

RE: [PATCH v5 06/14] ARM: OMAP2+: gpmc: CS configuration helper

Hi Jon, On Tue, Jun 12, 2012 at 23:36:17, Hunter, Jon wrote: > Well it is unclear what the code flow is for using this helper as this > change simply adds the helper. If someone other function is writing to > the CONFIG1 register before this function, then you may wish to > highlight the programm

RE: [PATCH v5 06/14] ARM: OMAP2+: gpmc: CS configuration helper

Hi Jon, On Tue, Jun 12, 2012 at 23:39:32, Hunter, Jon wrote: > On 06/12/2012 07:58 AM, Mohammed, Afzal wrote: > > Thinking again over it, I am feeling above is sufficient, reason same as > > said earlier, to keep code simple & currently this is sufficient to > > handle GPMC bit patterns for IPs p

Re: [PATCH V2 03/10] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS

On Thu, Jun 7, 2012 at 2:22 PM, Jon Hunter wrote: > In order to use the CTI interrupts inconjunction with the DEBUGSS we need to > re-map the CTI IRQs to the DEBUGSS HWMOD. The purpose for doing this is so we > can create a PMU device based upon the DEBUGSS HWMOD and use the CTI > interrupts > fo

RE: [PATCH v5 14/14] ARM: OMAP2+: gpmc: writeprotect helper

Hi Jon, On Wed, Jun 13, 2012 at 00:12:27, Hunter, Jon wrote: > I am still wondering if we should warn against multiple devices using > the wait pin. I see that if could be valid to have multiple memory > devices of the same type using the WP pin spanning multiple CS. However, > in that case would

Re: [PATCH V2 03/10] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS

On Tue, Jun 12, 2012 at 11:07 PM, Pandita, Vikram wrote: > On Thu, Jun 7, 2012 at 2:22 PM, Jon Hunter wrote: >> In order to use the CTI interrupts inconjunction with the DEBUGSS we need to >> re-map the CTI IRQs to the DEBUGSS HWMOD. The purpose for doing this is so we >> can create a PMU device

RE: [PATCH v5 07/14] ARM: OMAP2+: gpmc: time setting (register#) helper

Hi Jon, On Wed, Jun 13, 2012 at 00:25:23, Hunter, Jon wrote: > When are the timings calculated? Why not just use the existing > gpmc_cs_set_timings()? > > I guess I am not convinced that we need to have multiple formats to pass > timings such as clock, period, etc. > > I think that it is suffic

Re: [PATCH V2 03/10] ARM: OMAP4: Re-map the CTIs IRQs from MPU to DEBUGSS

On Wed, Jun 13, 2012 at 11:43 AM, Pandita, Vikram wrote: > On Tue, Jun 12, 2012 at 11:07 PM, Pandita, Vikram > wrote: >> On Thu, Jun 7, 2012 at 2:22 PM, Jon Hunter wrote: >>> In order to use the CTI interrupts inconjunction with the DEBUGSS we need to >>> re-map the CTI IRQs to the DEBUGSS HWMO

RE: [PATCH v5 01/14] ARM: OMAP2+: gpmc: platform definitions

Hi Jon, On Wed, Jun 13, 2012 at 00:28:15, Hunter, Jon wrote: > On 06/11/2012 09:26 AM, Afzal Mohammed wrote: > > +enum { > > + has_none, > > + has_period, > > + has_clock > > +}; > > + > > +struct gpmc_time_ctrl { > > + int type; > > + struct gpmc_timings timings; > > + struct gpmc_mi

RE: [PATCH v5 04/14] ARM: OMAP2+: gpmc: minimal driver support

Hi Jon, On Wed, Jun 13, 2012 at 00:49:22, Hunter, Jon wrote: > On 06/11/2012 09:26 AM, Afzal Mohammed wrote: > > clk_enable(gpmc_l3_clk); > > We should be able to get rid of the clk_enable() here and use ... > > pm_runtime_enable(&pdev->dev); > pm_runtime_get(&pdev->dev); > > T

  1   2   >