* [PATCH v4 3/9] pinctrl: single: support pinconf generic
From: Tony Lindgren @ 2012-11-09 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352301582-12244-4-git-send-email-haojian.zhuang@gmail.com>
Hi Haojian,
One more comment on this one..
* Haojian Zhuang <haojian.zhuang@gmail.com> [121107 07:21]:
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
> @@ -1009,6 +1186,46 @@ static int __devinit pcs_probe(struct platform_device *pdev)
> pcs->bits_per_mux = of_property_read_bool(np,
> "pinctrl-single,bit-per-mux");
>
> + if (conf->nconfs) {
> + pcs_pinconf_ops.is_generic = true;
> + ret = of_property_read_u32(np,
> + "pinctrl-single,power-source-mask",
> + &pcs->psmask);
> + if (ret) {
> + pcs->psmask = PCS_OFF_DISABLED;
> + pcs->psshift = PCS_OFF_DISABLED;
> + } else
> + pcs->psshift = ffs(pcs->psmask) - 1;
> + ret = of_property_read_u32(np,
> + "pinctrl-single,bias-mask", &pcs->bmask);
> + if (ret) {
> + pcs->bmask = PCS_OFF_DISABLED;
> + pcs->bshift = PCS_OFF_DISABLED;
> + } else
> + pcs->bshift = ffs(pcs->bmask) - 1;
> + ret = of_property_read_u32(np,
> + "pinctrl-single,bias-disable", &pcs->bdis);
> + if (ret)
> + pcs->bdis = PCS_OFF_DISABLED;
> + ret = of_property_read_u32(np,
> + "pinctrl-single,bias-pull-up", &pcs->bpullup);
> + if (ret)
> + pcs->bpullup = PCS_OFF_DISABLED;
> + ret = of_property_read_u32(np,
> + "pinctrl-single,bias-pull-down",
> + &pcs->bpulldown);
> + if (ret)
> + pcs->bpulldown = PCS_OFF_DISABLED;
> + ret = of_property_read_u32(np,
> + "pinctrl-single,input-schmitt-mask",
> + &pcs->ismask);
> + if (ret) {
> + pcs->ismask = PCS_OFF_DISABLED;
> + pcs->isshift = PCS_OFF_DISABLED;
> + } else
> + pcs->isshift = ffs(pcs->ismask) - 1;
> + }
> +
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> if (!res) {
> dev_err(pcs->dev, "could not get resource\n");
I tried to make pinconf work with the omap CONTROL_PBIASLITE
register, but noticed that we need to change the binding to make
pinctrl-single,bits type controllers work.
Basically we need to move the pinconf properties to be defined
under pinctrl-single,pins and pinctrl-single,bits rather than being
pinmux controller instance specific properties.
In the pinctrl-single,bits case we have multiple pinconf masks
for a single register, like in the omap CONTROL_PBIASLITE example
we discussed earlier.
Then let's just have a single pinctrl driver instance specific
property pinctrl-single,pinconf that we can use to optimize out
the pinconf parsing for ranges that don't support pinconf.
Other than that, I think I'm finally done with my comments for
this patch, sorry it took so long and took so many emails.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: tegra: retain L2 content over CPU suspend/resume
From: Stephen Warren @ 2012-11-09 21:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352194377-6209-1-git-send-email-josephl@nvidia.com>
On 11/06/2012 02:32 AM, Joseph Lo wrote:
> The L2 RAM is in different power domain from the CPU cluster. So the
> L2 content can be retained over CPU suspend/resume. To do that, we
> need to disable L2 after the MMU is disabled, and enable L2 before
> the MMU is enabled. But the L2 controller is in the same power domain
> with the CPU cluster. We need to restore it's settings and re-enable
> it after the power be resumed.
This doesn't compile:
arch/arm/mach-tegra/headsmp.S: Assembler messages:
arch/arm/mach-tegra/headsmp.S:119: Error: undefined symbol L2X0_CTRL_EN
used as an immediate value
arch/arm/mach-tegra/headsmp.S:119: Error: undefined symbol L2X0_CTRL_EN
used as an immediate value
^ permalink raw reply
* [PATCH] ARM: tegra: enable data prefetch on L2
From: Stephen Warren @ 2012-11-09 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352251597-2936-1-git-send-email-josephl@nvidia.com>
On 11/06/2012 06:26 PM, Joseph Lo wrote:
> Enable the data prefetch on L2. The bit28 in aux ctrl register.
Applied to Tegra's for-3.8/soc branch. Thanks.
^ permalink raw reply
* [GIT PULL] ARM: OMAP: DTS for 3.8 part 2
From: Tony Lindgren @ 2012-11-09 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509D0CC4.4080305@ti.com>
* Benoit Cousson <b-cousson@ti.com> [121109 06:03]:
> Hi Tony,
>
> Please pull some more OMAP5 and AM33xx data for 3.8.
Thanks pulling into omap-for-v3.8/dt.
Regards,
Tony
>
> Thanks,
> Benoit
>
>
>
> The following changes since commit 3b3132f7e80e3d786f8ad5d5b97d4b6122be9aaa:
> Jon Hunter (1):
> ARM: dts: OMAP5: Add counter node
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.8/dts_part2
>
> Afzal Mohammed (1):
> usb: musb: dsps: dt binding - add resources, example
>
> Ajay Kumar Gupta (1):
> ARM: dts: AM33XX: Add usbss node
>
> AnilKumar Ch (10):
> ARM: dts: AM33XX: Add pinmux configuration for matrix keypad to EVM
> ARM: dts: AM33XX: Add matrix keypad device tree data to am335x-evm
> ARM: dts: AM33XX: Add pinmux configuration for volume-keys to EVM
> ARM: dts: AM33XX: Add volume-keys device tree data to am335x-evm
> ARM: dts: AM33XX: Add pinmux configuration for user-leds to BONE
> ARM: dts: AM33XX: Add user-leds device tree data to am335x-bone
> ARM: dts: AM33XX: Add pinmux configuration for gpio-leds to EVMSK
> ARM: dts: AM33XX: Add user-leds device tree data to am335x-evmsk
> ARM: dts: AM33XX: Add pinmux configuration for gpio-keys to EVMSK
> ARM: dts: AM33XX: Add push-buttons device tree data to am335x-evmsk
>
> Benoit Cousson (1):
> ARM: dts: Makefile: Add the am335x-evmsk target in dtbs list
>
> Lokesh Vutla (3):
> ARM: dts: omap5-evm: Fix size of memory defined for EVM
> ARM: dts: omap5: EMIF device tree data for OMAP5 boards
> ARM: dts: omap5-evm: LPDDR2 memory device details for EVM
>
> Ricardo Neri (2):
> ARM: dts: omap4-panda: Add pinmux configuration for HDMI
> ARM: dts: omap4-sdp: Add pinmux configuration for HDMI
>
> .../devicetree/bindings/usb/am33xx-usb.txt | 21 +++++
> arch/arm/boot/dts/Makefile | 1 +
> arch/arm/boot/dts/am335x-bone.dts | 44 ++++++++++
> arch/arm/boot/dts/am335x-evm.dts | 63 +++++++++++++++
> arch/arm/boot/dts/am335x-evmsk.dts | 84 ++++++++++++++++++++
> arch/arm/boot/dts/am33xx.dtsi | 17 ++++
> arch/arm/boot/dts/omap4-panda-a4.dts | 17 ++++
> arch/arm/boot/dts/omap4-panda-es.dts | 9 ++
> arch/arm/boot/dts/omap4-panda.dts | 18 ++++
> arch/arm/boot/dts/omap4-sdp-es23plus.dts | 17 ++++
> arch/arm/boot/dts/omap4-sdp.dts | 18 ++++
> arch/arm/boot/dts/omap5-evm.dts | 13 +++-
> arch/arm/boot/dts/omap5.dtsi | 22 +++++
> arch/arm/boot/dts/samsung_k3pe0e000b.dtsi | 67 ++++++++++++++++
> 14 files changed, 410 insertions(+), 1 deletions(-)
> create mode 100644 arch/arm/boot/dts/omap4-panda-a4.dts
> create mode 100644 arch/arm/boot/dts/omap4-sdp-es23plus.dts
> create mode 100644 arch/arm/boot/dts/samsung_k3pe0e000b.dtsi
^ permalink raw reply
* [GIT PULL] ARM: OMAP: Timer and Counter DT Updates for v3.8
From: Tony Lindgren @ 2012-11-09 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509C4BF1.20505@ti.com>
* Jon Hunter <jon-hunter@ti.com> [121108 16:20]:
>
> On 11/08/2012 01:47 PM, Jon Hunter wrote:
> > Do you want to generate the patch or me?
>
> Patch posted here ...
>
> http://marc.info/?l=linux-omap&m=135242025202171&w=2
OK thanks!
Tony
^ permalink raw reply
* [PATCH v2 00/26] Move OMAP2+ over to common clk framework
From: Tony Lindgren @ 2012-11-09 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211092058540.20703@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121109 13:14]:
>
> Hi
>
> With the fixes that have been posted, this is testing clean here. Mike
> and Rajendra have put in months of work on these patches under
> often-difficult conditions, and it's really great that we've arrived at
> this point with zero obvious remaining regressions from the current code.
That's excellent news :)
> The branch has been posted for the time being at
> git://git.pwsan.com/linux-2.6 in the branch 'common_clk_devel_3.8', with
> the head at commit 376676b429cb6dc95c39cdac82b2be816ea22893, in case
> anyone else wants to try it.
>
> Anyway, barring any further regressions that haven't reared their ugly
> heads yet, and barring anything truly horrible in the code or data that
> I've missed so far, will take this branch from here. It still needs some
> more work before it's ready to merge. The clockdomain usecounting fix
> patch needs to be split and moved earlier in the patch stack so 'git
> bisect' doesn't result in warnings and broken PM on OMAP3. And it all is
> going to be rebased on the second set of PRCM cleanup patches at commit
> b99db36cdf37decb1b5575c5f293d170cbbc53d6, which I'm assuming Tony is
> planning to pull. Then will plan to send that pull request to Tony.
>
> Then after that, if there's still time to merge some of the clock changes
> that have showed up on the lists for 3.8, those will get stacked onto a
> topic branch based on the branch that's sent to Tony.
Sounds good to me.
Thanks,
Tony
^ permalink raw reply
* [GIT PULL v2] ARM: OMAP: second set of PRCM cleanups for 3.8
From: Tony Lindgren @ 2012-11-09 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211091654590.20703@utopia.booyaka.com>
* Paul Walmsley <paul@pwsan.com> [121109 08:57]:
> Hi Tony,
>
> The following changes since commit 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33:
>
> Merge branch 'omap-for-v3.8/cleanup-headers' into omap-for-v3.8/cleanup-prcm (2012-10-26 13:32:22 -0700)
>
> are available in the git repository at:
>
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-b2-for-3.8
>
> for you to fetch changes up to b99db36cdf37decb1b5575c5f293d170cbbc53d6:
>
> ARM: OMAP2+: PRCM: remove obsolete prcm.[ch] (2012-11-08 15:09:26 -0700)
>
> ----------------------------------------------------------------
> Second set of OMAP PRCM cleanups for 3.8.
>
> These patches remove the use of omap_prcm_get_reset_sources() from the
> OMAP watchdog driver, and remove mach-omap2/prcm.c and
> plat-omap/include/plat/prcm.h.
Thanks pulling into omap-for-v3.8/cleanup-prcm.
Regards,
Tony
> Basic test logs for this branch on top of Tony's cleanup-prcm branch
> at commit 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33 are here:
>
> http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121108151646/
>
> However, cleanup-prcm at 7fc54fd3 does not include some fixes
> that are needed for a successful test. With several reverts,
> fixes, and workarounds applied, the following test logs were
> obtained:
>
> http://www.pwsan.com/omap/testlogs/TEST_prcm_cleanup_b_3.8/20121108151930/
>
> which indicate that the series tests cleanly.
>
> This second pull request updates one of the patches which broke
> with rmk's allnoconfigs, and also updates the tag description to
> indicate that 7fc54fd3 is building cleanly here.
>
> ----------------------------------------------------------------
>
> vmlinux object size
> (delta in bytes from test_cleanup-prcm_7fc54fd_v3.7-rc (7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33)):
> text data bss total kernel
> -104 -72 0 -176 am33xx_only
> +120 -64 0 +56 n800_multi_omap2xxx
> +336 -32 0 +304 n800_only_a
> +88 -24 0 +64 omap1_defconfig
> 0 0 0 0 omap1_defconfig_1510innovator_only
> +132 -8 0 +124 omap1_defconfig_5912osk_only
> +788 -232 0 +556 omap2plus_defconfig
> +336 -32 0 +304 omap2plus_defconfig_2430sdp_only
> +788 -240 0 +548 omap2plus_defconfig_cpupm
> +844 -224 0 +620 omap2plus_defconfig_no_pm
> +336 -144 0 +192 omap2plus_defconfig_omap2_4_only
> +4528 -112 0 +4416 omap2plus_defconfig_omap3_4_only
> +1524 -248 +3472 +4748 rmk_omap3430_ldp_allnoconfig
> +312 -48 0 +264 rmk_omap3430_ldp_oldconfig
> +1524 -248 +3472 +4748 rmk_omap4430_sdp_allnoconfig
> +208 -48 0 +160 rmk_omap4430_sdp_oldconfig
>
>
> Paul Walmsley (17):
> ARM: OMAP1: CGRM: fix omap1_get_reset_sources() return type
> ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer
> watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr
> ARM: OMAP2+: PRCM: remove omap_prcm_get_reset_sources()
> ARM: OMAP2+: common: remove mach-omap2/common.c globals and map_common_io code
> ARM: OMAP2/3: PRM: add SoC reset functions (using the CORE DPLL method)
> ARM: OMAP2xxx: clock: remove global 'dclk' variable
> ARM: OMAP2xxx: clock: move virt_prcm_set code into clkt2xxx_virt_prcm_set.c
> ARM: OMAP2+: PRCM: create SoC-specific chip restart functions
> ARM: OMAP2+: board files: use SoC-specific system restart functions
> ARM: OMAP2xxx: APLL/CM: convert to use omap2_cm_wait_module_ready()
> ARM: OMAP2+: CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM functions
> ARM: OMAP2+: PRCM: remove omap2_cm_wait_idlest()
> ARM: OMAP2+: PRCM: split and relocate the PRM/CM globals setup
> ARM: OMAP2+: PRCM: consolidate PRCM-related timeout macros
> ARM: OMAP2+: hwmod: call to _omap4_disable_module() should use the SoC-specific call
> ARM: OMAP2+: PRCM: remove obsolete prcm.[ch]
>
> arch/arm/mach-omap1/common.h | 2 +-
> arch/arm/mach-omap1/devices.c | 21 ++-
> arch/arm/mach-omap1/reset.c | 9 +-
> arch/arm/mach-omap2/Makefile | 7 +-
> arch/arm/mach-omap2/am33xx.h | 1 +
> arch/arm/mach-omap2/board-2430sdp.c | 2 +-
> arch/arm/mach-omap2/board-3430sdp.c | 2 +-
> arch/arm/mach-omap2/board-3630sdp.c | 2 +-
> arch/arm/mach-omap2/board-4430sdp.c | 2 +-
> arch/arm/mach-omap2/board-am3517crane.c | 2 +-
> arch/arm/mach-omap2/board-am3517evm.c | 2 +-
> arch/arm/mach-omap2/board-apollon.c | 2 +-
> arch/arm/mach-omap2/board-cm-t35.c | 18 +--
> arch/arm/mach-omap2/board-cm-t3517.c | 2 +-
> arch/arm/mach-omap2/board-devkit8000.c | 2 +-
> arch/arm/mach-omap2/board-generic.c | 10 +-
> arch/arm/mach-omap2/board-h4.c | 2 +-
> arch/arm/mach-omap2/board-igep0020.c | 4 +-
> arch/arm/mach-omap2/board-ldp.c | 2 +-
> arch/arm/mach-omap2/board-n8x0.c | 6 +-
> arch/arm/mach-omap2/board-omap3beagle.c | 2 +-
> arch/arm/mach-omap2/board-omap3evm.c | 2 +-
> arch/arm/mach-omap2/board-omap3logic.c | 4 +-
> arch/arm/mach-omap2/board-omap3pandora.c | 2 +-
> arch/arm/mach-omap2/board-omap3stalker.c | 2 +-
> arch/arm/mach-omap2/board-omap3touchbook.c | 2 +-
> arch/arm/mach-omap2/board-omap4panda.c | 2 +-
> arch/arm/mach-omap2/board-overo.c | 2 +-
> arch/arm/mach-omap2/board-rm680.c | 4 +-
> arch/arm/mach-omap2/board-rx51.c | 2 +-
> arch/arm/mach-omap2/board-ti8168evm.c | 4 +-
> arch/arm/mach-omap2/board-zoom.c | 4 +-
> arch/arm/mach-omap2/clkt2xxx_apll.c | 57 ++------
> arch/arm/mach-omap2/clkt2xxx_dpllcore.c | 36 ++++-
> arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c | 70 ++++++++--
> arch/arm/mach-omap2/clkt_iclk.c | 1 -
> arch/arm/mach-omap2/clock.c | 57 +++++++-
> arch/arm/mach-omap2/clock.h | 28 ----
> arch/arm/mach-omap2/clock2420_data.c | 26 +---
> arch/arm/mach-omap2/clock2430_data.c | 26 +---
> arch/arm/mach-omap2/clock2xxx.c | 16 ---
> arch/arm/mach-omap2/clock2xxx.h | 9 +-
> arch/arm/mach-omap2/cm-regbits-24xx.h | 2 +
> arch/arm/mach-omap2/cm.h | 20 ++-
> arch/arm/mach-omap2/cm2xxx.c | 128 ++++++++++++++++-
> arch/arm/mach-omap2/cm2xxx.h | 4 +
> arch/arm/mach-omap2/cm2xxx_3xxx.h | 8 +-
> arch/arm/mach-omap2/cm3xxx.c | 66 +++++++++
> arch/arm/mach-omap2/cm3xxx.h | 5 +
> arch/arm/mach-omap2/cm_common.c | 70 +++++++++-
> arch/arm/mach-omap2/cminst44xx.h | 2 +
> arch/arm/mach-omap2/common.c | 183 -------------------------
> arch/arm/mach-omap2/common.h | 133 +++++-------------
> arch/arm/mach-omap2/control.c | 10 +-
> arch/arm/mach-omap2/control.h | 2 +
> arch/arm/mach-omap2/cpuidle34xx.c | 1 -
> arch/arm/mach-omap2/devices.c | 26 ----
> arch/arm/mach-omap2/display.c | 2 +-
> arch/arm/mach-omap2/hdq1w.c | 4 +-
> arch/arm/mach-omap2/i2c.c | 6 +-
> arch/arm/mach-omap2/id.c | 7 +-
> arch/arm/mach-omap2/io.c | 86 ++++++++++--
> arch/arm/mach-omap2/mcbsp.c | 2 +-
> arch/arm/mach-omap2/msdi.c | 4 +-
> arch/arm/mach-omap2/omap2-restart.c | 65 +++++++++
> arch/arm/mach-omap2/omap3-restart.c | 36 +++++
> arch/arm/mach-omap2/omap4-common.c | 19 +++
> arch/arm/mach-omap2/omap_hwmod.c | 8 +-
> arch/arm/mach-omap2/pm34xx.c | 1 -
> arch/arm/mach-omap2/powerdomain.c | 2 -
> arch/arm/mach-omap2/prcm-common.h | 22 ---
> arch/arm/mach-omap2/prcm.c | 189 --------------------------
> arch/arm/mach-omap2/prcm_mpu44xx.c | 17 +++
> arch/arm/mach-omap2/prcm_mpu44xx.h | 9 +-
> arch/arm/mach-omap2/prm.h | 24 +++-
> arch/arm/mach-omap2/prm2xxx.c | 15 +-
> arch/arm/mach-omap2/prm2xxx.h | 2 +
> arch/arm/mach-omap2/prm2xxx_3xxx.h | 7 -
> arch/arm/mach-omap2/prm3xxx.c | 16 ++-
> arch/arm/mach-omap2/prm3xxx.h | 2 +
> arch/arm/mach-omap2/prm44xx.c | 1 -
> arch/arm/mach-omap2/prm_common.c | 16 ++-
> arch/arm/mach-omap2/prminst44xx.h | 2 +
> arch/arm/mach-omap2/sdrc.c | 8 +-
> arch/arm/mach-omap2/sdrc.h | 2 +
> arch/arm/mach-omap2/ti81xx.h | 9 ++
> arch/arm/mach-omap2/wd_timer.c | 40 +++++-
> arch/arm/plat-omap/include/plat/prcm.h | 37 -----
> drivers/watchdog/omap_wdt.c | 26 ++--
> include/linux/platform_data/omap-wd-timer.h | 38 ++++++
> 90 files changed, 991 insertions(+), 851 deletions(-)
> create mode 100644 arch/arm/mach-omap2/omap2-restart.c
> create mode 100644 arch/arm/mach-omap2/omap3-restart.c
> delete mode 100644 arch/arm/mach-omap2/prcm.c
> delete mode 100644 arch/arm/plat-omap/include/plat/prcm.h
> create mode 100644 include/linux/platform_data/omap-wd-timer.h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2 00/26] Move OMAP2+ over to common clk framework
From: Mike Turquette @ 2012-11-09 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211092058540.20703@utopia.booyaka.com>
Quoting Paul Walmsley (2012-11-09 13:12:24)
> Hi
>
> With the fixes that have been posted, this is testing clean here. Mike
> and Rajendra have put in months of work on these patches under
> often-difficult conditions, and it's really great that we've arrived at
> this point with zero obvious remaining regressions from the current code.
>
> The branch has been posted for the time being at
> git://git.pwsan.com/linux-2.6 in the branch 'common_clk_devel_3.8', with
> the head at commit 376676b429cb6dc95c39cdac82b2be816ea22893, in case
> anyone else wants to try it.
>
Thanks a lot Paul. You put in a lot of work on this series as well and
that should not go unnoticed. I'm truly happy to see this series come
together.
> Anyway, barring any further regressions that haven't reared their ugly
> heads yet, and barring anything truly horrible in the code or data that
> I've missed so far, will take this branch from here. It still needs some
> more work before it's ready to merge. The clockdomain usecounting fix
> patch needs to be split and moved earlier in the patch stack so 'git
> bisect' doesn't result in warnings and broken PM on OMAP3. And it all is
> going to be rebased on the second set of PRCM cleanup patches at commit
> b99db36cdf37decb1b5575c5f293d170cbbc53d6, which I'm assuming Tony is
> planning to pull. Then will plan to send that pull request to Tony.
>
I just did some more testing on your branch and everything looks great.
The only thing that caught my eye was using the clk-private.h header in
the top-most patch. The following patch will help me sleep better at
night:
diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
index ba4d14c..3848735 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -22,7 +22,7 @@
#include <linux/clk.h>
#include <linux/limits.h>
#include <linux/err.h>
-#include <linux/clk-private.h>
+#include <linux/clk-provider.h>
#include <linux/io.h>
Tested on 3530 ES3.0 Beagleboard, boot + suspend/resume.
Regards,
Mike
> Then after that, if there's still time to merge some of the clock changes
> that have showed up on the lists for 3.8, those will get stacked onto a
> topic branch based on the branch that's sent to Tony.
>
>
> - Paul
^ permalink raw reply related
* [PATCH 15/26] ARM: omap2: clock: Add 24xx data using common struct clk
From: Mike Turquette @ 2012-11-09 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211092112340.20703@utopia.booyaka.com>
Quoting Paul Walmsley (2012-11-09 13:22:00)
> On Fri, 9 Nov 2012, Mike Turquette wrote:
>
> > Quoting Paul Walmsley (2012-11-09 12:32:59)
> Re the upstream CCF support for this, would suggest adding the CCF support
> for the new function pointer in this merge window (3.8) since it should
> be relatively straightforward. Then during the 3.9 merge window, the
> OMAP code can be switched over to use it.
>
Will do.
Regards,
Mike
>
> - Paul
^ permalink raw reply
* [PATCH] ARM: OMAP: Fix kernel panic in dmtimer probe
From: Tony Lindgren @ 2012-11-09 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352420243-31803-1-git-send-email-jon-hunter@ti.com>
* Jon Hunter <jon-hunter@ti.com> [121108 16:19]:
> When booting with device-tree the kernel is panicing in the probe of the
> DMTIMER driver. The panic is caused because the pointer to platform_data
> structure is NULL when booting with device-tree and the driver is
> attempting to access the structure without checking if the pointer is
> valid.
>
> Fix this by moving the code that accesses the platform data structure
> under the "else" clause of the "if (dev->of_node)" statement because
> here the pointer to platform_data is guaranteed to be valid. The code
> accessing the "timer_capability" member of the platform data is simply
> removed as this is already handled under the else clause.
>
> This regression was introduced while integrating commit "ARM: OMAP: Add
> DT support for timer driver" to add device-tree support to the DMTIMER
> driver and commit "ARM: OMAP: Move omap-pm-noop.c local to mach-omap2"
> to prepare for single zImage support.
Thanks, looks like this needs to be fixed in the merge, so I'll
merge omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3 into
omap-for-v3.8/dt and resolve the conflict according to your patch.
Regards,
Tony
> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> ---
> arch/arm/plat-omap/dmtimer.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
> index 38c12ef..9dca23e 100644
> --- a/arch/arm/plat-omap/dmtimer.c
> +++ b/arch/arm/plat-omap/dmtimer.c
> @@ -799,12 +799,11 @@ static int __devinit omap_dm_timer_probe(struct platform_device *pdev)
> timer->id = pdev->id;
> timer->capability = pdata->timer_capability;
> timer->reserved = omap_dm_timer_reserved_systimer(timer->id);
> + timer->get_context_loss_count = pdata->get_context_loss_count;
> }
>
> timer->irq = irq->start;
> timer->pdev = pdev;
> - timer->capability = pdata->timer_capability;
> - timer->get_context_loss_count = pdata->get_context_loss_count;
>
> /* Skip pm_runtime_enable for OMAP1 */
> if (!(timer->capability & OMAP_TIMER_NEEDS_RESET)) {
> --
> 1.7.9.5
>
^ permalink raw reply
* [GIT PULL] musb regression fixes for v3.7-rc4
From: Tony Lindgren @ 2012-11-09 22:39 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit 3d70f8c617a436c7146ecb81df2265b4626dfe89:
Linux 3.7-rc4 (2012-11-04 11:07:39 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.7-rc4/musb-regression-signed
for you to fetch changes up to 459bc971eba0fe84b3fe857cf0a71c5fd102f06b:
ARM: OMAP: ocp2scp: create omap device for ocp2scp (2012-11-07 10:10:28 -0800)
----------------------------------------------------------------
This series fixes an annoying regression to make MUSB working
on omap4 again. Although it's getting rather late for these
changes for the -rc cycle, it is important as many devices
are using MUSB for charging and connectivity.
With the USB PHY changes, MUSB started using the newly added
drivers/usb/phy/omap-usb2.c driver introduced by commit
657b306a (usb: phy: add a new driver for omap usb2 phy)
that is using the newly introduced drivers/bus/omap-ocp2scp.c
introduced by commit 26a84b3e (drivers: bus: add a new driver
for omap-ocp2scp).
These changes allowed dropping a lot of PHY related code from
arch/arm/mach-omap2/omap_phy_internal.c and have it live in
the device driver like it should with commit c9e4412a (arm: omap:
phy: remove unused functions from omap-phy-internal.c).
However, MUSB on omap4 broke with these changes for legacy
platform data boot, and now only works with device tree for
omap4. Unfortunately we are still few critical bindings away
from being able to make omap4 usbale with device tree.
Fix the regression properly by adding platform data support
to the ocp2scp driver so we can avoid adding back the driver
code to arch/arm/mach-omap2.
----------------------------------------------------------------
Kishon Vijay Abraham I (3):
drivers: bus: ocp2scp: add pdata support
ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy
ARM: OMAP: ocp2scp: create omap device for ocp2scp
arch/arm/mach-omap2/devices.c | 79 ++++++++++++++++++++++++++++++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 28 +++++++++++
drivers/bus/omap-ocp2scp.c | 68 +++++++++++++++++++++++--
include/linux/platform_data/omap_ocp2scp.h | 31 ++++++++++++
4 files changed, 203 insertions(+), 3 deletions(-)
create mode 100644 include/linux/platform_data/omap_ocp2scp.h
^ permalink raw reply
* [PATCH 2/4] arm64: Fix the update_vsyscall() prototype
From: John Stultz @ 2012-11-09 22:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350406000-30882-3-git-send-email-catalin.marinas@arm.com>
On 10/16/2012 09:46 AM, Catalin Marinas wrote:
> With commit 576094b7 (time: Introduce new GENERIC_TIME_VSYSCALL) the old
> update_vsyscall() prototype is no longer available. This patch updates
> the arm64 port.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Acked-by: Will Deacon <will.deacon@arm.com>
> Cc: John Stultz <john.stultz@linaro.org>
> ---
> arch/arm64/kernel/vdso.c | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
> index 17948fc..ba45794 100644
> --- a/arch/arm64/kernel/vdso.c
> +++ b/arch/arm64/kernel/vdso.c
> @@ -28,6 +28,7 @@
> #include <linux/sched.h>
> #include <linux/signal.h>
> #include <linux/slab.h>
> +#include <linux/timekeeper_internal.h>
> #include <linux/vmalloc.h>
>
> #include <asm/cacheflush.h>
> @@ -222,11 +223,10 @@ struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
> /*
> * Update the vDSO data page to keep in sync with kernel timekeeping.
> */
> -void update_vsyscall(struct timespec *ts, struct timespec *wtm,
> - struct clocksource *clock, u32 mult)
> +void update_vsyscall(struct timekeeper *tk)
> {
> struct timespec xtime_coarse;
> - u32 use_syscall = strcmp(clock->name, "arch_sys_counter");
> + u32 use_syscall = strcmp(tk->clock->name, "arch_sys_counter");
>
> ++vdso_data->tb_seq_count;
> smp_wmb();
> @@ -237,13 +237,13 @@ void update_vsyscall(struct timespec *ts, struct timespec *wtm,
> vdso_data->xtime_coarse_nsec = xtime_coarse.tv_nsec;
>
> if (!use_syscall) {
> - vdso_data->cs_cycle_last = clock->cycle_last;
> - vdso_data->xtime_clock_sec = ts->tv_sec;
> - vdso_data->xtime_clock_nsec = ts->tv_nsec;
> - vdso_data->cs_mult = mult;
> - vdso_data->cs_shift = clock->shift;
> - vdso_data->wtm_clock_sec = wtm->tv_sec;
> - vdso_data->wtm_clock_nsec = wtm->tv_nsec;
> + vdso_data->cs_cycle_last = tk->clock->cycle_last;
> + vdso_data->xtime_clock_sec = tk->xtime_sec;
> + vdso_data->xtime_clock_nsec = tk->xtime_nsec >> tk->shift;
Sorry for the collision here!
One word of warning: Truncating the sub-ns base like this can cause
small single ns inconsistencies from the vsyscalls.
So either use GENERIC_TIME_VSYSCALL_OLD to enable the 1ns generic
rounding-up code, or rework the vsyscall code to use the sub-ns
granularity as done in 650ea02475106e8d6bdf561896d2ffe0d1c0ebb4 for
x86_64. I hope to drop the _OLD config eventually, so this will need to
be done at some point.
thanks
-john
^ permalink raw reply
* [PATCH v4 4/9] ARM: dts: support pinctrl single in pxa910
From: Tony Lindgren @ 2012-11-09 22:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352301582-12244-5-git-send-email-haojian.zhuang@gmail.com>
Hi,
To clarify my binding change comment for the generic pinconf
support, here's an example.
We need to move pinctrl-single pinconf properties here for
each pin group:
* Haojian Zhuang <haojian.zhuang@gmail.com> [121107 07:21]:
> + uart1_pins: pinmux_uart1_pins {
> + pinctrl-single,pins = <
> + 0x198 0x6 /* GPIO47_UART1_RXD */
> + 0x19c 0x6 /* GPIO48_UART1_TXD */
> + >;
> + pinctrl-single,power-source = <0x2>;
> + pinctrl-single,bias = <0x6>;
pinctrl-single,power-source-mask = <0x1800>;
pinctrl-single,bias-mask = <0xe000>;
pinctrl-single,bias-disable = <0>;
pinctrl-single,bias-pull-down = <0xa000>;
pinctrl-single,bias-pull-up = <0xc000>;
> + };
> --- a/arch/arm/boot/dts/pxa910.dtsi
> +++ b/arch/arm/boot/dts/pxa910.dtsi
> @@ -54,6 +54,80 @@
> reg = <0xd4000000 0x00200000>;
> ranges;
>
> + pmx: pinmux at d401e000 {
> + compatible = "pinconf-single";
> + reg = <0xd401e000 0x0330>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <7>;
And then..
> + pinctrl-single,power-source-mask = <0x1800>;
> + pinctrl-single,bias-mask = <0xe000>;
> + pinctrl-single,bias-disable = <0>;
> + pinctrl-single,bias-pull-down = <0xa000>;
> + pinctrl-single,bias-pull-up = <0xc000>;
> + pinctrl-single,input-schmitt-mask = <0x70>;
..remove these from here. Otherwise pinctrl-single,bits type controllers
won't be able to use the pinconf functions as we can have multiple pins
supported in a single register.
Regards,
Tony
^ permalink raw reply
* [PATCH 02/11] time: convert arch_gettimeoffset to a pointer
From: John Stultz @ 2012-11-09 23:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1352408516-21988-4-git-send-email-swarren@wwwdotorg.org>
On 11/08/2012 01:01 PM, Stephen Warren wrote:
> From: Stephen Warren <swarren@nvidia.com>
>
> Currently, whenever CONFIG_ARCH_USES_GETTIMEOFFSET is enabled, each
> arch core provides a single implementation of arch_gettimeoffset(). In
> many cases, different sub-architectures, different machines, or
> different timer providers exist, and so the arch ends up implementing
> arch_gettimeoffset() as a call-through-pointer anyway. Examples are
> ARM, Cris, M68K, and it's arguable that the remaining architectures,
> M32R and Blackfin, should be doing this anyway.
>
> Modify arch_gettimeoffset so that it itself is a function pointer, which
> the arch initializes. This will allow later changes to move the
> initialization of this function into individual machine support or timer
> drivers. This is particularly useful for code in drivers/clocksource
> which should rely on an arch-independant mechanism to register their
> implementation of arch_gettimeoffset().
>
> This patch also converts the Cris architecture to set arch_gettimeoffset
> directly to the final implementation in time_init(), because Cris already
> had separate time_init() functions per sub-architecture. M68K and ARM
> are converted to set arch_gettimeoffset the final implementation in later
> patches, because they already have function pointers in place for this
> purpose.
[snip]
> diff --git a/include/linux/time.h b/include/linux/time.h
> index 4d358e9..05e32a7 100644
> --- a/include/linux/time.h
> +++ b/include/linux/time.h
> @@ -142,9 +142,7 @@ void timekeeping_inject_sleeptime(struct timespec *delta);
> * finer then tick granular time.
> */
> #ifdef CONFIG_ARCH_USES_GETTIMEOFFSET
> -extern u32 arch_gettimeoffset(void);
> -#else
> -static inline u32 arch_gettimeoffset(void) { return 0; }
> +extern u32 (*arch_gettimeoffset)(void);
> #endif
>
> extern void do_gettimeofday(struct timeval *tv);
> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index e424970..9d00ace 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -140,6 +140,20 @@ static void tk_setup_internals(struct timekeeper *tk, struct clocksource *clock)
> }
>
> /* Timekeeper helper functions. */
> +
> +#ifdef CONFIG_ARCH_USES_GETTIMEOFFSET
> +u32 (*arch_gettimeoffset)(void);
> +
> +u32 gettimeoffset(void)
> +{
> + if (likely(arch_gettimeoffset))
> + return arch_gettimeoffset();
> + return 0;
> +}
> +#else
> +static inline u32 gettimeoffset(void) { return 0; }
> +#endif
Minor nit-pick here, but get_arch_timeoffset() or get_arch_tickoffset()
might be clearer, as gettimeoffset() sounds a little generic, and could
be confused with the higher-level timekeeping_inject_offset() call.
Otherwise this looks ok to me (disclaimer: I'm back from a 4 week leave,
so I may not have my brain plugged in all the way yet).
thanks
-john
^ permalink raw reply
* Test of arm_timer_rework
From: Robert Jarzmik @ 2012-11-09 23:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi Stephen,
You asked board maintainers to test your tree in :
git://nv-tegra.nvidia.com/user/swarren/linux-2.6 arm_timer_rework
(top commit is 3bbbe63cb12f1f29f1eadc0b3b93516502562f0e)
I've just done so for mioa701 board, pxa based (mach-pxa).
Kernel timer does work, and RTC does work too, in both active usecase, and with
a suspend/resume cycle.
If you wish, feel free to add my :
Tested-by: Robert Jarzmik <robert.jarzmik@free.fr>
--
Robert
^ permalink raw reply
* OMAP baseline test results for v3.7-rc4
From: Kevin Hilman @ 2012-11-09 23:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1211050241410.23228@utopia.booyaka.com>
+Felipe, Venkat
Paul Walmsley <paul@pwsan.com> writes:
[...]
> Failing tests: needing investigation
> ------------------------------------
>
Here's another one for v3.7-rc4.
On all OMAP3 platforms I tested (3430/n900, 3530/Beagle, 3530/Overo,
3730/OveroSTORM, 3730/Beagle-xM), a system suspend (retention or off)
fails to wake up after a dynamic idle off-mode test (test script
below[1]).
I found that disabling MMC in the config made the tests pass again, so
then bisected it down to the commit below removing SYSCONFIG
accesses[2]. I haven't had the time to find out exactly the cause, but
clearly the code that was removed was doing something that hwmod is not
taking care of automatically.
Venkat, Felipe, could you please investigate this and hopefully get a
fix out for v3.7-rc?
Thanks,
Kevin
[1] Test for system suspend (retention) after off-idle
#!/bin/sh
echo 1 > /debug/pm_debug/enable_off_mode
echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
if [ -e /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms ]; then
echo 3000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms
fi
sleep 5
echo -1 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
echo -1 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
echo -1 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
if [ -e /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms ]; then
echo -1 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms
fi
echo 0 > /debug/pm_debug/enable_off_mode
rtcwake -m mem -s 1
[2]
commit 6c31b2150ff96755d24e0ab6d6fea08a7bf5c44c
Author: Venkatraman S <svenkatr@ti.com>
Date: Wed Aug 8 14:26:52 2012 +0530
mmc: omap_hsmmc: remove access to SYSCONFIG register
SYSCONFIG register of HSMMC IP is managed by the omap hwmod
abstraction layer. Resetting the IP and configuring the correct
SYSCONFIG mode is centrally managed by hwmod.
Remove code which manipulates IP reset and SYSCONFIG directly in
the driver.
Signed-off-by: Venkatraman S <svenkatr@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Prevent redefinition errors for soc.h
From: Jon Hunter @ 2012-11-09 23:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121109211052.GS6801@atomide.com>
On 11/09/2012 03:10 PM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter@ti.com> [121109 08:31]:
>>
>> On 11/09/2012 10:22 AM, Tony Lindgren wrote:
>>> * Jon Hunter <jon-hunter@ti.com> [121109 08:21]:
>>>> If the header soc.h is included more than once in a source (for example
>>>> once directly by the source file and once indirectly by another header
>>>> file), then the compiler will generate redefintion errors for the macros
>>>> in soc.h. Prevent this by only allowing the content in soc.h to be
>>>> included once.
>>>>
>>>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>>>> ---
>>>>
>>>> Please note that I ran into this problem when rebasing my dmtimer fixes
>>>> series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h
>>>> in dmtimer.h and I found several other files including dmtimer.h are also
>>>> including soc.h and so generate a lot of errors.
>>>>
>>>> [1] http://marc.info/?l=linux-omap&m=135231490218361&w=2
>>>
>>> As these headers are private to mach-omap2, I'd rather not allow including
>>> them more than once so we can eventually clean up the includes further.
>>>
>>> We should include the headers directly where used, except for the
>>> legacy board-*.c files that will be going away anyways.
>>>
>>> Including the files directly should fix this easily, if not let me
>>> know.
>>
>> The alternative fix is to ensure anyone including dmtimer.h also
>> includes soc.h. However, I did not know if we should have such a
>> dependency. If you are ok with that then that is what I will do for now.
>> It is not a massive change.
>
> Do you mean anything under mach-omap2/*.c including dmtimer.h also
> needs to also include soc.h? If sounds OK to me as long as we don't
> need to include soc.h outside mach-omap2.
Yes exactly. Right now dmtimer.h is including plat/cpu.h and so is
indirectly including soc.h. The function omap_dm_timer_populate_errata()
is using the cpu_is_xxxx macros. So maybe I should move this to into
platform data. Is that better?
Cheers
Jon
^ permalink raw reply
* [PATCH v2 00/26] Move OMAP2+ over to common clk framework
From: Paul Walmsley @ 2012-11-09 23:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121109221813.17381.31431@nucleus>
On Fri, 9 Nov 2012, Mike Turquette wrote:
> I just did some more testing on your branch and everything looks great.
> The only thing that caught my eye was using the clk-private.h header in
> the top-most patch. The following patch will help me sleep better at
> night:
>
> diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
> index ba4d14c..3848735 100644
> --- a/arch/arm/mach-omap2/clockdomain.c
> +++ b/arch/arm/mach-omap2/clockdomain.c
> @@ -22,7 +22,7 @@
> #include <linux/clk.h>
> #include <linux/limits.h>
> #include <linux/err.h>
> -#include <linux/clk-private.h>
> +#include <linux/clk-provider.h>
>
> #include <linux/io.h>
Just folded this one in, the updated patch follows.
> Tested on 3530 ES3.0 Beagleboard, boot + suspend/resume.
Great!
- Paul
From: Mike Turquette <mturquette@ti.com>
Date: Fri, 9 Nov 2012 11:28:42 -0700
Subject: [PATCH] ARM: OMAP2+: clockdomain: bypass clockdomain handling when
disabling unused clks
The OMAP port to the common clk framework[1] resulted in spurious WARNs
while disable unused clocks. This is due to _clkdm_clk_hwmod_disable
catching clkdm->usecount's with a value of zero. Even less desirable it
would not allow the clkdm_clk_disable function pointer to get called due
to an early return of -ERANGE.
This patch adds a check for such a corner case by skipping the WARN and
early return in the event that clkdm->usecount and clk->enable_usecount
are both zero. Presumably this could only happen during the check for
unused clocks at boot-time.
[1] http://article.gmane.org/gmane.linux.ports.arm.omap/88824
Signed-off-by: Mike Turquette <mturquette@ti.com>
[paul at pwsan.com: split the hwmod and clock disable cases; modified the
code to skip the clockdomain handling during the disable-unused-clocks phase;
added COMMON_CLK ifdef; removed include of clk-private.h at Mike's request]
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/clockdomain.c | 91 ++++++++++++++++++++++---------------
1 file changed, 54 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
index 64e5046..4424f3d 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -22,6 +22,7 @@
#include <linux/clk.h>
#include <linux/limits.h>
#include <linux/err.h>
+#include <linux/clk-provider.h>
#include <linux/io.h>
@@ -947,35 +948,6 @@ static int _clkdm_clk_hwmod_enable(struct clockdomain *clkdm)
return 0;
}
-static int _clkdm_clk_hwmod_disable(struct clockdomain *clkdm)
-{
- unsigned long flags;
-
- if (!clkdm || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
- return -EINVAL;
-
- spin_lock_irqsave(&clkdm->lock, flags);
-
- if (atomic_read(&clkdm->usecount) == 0) {
- spin_unlock_irqrestore(&clkdm->lock, flags);
- WARN_ON(1); /* underflow */
- return -ERANGE;
- }
-
- if (atomic_dec_return(&clkdm->usecount) > 0) {
- spin_unlock_irqrestore(&clkdm->lock, flags);
- return 0;
- }
-
- arch_clkdm->clkdm_clk_disable(clkdm);
- pwrdm_state_switch(clkdm->pwrdm.ptr);
- spin_unlock_irqrestore(&clkdm->lock, flags);
-
- pr_debug("clockdomain: %s: disabled\n", clkdm->name);
-
- return 0;
-}
-
/**
* clkdm_clk_enable - add an enabled downstream clock to this clkdm
* @clkdm: struct clockdomain *
@@ -1018,15 +990,39 @@ int clkdm_clk_enable(struct clockdomain *clkdm, struct clk *clk)
*/
int clkdm_clk_disable(struct clockdomain *clkdm, struct clk *clk)
{
- /*
- * XXX Rewrite this code to maintain a list of enabled
- * downstream clocks for debugging purposes?
- */
+ unsigned long flags;
- if (!clk)
+ if (!clkdm || !clk || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
return -EINVAL;
- return _clkdm_clk_hwmod_disable(clkdm);
+ spin_lock_irqsave(&clkdm->lock, flags);
+
+#ifdef CONFIG_COMMON_CLK
+ /* corner case: disabling unused clocks */
+ if (__clk_get_enable_count(clk) == 0)
+ goto ccd_exit;
+#endif
+
+ if (atomic_read(&clkdm->usecount) == 0) {
+ spin_unlock_irqrestore(&clkdm->lock, flags);
+ WARN_ON(1); /* underflow */
+ return -ERANGE;
+ }
+
+ if (atomic_dec_return(&clkdm->usecount) > 0) {
+ spin_unlock_irqrestore(&clkdm->lock, flags);
+ return 0;
+ }
+
+ arch_clkdm->clkdm_clk_disable(clkdm);
+ pwrdm_state_switch(clkdm->pwrdm.ptr);
+
+ pr_debug("clockdomain: %s: disabled\n", clkdm->name);
+
+ccd_exit:
+ spin_unlock_irqrestore(&clkdm->lock, flags);
+
+ return 0;
}
/**
@@ -1077,6 +1073,8 @@ int clkdm_hwmod_enable(struct clockdomain *clkdm, struct omap_hwmod *oh)
*/
int clkdm_hwmod_disable(struct clockdomain *clkdm, struct omap_hwmod *oh)
{
+ unsigned long flags;
+
/* The clkdm attribute does not exist yet prior OMAP4 */
if (cpu_is_omap24xx() || cpu_is_omap34xx())
return 0;
@@ -1086,9 +1084,28 @@ int clkdm_hwmod_disable(struct clockdomain *clkdm, struct omap_hwmod *oh)
* downstream hwmods for debugging purposes?
*/
- if (!oh)
+ if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
return -EINVAL;
- return _clkdm_clk_hwmod_disable(clkdm);
+ spin_lock_irqsave(&clkdm->lock, flags);
+
+ if (atomic_read(&clkdm->usecount) == 0) {
+ spin_unlock_irqrestore(&clkdm->lock, flags);
+ WARN_ON(1); /* underflow */
+ return -ERANGE;
+ }
+
+ if (atomic_dec_return(&clkdm->usecount) > 0) {
+ spin_unlock_irqrestore(&clkdm->lock, flags);
+ return 0;
+ }
+
+ arch_clkdm->clkdm_clk_disable(clkdm);
+ pwrdm_state_switch(clkdm->pwrdm.ptr);
+ spin_unlock_irqrestore(&clkdm->lock, flags);
+
+ pr_debug("clockdomain: %s: disabled\n", clkdm->name);
+
+ return 0;
}
--
1.7.10.4
^ permalink raw reply related
* OMAP baseline test results for v3.7-rc4
From: Paul Walmsley @ 2012-11-09 23:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87390iicno.fsf@deeprootsystems.com>
On Fri, 9 Nov 2012, Kevin Hilman wrote:
> I found that disabling MMC in the config made the tests pass again, so
> then bisected it down to the commit below removing SYSCONFIG
> accesses[2]. I haven't had the time to find out exactly the cause, but
> clearly the code that was removed was doing something that hwmod is not
> taking care of automatically.
>
> Venkat, Felipe, could you please investigate this and hopefully get a
> fix out for v3.7-rc?
This one might fix it -- it fixes another PM bug in the v3.7-rcs involving
the same commit:
http://git.kernel.org/?p=linux/kernel/git/pjw/omap-pending.git;a=commit;h=613ad0e98c3596cd2524172fae2a795c3fc57e4a
- Paul
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Prevent redefinition errors for soc.h
From: Tony Lindgren @ 2012-11-09 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509D94F7.8010707@ti.com>
* Jon Hunter <jon-hunter@ti.com> [121109 15:44]:
>
> On 11/09/2012 03:10 PM, Tony Lindgren wrote:
> > * Jon Hunter <jon-hunter@ti.com> [121109 08:31]:
> >>
> >> On 11/09/2012 10:22 AM, Tony Lindgren wrote:
> >>> * Jon Hunter <jon-hunter@ti.com> [121109 08:21]:
> >>>> If the header soc.h is included more than once in a source (for example
> >>>> once directly by the source file and once indirectly by another header
> >>>> file), then the compiler will generate redefintion errors for the macros
> >>>> in soc.h. Prevent this by only allowing the content in soc.h to be
> >>>> included once.
> >>>>
> >>>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
> >>>> ---
> >>>>
> >>>> Please note that I ran into this problem when rebasing my dmtimer fixes
> >>>> series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h
> >>>> in dmtimer.h and I found several other files including dmtimer.h are also
> >>>> including soc.h and so generate a lot of errors.
> >>>>
> >>>> [1] http://marc.info/?l=linux-omap&m=135231490218361&w=2
> >>>
> >>> As these headers are private to mach-omap2, I'd rather not allow including
> >>> them more than once so we can eventually clean up the includes further.
> >>>
> >>> We should include the headers directly where used, except for the
> >>> legacy board-*.c files that will be going away anyways.
> >>>
> >>> Including the files directly should fix this easily, if not let me
> >>> know.
> >>
> >> The alternative fix is to ensure anyone including dmtimer.h also
> >> includes soc.h. However, I did not know if we should have such a
> >> dependency. If you are ok with that then that is what I will do for now.
> >> It is not a massive change.
> >
> > Do you mean anything under mach-omap2/*.c including dmtimer.h also
> > needs to also include soc.h? If sounds OK to me as long as we don't
> > need to include soc.h outside mach-omap2.
>
> Yes exactly. Right now dmtimer.h is including plat/cpu.h and so is
> indirectly including soc.h. The function omap_dm_timer_populate_errata()
> is using the cpu_is_xxxx macros. So maybe I should move this to into
> platform data. Is that better?
I think I already fixed that up in the cleanup branch. I've now
merged that into the omap-for-v3.8/dt branch. The only remaining
cpu_is_omap usage there is:
$ grep cpu_is_omap arch/arm/plat-omap/*.[chS]
arch/arm/plat-omap/fb.c: if (cpu_is_omap24xx()) {
arch/arm/plat-omap/fb.c: } else if (cpu_is_omap34xx()) {
So maybe see what needs to be patches on top of omap-for-v3.8/dt?
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Prevent redefinition errors for soc.h
From: Jon Hunter @ 2012-11-09 23:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121109235006.GB6801@atomide.com>
On 11/09/2012 05:50 PM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter@ti.com> [121109 15:44]:
>>
>> On 11/09/2012 03:10 PM, Tony Lindgren wrote:
>>> * Jon Hunter <jon-hunter@ti.com> [121109 08:31]:
>>>>
>>>> On 11/09/2012 10:22 AM, Tony Lindgren wrote:
>>>>> * Jon Hunter <jon-hunter@ti.com> [121109 08:21]:
>>>>>> If the header soc.h is included more than once in a source (for example
>>>>>> once directly by the source file and once indirectly by another header
>>>>>> file), then the compiler will generate redefintion errors for the macros
>>>>>> in soc.h. Prevent this by only allowing the content in soc.h to be
>>>>>> included once.
>>>>>>
>>>>>> Signed-off-by: Jon Hunter <jon-hunter@ti.com>
>>>>>> ---
>>>>>>
>>>>>> Please note that I ran into this problem when rebasing my dmtimer fixes
>>>>>> series [1] on Tony's Linux-OMAP master branch. I am including plat/cpu.h
>>>>>> in dmtimer.h and I found several other files including dmtimer.h are also
>>>>>> including soc.h and so generate a lot of errors.
>>>>>>
>>>>>> [1] http://marc.info/?l=linux-omap&m=135231490218361&w=2
>>>>>
>>>>> As these headers are private to mach-omap2, I'd rather not allow including
>>>>> them more than once so we can eventually clean up the includes further.
>>>>>
>>>>> We should include the headers directly where used, except for the
>>>>> legacy board-*.c files that will be going away anyways.
>>>>>
>>>>> Including the files directly should fix this easily, if not let me
>>>>> know.
>>>>
>>>> The alternative fix is to ensure anyone including dmtimer.h also
>>>> includes soc.h. However, I did not know if we should have such a
>>>> dependency. If you are ok with that then that is what I will do for now.
>>>> It is not a massive change.
>>>
>>> Do you mean anything under mach-omap2/*.c including dmtimer.h also
>>> needs to also include soc.h? If sounds OK to me as long as we don't
>>> need to include soc.h outside mach-omap2.
>>
>> Yes exactly. Right now dmtimer.h is including plat/cpu.h and so is
>> indirectly including soc.h. The function omap_dm_timer_populate_errata()
>> is using the cpu_is_xxxx macros. So maybe I should move this to into
>> platform data. Is that better?
>
> I think I already fixed that up in the cleanup branch. I've now
> merged that into the omap-for-v3.8/dt branch. The only remaining
> cpu_is_omap usage there is:
>
> $ grep cpu_is_omap arch/arm/plat-omap/*.[chS]
>
> arch/arm/plat-omap/fb.c: if (cpu_is_omap24xx()) {
> arch/arm/plat-omap/fb.c: } else if (cpu_is_omap34xx()) {
>
> So maybe see what needs to be patches on top of omap-for-v3.8/dt?
Sorry, I meant in the fixes series I have posted for dmtimer, I am
adding a new function called omap_dm_timer_populate_errata() that is
using cpu_is_xxxx() [1]. I had done this a while back, but now I see
that we want to get away from doing that right?
I was planning on sending you a pull request for that series on Monday
but now I am wondering if I should fix this now or later. I was hoping
this series would make 3.8.
Cheers
Jon
[1] http://marc.info/?l=linux-omap&m=135249008128365&w=2
^ permalink raw reply
* [PATCH] ARM: OMAP2+: Prevent redefinition errors for soc.h
From: Tony Lindgren @ 2012-11-10 0:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <509D9876.9040301@ti.com>
* Jon Hunter <jon-hunter@ti.com> [121109 15:59]:
>
> Sorry, I meant in the fixes series I have posted for dmtimer, I am
> adding a new function called omap_dm_timer_populate_errata() that is
> using cpu_is_xxxx() [1]. I had done this a while back, but now I see
> that we want to get away from doing that right?
Yes. Looks like everything we have under plat-omap can be moved
to live under drivers eventually, so let's not use cpu_is_omap
there either. For legacy boot, you can use pdata->timer_capability
for passing that?
> I was planning on sending you a pull request for that series on Monday
> but now I am wondering if I should fix this now or later. I was hoping
> this series would make 3.8.
Yeah, sounds like that should be fixed though as we still have a bit
of time early next week.
Regards,
Tony
> [1] http://marc.info/?l=linux-omap&m=135249008128365&w=2
^ permalink raw reply
* [RFC] dt/platform: Use cell-index for device naming if available
From: Stepan Moskovchenko @ 2012-11-10 0:48 UTC (permalink / raw)
To: linux-arm-kernel
Use the cell-index property to construct names for platform
devices, falling back on the existing scheme of using the
device register address if cell-index is not specified.
The cell-index property is a more useful device identifier,
especially in systems containing several numbered instances
of a particular hardware block, since it more easily
illustrates how devices relate to each other.
Additionally, userspace software may rely on the classic
<name>.<id> naming scheme to access device attributes in
sysfs, without having to know the physical addresses of
that device on every platform the userspace software may
support. Using cell-index for device naming allows the
device addresses to be hidden from userspace and to be
exposed by logical device number without having to rely on
auxdata to perform name overrides. This allows userspace to
make assumptions about which sysfs nodes map to which
logical instance of a specific hardware block.
Signed-off-by: Stepan Moskovchenko <stepanm@codeaurora.org>
---
I had also considered using something like the linux,label property to allow
custom names for platform devices without resorting to auxdata, but the
cell-index approach seems more in line with what cell-index was intended for
and with what the pre-DT platform device naming scheme used to be. Please let
me know if you think there is a better way to accomplish this.
This is just being sent out as an RFC for now. If there are no objections, I
will send this out as an official patch, along with (or combined with) a patch
to fix up the device names in things like clock tables of any affected
platforms.
drivers/of/platform.c | 13 ++++++++++++-
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 343ad29..472e374 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -77,8 +77,9 @@ void of_device_make_bus_id(struct device *dev)
static atomic_t bus_no_reg_magic;
struct device_node *node = dev->of_node;
const u32 *reg;
+ u32 cell_index;
u64 addr;
- int magic;
+ int magic, ret;
#ifdef CONFIG_PPC_DCR
/*
@@ -101,6 +102,16 @@ void of_device_make_bus_id(struct device *dev)
#endif /* CONFIG_PPC_DCR */
/*
+ * For devices with a specified cell-index, use the traditional
+ * naming scheme of <name>.<id>
+ */
+ ret = of_property_read_u32(node, "cell-index", &cell_index);
+ if (ret == 0) {
+ dev_set_name(dev, "%s.%d", node->name, cell_index);
+ return;
+ }
+
+ /*
* For MMIO, get the physical address
*/
reg = of_get_property(node, "reg", NULL);
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH] CLK: vt8500: Fix SDMMC clk special cases
From: Mike Turquette @ 2012-11-10 0:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350552413-24452-1-git-send-email-linux@prisktech.co.nz>
Quoting Tony Prisk (2012-10-18 02:26:53)
> This patch adds some additional handling for the SDMMC special case
> in round_rate and set_rate which results in invalid divisor messages
> at boot time.
>
> Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Taken into clk-next.
Thanks,
Mike
> ---
> drivers/clk/clk-vt8500.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/clk/clk-vt8500.c b/drivers/clk/clk-vt8500.c
> index a885600..fe25570 100644
> --- a/drivers/clk/clk-vt8500.c
> +++ b/drivers/clk/clk-vt8500.c
> @@ -120,8 +120,17 @@ static unsigned long vt8500_dclk_recalc_rate(struct clk_hw *hw,
> static long vt8500_dclk_round_rate(struct clk_hw *hw, unsigned long rate,
> unsigned long *prate)
> {
> + struct clk_device *cdev = to_clk_device(hw);
> u32 divisor = *prate / rate;
>
> + /*
> + * If this is a request for SDMMC we have to adjust the divisor
> + * when >31 to use the fixed predivisor
> + */
> + if ((cdev->div_mask == 0x3F) && (divisor > 31)) {
> + divisor = 64 * ((divisor / 64) + 1);
> + }
> +
> return *prate / divisor;
> }
>
> @@ -135,6 +144,15 @@ static int vt8500_dclk_set_rate(struct clk_hw *hw, unsigned long rate,
> if (divisor == cdev->div_mask + 1)
> divisor = 0;
>
> + /* SDMMC mask may need to be corrected before testing if its valid */
> + if ((cdev->div_mask == 0x3F) && (divisor > 31)) {
> + /*
> + * Bit 5 is a fixed /64 predivisor. If the requested divisor
> + * is >31 then correct for the fixed divisor being required.
> + */
> + divisor = 0x20 + (divisor / 64);
> + }
> +
> if (divisor > cdev->div_mask) {
> pr_err("%s: invalid divisor for clock\n", __func__);
> return -EINVAL;
> --
> 1.7.9.5
^ permalink raw reply
* [PATCH 0/5] clk: ux500: Add clock lookups for u8500
From: Mike Turquette @ 2012-11-10 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121025075138.GD971@gmail.com>
Quoting Lee Jones (2012-10-25 00:51:38)
> On Mon, 22 Oct 2012, Ulf Hansson wrote:
>
> > From: Ulf Hansson <ulf.hansson@linaro.org>
> >
> > Step by step, clock lookups for u8500 are being added in this set
> > of patches.
> >
> > These patches will require additional patches for sound/soc/ux500/
> > driver as well as drivers/i2c/busses/i2c-nomadik driver to prevent
> > the boot for ux500 from break. Those patches are being merged through
> > separate trees.
> >
> > Ulf Hansson (5):
> > clk: ux500: Register i2c clock lookups for u8500
> > clk: ux500: Register ssp clock lookups for u8500
> > clk: ux500: Register msp clock lookups for u8500
> > clk: ux500: Update rtc clock lookup for u8500
> > clk: ux500: Register slimbus clock lookups for u8500
>
> Acked-by: Lee Jones <lee.jones@linaro.org>
>
> Can I also mention that these need to go into the -rcs at the
> earliest opportunity please, as it is preventing ~50% of the
> devices from functioning on all of the ST-Ericsson development
> boards.
>
> This is a massive blocker for us!
>
I've taken these patches into clk-next. Do you need them in as a late
fix in the 3.7 cycle or is your urgent need only for 3.8 development?
Regards,
Mike
> --
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox