Re: [PATCH 2/2] arm: dts: add support for AM437x StarterKit
* Felipe Balbi ba...@ti.com [140613 09:33]:
On Fri, Jun 13, 2014 at 11:23:34AM -0500, Felipe Balbi wrote:
On Fri, Jun 13, 2014 at 11:15:47AM -0500, Felipe Balbi wrote:
--- /dev/null
+++ b/arch/arm/boot/dts/am437x-sk-evm.dts
@@ -0,0 +1,539 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+/* AM437x SK EVM */
+
+/dts-v1/;
+
+#include am4372.dtsi
+#include dt-bindings/pinctrl/am43xx.h
+#include dt-bindings/pwm/pwm.h
+#include dt-bindings/gpio/gpio.h
+#include dt-bindings/input/input.h
+
+/ {
+ model = TI AM437x SK EVM;
+ compatible = ti,am437x-sk-evm,ti,am4372,ti,am43;
+
+ aliases {
+ display0 = lcd0;
+ };
+
+ vmmcsd_fixed: fixedregulator-sd {
+ compatible = regulator-fixed;
+ regulator-name = vmmcsd_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ enable-active-high;
+ };
+
+ v33_fixed: fixedregulator-v33 {
+ compatible = regulator-fixed;
+ regulator-name = v33_fixed;
+ regulator-min-microvolt = 330;
+ regulator-max-microvolt = 330;
+ enable-active-high;
+ };
+
+ v18_fixed: fixedregulator-v18 {
+ compatible = regulator-fixed;
+ regulator-name = v18_fixed;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ enable-active-high;
+ };
Chances are these are not fixed regulators.. Typically the these
come from external regulators controlled by GPIO pins. Sounds
like you have the schematics so it would be best to verify it.
If they come from something not yet supported, let's at least
document it with comments.
Also looks like all the am43xx boards are using vmmcsd_fixed,
might be worth checking those as well while at it.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: hwmod code and data changes for early v3.16-rc
* Paul Walmsley p...@pwsan.com [140615 20:19]: Hi Tony, The following changes since commit abf04af74a9f27a65172a43b43ccabcbc2bbdc39: Merge tag 'scsi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi (2014-06-14 19:49:48 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.16-rc/omap-fixes-a for you to fetch changes up to bf32c4ad9924e2d60a23de4a3c074f806bf2ef05: ARM: OMAP5: hwmod: Add ocp2scp3 and sata hwmods (2014-06-15 20:12:52 -0600) Two OMAP hwmod patches for early v3.16-rc kernels. There's one OMAP SoC integration fix for the AM43xx SoC, without which, IP blocks can't be placed into hard-reset. There is also one OMAP5 SoC data addition patch that should have gone in for v3.16. Normally I wouldn't send this as part of an -rc series, since it's not technically a fix. But I'd like to make an exception in this case because: - it's intended to go in very early in the v3.16-rc series (or even pre-rc1); - it's a fairly small change; - the impact is limited to a single SoC and a single device; - the only reason that it didn't go in earlier is because it slipped through the cracks, rather than for any technical reason. Basic build, boot, and PM test logs are available here: http://www.pwsan.com/omap/testlogs/hwmod-a-v3.16-rc/20140615201307/ Thanks, pulling into omap-for-v3.16/fixes. BTW, starting with -rc2 your off-idle tests should finally start working for some DT based boards. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data
* Felipe Balbi ba...@ti.com [140613 09:17]:
From: Sathya Prakash M R sath...@ti.com
Add DSS hwmod data for AM43xx.
Cc: Andrew Morton a...@linux-foundation.org
Acked-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Sathya Prakash M R sath...@ti.com
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
Note that this patch was originally send on May 9th [1], changes were
requested
and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged
maintainer again and go no response.
Without this patch, we cannot get display working on any AM437x devices.
[1] http://marc.info/?l=linux-arm-kernelm=139963677925227w=2
[2] http://marc.info/?l=linux-arm-kernelm=140049799425512w=2
[3] http://marc.info/?l=linux-arm-kernelm=140117232826754w=2
arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98
++
arch/arm/mach-omap2/prcm43xx.h | 1 +
2 files changed, 99 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 5c2cc80..d2a7b6d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -19,6 +19,8 @@
#include omap_hwmod.h
#include omap_hwmod_33xx_43xx_common_data.h
#include prcm43xx.h
+#include omap_hwmod_common_data.h
+
/* IP blocks */
static struct omap_hwmod am43xx_l4_hs_hwmod = {
@@ -415,6 +417,70 @@ static struct omap_hwmod am43xx_qspi_hwmod = {
},
};
+/* Display sub system - DSS */
+
+struct omap_dss_dispc_dev_attr am43xx_dss_dispc_dev_attr = {
+ .manager_count = 1,
+ .has_framedonetv_irq= 0
+};
+
+
+static struct omap_hwmod_class_sysconfig am43xx_dispc_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_SIDLEMODE | SYSC_HAS_MIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
Looking at the TRM, Table 13-43. DISPC_SYSCFG Register Field
Descriptions seems to list the folowing bits available:
13-12 MIDLEMODE
9-8 CLOCK_ACTIVITY
4-3 SIDLEMODE
2 ENWAKEUP
1 SOFTRESET
0 AUTOIDLE
Have I missed something or how come we don't define them all
as available?
The .idlemodes available values and .sysc_fields seems to match
the TRM.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v14 0/6] mmc: omap_hsmmc: Enable SDIO IRQ
On 29 May 2014 10:27, Andreas Fenkart afenk...@gmail.com wrote:
Hi Balaji, Tony, Ulf, all
v14
- drop all ifdef/endif introduced by v13
-- rely on pinctrl_lookup_state to prevent ifdef CONFIG_PM
-- benefit: all code is compile tested no matter the configuration
-- drawback: require wake_irq/pinctrl configuration even when
runtime suspend is not configured
- drop runtime state from debugfs output
- rebased onto current mmc-next 06732b84b4cf
Thanks! Applied for next.
Kind regards
Ulf Hansson
v13
- fix compile breaks if !CONFIG_PM
- additional patch: install dummy pm runtime hooks if !CONFIG_PM_RUNTIME
v12
- drop !CONFIG_OF compile break only exists when
#undef CONFIG_OF after include headers 1/7(Sebastian Reichel)
- do not emit falling back to polling if wake_irq not specified
since MMC does not need it, and it might confuse users
only emit if pinmux default/idle is not present or claiming
the irq failed 2/7(Balaji)
- dropped out-of-tree patches 6/7(Balaji)
- mention ti,am33xx-hsmmc compatible section in bindings
documentation 1/5
v11
- split !CONFIG_OF compile break into separate patch
- enable IWE/CLKEXTFREE in CON/HCTL register needed for omap4
- '' vs '' in omap_hsmmc_resume, 1/5 (Andreas Müller)
- #define DLEV_DAT instead of BIT(21) 2/5 (Balaji)
- pinctrl_pm_select_default_state() removed, 4/5 (Balaji)
- drop _irqsave/_irqrestore from omap_hsmmc_wake_irq handler since it
can't be preempted by same priority omap_hsmmc_irq handler 1/5(Joel
Fernandes)
- replace devres_open_group by explicit devm_free calls 1/5 (Balaji)
- disable_irq_nosync wake_irq since we handle it thread safe 1/5 (Balaji)
- drop 'gpio_dat1' pinctrl states and rework documentation 5/5 (Balaji)
v10
- bug fix on multi-core, untested
- incorporated changes from Balaji
- use devres / RAII mechanism to configure wake_up /
sdio irq capabilities
- drop pinctrl state 'active'
rely on driver-model states 'default', 'idle'
- add specific 'gpio_dat1' state for am335x SWAKEUP hack
- reorganized patches; +1 patch multi-core bugfix / +1 for pinctrl
- rebased 455c6fdbd21916 / cherry-picks from mmc-next
v9
- extended comment about why wake-irq is needed
- drop double '(' ')' around card_detect_irq
- drop final '.' in in subject line of patch
v8
- rebased on top of Tony Lindgrent...@atomide.com changes
- improved changelog describing the earlier work
- improved wakeup irq setup
- works for am3730 es platform now
- my changes on top:
- compile tested with #undef CONFIG_OF
- disable wake_irq in handler to prevent infinite loop
- fixed typo and added comment about wake-irq
v7
- rebase on 3.14.0-rc3-49726-g77e15ec
- split omap_hsmmc_pin_init due to regression on omap-3730 platform
v6
- rebase on Linux 3.13-rc3
- reformatting debugfs
v5
- fix compile error introduced by last minute one line fix
v4:
- switch to interrupts-extended format
- drop ti,swakeup-missing flag convert to comaptible section
v3:
- removed gpio_irq from platform_data
v2:
- incorparated changes as suggested by reviewers
- simplified workaround for am335x, gpio will now only wake
the module from runtime suspend, not handle the sdio irq
itself
Andreas Fenkart (6):
mmc: omap_hsmmc: Enable SDIO interrupt
mmc: omap_hsmmc: Extend debugfs by SDIO IRQ handling, runtime state
mmc: omap_hsmmc: enable wakeup event for sdio OMAP4
mmc: omap_hsmmc: abort runtime suspend if pending sdio irq detected
mmc: omap_hsmmc: switch default/idle pinctrl states in runtime hooks
mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on
AM335x
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 54
drivers/mmc/host/omap_hsmmc.c | 283
++--
include/linux/platform_data/mmc-omap.h |1 +
3 files changed, 317 insertions(+), 21 deletions(-)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/14] ARM: omap2: fix am43xx dependency on l2x0 cache
* Arnd Bergmann a...@arndb.de [140613 09:02]: Commit d941f86fad41b (ARM: l2c: AM43x: add L2 cache support) enabled the L2 cache support for the am43xx SoC, but caused a build regression when the driver for that cache controller is disabled: arch/arm/mach-omap2/built-in.o: In function `am43xx_init_early': :(.init.text+0xb20): undefined reference to `omap_l2_cache_init' This did not happen for OMAP4, which has the same call, but enables the l2x0 driver unconditionally. We could do the same thing for am43xx, but it seems better to allow turning it off and make the code work in either case. This adds an inline wrapper for omap_l2_cache_init for the disabled case, and removes the 'select' from OMAP4 so it becomes a user visible option. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: linux-omap@vger.kernel.org Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: omap: rework platform selection
Commit 9851b662f659 (ARM: use menuconfig for sub-arch menus) did more than expected, which led to two OMAP specific bugs: * Turning CONFIG_ARCH_OMAP into a user-selectable option makes it possible to have a configuration with ARCH_OMAP enabled but none of the specific OMAP SoCs enabled, which triggers a couple of link errors due to the layout of the Makefile * The plat-omap menu still appears mixed into the normal menuconfig list, which is confusing and inconsistent. To make matters worse, the change did not enable CONFIG_ARCH_OMAP in the defconfig files, which through some ripple effects disabled options that were implicitly enabled from OMAP2, and that caused all machines to fail booting with the unchanged config files. This reorders the OMAP Kconfig files some more, to be consistent with the others, and also changes the defconfig files. Signed-off-by: Arnd Bergmann a...@arndb.de --- Tony, can you have a look at this please? I'd like to send out the fixes for 3.16, but this is needed on top of Rob's Kconfig changes. diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 245058b..fcf6ddf 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -973,10 +973,6 @@ source arch/arm/mach-nspire/Kconfig source arch/arm/plat-omap/Kconfig -source arch/arm/mach-omap1/Kconfig - -source arch/arm/mach-omap2/Kconfig - source arch/arm/mach-orion5x/Kconfig source arch/arm/mach-picoxcell/Kconfig diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index e2d6204..d77bb9e 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -23,6 +23,7 @@ CONFIG_ARCH_BERLIN=y CONFIG_MACH_BERLIN_BG2=y CONFIG_MACH_BERLIN_BG2CD=y CONFIG_MACH_BERLIN_BG2Q=y +CONFIG_ARCH_OMAP_ENABLE=y CONFIG_ARCH_HIGHBANK=y CONFIG_ARCH_HI3xxx=y CONFIG_ARCH_KEYSTONE=y diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index 536a137..85de0a1 100644 --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -25,6 +25,7 @@ CONFIG_POWER_AVS_OMAP=y CONFIG_POWER_AVS_OMAP_CLASS3=y CONFIG_OMAP_RESET_CLOCKS=y CONFIG_OMAP_MUX_DEBUG=y +CONFIG_ARCH_OMAP_ENABLE=y CONFIG_ARCH_OMAP2=y CONFIG_ARCH_OMAP3=y CONFIG_ARCH_OMAP4=y diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig index cdd05f2..53a802c 100644 --- a/arch/arm/mach-omap1/Kconfig +++ b/arch/arm/mach-omap1/Kconfig @@ -1,8 +1,6 @@ if ARCH_OMAP1 -menu TI OMAP1 specific features - -comment OMAP Core Type +comment OMAP1 Core Type depends on ARCH_OMAP1 config ARCH_OMAP730 @@ -164,6 +162,4 @@ config MACH_OMAP_GENERIC custom OMAP boards. Say Y here if you have a custom board. -endmenu - endif diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 4e81860..0006012 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -1,7 +1,5 @@ -menuconfig ARCH_OMAP - bool TI OMAP/AM/DRA Based if (ARCH_MULTI_V6 || ARCH_MULTI_V7) - -if ARCH_OMAP +config ARCH_OMAP + bool config ARCH_OMAP2 bool TI OMAP2 @@ -82,6 +80,7 @@ config ARCH_OMAP2PLUS bool select ARCH_HAS_BANDGAP select ARCH_HAS_HOLES_MEMORYMODEL + select ARCH_OMAP select ARCH_REQUIRE_GPIOLIB select CLKSRC_MMIO select GENERIC_IRQ_CHIP @@ -342,5 +341,3 @@ config OMAP4_ERRATA_I688 endmenu endif - -endif diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig index 02fc10d..8aa2dd2 100644 --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -1,6 +1,11 @@ -if ARCH_OMAP +menuconfig ARCH_OMAP_ENABLE + bool TI OMAP platforms if ARCH_MULTI_V6 || ARCH_MULTI_V7 + default ARCH_OMAP1 -menu TI OMAP Common Features +if ARCH_OMAP_ENABLE + +source arch/arm/mach-omap1/Kconfig +source arch/arm/mach-omap2/Kconfig config ARCH_OMAP_OTG bool @@ -153,6 +158,4 @@ config OMAP_PM_NOOP endchoice -endmenu - endif -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] mfd: Immutable branch between MFD and OMAP, due for v3.16
Still not seeing this branch being merged.. Oh crap, I see what's happened and it's completely my fault. If you read the final merge commit carefully: 28fee3f: (Merge branches 'ib-from-asoc-3.16', 'ib-from-pm-3.16', 'ib-from-regulator-3.16', 'ib-mfd-gpio-3.16' and 'ib-mfd-mmc-memstick-3.16', tags 'ib-mfd-extcon-3.16', 'ib-mfd-omap-3.16' and 'ib-mfd-regulator-3.16' into ibs-for-mfd-merged) I appear to have a _branch_ AND a _tag_ called ib-mfd-omap-3.16 and it looks like Git has taken the tag as a preference. heads/ib-mfd-omap-3.16 is actually at tag/ib-mfd-omap-3.16-1 (notice the appended '-1'), which contains your most recent patches. Since I created the MFD-OMAP shared branch I have changed the naming convention to avoid this sort of ambiguity. I'll send a second MFD pull-request to Linus today. Heh OK yeah I've hit that also at some point :) Sorry Tony. No problem, good to hear you got it figured out. Pull-request sent. Hopefully it's sorted now. bae14e7a2dcb726476b5020396923a24ccc4c40b -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] mfd: Immutable branch between MFD and OMAP, due for v3.16
* Lee Jones lee.jo...@linaro.org [140616 03:19]: Still not seeing this branch being merged.. Oh crap, I see what's happened and it's completely my fault. If you read the final merge commit carefully: 28fee3f: (Merge branches 'ib-from-asoc-3.16', 'ib-from-pm-3.16', 'ib-from-regulator-3.16', 'ib-mfd-gpio-3.16' and 'ib-mfd-mmc-memstick-3.16', tags 'ib-mfd-extcon-3.16', 'ib-mfd-omap-3.16' and 'ib-mfd-regulator-3.16' into ibs-for-mfd-merged) I appear to have a _branch_ AND a _tag_ called ib-mfd-omap-3.16 and it looks like Git has taken the tag as a preference. heads/ib-mfd-omap-3.16 is actually at tag/ib-mfd-omap-3.16-1 (notice the appended '-1'), which contains your most recent patches. Since I created the MFD-OMAP shared branch I have changed the naming convention to avoid this sort of ambiguity. I'll send a second MFD pull-request to Linus today. Heh OK yeah I've hit that also at some point :) Sorry Tony. No problem, good to hear you got it figured out. Pull-request sent. Hopefully it's sorted now. bae14e7a2dcb726476b5020396923a24ccc4c40b Yes saw that thanks, omap PM tests are now working for me with v3.16-rc1. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Resend/PATCH] arm: dts: dra7: Add qspi device.
* Nishanth Menon n...@ti.com [140530 06:19]: On 05/30/2014 06:34 AM, Sricharan R wrote: Hi, On Tuesday 06 May 2014 10:22 PM, Tony Lindgren wrote: * Sourav Poddar sourav.pod...@ti.com [140506 04:08]: These add device tree entry for qspi controller driver on dra7-evm. Thanks applying into omap-for-v3.16/dt. There is a problem with this. The qspi node defines crossbar number as its interrupt number. Since the crossbar dts patches are not yet there, this causes a warning during boot. So interrupts = property should be removed from DT and added later by crossbar series. https://github.com/nmenon/kernel-test-logs/blob/next-20140530/omap2plus_defconfig/dra7.txt#L151 as an indication of the warning. Tony, Would you prefer a patch on top of omap-for-v3.16/dt-v2 branch? Sorting through my mailbox.. If this is still an issue a fix against v3.16-rc1 please. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap: rework platform selection
* Arnd Bergmann a...@arndb.de [140616 03:06]: Commit 9851b662f659 (ARM: use menuconfig for sub-arch menus) did more than expected, which led to two OMAP specific bugs: It seems the commit above is not -rc cycle material at least not without proper testing. There's a good chance of breaking a lot of the existing .config files which can create a big mess as we've seen before. * Turning CONFIG_ARCH_OMAP into a user-selectable option makes it possible to have a configuration with ARCH_OMAP enabled but none of the specific OMAP SoCs enabled, which triggers a couple of link errors due to the layout of the Makefile And so we have a regression to this old problem again :( * The plat-omap menu still appears mixed into the normal menuconfig list, which is confusing and inconsistent. That we should be able to remove completely soon but that's a separate patch.. To make matters worse, the change did not enable CONFIG_ARCH_OMAP in the defconfig files, which through some ripple effects disabled options that were implicitly enabled from OMAP2, and that caused all machines to fail booting with the unchanged config files. This reorders the OMAP Kconfig files some more, to be consistent with the others, and also changes the defconfig files. Signed-off-by: Arnd Bergmann a...@arndb.de --- Tony, can you have a look at this please? I'd like to send out the fixes for 3.16, but this is needed on top of Rob's Kconfig changes. Hmm why is this patch already in linux next before getting posted to the mailing lists? --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -1,6 +1,11 @@ -if ARCH_OMAP +menuconfig ARCH_OMAP_ENABLE + bool TI OMAP platforms if ARCH_MULTI_V6 || ARCH_MULTI_V7 + default ARCH_OMAP1 -menu TI OMAP Common Features +if ARCH_OMAP_ENABLE + +source arch/arm/mach-omap1/Kconfig +source arch/arm/mach-omap2/Kconfig It seems to me this kind of change is going to break all the existing .config files unless they are manually updated. This includes all the distros and automated build systems. I'll look more at it, but my initial take is that we should be able to do this all with CONFIG_ARCH_OMAP + the selected OMAP SoC and should not introduce any new Kconfig options. For now I'd just leave out Rob's changed and this patch from fixes until they have been properly tested. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap: rework platform selection
On Monday 16 June 2014 04:00:42 Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [140616 03:06]: Commit 9851b662f659 (ARM: use menuconfig for sub-arch menus) did more than expected, which led to two OMAP specific bugs: It seems the commit above is not -rc cycle material at least not without proper testing. There's a good chance of breaking a lot of the existing .config files which can create a big mess as we've seen before. Well, Kconfig is a big mess without it at the moment. The OMAP change was definitely wrong there, but for all other platforms I don't see any risk in applying it, because there is no semantic change, only cosmetic. * Turning CONFIG_ARCH_OMAP into a user-selectable option makes it possible to have a configuration with ARCH_OMAP enabled but none of the specific OMAP SoCs enabled, which triggers a couple of link errors due to the layout of the Makefile And so we have a regression to this old problem again :( Yes, I didn't actually see this happen but from looking at the patch, I concluded that it would likely be the case. * The plat-omap menu still appears mixed into the normal menuconfig list, which is confusing and inconsistent. That we should be able to remove completely soon but that's a separate patch.. Ok. To make matters worse, the change did not enable CONFIG_ARCH_OMAP in the defconfig files, which through some ripple effects disabled options that were implicitly enabled from OMAP2, and that caused all machines to fail booting with the unchanged config files. This reorders the OMAP Kconfig files some more, to be consistent with the others, and also changes the defconfig files. Signed-off-by: Arnd Bergmann a...@arndb.de --- Tony, can you have a look at this please? I'd like to send out the fixes for 3.16, but this is needed on top of Rob's Kconfig changes. Hmm why is this patch already in linux next before getting posted to the mailing lists? I had applied Rob's patch to the fixes series but that broke all multi_v7_defconfig runs on the boot test machines. I didn't want to spend too much work on it over the weekend, but applied it so at least today's linux-next wouldn't regress over last week's. --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -1,6 +1,11 @@ -if ARCH_OMAP +menuconfig ARCH_OMAP_ENABLE + bool TI OMAP platforms if ARCH_MULTI_V6 || ARCH_MULTI_V7 + default ARCH_OMAP1 -menu TI OMAP Common Features +if ARCH_OMAP_ENABLE + +source arch/arm/mach-omap1/Kconfig +source arch/arm/mach-omap2/Kconfig It seems to me this kind of change is going to break all the existing .config files unless they are manually updated. This includes all the distros and automated build systems. I'll look more at it, but my initial take is that we should be able to do this all with CONFIG_ARCH_OMAP + the selected OMAP SoC and should not introduce any new Kconfig options. For now I'd just leave out Rob's changed and this patch from fixes until they have been properly tested. Let's see if others have similar opinions Rob's patch as a whole. I'd still like to keep all the parts aside from the OMAP change and just back out the change that caused the problems. Does that seem reasonable to you? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 00/16] irqchip: crossbar: driver fixes
This series does some cleanups, fixes for handling two interrupts getting mapped twice to same crossbar and provides support for hardwired IRQ and crossbar definitions. On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10, 131, 132, 133 are direct wired to hardware blocks bypassing crossbar. This quirky implementation is *NOT* supposed to be the expectation of crossbar hardware usage. This series adds support to represent such hard-wired irqs through DT and avoid generic allocation/programming of crossbar in the driver. This way of supporting hard-wired irqs was a result of the below discussions. http://www.spinics.net/lists/arm-kernel/msg329946.html Based on 3.15 mainline. All the patches are available here g...@github.com:Sricharanti/sricharan.git crossbar_updates The fixes series[1] earlier posted is merged in to this. [1] http://www.spinics.net/lists/arm-kernel/msg328273.html [V2] Merged the above series and rebased on 3.15 mainline [V3] Modified patch#3 to get irqs-skip properties from DT, merged path#8 for checkpatch warning to other relevant patches and fixed comments for other patches. Nishanth Menon (14): irqchip: crossbar: dont use '0' to mark reserved interrupts irqchip: crossbar: check for premapped crossbar before allocating irqchip: crossbar: introduce ti,irqs-skip to skip irqchip: crossbar: initialise the crossbar with a safe value irqchip: crossbar: change allocation logic by reversing search for free irqs irqchip: crossbar: remove IS_ERR_VALUE check irqchip: crossbar: fix sparse and checkpatch warnings irqchip: crossbar: fix kerneldoc warning irqchip: crossbar: return proper error value irqchip: crossbar: change the goto naming irqchip: crossbar: introduce ti,max-crossbar-sources to identify valid crossbar mapping irqchip: crossbar: introduce centralized check for crossbar write documentation: dt: omap: crossbar: add description for interrupt consumer irqchip: crossbar: allow for quirky hardware with direct hardwiring of GIC Sricharan R (2): irqchip: crossbar: set cb pointer to null in case of error irqchip: crossbar: add kerneldoc for crossbar_domain_unmap callback .../devicetree/bindings/arm/omap/crossbar.txt | 34 drivers/irqchip/irq-crossbar.c | 168 +--- 2 files changed, 177 insertions(+), 25 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 15/16] documentation: dt: omap: crossbar: add description for interrupt consumer
From: Nishanth Menon n...@ti.com
The current crossbar description does not include the description
required for the consumer of the crossbar, a.k.a devices whoes events
pass through the crossbar into the GIC interrupt controller.
So, provide documentation for the same.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
.../devicetree/bindings/arm/omap/crossbar.txt | 17 +
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
index 41aef44..8210ea4 100644
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -34,3 +34,20 @@ Examples:
ti,reg-size = 2;
ti,irqs-reserved = 0 1 2 3 5 6 131 132 139 140;
};
+
+Consumer:
+
+See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt and
+Documentation/devicetree/bindings/arm/gic.txt for further details.
+
+An interrupt consumer on an SoC using crossbar will use:
+ interrupts = GIC_SPI request_number interrupt_level
+request number shall be between 0 to that described by
+ti,max-crossbar-sources
+
+Example:
+ device_x@0x4a023000 {
+ /* Crossbar 8 used */
+ interrupts = GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH;
+ ...
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 16/16] irqchip: crossbar: allow for quirky hardware with direct hardwiring of GIC
From: Nishanth Menon n...@ti.com
On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10, 131,
132, 133 are direct wired to hardware blocks bypassing crossbar.
This quirky implementation is *NOT* supposed to be the expectation
of crossbar hardware usage. However, these are already marked in our
description of the hardware with SKIP and RESERVED where appropriate.
Unfortunately, we need to be able to refer to these hardwired IRQs.
So, to request these, crossbar driver can use the existing information
from it's table that these SKIP/RESERVED maps are direct wired sources
and generic allocation/programming of crossbar should be avoided.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
.../devicetree/bindings/arm/omap/crossbar.txt | 12 ++--
drivers/irqchip/irq-crossbar.c | 20 ++--
2 files changed, 28 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
index 8210ea4..438ccab 100644
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -42,8 +42,10 @@ Documentation/devicetree/bindings/arm/gic.txt for further
details.
An interrupt consumer on an SoC using crossbar will use:
interrupts = GIC_SPI request_number interrupt_level
-request number shall be between 0 to that described by
-ti,max-crossbar-sources
+When the request number is between 0 to that described by
+ti,max-crossbar-sources, it is assumed to be a crossbar mapping. If the
+request_number is greater than ti,max-crossbar-sources, then it is mapped as
a
+quirky hardware mapping direct to GIC.
Example:
device_x@0x4a023000 {
@@ -51,3 +53,9 @@ Example:
interrupts = GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH;
...
};
+
+ device_y@0x4a033000 {
+ /* Direct mapped GIC SPI 1 used */
+ interrupts = GIC_SPI 401 IRQ_TYPE_LEVEL_HIGH;
+ ...
+ };
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index ef613c4..fff6218 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -86,8 +86,13 @@ static inline int allocate_free_irq(int cb_no)
static inline bool needs_crossbar_write(irq_hw_number_t hw)
{
- if (hw GIC_IRQ_START)
- return true;
+ int cb_no;
+
+ if (hw GIC_IRQ_START) {
+ cb_no = cb-irq_map[hw - GIC_IRQ_START];
+ if (cb_no != IRQ_RESERVED cb_no != IRQ_SKIP)
+ return true;
+ }
return false;
}
@@ -130,8 +135,19 @@ static int crossbar_domain_xlate(struct irq_domain *d,
{
int ret;
int req_num = intspec[1];
+ int direct_map_num;
if (req_num = cb-max_crossbar_sources) {
+ direct_map_num = req_num - cb-max_crossbar_sources;
+ if (direct_map_num cb-int_max) {
+ ret = cb-irq_map[direct_map_num];
+ if (ret == IRQ_RESERVED || ret == IRQ_SKIP) {
+ /* We use the interrupt num as h/w irq num */
+ ret = direct_map_num;
+ goto found;
+ }
+ }
+
pr_err(%s: requested crossbar number %d max %d\n,
__func__, req_num, cb-max_crossbar_sources);
return -EINVAL;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 11/16] irqchip: crossbar: set cb pointer to null in case of error
If crossbar_of_init returns with a error, then set the cb pointer to null. Signed-off-by: Sricharan R r.sricha...@ti.com --- drivers/irqchip/irq-crossbar.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c index 5bd7f3d..9b4c0f1 100644 --- a/drivers/irqchip/irq-crossbar.c +++ b/drivers/irqchip/irq-crossbar.c @@ -250,6 +250,8 @@ err_base: iounmap(cb-crossbar_base); err_cb: kfree(cb); + + cb = NULL; return ret; } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 13/16] irqchip: crossbar: introduce ti,max-crossbar-sources to identify valid crossbar mapping
From: Nishanth Menon n...@ti.com
Currently we attempt to map any crossbar value to an IRQ, however,
this is not correct from hardware perspective. There is a max crossbar
event number upto which hardware supports. So describe the same in
device tree using 'ti,max-crossbar-sources' property and use it to
validate requests.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
.../devicetree/bindings/arm/omap/crossbar.txt |2 ++
drivers/irqchip/irq-crossbar.c | 21 ++--
2 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
index e54d1fb..41aef44 100644
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -10,6 +10,7 @@ Required properties:
- compatible : Should be ti,irq-crossbar
- reg: Base address and the size of the crossbar registers.
- ti,max-irqs: Total number of irqs available at the interrupt controller.
+- ti,max-crossbar-sources: Maximum number of crossbar sources that can be
routed.
- ti,reg-size: Size of a individual register in bytes. Every individual
register is assumed to be of same size. Valid sizes are 1, 2, 4.
- ti,irqs-reserved: List of the reserved irq lines that are not muxed using
@@ -29,6 +30,7 @@ Examples:
compatible = ti,irq-crossbar;
reg = 0x4a002a48 0x130;
ti,max-irqs = 160;
+ ti,max-crossbar-sources = 400;
ti,reg-size = 2;
ti,irqs-reserved = 0 1 2 3 5 6 131 132 139 140;
};
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index df16ef8..c46e14b 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -26,6 +26,7 @@
* struct crossbar_device - crossbar device description
* @int_max: maximum number of supported interrupts
* @safe_map: safe default value to initialize the crossbar
+ * @max_crossbar_sources: Maximum number of crossbar sources
* @irq_map: array of interrupts to crossbar number mapping
* @crossbar_base: crossbar base address
* @register_offsets: offsets for each irq number
@@ -34,6 +35,7 @@
struct crossbar_device {
uint int_max;
uint safe_map;
+ uint max_crossbar_sources;
uint *irq_map;
void __iomem *crossbar_base;
int *register_offsets;
@@ -117,12 +119,19 @@ static int crossbar_domain_xlate(struct irq_domain *d,
unsigned int *out_type)
{
int ret;
+ int req_num = intspec[1];
- ret = get_prev_map_irq(intspec[1]);
+ if (req_num = cb-max_crossbar_sources) {
+ pr_err(%s: requested crossbar number %d max %d\n,
+ __func__, req_num, cb-max_crossbar_sources);
+ return -EINVAL;
+ }
+
+ ret = get_prev_map_irq(req_num);
if (ret = 0)
goto found;
- ret = allocate_free_irq(intspec[1]);
+ ret = allocate_free_irq(req_num);
if (ret 0)
return ret;
@@ -153,6 +162,14 @@ static int __init crossbar_of_init(struct device_node
*node)
if (!cb-crossbar_base)
goto err_cb;
+ of_property_read_u32(node, ti,max-crossbar-sources,
+cb-max_crossbar_sources);
+ if (!cb-max_crossbar_sources) {
+ pr_err(missing 'ti,max-crossbar-sources' property\n);
+ ret = -EINVAL;
+ goto err_base;
+ }
+
of_property_read_u32(node, ti,max-irqs, max);
if (!max) {
pr_err(missing 'ti,max-irqs' property\n);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 14/16] irqchip: crossbar: introduce centralized check for crossbar write
From: Nishanth Menon n...@ti.com
This is a basic check to ensure that crossbar register needs to be
written. This ensures that we have a common check which is used in
both map and unmap logic.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
drivers/irqchip/irq-crossbar.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index c46e14b..ef613c4 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -84,10 +84,20 @@ static inline int allocate_free_irq(int cb_no)
return -ENODEV;
}
+static inline bool needs_crossbar_write(irq_hw_number_t hw)
+{
+ if (hw GIC_IRQ_START)
+ return true;
+
+ return false;
+}
+
static int crossbar_domain_map(struct irq_domain *d, unsigned int irq,
irq_hw_number_t hw)
{
- cb-write(hw - GIC_IRQ_START, cb-irq_map[hw - GIC_IRQ_START]);
+ if (needs_crossbar_write(hw))
+ cb-write(hw - GIC_IRQ_START, cb-irq_map[hw - GIC_IRQ_START]);
+
return 0;
}
@@ -106,7 +116,7 @@ static void crossbar_domain_unmap(struct irq_domain *d,
unsigned int irq)
{
irq_hw_number_t hw = irq_get_irq_data(irq)-hwirq;
- if (hw GIC_IRQ_START) {
+ if (needs_crossbar_write(hw)) {
cb-irq_map[hw - GIC_IRQ_START] = IRQ_FREE;
cb-write(hw - GIC_IRQ_START, cb-safe_map);
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 09/16] irqchip: crossbar: return proper error value
From: Nishanth Menon n...@ti.com
crossbar_of_init always returns -ENOMEM in case of errors.
There can be other causes of failure like invalid data from
DT. So return a appropriate error value for that case.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V3] Changed commit log
drivers/irqchip/irq-crossbar.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 6eee61b..5bcedc0 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -129,19 +129,25 @@ static const struct irq_domain_ops
routable_irq_domain_ops = {
static int __init crossbar_of_init(struct device_node *node)
{
- int i, size, max, reserved = 0, entry;
+ int i, size, max = 0, reserved = 0, entry;
const __be32 *irqsr;
+ int ret = -ENOMEM;
cb = kzalloc(sizeof(*cb), GFP_KERNEL);
if (!cb)
- return -ENOMEM;
+ return ret;
cb-crossbar_base = of_iomap(node, 0);
if (!cb-crossbar_base)
goto err1;
of_property_read_u32(node, ti,max-irqs, max);
+ if (!max) {
+ pr_err(missing 'ti,max-irqs' property\n);
+ ret = -EINVAL;
+ goto err2;
+ }
cb-irq_map = kcalloc(max, sizeof(int), GFP_KERNEL);
if (!cb-irq_map)
goto err2;
@@ -162,6 +168,7 @@ static int __init crossbar_of_init(struct device_node *node)
i, entry);
if (entry max) {
pr_err(Invalid reserved entry\n);
+ ret = -EINVAL;
goto err3;
}
cb-irq_map[entry] = IRQ_RESERVED;
@@ -205,6 +212,7 @@ static int __init crossbar_of_init(struct device_node *node)
break;
default:
pr_err(Invalid reg-size property\n);
+ ret = -EINVAL;
goto err4;
break;
}
@@ -243,7 +251,7 @@ err2:
iounmap(cb-crossbar_base);
err1:
kfree(cb);
- return -ENOMEM;
+ return ret;
}
static const struct of_device_id crossbar_match[] __initconst = {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 12/16] irqchip: crossbar: add kerneldoc for crossbar_domain_unmap callback
Adding kerneldoc for unmap callback function.
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V3] Reworded the kerneldoc
drivers/irqchip/irq-crossbar.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 9b4c0f1..df16ef8 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -89,6 +89,17 @@ static int crossbar_domain_map(struct irq_domain *d,
unsigned int irq,
return 0;
}
+/**
+ * crossbar_domain_unmap - unmap a crossbar-irq connection
+ * @d: domain of irq to unmap
+ * @irq: virq number
+ *
+ * We do not maintain a use count of total number of map/unmap
+ * calls for a particular irq to find out if a irq can be really
+ * unmapped. This is because unmap is called during irq_dispose_mapping(irq),
+ * after which irq is anyways unusable. So an explicit map has to be called
+ * after that.
+ */
static void crossbar_domain_unmap(struct irq_domain *d, unsigned int irq)
{
irq_hw_number_t hw = irq_get_irq_data(irq)-hwirq;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 08/16] irqchip: crossbar: fix kerneldoc warning
From: Nishanth Menon n...@ti.com
Adding missing properties for kerneldoc (@write) and cleanup
of harmless warnings while we are here.
kerneldoc warnings:
Warning(drivers/irqchip/irq-crossbar.c:27): missing initial short description
on line:
* struct crossbar_device: crossbar device description
Info(drivers/irqchip/irq-crossbar.c:27): Scanning doc for struct
Warning(drivers/irqchip/irq-crossbar.c:39): No description found for parameter
'write'
2 warnings
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V3] Reworded the commit log
drivers/irqchip/irq-crossbar.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 2d7fbdb..6eee61b 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -22,12 +22,14 @@
#define IRQ_SKIP -3
#define GIC_IRQ_START 32
-/*
+/**
+ * struct crossbar_device - crossbar device description
* @int_max: maximum number of supported interrupts
* @safe_map: safe default value to initialize the crossbar
* @irq_map: array of interrupts to crossbar number mapping
* @crossbar_base: crossbar base address
* @register_offsets: offsets for each irq number
+ * @write: register write function pointer
*/
struct crossbar_device {
uint int_max;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 07/16] irqchip: crossbar: fix sparse and checkpatch warnings
From: Nishanth Menon n...@ti.com
There is absolutely no need for crossbar driver to expose functions and
variables into global namespace. So make them all static
Also fix a couple of checkpatch warnings.
Fixes sparse warnings:
drivers/irqchip/irq-crossbar.c:129:29: warning: symbol
'routable_irq_domain_ops' was not declared. Should it be static?
drivers/irqchip/irq-crossbar.c:261:12: warning: symbol 'irqcrossbar_init' was
not declared. Should it be static?
Checkpatch warnings:
WARNING: Prefer kcalloc over kzalloc with multiply
+ cb-irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
WARNING: Prefer kcalloc over kzalloc with multiply
+ cb-register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V3] Added checkpatch fixes as well to this.
drivers/irqchip/irq-crossbar.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 42ea49d..2d7fbdb 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -15,6 +15,7 @@
#include linux/of_irq.h
#include linux/slab.h
#include linux/irqchip/arm-gic.h
+#include linux/irqchip/irq-crossbar.h
#define IRQ_FREE -1
#define IRQ_RESERVED -2
@@ -118,7 +119,7 @@ found:
return 0;
}
-const struct irq_domain_ops routable_irq_domain_ops = {
+static const struct irq_domain_ops routable_irq_domain_ops = {
.map = crossbar_domain_map,
.unmap = crossbar_domain_unmap,
.xlate = crossbar_domain_xlate
@@ -139,7 +140,7 @@ static int __init crossbar_of_init(struct device_node *node)
goto err1;
of_property_read_u32(node, ti,max-irqs, max);
- cb-irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
+ cb-irq_map = kcalloc(max, sizeof(int), GFP_KERNEL);
if (!cb-irq_map)
goto err2;
@@ -184,7 +185,7 @@ static int __init crossbar_of_init(struct device_node *node)
}
- cb-register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
+ cb-register_offsets = kcalloc(max, sizeof(int), GFP_KERNEL);
if (!cb-register_offsets)
goto err3;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 06/16] irqchip: crossbar: remove IS_ERR_VALUE check
From: Nishanth Menon n...@ti.com
IS_ERR_VALUE makes sense only *if* there could be valid values in
negative error range. But in the cases that we do use it, there is no
such case. Just remove the same.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
drivers/irqchip/irq-crossbar.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 9528cf2..42ea49d 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -102,15 +102,15 @@ static int crossbar_domain_xlate(struct irq_domain *d,
unsigned long *out_hwirq,
unsigned int *out_type)
{
- unsigned long ret;
+ int ret;
ret = get_prev_map_irq(intspec[1]);
- if (!IS_ERR_VALUE(ret))
+ if (ret = 0)
goto found;
ret = allocate_free_irq(intspec[1]);
- if (IS_ERR_VALUE(ret))
+ if (ret 0)
return ret;
found:
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap: rework platform selection
* Arnd Bergmann a...@arndb.de [140616 04:18]: On Monday 16 June 2014 04:00:42 Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [140616 03:06]: Commit 9851b662f659 (ARM: use menuconfig for sub-arch menus) did more than expected, which led to two OMAP specific bugs: It seems the commit above is not -rc cycle material at least not without proper testing. There's a good chance of breaking a lot of the existing .config files which can create a big mess as we've seen before. Well, Kconfig is a big mess without it at the moment. The OMAP change was definitely wrong there, but for all other platforms I don't see any risk in applying it, because there is no semantic change, only cosmetic. * Turning CONFIG_ARCH_OMAP into a user-selectable option makes it possible to have a configuration with ARCH_OMAP enabled but none of the specific OMAP SoCs enabled, which triggers a couple of link errors due to the layout of the Makefile And so we have a regression to this old problem again :( Yes, I didn't actually see this happen but from looking at the patch, I concluded that it would likely be the case. * The plat-omap menu still appears mixed into the normal menuconfig list, which is confusing and inconsistent. That we should be able to remove completely soon but that's a separate patch.. Ok. To make matters worse, the change did not enable CONFIG_ARCH_OMAP in the defconfig files, which through some ripple effects disabled options that were implicitly enabled from OMAP2, and that caused all machines to fail booting with the unchanged config files. This reorders the OMAP Kconfig files some more, to be consistent with the others, and also changes the defconfig files. Signed-off-by: Arnd Bergmann a...@arndb.de --- Tony, can you have a look at this please? I'd like to send out the fixes for 3.16, but this is needed on top of Rob's Kconfig changes. Hmm why is this patch already in linux next before getting posted to the mailing lists? I had applied Rob's patch to the fixes series but that broke all multi_v7_defconfig runs on the boot test machines. I didn't want to spend too much work on it over the weekend, but applied it so at least today's linux-next wouldn't regress over last week's. Ah OK I see. Some quality time with duct tape in the basement with the leaking pipes :) --- a/arch/arm/plat-omap/Kconfig +++ b/arch/arm/plat-omap/Kconfig @@ -1,6 +1,11 @@ -if ARCH_OMAP +menuconfig ARCH_OMAP_ENABLE + bool TI OMAP platforms if ARCH_MULTI_V6 || ARCH_MULTI_V7 + default ARCH_OMAP1 -menu TI OMAP Common Features +if ARCH_OMAP_ENABLE + +source arch/arm/mach-omap1/Kconfig +source arch/arm/mach-omap2/Kconfig It seems to me this kind of change is going to break all the existing .config files unless they are manually updated. This includes all the distros and automated build systems. I'll look more at it, but my initial take is that we should be able to do this all with CONFIG_ARCH_OMAP + the selected OMAP SoC and should not introduce any new Kconfig options. For now I'd just leave out Rob's changed and this patch from fixes until they have been properly tested. Let's see if others have similar opinions Rob's patch as a whole. I'd still like to keep all the parts aside from the OMAP change and just back out the change that caused the problems. Does that seem reasonable to you? Yes makes sense to me if others don't have similar issues. I guess it should be possible to verify that by diffing the generated .config files compared to the old ones. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 10/16] irqchip: crossbar: change the goto naming
From: Nishanth Menon n...@ti.com
Using err1,2,3,4 etc makes it hard to ensure a new exit path in the
middle will not result in spurious changes, so rename the error paths
as per the function it does.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
drivers/irqchip/irq-crossbar.c | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 5bcedc0..5bd7f3d 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -140,17 +140,17 @@ static int __init crossbar_of_init(struct device_node
*node)
cb-crossbar_base = of_iomap(node, 0);
if (!cb-crossbar_base)
- goto err1;
+ goto err_cb;
of_property_read_u32(node, ti,max-irqs, max);
if (!max) {
pr_err(missing 'ti,max-irqs' property\n);
ret = -EINVAL;
- goto err2;
+ goto err_base;
}
cb-irq_map = kcalloc(max, sizeof(int), GFP_KERNEL);
if (!cb-irq_map)
- goto err2;
+ goto err_base;
cb-int_max = max;
@@ -169,7 +169,7 @@ static int __init crossbar_of_init(struct device_node *node)
if (entry max) {
pr_err(Invalid reserved entry\n);
ret = -EINVAL;
- goto err3;
+ goto err_irq_map;
}
cb-irq_map[entry] = IRQ_RESERVED;
}
@@ -187,7 +187,7 @@ static int __init crossbar_of_init(struct device_node *node)
if (entry max) {
pr_err(Invalid skip entry\n);
ret = -EINVAL;
- goto err3;
+ goto err_irq_map;
}
cb-irq_map[entry] = IRQ_SKIP;
}
@@ -196,7 +196,7 @@ static int __init crossbar_of_init(struct device_node *node)
cb-register_offsets = kcalloc(max, sizeof(int), GFP_KERNEL);
if (!cb-register_offsets)
- goto err3;
+ goto err_irq_map;
of_property_read_u32(node, ti,reg-size, size);
@@ -213,7 +213,7 @@ static int __init crossbar_of_init(struct device_node *node)
default:
pr_err(Invalid reg-size property\n);
ret = -EINVAL;
- goto err4;
+ goto err_reg_offset;
break;
}
@@ -230,7 +230,6 @@ static int __init crossbar_of_init(struct device_node *node)
}
of_property_read_u32(node, ti,irqs-safe-map, cb-safe_map);
-
/* Initialize the crossbar with safe map to start with */
for (i = 0; i max; i++) {
if (cb-irq_map[i] == IRQ_RESERVED ||
@@ -243,13 +242,13 @@ static int __init crossbar_of_init(struct device_node
*node)
register_routable_domain_ops(routable_irq_domain_ops);
return 0;
-err4:
+err_reg_offset:
kfree(cb-register_offsets);
-err3:
+err_irq_map:
kfree(cb-irq_map);
-err2:
+err_base:
iounmap(cb-crossbar_base);
-err1:
+err_cb:
kfree(cb);
return ret;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 05/16] irqchip: crossbar: change allocation logic by reversing search for free irqs
From: Nishanth Menon n...@ti.com
Reverse the search algorithm to ensure that address mapping and IRQ
allocation logics are proper. This makes the below bugs visible sooner.
class 1. address space errors - example:
reg = a size_b
ti,max-irqs = is a wrong parameter
class 2: irq-reserved list - which decides which entries in the
address space is not actually wired in
class 3: wrong list of routable-irqs.
In general allocating from max to min tends to have benefits in
ensuring the different issues that may be present in dts is easily
caught at definition time, rather than at a later point in time.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V3] Added more description to commit log.
drivers/irqchip/irq-crossbar.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index d1f67f6..9528cf2 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -58,7 +58,7 @@ static inline int get_prev_map_irq(int cb_no)
{
int i;
- for (i = 0; i cb-int_max; i++)
+ for (i = cb-int_max - 1; i = 0; i--)
if (cb-irq_map[i] == cb_no)
return i;
@@ -69,7 +69,7 @@ static inline int allocate_free_irq(int cb_no)
{
int i;
- for (i = 0; i cb-int_max; i++) {
+ for (i = cb-int_max - 1; i = 0; i--) {
if (cb-irq_map[i] == IRQ_FREE) {
cb-irq_map[i] = cb_no;
return i;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 04/16] irqchip: crossbar: initialise the crossbar with a safe value
From: Nishanth Menon n...@ti.com
Since crossbar is s/w configurable, the initial settings of the
crossbar cannot be assumed to be sane. This implies that:
a) On initialization all un-reserved crossbars must be initialized to
a known 'safe' value.
b) When unmapping the interrupt, the safe value must be written to
ensure that the crossbar mapping matches with interrupt controller
usage.
So provide a safe value in the dt data to map if
'0' is not safe for the platform and use it during init and unmap
While at this, fix the below checkpatch warning.
Fixes checkpatch warning:
WARNING: Unnecessary space before function pointer arguments
#37: FILE: drivers/irqchip/irq-crossbar.c:37:
+ void (*write) (int, int);
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V3] introduced ti,irqs-safe-map which defines a safe value
to initialize the crossbar.
.../devicetree/bindings/arm/omap/crossbar.txt |3 +++
drivers/irqchip/irq-crossbar.c | 19 +--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
index cfcbd52..e54d1fb 100644
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -21,6 +21,9 @@ Optional properties:
- ti,irqs-skip: This is similar to ti,irqs-reserved, but are irq mappings
which are not supposed to be used for errata or other
reasons(virtualization).
+- ti,irqs-safe-map: integer which maps to a safe configuration to use
+ when the interrupt controller irq is unused (when not provided, default is 0)
+
Examples:
crossbar_mpu: @4a02 {
compatible = ti,irq-crossbar;
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 27049de..d1f67f6 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -23,16 +23,18 @@
/*
* @int_max: maximum number of supported interrupts
+ * @safe_map: safe default value to initialize the crossbar
* @irq_map: array of interrupts to crossbar number mapping
* @crossbar_base: crossbar base address
* @register_offsets: offsets for each irq number
*/
struct crossbar_device {
uint int_max;
+ uint safe_map;
uint *irq_map;
void __iomem *crossbar_base;
int *register_offsets;
- void (*write) (int, int);
+ void (*write)(int, int);
};
static struct crossbar_device *cb;
@@ -88,8 +90,10 @@ static void crossbar_domain_unmap(struct irq_domain *d,
unsigned int irq)
{
irq_hw_number_t hw = irq_get_irq_data(irq)-hwirq;
- if (hw GIC_IRQ_START)
+ if (hw GIC_IRQ_START) {
cb-irq_map[hw - GIC_IRQ_START] = IRQ_FREE;
+ cb-write(hw - GIC_IRQ_START, cb-safe_map);
+ }
}
static int crossbar_domain_xlate(struct irq_domain *d,
@@ -214,6 +218,17 @@ static int __init crossbar_of_init(struct device_node
*node)
reserved += size;
}
+ of_property_read_u32(node, ti,irqs-safe-map, cb-safe_map);
+
+ /* Initialize the crossbar with safe map to start with */
+ for (i = 0; i max; i++) {
+ if (cb-irq_map[i] == IRQ_RESERVED ||
+ cb-irq_map[i] == IRQ_SKIP)
+ continue;
+
+ cb-write(i, cb-safe_map);
+ }
+
register_routable_domain_ops(routable_irq_domain_ops);
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 03/16] irqchip: crossbar: introduce ti,irqs-skip to skip
From: Nishanth Menon n...@ti.com
When, in the system due to varied reasons, interrupts might be unusable
due to hardware behavior, but register maps do exist, then those interrupts
should be skipped while mapping irq to crossbars.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
[V3] introduced ti,irqs-skip dt property to list the
irqs to be skipped.
.../devicetree/bindings/arm/omap/crossbar.txt |4
drivers/irqchip/irq-crossbar.c | 20
2 files changed, 24 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
index fb88585..cfcbd52 100644
--- a/Documentation/devicetree/bindings/arm/omap/crossbar.txt
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -17,6 +17,10 @@ Required properties:
so crossbar bar driver should not consider them as free
lines.
+Optional properties:
+- ti,irqs-skip: This is similar to ti,irqs-reserved, but are irq mappings
+ which are not supposed to be used for errata or other
reasons(virtualization).
+
Examples:
crossbar_mpu: @4a02 {
compatible = ti,irq-crossbar;
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 51d4b87..27049de 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -18,6 +18,7 @@
#define IRQ_FREE -1
#define IRQ_RESERVED -2
+#define IRQ_SKIP -3
#define GIC_IRQ_START 32
/*
@@ -160,6 +161,25 @@ static int __init crossbar_of_init(struct device_node
*node)
}
}
+ /* Skip the ones marked as skip */
+ irqsr = of_get_property(node, ti,irqs-skip, size);
+ if (irqsr) {
+ size /= sizeof(__be32);
+
+ for (i = 0; i size; i++) {
+ of_property_read_u32_index(node,
+ ti,irqs-skip,
+ i, entry);
+ if (entry max) {
+ pr_err(Invalid skip entry\n);
+ ret = -EINVAL;
+ goto err3;
+ }
+ cb-irq_map[entry] = IRQ_SKIP;
+ }
+ }
+
+
cb-register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
if (!cb-register_offsets)
goto err3;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 02/16] irqchip: crossbar: check for premapped crossbar before allocating
From: Nishanth Menon n...@ti.com
If irq_of_parse_and_map is executed twice, the same crossbar is mapped to two
different GIC interrupts. This is completely undesirable. Instead, check
if the requested crossbar event is pre-allocated and provide that GIC
mapping back to caller if already allocated.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
drivers/irqchip/irq-crossbar.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 20105bc..51d4b87 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -51,6 +51,17 @@ static inline void crossbar_writeb(int irq_no, int cb_no)
writeb(cb_no, cb-crossbar_base + cb-register_offsets[irq_no]);
}
+static inline int get_prev_map_irq(int cb_no)
+{
+ int i;
+
+ for (i = 0; i cb-int_max; i++)
+ if (cb-irq_map[i] == cb_no)
+ return i;
+
+ return -ENODEV;
+}
+
static inline int allocate_free_irq(int cb_no)
{
int i;
@@ -88,11 +99,16 @@ static int crossbar_domain_xlate(struct irq_domain *d,
{
unsigned long ret;
+ ret = get_prev_map_irq(intspec[1]);
+ if (!IS_ERR_VALUE(ret))
+ goto found;
+
ret = allocate_free_irq(intspec[1]);
if (IS_ERR_VALUE(ret))
return ret;
+found:
*out_hwirq = ret + GIC_IRQ_START;
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 01/16] irqchip: crossbar: dont use '0' to mark reserved interrupts
From: Nishanth Menon n...@ti.com
Today '0' is actually reserved, but may not be the same in the future.
So, use a flag to mark the GIC interrupts that are reserved.
Signed-off-by: Nishanth Menon n...@ti.com
Signed-off-by: Sricharan R r.sricha...@ti.com
---
drivers/irqchip/irq-crossbar.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index 3d15d16..20105bc 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -17,6 +17,7 @@
#include linux/irqchip/arm-gic.h
#define IRQ_FREE -1
+#define IRQ_RESERVED -2
#define GIC_IRQ_START 32
/*
@@ -139,7 +140,7 @@ static int __init crossbar_of_init(struct device_node *node)
pr_err(Invalid reserved entry\n);
goto err3;
}
- cb-irq_map[entry] = 0;
+ cb-irq_map[entry] = IRQ_RESERVED;
}
}
@@ -170,7 +171,7 @@ static int __init crossbar_of_init(struct device_node *node)
* reserved irqs. so find and store the offsets once.
*/
for (i = 0; i max; i++) {
- if (!cb-irq_map[i])
+ if (cb-irq_map[i] == IRQ_RESERVED)
continue;
cb-register_offsets[i] = reserved;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC v2 2/6] ARM: PRCM: split PRCM module init to their own driver files
* Archit Taneja arc...@ti.com [140528 03:53]:
Currently, clock providers coming from CM, PRM, and SCRM are all initialized
in
prm_common.c.
Move the DT-match tables to their respective files, and create separate init
functions for each module.
Originally worked on by: Tero Kristo t-kri...@ti.com
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Archit Taneja arc...@ti.com
---
arch/arm/mach-omap2/cm_common.c | 18 ++
arch/arm/mach-omap2/control.c | 15 +++
arch/arm/mach-omap2/control.h | 1 +
arch/arm/mach-omap2/io.c | 4 +++
arch/arm/mach-omap2/prcm-common.h | 5
arch/arm/mach-omap2/prm_common.c | 52
+++
6 files changed, 74 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/cm_common.c b/arch/arm/mach-omap2/cm_common.c
index 40b3b5a..8506990 100644
--- a/arch/arm/mach-omap2/cm_common.c
+++ b/arch/arm/mach-omap2/cm_common.c
@@ -14,6 +14,7 @@
#include linux/kernel.h
#include linux/init.h
#include linux/errno.h
+#include linux/of.h
#include cm2xxx.h
#include cm3xxx.h
@@ -138,3 +139,20 @@ int cm_unregister(struct cm_ll_data *cld)
return 0;
}
+
+static struct of_device_id omap_cm_dt_match_table[] = {
+ { .compatible = ti,omap3-cm },
+ { .compatible = ti,omap4-cm1 },
+ { .compatible = ti,omap4-cm2 },
+ { .compatible = ti,omap5-cm-core-aon },
+ { .compatible = ti,omap5-cm-core },
+ { .compatible = ti,dra7-cm-core-aon },
+ { .compatible = ti,dra7-cm-core },
+ { }
+};
+
+
+int __init of_cm_init(void)
+{
+ return of_prcm_module_init(omap_cm_dt_match_table);
+}
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 44bb4d5..12cd736 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -581,3 +581,18 @@ void omap3_ctrl_set_iva_bootmode_idle(void)
OMAP343X_CONTROL_IVA2_BOOTMOD);
}
#endif /* CONFIG_ARCH_OMAP3 CONFIG_PM */
+
+static struct of_device_id omap_scrm_dt_match_table[] = {
+ { .compatible = ti,am3-scrm },
+ { .compatible = ti,am4-scrm },
+ { .compatible = ti,omap2-scrm },
+ { .compatible = ti,omap3-scrm },
+ { .compatible = ti,omap4-scrm },
+ { .compatible = ti,omap5-scrm },
+ { }
+};
+
+int __init of_scrm_init(void)
+{
+ return of_prcm_module_init(omap_scrm_dt_match_table);
+}
I think you may be able to leave out this driver like code
from arch/arm/mach-omap2 by using the existing syscon mapping
we have in the .dtsi files? See for example how the PBIAS
is using the syscon in drivers/regulator/pbias-regulator.c.
If the clock registers don't fall into the existing SCM syscon
area, we can also set up more syscon areas.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DRA722: add detection of SoC information.
* Nishanth Menon n...@ti.com [140529 12:07]:
Add support for DRA72x device DIEID. Currently these devices are
reported as DRA75/74 family of processors.
Signed-off-by: Nishanth Menon n...@ti.com
Thanks applying into omap-for-v3.16/fixes.
Tony
---
(test using linux-next next-20140529 tag):
before: http://slexy.org/raw/s21Yb8sOhy
after: http://slexy.org/raw/s20Nx96NrY
Applies on:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
branch: omap-for-v3.16/soc
arch/arm/mach-omap2/id.c | 12
arch/arm/mach-omap2/soc.h |1 +
2 files changed, 13 insertions(+)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 71bf216..801244a 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -649,6 +649,18 @@ void __init dra7xxx_check_revision(void)
}
break;
+ case 0xb9bc:
+ switch (rev) {
+ case 0:
+ omap_revision = DRA722_REV_ES1_0;
+ break;
+ default:
+ /* If we have no new revisions */
+ omap_revision = DRA722_REV_ES1_0;
+ break;
+ }
+ break;
+
default:
/* Unknown default to latest silicon rev as default*/
pr_warn(%s: unknown idcode=0x%08x (hawkeye=0x%08x,rev=0x%d)\n,
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index de2a34c..01ca808 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -462,6 +462,7 @@ IS_OMAP_TYPE(3430, 0x3430)
#define DRA7XX_CLASS 0x0700
#define DRA752_REV_ES1_0 (DRA7XX_CLASS | (0x52 16) | (0x10 8))
#define DRA752_REV_ES1_1 (DRA7XX_CLASS | (0x52 16) | (0x11 8))
+#define DRA722_REV_ES1_0 (DRA7XX_CLASS | (0x22 16) | (0x10 8))
void omap2xxx_check_revision(void);
void omap3xxx_check_revision(void);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: OMAP5: Update CPU OPP table as per final production Manual
* Nishanth Menon n...@ti.com [140605 18:11]: As per the Final production Data Manual for OMAP5432, SWPS050F(APRIL 2014) There are only two OPPs - 1GHz and 1.5GHz. the older OPP_LOW has been completely descoped. The Nominal voltages are still correct though. However, expectation for final production configuration is operation with Adaptive Body Bias (ABB) and Adaptive Voltage Scaling Class 0 operation. There are no IDcode or version change information encoded to programmatically detect this and software is supposed to NOT use OPP_LOW(500MHz) anymore for all devices (legacy and production samples). Signed-off-by: Nishanth Menon n...@ti.com Thanks applying into omap-for-v3.16/fixes. Tony --- arch/arm/boot/dts/omap5.dtsi |1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 3bfda16..a4ed549 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -45,7 +45,6 @@ operating-points = /* kHzuV */ - 50 88 100 106 150 125 ; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: am43x-epos-evm: Add Missing cpsw-phy-sel for am43x-epos-evm
* Nishanth Menon n...@ti.com [140606 08:30]:
On 06/06/2014 04:52 AM, George Cherian wrote:
On 6/6/2014 12:23 PM, Nishanth Menon wrote:
On 06/06/2014 01:17 AM, George Cherian wrote:
AM437x EPOS evm use external clock for RMII interface.
Enable the same in DT.
Signed-off-by: George Cherian george.cher...@ti.com
Reported-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/am43x-epos-evm.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 19f1f7e..90098f9 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -319,6 +319,10 @@
phy-mode = rmii;
};
+phy_sel {
+ rmii-clock-ext;
+};
+
i2c0 {
status = okay;
pinctrl-names = default;
Where does this apply on?
With linux-next next-20140506 tag, and this patch applied, I get the
Is'nt next-20140506 a month old.
Uggh.. yeah - 1AM+migraine is not a good combination to try to do
testing. :( Apologies on the noise
I tried the patch on next-20140604.
Tested on next-20140606 - applies clean, builds and works :)
am43xx-epos: Boot PASS: http://slexy.org/raw/s2fT6zs45y
Tested-by: Nishanth Menon n...@ti.com
Applying into omap-for-v3.16/fixes thanks.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: drop unused function
* Brian Norris computersforpe...@gmail.com [140610 14:31]: gic_init_irq() is no longer used as of: commit b42b918194c4791510ac049e3d507169a7de8544 Author: Tony Lindgren t...@atomide.com Date: Thu May 30 12:53:05 2013 -0700 ARM: OMAP2+: Remove board-omap4panda.c Drop it. Signed-off-by: Brian Norris computersforpe...@gmail.com Applying into omap-for-v3.16/fixes thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 0/2] arm: dts: dra7: add crossbar dt support
This series introduces DT support for crossbar device and changes dra7 peripherals to use crossbar number instead of irq. This depends on below driver fixes and cleanup series. https://lkml.org/lkml/2014/6/16/218 [V2] Rebased on 3.15 mainline. [V3] Added ti,irqs-skip property and ti,irqs-safe-map property to crossbar dt node. R Sricharan (2): arm: dts: dra7: add routable-irqs property for gic node arm: dts: dra7: add crossbar device binding arch/arm/boot/dts/dra7.dtsi | 136 +-- 1 file changed, 78 insertions(+), 58 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 1/2] arm: dts: dra7: add routable-irqs property for gic node
From: R Sricharan r.sricha...@ti.com There is a IRQ crossbar device in the soc, which maps the irq requests from the peripherals to the mpu interrupt controller's inputs. The gic provides the support for such IPs in the form of routable-irqs. So adding the property here to gic node. Signed-off-by: Sricharan R r.sricha...@ti.com Signed-off-by: Nishanth Menon n...@ti.com Cc: Benoit Cousson bcous...@baylibre.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Rajendra Nayak rna...@ti.com Cc: Tony Lindgren t...@atomide.com --- arch/arm/boot/dts/dra7.dtsi |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index c29945e..1cf4ee1 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -45,6 +45,7 @@ compatible = arm,cortex-a15-gic; interrupt-controller; #interrupt-cells = 3; + arm,routable-irqs = 192; reg = 0x48211000 0x1000, 0x48212000 0x1000, 0x48214000 0x2000, -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 2/2] arm: dts: dra7: add crossbar device binding
From: R Sricharan r.sricha...@ti.com
There is a IRQ crossbar device in the soc, which
maps the irq requests from the peripherals to the
mpu interrupt controller's inputs. The Peripheral irq
requests are connected to only one crossbar
input and the output of the crossbar is connected to only one
controller's input line. The crossbar device is used to map
a peripheral input to a free mpu's interrupt controller line.
Here, adding a new crossbar device node and replacing all the peripheral
interrupt numbers with its fixed crossbar input lines.
Signed-off-by: Sricharan R r.sricha...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Cc: Benoit Cousson bcous...@baylibre.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Rajendra Nayak rna...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
[V3] Added ti,irqs-skip and ti,irqs-safe-map properties
to the crossbar device node.
arch/arm/boot/dts/dra7.dtsi | 135 ---
1 file changed, 77 insertions(+), 58 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1cf4ee1..6de99c2 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -80,8 +80,8 @@
ti,hwmods = l3_main_1, l3_main_2;
reg = 0x4400 0x100,
0x4500 0x1000;
- interrupts = GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
-GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 410 IRQ_TYPE_LEVEL_HIGH;
prm: prm@4ae06000 {
compatible = ti,dra7-prm;
@@ -156,10 +156,10 @@
sdma: dma-controller@4a056000 {
compatible = ti,omap4430-sdma;
reg = 0x4a056000 0x1000;
- interrupts = GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH,
-GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH,
-GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH,
-GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
+GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
#dma-cells = 1;
#dma-channels = 32;
#dma-requests = 127;
@@ -168,7 +168,7 @@
gpio1: gpio@4ae1 {
compatible = ti,omap4-gpio;
reg = 0x4ae1 0x200;
- interrupts = GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio1;
gpio-controller;
#gpio-cells = 2;
@@ -179,7 +179,7 @@
gpio2: gpio@48055000 {
compatible = ti,omap4-gpio;
reg = 0x48055000 0x200;
- interrupts = GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio2;
gpio-controller;
#gpio-cells = 2;
@@ -190,7 +190,7 @@
gpio3: gpio@48057000 {
compatible = ti,omap4-gpio;
reg = 0x48057000 0x200;
- interrupts = GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio3;
gpio-controller;
#gpio-cells = 2;
@@ -201,7 +201,7 @@
gpio4: gpio@48059000 {
compatible = ti,omap4-gpio;
reg = 0x48059000 0x200;
- interrupts = GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio4;
gpio-controller;
#gpio-cells = 2;
@@ -212,7 +212,7 @@
gpio5: gpio@4805b000 {
compatible = ti,omap4-gpio;
reg = 0x4805b000 0x200;
- interrupts = GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio5;
gpio-controller;
#gpio-cells = 2;
@@ -223,7 +223,7 @@
gpio6: gpio@4805d000 {
compatible = ti,omap4-gpio;
reg = 0x4805d000 0x200;
- interrupts = GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH;
+ interrupts = GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = gpio6;
Re: [PATCH 1/3] clk: ti: add 'ti,round-rate' flag
On 13/06/14 22:53, Paul Walmsley wrote: Whatever we do to the (common, not DSS-specific) clock code to fix this issue, it has to make sense independently of your specific DSS needs. I agree. I think the fix (v1) makes sense for all users of the pll. Correct me if I'm wrong, but the current state is: - The pll's round_rate does not round, but instead returns an error if it cannot produce the exact rate that was requested. - All OMAP PLL's have dividers after them, handled with clk-divider driver. - clk-divider driver does not handle errors from round_rate, but instead goes on and the resulting clock rate is more or less garbage. - If a driver requests a clock rate that cannot be produced exactly, it'll instead get a garbage clock rate, leading to undefined behavior. So surely fixing the round_rate so that the clock code behaves sanely, if not optimally, is much better than the current undefined behavior? And again, currently a driver needs to request an exact clock rate, as otherwise it'll get a garbage clock rate, and I'm quite sure it won't work correctly. So all the current drivers request an exact clock rate, and they are not affected by the fix, or the drivers are totally broken already. This is why I asked you for a DSS-specific change, since it would effectively avoid this basic principle. Yes, a DSS specific change would be marginally safer, but I think the DSS specific options get rather hacky or complex. One option was the DT flag, which was not accepted. Another would be adding a list of accepted clock rates to DSS driver, and the DSS driver would round internally. Quite hacky, I wouldn't like to go there. And as I don't see the generic fix causing any problems, I don't see why we would want to make big hacks somewhere else, just to avoid the generic fix. I'm open to ideas how to make a relatively clean DSS specific fix for this, which can be merged for the next -rc. Right now, in my view, it does not make sense to have a PLL clk_set_rate() function that unconditionally rounds to the closest rate for all users. As I've written before, callers could end up with a clock rate that is different than what's needed for a synchronous I/O user that expects an exact rate. I am concerned about both rounding to a lower rate and rounding to a higher rate in this case, although the higher rate is marginally more of a concern to me since the resulting rate may be higher than the device is characterized for at a given voltage. Furthermore, as a general interface principle, allowing clk_set_rate() to silently round rates could lead to unexpected behavior, since the set of rates that clk_set_rate() can round to may change between the call to clk_round_rate() and the call to clk_set_rate(). Maybe, but, correct me if I'm wrong, that's how the clock set_rate has worked (always?). The exact behavior for set_rate and round_rate isn't defined anywhere I've seen, which to me means the behavior is implementation specific. However, I think it's clear that round_rate _should_ round, which it currently does not. With this fix, both set_rate and round_rate work inside the spec. So again I think that the right way to deal with this is to: 1. avoid silently rounding rates in clk_set_rate() and to return an error if calling clk_set_rate() would result in a rate other than the one desired; and to 2. modify clk_round_rate() such that it returns the closest lowest-or-equal rate match to the target rate requested. I see that as a separate thing. What you're talking about is improving the clock API. What I'm talking about is fixing a major (at least to the owners of AM3xxx boards) bug in the mainline kernel, with as minimal changes as possible. The fix doesn't need to solve all the possible issues around clock rate. It just needs to fix the bug we have, without causing any new bugs. Afaik, the fix does not introduce any new problems. The behavior of set_rate and round_rate can be improved later. If the fix would be merged asap, we would get as long testing time as possible before the 3.16 is released. If we find any drivers broken by this fix, we can fix the drivers or in the worst case revert the fix. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] regulator: twl: Convert to use devm_kmemdup()
+linux-omap.
On 06/15/2014 08:44 PM, Axel Lin wrote:
Might be nice to have a commit message here.
Signed-off-by: Axel Lin axel@ingics.com
---
drivers/regulator/twl-regulator.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index fed28ab..0b4f866 100644
--- a/drivers/regulator/twl-regulator.c
+++ b/drivers/regulator/twl-regulator.c
@@ -1128,7 +1128,7 @@ static int twlreg_probe(struct platform_device *pdev)
if (!initdata)
return -EINVAL;
- info = kmemdup(template, sizeof(*info), GFP_KERNEL);
+ info = devm_kmemdup(pdev-dev, template, sizeof(*info), GFP_KERNEL);
if (!info)
return -ENOMEM;
@@ -1192,7 +1192,6 @@ static int twlreg_probe(struct platform_device *pdev)
if (IS_ERR(rdev)) {
dev_err(pdev-dev, can't register %s, %ld\n,
info-desc.name, PTR_ERR(rdev));
- kfree(info);
return PTR_ERR(rdev);
}
platform_set_drvdata(pdev, rdev);
@@ -1212,20 +1211,10 @@ static int twlreg_probe(struct platform_device *pdev)
return 0;
}
-static int twlreg_remove(struct platform_device *pdev)
-{
- struct regulator_dev *rdev = platform_get_drvdata(pdev);
- struct twlreg_info *info = rdev-reg_data;
-
- kfree(info);
- return 0;
-}
-
MODULE_ALIAS(platform:twl_reg);
static struct platform_driver twlreg_driver = {
.probe = twlreg_probe,
- .remove = twlreg_remove,
/* NOTE: short name, to work around driver model truncation of
* twl_regulator.12 (and friends) to twl_regulator.1.
*/
otherwise, looks good to me.
Reviewed-by: Nishanth Menon n...@ti.com
--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
Adding devicetree and linux-arm-kernel lists based on feedback on IRC... On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner jkrid...@gmail.com wrote: I'd like to discuss moving our current library of cape devicetree overlay sources into a single tree, including the boot .dtb files for BeagleBoard.org boards and moving towards enabling as much of the cape support into a single boot-time .dtb file with an approach similar to the cape-universal overlay (https://github.com/cdsteinkuehler/beaglebone-universal-io), but not in an overlay. First of all, I want to note this doesn't change my view on the importance of mainline support for devicetree overlays. They are still absolutely critical and highly useful, solving problems that cannot be solved through boot-time devicetrees. I'm simply looking for an approach that will complement the availability of overlays and provide the best user experience. Robert has been talking about the actions required to clean-up Debian Jessie support in another thread (https://groups.google.com/d/msg/beagleboard/2b8rArtfABY/A8d1JzmJa4IJ) and I suggested we should add a bit of a detour by cleaning up the cape support for the mainline kernel and switching away our primary process of supporting capes from using overlays to using a single devicetree file provided at boot. I promised a pull-request and hadn't gotten around to sending it until now (below). No architecture changes have been made in my pull-request, just bringing in the kernel devicetree source history. This suggestion is based on several assumptions, any number of which might be wrong. The assumptions (for which I'm looking for feedback/corrections): * The overlays pretty much all need to be compiled into the kernel if they are going to be loaded using kernel command-line arguments or /etc/capemgr for the majority of distros. While many cape devicetree use cases are perfectly happy with loading at run-time rather than boot-time, it seems there should be a mechanism for pushing cape support into the category of being available at boot-time across distributions. * The devicetree sources, including the primary boot .dts files, will eventually be removed from the kernel source tree. I'm not too sure if and when it'll really happen, but starting up a project to maintain the definitive beagleboard.org board devicetree files outside the kernel seems to make sense. Given the interdependency of the boot .dtb and the overlay .dtbo files, combining them into a single repository where every distribution can pick them up seems like a natural and obvious choice. There are of course some dependencies on kernel versions, but I believe most of those have settled out by now and we should be OK moving forward. * There seems to be little or no interest in my previous proposal to use cape EEPROMs to store the overlay fragments. Given some churn in the devicetree node definitions, it is likely this would have failed in bad ways anyway. It seems mostly reasonable to expect users to update their kernel and firmware to gain support for new add-on hardware and we mostly try to avoid regressions (with the seemingly ever-living exception of 3D graphics support), so I think I'm better aligned with the community to drop my older suggestion. Some people, including CircuitCo, are building capes without configuration EEPROMs now, so a different recommended mechanism seems like a requirement. * With the patches in our vendor 3.8 kernels and with all recent mainline kernels, performing userspace muxing operations has become easy again. It seems to be possible to turn on drivers not currently in use without an unacceptable level of bloat or conflict. This has been partially proven out using Charles' universal cape (https://github.com/cdsteinkuehler/beaglebone-universal-io), though I still have some concerns about conflicts. The result might be that there is still some number of overlays, but the approach of minimizing the overlays and instead relying on the existing loading/unloading mechanisms of the mainline drivers as much as possible feels right to me. * It will still be some time before devicetree overlay support is adopted in the mainline kernel. While I still see a strong need to have devicetree overlay support and CapeMgr in the mainline, the desire here is to optimize the user experience in the shortest term possible. Users get really confused by the errors that get generated by loading incorrect devicetree overlays and it is always nice when you can avoid confusing users. My suggestion is: * Maintain the source for .dtb and .dtbo files for all BeagleBoard.org boards at http://github.com/beagleboard/devicetree-source, overriding the sources in the mainline kernel when performing kernel builds. We can host pre-built .dtb and .dtbo files at a normailzed location outside the source repository for those that don't want to perform the builds, since I don't believe the binary
Re: [PATCH v2 4/4] ARM: DTS: dra7/dra7xx-clocks: ATL related changes
On 05/07/2014 01:20 PM, Peter Ujfalusi wrote:
Modify the clock nodes for the ATL clocks to use the ATL clock driver to
handle them.
Add the ATL device node at the same time for DRA7.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
This patch missed the merge window due to long dependency chain, however
Tony promised to pull this with rc-fixes. So, for that purpose:
Acked-by: Tero Kristo t-kri...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 11 +++
arch/arm/boot/dts/dra7xx-clocks.dtsi | 16
2 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 149b55099935..84071423016e 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -789,6 +789,17 @@
dma-names = tx0, rx0;
status = disabled;
};
+
+ atl: atl@4843c000 {
+ compatible = ti,dra7-atl;
+ reg = 0x4843c000 0x3ff;
+ ti,hwmods = atl;
+ ti,provided-clocks = atl_clkin0_ck, atl_clkin1_ck,
+atl_clkin2_ck, atl_clkin3_ck;
+ clocks = atl_gfclk_mux;
+ clock-names = fck;
+ status = disabled;
+ };
};
};
diff --git a/arch/arm/boot/dts/dra7xx-clocks.dtsi
b/arch/arm/boot/dts/dra7xx-clocks.dtsi
index 30160348934c..789e92cd5595 100644
--- a/arch/arm/boot/dts/dra7xx-clocks.dtsi
+++ b/arch/arm/boot/dts/dra7xx-clocks.dtsi
@@ -10,26 +10,26 @@
cm_core_aon_clocks {
atl_clkin0_ck: atl_clkin0_ck {
#clock-cells = 0;
- compatible = fixed-clock;
- clock-frequency = 0;
+ compatible = ti,dra7-atl-clock;
+ clocks = atl_gfclk_mux;
};
atl_clkin1_ck: atl_clkin1_ck {
#clock-cells = 0;
- compatible = fixed-clock;
- clock-frequency = 0;
+ compatible = ti,dra7-atl-clock;
+ clocks = atl_gfclk_mux;
};
atl_clkin2_ck: atl_clkin2_ck {
#clock-cells = 0;
- compatible = fixed-clock;
- clock-frequency = 0;
+ compatible = ti,dra7-atl-clock;
+ clocks = atl_gfclk_mux;
};
atl_clkin3_ck: atl_clkin3_ck {
#clock-cells = 0;
- compatible = fixed-clock;
- clock-frequency = 0;
+ compatible = ti,dra7-atl-clock;
+ clocks = atl_gfclk_mux;
};
hdmi_clkin_ck: hdmi_clkin_ck {
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 00/16] irqchip: crossbar: driver fixes
Sricharan, On Monday 16 June 2014 07:23 AM, Sricharan R wrote: This series does some cleanups, fixes for handling two interrupts getting mapped twice to same crossbar and provides support for hardwired IRQ and crossbar definitions. On certain platforms such as DRA7, SPIs 0, 1, 2, 3, 5, 6, 10, 131, 132, 133 are direct wired to hardware blocks bypassing crossbar. This quirky implementation is *NOT* supposed to be the expectation of crossbar hardware usage. This series adds support to represent such hard-wired irqs through DT and avoid generic allocation/programming of crossbar in the driver. This way of supporting hard-wired irqs was a result of the below discussions. http://www.spinics.net/lists/arm-kernel/msg329946.html Based on 3.15 mainline. All the patches are available here g...@github.com:Sricharanti/sricharan.git crossbar_updates The fixes series[1] earlier posted is merged in to this. [1] http://www.spinics.net/lists/arm-kernel/msg328273.html [V2] Merged the above series and rebased on 3.15 mainline [V3] Modified patch#3 to get irqs-skip properties from DT, merged path#8 for checkpatch warning to other relevant patches and fixed comments for other patches. I scanned entire series again including your updates on Jason's comments. All look good to my eyes. Hopefully after this series now, we can actually enable the crossbar support on those machines. FWIW, Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/4] ARM: DTS: dra7/dra7xx-clocks: ATL related changes
* Tero Kristo t-kri...@ti.com [140616 07:03]: On 05/07/2014 01:20 PM, Peter Ujfalusi wrote: Modify the clock nodes for the ATL clocks to use the ATL clock driver to handle them. Add the ATL device node at the same time for DRA7. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com This patch missed the merge window due to long dependency chain, however Tony promised to pull this with rc-fixes. So, for that purpose: Acked-by: Tero Kristo t-kri...@ti.com Thanks applying into omap-for-v3.16/fixes. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: omap: rework platform selection
* Tony Lindgren t...@atomide.com [140616 04:31]: * Arnd Bergmann a...@arndb.de [140616 04:18]: Let's see if others have similar opinions Rob's patch as a whole. I'd still like to keep all the parts aside from the OMAP change and just back out the change that caused the problems. Does that seem reasonable to you? Yes makes sense to me if others don't have similar issues. I guess it should be possible to verify that by diffing the generated .config files compared to the old ones. If you update Rob's patch and undo the omap2+ changes, you might want to fold in something like the following to hide the omap options behind a menu. So far I have not come up with no great ideas on fixing this properly short of requiring all omap .config files to add CONFIG_ARCH_OMAP=y manually. Anybody got good ideas for that? Regards, Tony --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -1,3 +1,5 @@ +menu TI OMAP/AM/DM/DRA Family + config ARCH_OMAP bool @@ -342,3 +344,5 @@ config OMAP4_ERRATA_I688 endmenu endif + +endmenu -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH 1/2] ARM: AM43xx: hwmod: add DSS hwmod data
Hi, On Sun, Jun 15, 2014 at 03:29:40AM +, Paul Walmsley wrote: Hi, On Fri, 13 Jun 2014, Felipe Balbi wrote: On Sat, Jun 14, 2014 at 02:57:32AM +, Paul Walmsley wrote: From: Sathya Prakash M R sath...@ti.com Add DSS hwmod data for AM43xx. Cc: Andrew Morton a...@linux-foundation.org Acked-by: Rajendra Nayak rna...@ti.com Signed-off-by: Sathya Prakash M R sath...@ti.com Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com --- Note that this patch was originally send on May 9th [1], changes were requested and a new version was sent on May 19th [2], then on May 27th [3] Tomi pinged maintainer again and go no response. Without this patch, we cannot get display working on any AM437x devices. [1] http://marc.info/?l=linux-arm-kernelm=139963677925227w=2 [2] http://marc.info/?l=linux-arm-kernelm=140049799425512w=2 [3] http://marc.info/?l=linux-arm-kernelm=140117232826754w=2 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 98 ++ arch/arm/mach-omap2/prcm43xx.h | 1 + 2 files changed, 99 insertions(+) Sorry for the delay on this. Have been corresponding with TI management to figure out what to do about patches for AM43xx. I don't have boards or public documentation for these devices, so it's impossible for me to meaningfully review the patches. Looks like boards and/or public docs won't be coming any time soon. So for my part, here's what I'll need to merge any hwmod or PRCM patches that involve AM437x: 1. A Reviewed-by: from one of the following folks (which should come from a different person than who is submitting the patches): Roger Quadros Nishanth Menon Rajendra Nayak Kevin Hilman Tony Lindgren 2. A Tested-by: from one of the following folks (who can be the same as the person who is the same as the person who is submitting the patches): Nishanth Menon Rajendra Nayak Kevin Hilman Tony Lindgren What you're saying here is that it's pointless for anybody else in TI to review and/or test patches because you will only accept such tags from this list of 4 ~ 5 people. That might be how you interpreted the E-mail. But that's not what was written. of course it was. Read what you wrote: here's what I'll need to *merge* any hwmod or PRCM patches that involve AM437x. That basically puts down the requirements to getting any patches accepted and those requirements are the blessings of a handful. For the record, I'm pleased to accept Reviewed-by:s and Tested-by:s from anyone. But, like most maintainers, there are some folks who I think do a better job of reviewing and testing hwmod and PRCM patches than others. The people listed above are a first cut at that list. I'm certainly happy to consider adding others, but the reviewers need: 1. to have experience with those parts of the kernel; 2. to have access to the canonical documentation for AM43xx to review against; and anybody in ti.com have access to those. 3. to have some kind of track record doing in-depth reviews of patches for that subsystem, or writing clean code for that subsystem. Similarly, for testers, the folks listed above are people who: 1. could actually have AM43xx boards; and well, quite a few have rather easy access to multiple (3, to be exact) different am437x platforms. 2. who have a history of testing patches against mainline kernels in public forums, rather than testing against vendor kernels; and $subject and patch two have both been tested on top of linux next from june 10th. Is that bleeding edge enough for you ? Moreover, *only* these two patches were applied on top of Stephen's linux-next. 3. who I think would be mortally embarrassed if a patch was broken that they had a Tested-by: for. right, and when those guys try to get bugs fixed, we spend half a year discussing pointless might-happen-when-the-sun-dies problems with other drivers even when... h what the heck, you'll just say I'm mixing threads again... The point is that it has been this back and forth for quite a while now, in countless occasions we have missed merge windows because this or that maintainer just stops responding and *nobody* else has balls to pick the patch up. Weeks later social network posts start to arise blaming TI for not sending patches upstream. (N.B. In the case of anything involving DSS, such as this patch, I'd be happy to accept Tested-by:s from Archit or Tomi.) If you have other
Re: [PATCH] ARM: omap: rework platform selection
On Mon, Jun 16, 2014 at 9:17 AM, Tony Lindgren t...@atomide.com wrote: * Tony Lindgren t...@atomide.com [140616 04:31]: * Arnd Bergmann a...@arndb.de [140616 04:18]: Let's see if others have similar opinions Rob's patch as a whole. I'd still like to keep all the parts aside from the OMAP change and just back out the change that caused the problems. Does that seem reasonable to you? Yes makes sense to me if others don't have similar issues. I guess it should be possible to verify that by diffing the generated .config files compared to the old ones. Other than exynos (which is new to MP) and OMAP, the rest are straightforward user config to menuconfig conversions. If you update Rob's patch and undo the omap2+ changes, you might want to fold in something like the following to hide the omap options behind a menu. This or reverting the OMAP part seems like the best change for now. So far I have not come up with no great ideas on fixing this properly short of requiring all omap .config files to add CONFIG_ARCH_OMAP=y manually. Anybody got good ideas for that? I've failed to come up with anything... Rob Regards, Tony --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -1,3 +1,5 @@ +menu TI OMAP/AM/DM/DRA Family + config ARCH_OMAP bool @@ -342,3 +344,5 @@ config OMAP4_ERRATA_I688 endmenu endif + +endmenu -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: hwmod: Change hardreset soc_ops for AM43XX
On 06/15/2014 08:56 PM, Paul Walmsley wrote: On Fri, 13 Jun 2014, Paul Walmsley wrote: On Mon, 9 Jun 2014, Dave Gerlach wrote: am43xx reset register layout is more similar to am33xx than omap4 so use the am33xx functions for hwmod hardreset soc_ops rather than the currently used omap4 functions. Without this, assert_hardreset and deassert_hardreset will not work on am43xx. Signed-off-by: Dave Gerlach d-gerl...@ti.com Makes sense to me; queued for v3.16-rc. The patch failed a build test for an AM43xx-only config: arch/arm/mach-omap2/built-in.o: In function `_am33xx_is_hardreset_asserted': arch/arm/mach-omap2/omap_hwmod.c:3223: undefined reference to `am33xx_prm_is_hardreset_asserted' arch/arm/mach-omap2/built-in.o: In function `_am33xx_deassert_hardreset': arch/arm/mach-omap2/omap_hwmod.c:3201: undefined reference to `am33xx_prm_deassert_hardreset' arch/arm/mach-omap2/built-in.o: In function `_am33xx_assert_hardreset': arch/arm/mach-omap2/omap_hwmod.c:3181: undefined reference to `am33xx_prm_assert_hardreset' make: *** [vmlinux] Error 1 I went ahead and modified the patch to build (updated patch below), but it would be helpful if you could also build-test your AM43xx-specific patches with an AM43xx-specific .config (along with the usual omap2plus_defconfig). Sorry about that, I definitely should have tried that, thanks for the fixup! Regards, Dave - Paul From: Dave Gerlach d-gerl...@ti.com Date: Sun, 15 Jun 2014 16:02:17 -0600 Subject: [PATCH 1/2] ARM: OMAP2+: hwmod: Change hardreset soc_ops for AM43XX am43xx reset register layout is more similar to am33xx than omap4 so use the am33xx functions for hwmod hardreset soc_ops rather than the currently used omap4 functions. Without this, assert_hardreset and deassert_hardreset will not work on am43xx. Signed-off-by: Dave Gerlach d-gerl...@ti.com [p...@pwsan.com: fixed build errors for an AM43xx-only Kconfig] Signed-off-by: Paul Walmsley p...@pwsan.com --- arch/arm/mach-omap2/Makefile | 6 -- arch/arm/mach-omap2/cm33xx.h | 2 +- arch/arm/mach-omap2/omap_hwmod.c | 6 +++--- 3 files changed, 8 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 8421f38cf445..7a695362aee7 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -110,14 +110,16 @@ obj-y += prm_common.o cm_common.o obj-$(CONFIG_ARCH_OMAP2) += prm2xxx_3xxx.o prm2xxx.o cm2xxx.o obj-$(CONFIG_ARCH_OMAP3) += prm2xxx_3xxx.o prm3xxx.o cm3xxx.o obj-$(CONFIG_ARCH_OMAP3) += vc3xxx_data.o vp3xxx_data.o -obj-$(CONFIG_SOC_AM33XX) += prm33xx.o cm33xx.o omap-prcm-4-5-common = cminst44xx.o cm44xx.o prm44xx.o \ prcm_mpu44xx.o prminst44xx.o \ vc44xx_data.o vp44xx_data.o obj-$(CONFIG_ARCH_OMAP4) += $(omap-prcm-4-5-common) obj-$(CONFIG_SOC_OMAP5) += $(omap-prcm-4-5-common) obj-$(CONFIG_SOC_DRA7XX) += $(omap-prcm-4-5-common) -obj-$(CONFIG_SOC_AM43XX) += $(omap-prcm-4-5-common) +am33xx-43xx-prcm-common+= prm33xx.o +obj-$(CONFIG_SOC_AM33XX) += $(am33xx-43xx-prcm-common) cm33xx.o +obj-$(CONFIG_SOC_AM43XX) += $(omap-prcm-4-5-common) \ + $(am33xx-43xx-prcm-common) # OMAP voltage domains voltagedomain-common := voltage.o vc.o vp.o diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h index 15a778ce7707..bd2441790779 100644 --- a/arch/arm/mach-omap2/cm33xx.h +++ b/arch/arm/mach-omap2/cm33xx.h @@ -380,7 +380,7 @@ void am33xx_cm_clkdm_disable_hwsup(u16 inst, u16 cdoffs); void am33xx_cm_clkdm_force_sleep(u16 inst, u16 cdoffs); void am33xx_cm_clkdm_force_wakeup(u16 inst, u16 cdoffs); -#ifdef CONFIG_SOC_AM33XX +#if defined(CONFIG_SOC_AM33XX) || defined(CONFIG_SOC_AM43XX) extern int am33xx_cm_wait_module_idle(u16 inst, s16 cdoffs, u16 clkctrl_offs); extern void am33xx_cm_module_enable(u8 mode, u16 inst, s16 cdoffs, diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index f7bb435bb543..6c074f37cdd2 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -4251,9 +4251,9 @@ void __init omap_hwmod_init(void) soc_ops.enable_module = _omap4_enable_module; soc_ops.disable_module = _omap4_disable_module; soc_ops.wait_target_ready = _omap4_wait_target_ready; - soc_ops.assert_hardreset = _omap4_assert_hardreset; - soc_ops.deassert_hardreset = _omap4_deassert_hardreset; - soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted; + soc_ops.assert_hardreset = _am33xx_assert_hardreset; +
Re: [PATCH] ARM: OMAP2+: hwmod: Change hardreset soc_ops for AM43XX
Paul,
On 06/15/2014 11:43 PM, Paul Walmsley wrote:
Dave,
On Mon, 9 Jun 2014, Dave Gerlach wrote:
am43xx reset register layout is more similar to am33xx than omap4 so
use the am33xx functions for hwmod hardreset soc_ops rather than the
currently used omap4 functions. Without this, assert_hardreset and
deassert_hardreset will not work on am43xx.
Signed-off-by: Dave Gerlach d-gerl...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 66c60fe..1c0885b 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -4251,9 +4251,9 @@ void __init omap_hwmod_init(void)
soc_ops.enable_module = _omap4_enable_module;
soc_ops.disable_module = _omap4_disable_module;
soc_ops.wait_target_ready = _omap4_wait_target_ready;
- soc_ops.assert_hardreset = _omap4_assert_hardreset;
- soc_ops.deassert_hardreset = _omap4_deassert_hardreset;
- soc_ops.is_hardreset_asserted = _omap4_is_hardreset_asserted;
+ soc_ops.assert_hardreset = _am33xx_assert_hardreset;
+ soc_ops.deassert_hardreset = _am33xx_deassert_hardreset;
+ soc_ops.is_hardreset_asserted = _am33xx_is_hardreset_asserted;
soc_ops.init_clkdm = _init_clkdm;
} else if (soc_is_am33xx()) {
soc_ops.enable_module = _am33xx_enable_module;
Should AM43XX be using the _am33xx_{enable,disable}_module and
wait_target_ready functions?
AM43xx has been using the _omap4_{enable,disable}_module functions
without issue. Nothing is currently using the hardreset ops for am43xx
which is why it went unnoticed but I saw the issue when I tried to use
them for the wkup_m3 hwmod and they failed during internal development.
With that said, am43xx clockdomains have prcm_partition defined as part
of their data which is only used by the _omap4_{enable,disable}_module
functions and not the _am33xx functions so as the current configuration
stands the _omap4 variants are the right choice.
Regards,
Dave
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] omap2: fix parser-bug in platform muxing code
Fix a parser-bug in the omap2 muxing code where muxtable-entries will be
wrongly selected if the requested muxname is a *prefix* of their
m0-entry and they have a matching mN-entry. Fix by additionally checking
that the length of the m0_entry is equal.
Signed-off-by: David R. Piegdon l...@p23q.org
For example muxing of dss_data2.dss_data2 on omap32xx will fail
because the prefix dss_data2 will match the mux-entries dss_data2 as
well as dss_data20, with the suffix dss_data2 matching m0 (for
dss_data2) and m4 (for dss_data20). Thus both are recognized as signal
path candidates:
Relevant muxentries from mux34xx.c:
_OMAP3_MUXENTRY(DSS_DATA20, 90,
dss_data20, NULL, mcspi3_somi, dss_data2,
gpio_90, NULL, NULL, safe_mode),
_OMAP3_MUXENTRY(DSS_DATA2, 72,
dss_data2, NULL, NULL, NULL,
gpio_72, NULL, NULL, safe_mode),
This will result in a failure to mux the pin at all:
_omap_mux_get_by_name: Multiple signal paths (2) for dss_data2.dss_data2
Patch should apply to linus' latest master down to rather old linux-2.6
trees.
Yours,
David
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index fd88ede..957a66f 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -183,8 +183,10 @@ static int __init _omap_mux_get_by_name(struct
omap_mux_partition *partition,
m0_entry = mux-muxnames[0];
/* First check for full name in mode0.muxmode format */
- if (mode0_len strncmp(muxname, m0_entry, mode0_len))
- continue;
+ if (mode0_len)
+ if (strncmp(muxname, m0_entry, mode0_len)
+ ||(strlen(m0_entry) != mode0_len))
+ continue;
/* Then check for muxmode only */
for (i = 0; i OMAP_MUX_NR_MODES; i++) {
signature.asc
Description: Digital signature
