Re: [PATCH V2 2/2] Input: misc: introduce palmas-pwrbutton
On Thu, Sep 11, 2014 at 07:01:19AM -0500, Nishanth Menon wrote: Hi Dimtry, On 14:13-20140910, Dmitry Torokhov wrote: On Thu, Aug 21, 2014 at 02:01:43PM -0500, Nishanth Menon wrote: On 08/21/2014 01:03 PM, Dmitry Torokhov wrote: I believe I have taken care of other concerns on v2, but..Arrgh.. I did not reply to this comment.. BTW, I do not think you need to use of_node_get/put here, it's not going anywhere. It has been mentioned as a good practice to ensure we use get_put in to ensure reference count is appropriately maintained. So, I have'nt changed that in v3. You only need to maintain reference count if you pass the handle on. Otherwise you'd have to do get/put every time you dereference something. Anyway, I did a few changes to the driver (no need to store current state, do not fre einput device after unregister, etc.), could you please tell me if the version below still works for you? [...] Thanks for taking the time to do all the changes - they are awesome and the resultant driver does work. Thank you for [re]testing. I queued the driver for the next merge window. -- Dmitry -- 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 1/2] ARM: dts: dra7: Add CPSW and MDIO module nodes for dra7
On Friday 12 September 2014 02:59 AM, Lennart Sorensen wrote: I have the mac but I don't want to use both ports on the 2 port switch. In fact in our case ethernet1 is a pru_eth interface. Can a board dts override the alias for ethernet1 or is that a syntax error? I don't think I tried that yet. You can override it in board dts file Regards Mugunthan V N -- 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 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On 09/11/2014 07:04 PM, Frans Klaver wrote: On 11 September 2014 18:04:32 CEST, Sebastian Andrzej Siewior bige...@linutronix.de wrote: On 09/11/2014 05:11 PM, Frans Klaver wrote: I can still reproduce it on am335x. I can get out of it as soon as something else gets written to the console though. # echo 3something /dev/kmsg Is this to stall it or to get out of it? This is to get out of it. I do this from an ssh connection after the console got stuck. The 3 kind of ensures the message is actually sent to ttyS0. Interesting. This shouldn't do anything. If there is a TX operation in progress then -start_tx() will simply return and the xmit buffer will be send once the current TX operation completes. Is there anything I can do to reproduce this behavior? This problem only pops-up if you use DMA. With disabled DMA you don't see this, right? Sebastian -- 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] mmc: omap_hsmmc: Add small delay after enabling power
On 11.09.2014 16:15, Ulf Hansson wrote: On 11 September 2014 16:11, Stefan Roese s...@denx.de wrote: From: Thorsten Einsbein thorsten.eisb...@head-acoustics.de On the TAO3530 (OMAP3530 based) we noticed that some SD cards are not detected reliably upon bootup (timeout). Especially the SanDisk Ultra 8GiB seems to be problematic here. The SanDisk Extreme also has this problem on this platform, but not that often. A Samsung 8 GiB type 6 doesn't show this problem at all. This patch now adds a short delay after enabling the power on the slot. With this delay all cards are detected reliably. Is this delay related to regulator ramp up/down time? Then I think it maybe should be a part of the regulator code/DT. Thanks for this feedback. Yes, adding regulator-enable-ramp-delay to the regulator(s) solves this issue too. I wasn't aware of that one. The patch can be dropped. Thanks, Stefan -- 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] clk: don't use __initconst for non-const arrays
On 12 September 2014 00:04, Uwe Kleine-König
u.kleine-koe...@pengutronix.de wrote:
Hello,
On Thu, Sep 11, 2014 at 11:04:31PM +0200, Uwe Kleine-König wrote:
/* Mux parent lists. */
-static const char *fin_pll_p[] __initconst = {
+static const char *fin_pll_p[] __initdata = {
xxti,
xusbxti
};
As discussed with Tomasz on irc: The sad thing here is that for this
array only 8 bytes are freed when .init.rodata is thrown away (that is
two pointers). The actual data---5 + 8 bytes + maybe aligning---isn't
freed though.
We wondered if there is a nice and easy way to throw away the
characters, too.
The only way I currently see is:
const char xxti[] __initconst = xxti;
...
static const char *fin_pll_p[] __initdata = {
xxti,
...
};
but this definitively doesn't qualify as nice and easy. Is there an
alternative?
What about doing
static const char fin_pll_p[][8] __initconst = {
xxti,
xusbxti
};
--
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] clk: don't use __initconst for non-const arrays
Hello Ard,
On Fri, Sep 12, 2014 at 09:42:29AM +0200, Ard Biesheuvel wrote:
On 12 September 2014 00:04, Uwe Kleine-König
u.kleine-koe...@pengutronix.de wrote:
Hello,
On Thu, Sep 11, 2014 at 11:04:31PM +0200, Uwe Kleine-König wrote:
/* Mux parent lists. */
-static const char *fin_pll_p[] __initconst = {
+static const char *fin_pll_p[] __initdata = {
xxti,
xusbxti
};
As discussed with Tomasz on irc: The sad thing here is that for this
array only 8 bytes are freed when .init.rodata is thrown away (that is
two pointers). The actual data---5 + 8 bytes + maybe aligning---isn't
freed though.
We wondered if there is a nice and easy way to throw away the
characters, too.
The only way I currently see is:
const char xxti[] __initconst = xxti;
...
static const char *fin_pll_p[] __initdata = {
xxti,
...
};
but this definitively doesn't qualify as nice and easy. Is there an
alternative?
What about doing
static const char fin_pll_p[][8] __initconst = {
xxti,
xusbxti
};
This results in the strings being moved to .init.rodata and so they are
discarded. But it also results in:
drivers/clk/samsung/clk-s5pv210.c:412:2: warning: initialization from
incompatible pointer type [enabled by default]
MUX_F(FIN_PLL, fin_pll, fin_pll_p, OM_STAT, 0, 1,
^
drivers/clk/samsung/clk-s5pv210.c:412:2: warning: (near initialization
for 'early_mux_clks[0].parent_names') [enabled by default]
That's because early_mux_clks[0].parent_names is of type const char **
while fin_pll_p as suggested doesn't provide an array of pointers to the
start of the contained strings.
I don't see a way to fix that unless we fix the maximal clock name
length globally and so waste much memory.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
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] PM / OPP: Remove ARCH_HAS_OPP completely
The Kconfig symbol ARCH_HAS_OPP became redundant in v3.16: commit 049d595a4db3 (PM / OPP: Make OPP invisible to users in Kconfig) removed the only dependency that used it. Setting it had no effect anymore. So commit 78c5e0bb145d (PM / OPP: Remove ARCH_HAS_OPP) removed it. For some reason that commit did not remove all select statements for that symbol. These statements are useless. Remove them too. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Done on top of next-20140912. Tested with git grep only! arch/arm/mach-omap2/Kconfig| 5 - arch/arm/mach-shmobile/Kconfig | 1 - drivers/devfreq/Kconfig| 1 - 3 files changed, 7 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 5b103099626d..f138bd33a463 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -22,7 +22,6 @@ config ARCH_OMAP4 bool TI OMAP4 depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP select ARM_CPU_SUSPEND if PM select ARM_ERRATA_720789 @@ -41,7 +40,6 @@ config SOC_OMAP5 bool TI OMAP5 depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_CPU_SUSPEND if PM select ARM_GIC select HAVE_ARM_SCU if SMP @@ -53,14 +51,12 @@ config SOC_AM33XX bool TI AM33XX depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_CPU_SUSPEND if PM config SOC_AM43XX bool TI AM43x depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_GIC select MACH_OMAP_GENERIC select MIGHT_HAVE_CACHE_L2X0 @@ -69,7 +65,6 @@ config SOC_DRA7XX bool TI DRA7XX depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_CPU_SUSPEND if PM select ARM_GIC select HAVE_ARM_ARCH_TIMER diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig index 21f457b56c01..f59019dd986e 100644 --- a/arch/arm/mach-shmobile/Kconfig +++ b/arch/arm/mach-shmobile/Kconfig @@ -36,7 +36,6 @@ menuconfig ARCH_SHMOBILE_MULTI select NO_IOPORT_MAP select PINCTRL select ARCH_REQUIRE_GPIOLIB - select ARCH_HAS_OPP if ARCH_SHMOBILE_MULTI diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig index 3dced0a9eae3..2227e9bf3884 100644 --- a/drivers/devfreq/Kconfig +++ b/drivers/devfreq/Kconfig @@ -80,7 +80,6 @@ config ARM_EXYNOS4_BUS_DEVFREQ config ARM_EXYNOS5_BUS_DEVFREQ bool ARM Exynos5250 Bus DEVFREQ Driver depends on SOC_EXYNOS5250 - select ARCH_HAS_OPP select DEVFREQ_GOV_SIMPLE_ONDEMAND select PM_OPP help -- 1.9.3 -- 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 0/3] nand: Renaming, moving and fixing NAND and ELM drivers
Hi Ezequiel,
On 09/11/2014 04:47 PM, Ezequiel Garcia wrote:
Following the recent discussion with Roger, here's a few patches that
(hopefully) fix all the issues.
The first patches rename the OMAP NAND drivers, so they are now called
omap2_nand and omap_elm.
The last patch picks an idea from Yann E. Morin and fixes the build issue
reported by Roger. Quoting Roger:
I still get the following error if I set CONFIG_MTD_NAND_OMAP2 to y and
CONFIG_MTD_NAND_OMAP_BCH to m.
CONFIG_MTD_NAND_OMAP_BCH is used to select the ELM driver and it must be
limited to
be built-in if CONFIG_MTD_NAND_OMAP2 is built-in.
Maybe it should be a sub option of CONFIG_MTD_NAND_OMAP2.
IMHO the elm.c file must be moved from mtd/devices to mtd/nand and renamed to
omap_elm.c
drivers/built-in.o: In function `omap_nand_probe':
/work/linux-2.6/drivers/mtd/nand/omap2.c:2010: undefined reference to
`elm_config'
/work/linux-2.6/drivers/mtd/nand/omap2.c:1980: undefined reference to
`elm_config'
/work/linux-2.6/drivers/mtd/nand/omap2.c:1927: undefined reference to
`elm_config'
drivers/built-in.o: In function `omap_elm_correct_data':
/work/linux-2.6/drivers/mtd/nand/omap2.c:1444: undefined reference to
`elm_decode_bch_error_page'
make: *** [vmlinux] Error 1
[1] https://lkml.org/lkml/2013/5/4/84
Ezequiel Garcia (3):
mtd: nand: Move ELM driver and rename as omap_elm
mtd: nand: Rename OMAP NAND driver
mtd: nand: Force omap_elm to be built as a module if omap2_nand is a
module
Thanks for the patches. I see a lot of errors reported by checkpatch.pl which
need fixing.
cheers,
-roger
drivers/mtd/devices/Makefile | 1 -
drivers/mtd/nand/Kconfig | 8 +++-
drivers/mtd/nand/Makefile | 3 ++-
drivers/mtd/nand/{omap2.c = omap2_nand.c} | 0
drivers/mtd/{devices/elm.c = nand/omap_elm.c} | 0
5 files changed, 9 insertions(+), 3 deletions(-)
rename drivers/mtd/nand/{omap2.c = omap2_nand.c} (100%)
rename drivers/mtd/{devices/elm.c = nand/omap_elm.c} (100%)
--
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 2/3] mtd: nand: Rename OMAP NAND driver
On 09/11/2014 04:47 PM, Ezequiel Garcia wrote:
Rename it to a less generic name, so the module is built with a meaningful
name instead of the previous 'omap2.ko'.
Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
Acked-by: Roger Quadros rog...@ti.com
---
drivers/mtd/nand/Makefile | 2 +-
drivers/mtd/nand/{omap2.c = omap2_nand.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename drivers/mtd/nand/{omap2.c = omap2_nand.c} (100%)
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index b3237b7..4bcdeb0 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -26,7 +26,7 @@ obj-$(CONFIG_MTD_NAND_CS553X) += cs553x_nand.o
obj-$(CONFIG_MTD_NAND_NDFC) += ndfc.o
obj-$(CONFIG_MTD_NAND_ATMEL) += atmel_nand.o
obj-$(CONFIG_MTD_NAND_GPIO) += gpio.o
-obj-$(CONFIG_MTD_NAND_OMAP2) += omap2.o
+obj-$(CONFIG_MTD_NAND_OMAP2) += omap2_nand.o
obj-$(CONFIG_MTD_NAND_OMAP_BCH) += omap_elm.o
obj-$(CONFIG_MTD_NAND_CM_X270) += cmx270_nand.o
obj-$(CONFIG_MTD_NAND_PXA3xx)+= pxa3xx_nand.o
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2_nand.c
similarity index 100%
rename from drivers/mtd/nand/omap2.c
rename to drivers/mtd/nand/omap2_nand.c
--
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 1/3] mtd: nand: Move ELM driver and rename as omap_elm
On 09/11/2014 04:47 PM, Ezequiel Garcia wrote:
The ELM driver is only used by the OMAP NAND driver, so let's move it
to the nand/ directory. Additionally, let's rename it to a less confusing
name, so the module is built with a meaningful name, instead of the previous
'elm.ko'.
Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar
Acked-by: Roger Quadros rog...@ti.com
---
drivers/mtd/devices/Makefile | 1 -
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/{devices/elm.c = nand/omap_elm.c} | 0
3 files changed, 1 insertion(+), 1 deletion(-)
rename drivers/mtd/{devices/elm.c = nand/omap_elm.c} (100%)
diff --git a/drivers/mtd/devices/Makefile b/drivers/mtd/devices/Makefile
index c68868f..f0b0e61 100644
--- a/drivers/mtd/devices/Makefile
+++ b/drivers/mtd/devices/Makefile
@@ -12,7 +12,6 @@ obj-$(CONFIG_MTD_LART) += lart.o
obj-$(CONFIG_MTD_BLOCK2MTD) += block2mtd.o
obj-$(CONFIG_MTD_DATAFLASH) += mtd_dataflash.o
obj-$(CONFIG_MTD_M25P80) += m25p80.o
-obj-$(CONFIG_MTD_NAND_OMAP_BCH) += elm.o
obj-$(CONFIG_MTD_SPEAR_SMI) += spear_smi.o
obj-$(CONFIG_MTD_SST25L) += sst25l.o
obj-$(CONFIG_MTD_BCM47XXSFLASH) += bcm47xxsflash.o
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index a035e7c..b3237b7 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_MTD_NAND_NDFC) += ndfc.o
obj-$(CONFIG_MTD_NAND_ATMEL) += atmel_nand.o
obj-$(CONFIG_MTD_NAND_GPIO) += gpio.o
obj-$(CONFIG_MTD_NAND_OMAP2) += omap2.o
+obj-$(CONFIG_MTD_NAND_OMAP_BCH) += omap_elm.o
obj-$(CONFIG_MTD_NAND_CM_X270) += cmx270_nand.o
obj-$(CONFIG_MTD_NAND_PXA3xx)+= pxa3xx_nand.o
obj-$(CONFIG_MTD_NAND_TMIO) += tmio_nand.o
diff --git a/drivers/mtd/devices/elm.c b/drivers/mtd/nand/omap_elm.c
similarity index 100%
rename from drivers/mtd/devices/elm.c
rename to drivers/mtd/nand/omap_elm.c
--
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 3/3] mtd: nand: Force omap_elm to be built as a module if omap2_nand is a module
On 09/11/2014 04:47 PM, Ezequiel Garcia wrote: This commit adds a hidden option to build the omap_elm as a module, if omap2_nand is a module (and similarly in the built-in case). This fixes the following build error when omap2_nand is chosen built-in, and omap_elm is chosen as a module: drivers/built-in.o: In function `omap_nand_probe': /work/linux-2.6/drivers/mtd/nand/omap2.c:2010: undefined reference to `elm_config' /work/linux-2.6/drivers/mtd/nand/omap2.c:1980: undefined reference to `elm_config' /work/linux-2.6/drivers/mtd/nand/omap2.c:1927: undefined reference to `elm_config' drivers/built-in.o: In function `omap_elm_correct_data': /work/linux-2.6/drivers/mtd/nand/omap2.c:1444: undefined reference to `elm_decode_bch_error_page' Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar --- drivers/mtd/nand/Kconfig | 8 +++- drivers/mtd/nand/Makefile | 2 +- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index f1cf503..12e8ee8 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -96,7 +96,7 @@ config MTD_NAND_OMAP2 config MTD_NAND_OMAP_BCH depends on MTD_NAND_OMAP2 - tristate Support hardware based BCH error correction + bool Support hardware based BCH error correction default n select BCH help @@ -106,6 +106,12 @@ config MTD_NAND_OMAP_BCH legacy OMAP families like OMAP2xxx, OMAP3xxx do not have ELM engine so they should not enable this config symbol. +config MTD_NAND_OMAP_BCH_BUILD + tristate + depends on MTD_NAND_OMAP2 + default m if MTD_NAND_OMAP2=m MTD_NAND_OMAP_BCH + default y if MTD_NAND_OMAP2=y MTD_NAND_OMAP_BCH + config MTD_NAND_IDS tristate diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 4bcdeb0..3580188 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -27,7 +27,7 @@ obj-$(CONFIG_MTD_NAND_NDFC) += ndfc.o obj-$(CONFIG_MTD_NAND_ATMEL) += atmel_nand.o obj-$(CONFIG_MTD_NAND_GPIO) += gpio.o obj-$(CONFIG_MTD_NAND_OMAP2) += omap2_nand.o -obj-$(CONFIG_MTD_NAND_OMAP_BCH) += omap_elm.o +obj-$(CONFIG_MTD_NAND_OMAP_BCH_BUILD)+= omap_elm.o obj-$(CONFIG_MTD_NAND_CM_X270) += cmx270_nand.o obj-$(CONFIG_MTD_NAND_PXA3xx)+= pxa3xx_nand.o obj-$(CONFIG_MTD_NAND_TMIO) += tmio_nand.o The overall logic seems to work but I still see the following issue. In menuconfig, the OMAP_BCH option is still visible as a boolean even though the ELM module finally gets built as a module. This can be confusing to the user and I'd avoid that behaviour. cheers, -roger -- 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 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On 09/12/2014 11:40 AM, Frans Klaver wrote: I'm not sure. I just reproduced this on a boneblack, using your uart_v9 branch. This problem only pops-up if you use DMA. With disabled DMA you don't see this, right? I get the lockup both with and without DMA enabled. Here's the 8250 config I use. Our full .config is attached in case it may provide something relevant. Hmm. I have a bone black here. Can you tell what you did to get this lockup? The port configuration (unless 115200 8N1) and what you did to get this lockup. Something that may also help: when I have a lockup on the boneblack, dma is enabled and something is written to console like I described earlier, I get the following bad irq: Full dmesg is also attached. This one should be stuffed by this: [RFC] ARM: edma: unconditionally ack the error interrupt https://lkml.org/lkml/2014/9/10/714 Hope you find something useful in there. Thanks, Frans Sebastian -- 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] PM / OPP: Remove ARCH_HAS_OPP completely
On Fri, Sep 12, 2014 at 3:38 AM, Paul Bolle pebo...@tiscali.nl wrote: The Kconfig symbol ARCH_HAS_OPP became redundant in v3.16: commit 049d595a4db3 (PM / OPP: Make OPP invisible to users in Kconfig) removed the only dependency that used it. Setting it had no effect anymore. So commit 78c5e0bb145d (PM / OPP: Remove ARCH_HAS_OPP) removed it. For some reason that commit did not remove all select statements for that symbol. These statements are useless. Remove them too. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Done on top of next-20140912. Tested with git grep only! arch/arm/mach-omap2/Kconfig| 5 - there can be conflict here: https://patchwork.kernel.org/patch/4857231/ http://marc.info/?l=linux-omapm=141047815520894w=2 arch/arm/mach-shmobile/Kconfig | 1 - drivers/devfreq/Kconfig| 1 - 3 files changed, 7 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index 5b103099626d..f138bd33a463 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -22,7 +22,6 @@ config ARCH_OMAP4 bool TI OMAP4 depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARCH_NEEDS_CPU_IDLE_COUPLED if SMP select ARM_CPU_SUSPEND if PM select ARM_ERRATA_720789 @@ -41,7 +40,6 @@ config SOC_OMAP5 bool TI OMAP5 depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_CPU_SUSPEND if PM select ARM_GIC select HAVE_ARM_SCU if SMP @@ -53,14 +51,12 @@ config SOC_AM33XX bool TI AM33XX depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_CPU_SUSPEND if PM config SOC_AM43XX bool TI AM43x depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_GIC select MACH_OMAP_GENERIC select MIGHT_HAVE_CACHE_L2X0 @@ -69,7 +65,6 @@ config SOC_DRA7XX bool TI DRA7XX depends on ARCH_MULTI_V7 select ARCH_OMAP2PLUS - select ARCH_HAS_OPP select ARM_CPU_SUSPEND if PM select ARM_GIC select HAVE_ARM_ARCH_TIMER diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig index 21f457b56c01..f59019dd986e 100644 --- a/arch/arm/mach-shmobile/Kconfig +++ b/arch/arm/mach-shmobile/Kconfig @@ -36,7 +36,6 @@ menuconfig ARCH_SHMOBILE_MULTI select NO_IOPORT_MAP select PINCTRL select ARCH_REQUIRE_GPIOLIB - select ARCH_HAS_OPP if ARCH_SHMOBILE_MULTI diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig index 3dced0a9eae3..2227e9bf3884 100644 --- a/drivers/devfreq/Kconfig +++ b/drivers/devfreq/Kconfig @@ -80,7 +80,6 @@ config ARM_EXYNOS4_BUS_DEVFREQ config ARM_EXYNOS5_BUS_DEVFREQ bool ARM Exynos5250 Bus DEVFREQ Driver depends on SOC_EXYNOS5250 - select ARCH_HAS_OPP select DEVFREQ_GOV_SIMPLE_ONDEMAND select PM_OPP help -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-pm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- --- 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: [PATCH 09/16] tty: serial: 8250_dma: Add a TX trigger workaround for AM33xx
On Fri, Sep 12, 2014 at 11:51:22AM +0200, Sebastian Andrzej Siewior wrote: On 09/12/2014 11:40 AM, Frans Klaver wrote: I'm not sure. I just reproduced this on a boneblack, using your uart_v9 branch. This problem only pops-up if you use DMA. With disabled DMA you don't see this, right? I get the lockup both with and without DMA enabled. Here's the 8250 config I use. Our full .config is attached in case it may provide something relevant. Hmm. I have a bone black here. Can you tell what you did to get this lockup? The port configuration (unless 115200 8N1) and what you did to get this lockup. port config is 115200 8N1. I don't recall doing anything special. I boot, login, less file and get a lock. Something that may also help: when I have a lockup on the boneblack, dma is enabled and something is written to console like I described earlier, I get the following bad irq: Full dmesg is also attached. This one should be stuffed by this: [RFC] ARM: edma: unconditionally ack the error interrupt https://lkml.org/lkml/2014/9/10/714 OK, that makes the console usable again after I write something to kmsg. Hope you find something useful in there. Thanks, Frans Sebastian -- 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] PM / OPP: Remove ARCH_HAS_OPP completely
On Fri, 2014-09-12 at 05:20 -0500, Nishanth Menon wrote: On Fri, Sep 12, 2014 at 3:38 AM, Paul Bolle pebo...@tiscali.nl wrote: The Kconfig symbol ARCH_HAS_OPP became redundant in v3.16: commit 049d595a4db3 (PM / OPP: Make OPP invisible to users in Kconfig) removed the only dependency that used it. Setting it had no effect anymore. So commit 78c5e0bb145d (PM / OPP: Remove ARCH_HAS_OPP) removed it. For some reason that commit did not remove all select statements for that symbol. These statements are useless. Remove them too. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Done on top of next-20140912. Tested with git grep only! arch/arm/mach-omap2/Kconfig| 5 - there can be conflict here: https://patchwork.kernel.org/patch/4857231/ http://marc.info/?l=linux-omapm=141047815520894w=2 Thanks. arch/arm/mach-shmobile/Kconfig | 1 - drivers/devfreq/Kconfig| 1 - Were patches submitted for these two files too? If so, we can probably just drop my patch. Paul Bolle -- 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] PM / OPP: Remove ARCH_HAS_OPP completely
Hi Paul, Rafael,
On Fri, Sep 12, 2014 at 12:46 PM, Paul Bolle pebo...@tiscali.nl wrote:
arch/arm/mach-shmobile/Kconfig | 1 -
drivers/devfreq/Kconfig| 1 -
Were patches submitted for these two files too? If so, we can probably
just drop my patch.
Rafael said: I've queued this up for 3.17, thanks!
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/274681.html
But it's not in -next.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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] PM / OPP: Remove ARCH_HAS_OPP completely
On Fri, 2014-09-12 at 13:03 +0200, Geert Uytterhoeven wrote: Hi Paul, Rafael, On Fri, Sep 12, 2014 at 12:46 PM, Paul Bolle pebo...@tiscali.nl wrote: arch/arm/mach-shmobile/Kconfig | 1 - drivers/devfreq/Kconfig| 1 - Were patches submitted for these two files too? If so, we can probably just drop my patch. Rafael said: I've queued this up for 3.17, thanks! http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/274681.html But it's not in -next. I think that patch landed as commit 78c5e0bb145d. But for some unknown reason it didn't remove all selects statements for ARCH_HAS_OPP. The odd thing here is that the last select statements I remove in this patch are all to be found in Kconfig files that actually were touched in that commit. Perhaps these select statements were merged back in during conflict resolution. I have no idea. Paul Bolle -- 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
[PATCHv2] clk: ti: change clock init to use generic of_clk_init
Previously, the TI clock driver initialized all the clocks hierarchically
under each separate clock provider node. Now, each clock that requires
IO access will instead check their parent node to find out which IO range
to use.
This patch allows the TI clock driver to use a few new features provided
by the generic of_clk_init, and also allows registration of clock nodes
outside the clock hierarchy (for example, any external clocks.)
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
Cc: Tony Lindgren t...@atomide.com
Cc: Mark Rutland mark.rutl...@arm.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: Jyri Sarha jsa...@ti.com
Cc: Stefan Assmann sassm...@kpanic.de
---
Changes from v1:
- fixed the retry logic for deferred clock inits, this wasn't working
properly in v1
arch/arm/mach-omap2/io.c | 12 +--
arch/arm/mach-omap2/prm_common.c |2 --
drivers/clk/ti/clk.c | 68 --
include/linux/clk/ti.h |1 +
4 files changed, 54 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 5d0667c..a1b82a9 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -734,8 +734,16 @@ int __init omap_clk_init(void)
ti_clk_init_features();
ret = of_prcm_init();
- if (!ret)
- ret = omap_clk_soc_init();
+ if (ret)
+ return ret;
+
+ of_clk_init(NULL);
+
+ ti_dt_clk_init_retry_clks();
+
+ ti_dt_clockdomains_setup();
+
+ ret = omap_clk_soc_init();
return ret;
}
diff --git a/arch/arm/mach-omap2/prm_common.c b/arch/arm/mach-omap2/prm_common.c
index 76ca320..3b89080 100644
--- a/arch/arm/mach-omap2/prm_common.c
+++ b/arch/arm/mach-omap2/prm_common.c
@@ -525,8 +525,6 @@ int __init of_prcm_init(void)
memmap_index++;
}
- ti_dt_clockdomains_setup();
-
return 0;
}
diff --git a/drivers/clk/ti/clk.c b/drivers/clk/ti/clk.c
index b1a6f71..337abe5 100644
--- a/drivers/clk/ti/clk.c
+++ b/drivers/clk/ti/clk.c
@@ -25,8 +25,8 @@
#undef pr_fmt
#define pr_fmt(fmt) %s: fmt, __func__
-static int ti_dt_clk_memmap_index;
struct ti_clk_ll_ops *ti_clk_ll_ops;
+static struct device_node *clocks_node_ptr[CLK_MAX_MEMMAPS];
/**
* ti_dt_clocks_register - register DT alias clocks during boot
@@ -108,9 +108,21 @@ void __iomem *ti_clk_get_reg_addr(struct device_node
*node, int index)
struct clk_omap_reg *reg;
u32 val;
u32 tmp;
+ int i;
reg = (struct clk_omap_reg *)tmp;
- reg-index = ti_dt_clk_memmap_index;
+
+ for (i = 0; i CLK_MAX_MEMMAPS; i++) {
+ if (clocks_node_ptr[i] == node-parent)
+ break;
+ }
+
+ if (i == CLK_MAX_MEMMAPS) {
+ pr_err(clk-provider not found for %s!\n, node-name);
+ return NULL;
+ }
+
+ reg-index = i;
if (of_property_read_u32_index(node, reg, index, val)) {
pr_err(%s must have reg[%d]!\n, node-name, index);
@@ -127,20 +139,14 @@ void __iomem *ti_clk_get_reg_addr(struct device_node
*node, int index)
* @parent: master node
* @index: internal index for clk_reg_ops
*
- * Initializes a master clock IP block and its child clock nodes.
- * Regmap is provided for accessing the register space for the
- * IP block and all the clocks under it.
+ * Initializes a master clock IP block. This basically sets up the
+ * mapping from clocks node to the memory map index. All the clocks
+ * are then initialized through the common of_clk_init call, and the
+ * clocks will access their memory maps based on the node layout.
*/
void ti_dt_clk_init_provider(struct device_node *parent, int index)
{
- const struct of_device_id *match;
- struct device_node *np;
struct device_node *clocks;
- of_clk_init_cb_t clk_init_cb;
- struct clk_init_item *retry;
- struct clk_init_item *tmp;
-
- ti_dt_clk_memmap_index = index;
/* get clocks for this parent */
clocks = of_get_child_by_name(parent, clocks);
@@ -149,19 +155,31 @@ void ti_dt_clk_init_provider(struct device_node *parent,
int index)
return;
}
- for_each_child_of_node(clocks, np) {
- match = of_match_node(__clk_of_table, np);
- if (!match)
- continue;
- clk_init_cb = (of_clk_init_cb_t)match-data;
- pr_debug(%s: initializing: %s\n, __func__, np-name);
- clk_init_cb(np);
- }
+ /* add clocks node info */
+ clocks_node_ptr[index] = clocks;
+}
- list_for_each_entry_safe(retry, tmp, retry_list, link) {
- pr_debug(retry-init: %s\n, retry-node-name);
- retry-func(retry-hw, retry-node);
- list_del(retry-link);
- kfree(retry);
+/**
+ *
[PATCH] clk: ti: dra7-atl-clock: fix a memory leak
of_clk_add_provider makes an internal copy of the parent_names property
while its called, thus it is no longer needed after this call and can
be freed.
Signed-off-by: Tero Kristo t-kri...@ti.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/clk/ti/clk-dra7-atl.c |1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/ti/clk-dra7-atl.c b/drivers/clk/ti/clk-dra7-atl.c
index 4a65b41..3f9308a 100644
--- a/drivers/clk/ti/clk-dra7-atl.c
+++ b/drivers/clk/ti/clk-dra7-atl.c
@@ -199,6 +199,7 @@ static void __init of_dra7_atl_clock_setup(struct
device_node *node)
if (!IS_ERR(clk)) {
of_clk_add_provider(node, of_clk_src_simple_get, clk);
+ kfree(parent_names);
return;
}
cleanup:
--
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 0/3] nand: Renaming, moving and fixing NAND and ELM drivers
On 12 September 2014 09:54, Roger Quadros rog...@ti.com wrote: Hi Ezequiel, On 09/11/2014 04:47 PM, Ezequiel Garcia wrote: Following the recent discussion with Roger, here's a few patches that (hopefully) fix all the issues. The first patches rename the OMAP NAND drivers, so they are now called omap2_nand and omap_elm. The last patch picks an idea from Yann E. Morin and fixes the build issue reported by Roger. Quoting Roger: I still get the following error if I set CONFIG_MTD_NAND_OMAP2 to y and CONFIG_MTD_NAND_OMAP_BCH to m. CONFIG_MTD_NAND_OMAP_BCH is used to select the ELM driver and it must be limited to be built-in if CONFIG_MTD_NAND_OMAP2 is built-in. Maybe it should be a sub option of CONFIG_MTD_NAND_OMAP2. IMHO the elm.c file must be moved from mtd/devices to mtd/nand and renamed to omap_elm.c drivers/built-in.o: In function `omap_nand_probe': /work/linux-2.6/drivers/mtd/nand/omap2.c:2010: undefined reference to `elm_config' /work/linux-2.6/drivers/mtd/nand/omap2.c:1980: undefined reference to `elm_config' /work/linux-2.6/drivers/mtd/nand/omap2.c:1927: undefined reference to `elm_config' drivers/built-in.o: In function `omap_elm_correct_data': /work/linux-2.6/drivers/mtd/nand/omap2.c:1444: undefined reference to `elm_decode_bch_error_page' make: *** [vmlinux] Error 1 [1] https://lkml.org/lkml/2013/5/4/84 Ezequiel Garcia (3): mtd: nand: Move ELM driver and rename as omap_elm mtd: nand: Rename OMAP NAND driver mtd: nand: Force omap_elm to be built as a module if omap2_nand is a module Thanks for the patches. I see a lot of errors reported by checkpatch.pl which need fixing. You mean on these patches or across the file? -- Ezequiel García, VanguardiaSur www.vanguardiasur.com.ar -- 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 3/3] mtd: nand: Force omap_elm to be built as a module if omap2_nand is a module
On 12 Sep 12:01 PM, Roger Quadros wrote: On 09/11/2014 04:47 PM, Ezequiel Garcia wrote: This commit adds a hidden option to build the omap_elm as a module, if omap2_nand is a module (and similarly in the built-in case). This fixes the following build error when omap2_nand is chosen built-in, and omap_elm is chosen as a module: drivers/built-in.o: In function `omap_nand_probe': /work/linux-2.6/drivers/mtd/nand/omap2.c:2010: undefined reference to `elm_config' /work/linux-2.6/drivers/mtd/nand/omap2.c:1980: undefined reference to `elm_config' /work/linux-2.6/drivers/mtd/nand/omap2.c:1927: undefined reference to `elm_config' drivers/built-in.o: In function `omap_elm_correct_data': /work/linux-2.6/drivers/mtd/nand/omap2.c:1444: undefined reference to `elm_decode_bch_error_page' Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar --- drivers/mtd/nand/Kconfig | 8 +++- drivers/mtd/nand/Makefile | 2 +- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index f1cf503..12e8ee8 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -96,7 +96,7 @@ config MTD_NAND_OMAP2 config MTD_NAND_OMAP_BCH depends on MTD_NAND_OMAP2 - tristate Support hardware based BCH error correction + bool Support hardware based BCH error correction default n select BCH help @@ -106,6 +106,12 @@ config MTD_NAND_OMAP_BCH legacy OMAP families like OMAP2xxx, OMAP3xxx do not have ELM engine so they should not enable this config symbol. +config MTD_NAND_OMAP_BCH_BUILD + tristate + depends on MTD_NAND_OMAP2 + default m if MTD_NAND_OMAP2=m MTD_NAND_OMAP_BCH + default y if MTD_NAND_OMAP2=y MTD_NAND_OMAP_BCH + config MTD_NAND_IDS tristate diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 4bcdeb0..3580188 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -27,7 +27,7 @@ obj-$(CONFIG_MTD_NAND_NDFC) += ndfc.o obj-$(CONFIG_MTD_NAND_ATMEL) += atmel_nand.o obj-$(CONFIG_MTD_NAND_GPIO)+= gpio.o obj-$(CONFIG_MTD_NAND_OMAP2) += omap2_nand.o -obj-$(CONFIG_MTD_NAND_OMAP_BCH)+= omap_elm.o +obj-$(CONFIG_MTD_NAND_OMAP_BCH_BUILD) += omap_elm.o obj-$(CONFIG_MTD_NAND_CM_X270) += cmx270_nand.o obj-$(CONFIG_MTD_NAND_PXA3xx) += pxa3xx_nand.o obj-$(CONFIG_MTD_NAND_TMIO)+= tmio_nand.o The overall logic seems to work but I still see the following issue. In menuconfig, the OMAP_BCH option is still visible as a boolean even though the ELM module finally gets built as a module. This can be confusing to the user and I'd avoid that behaviour. Yes, I know. But it's either this solution or no solution at all, I think. Let me give some further context about this patch, so we can have more information to decide. First of all (and IMO) the user doesn't have to know about the ELM being a module or not, because modprobe will load it (since omap2_nand depends on omap_elm's symbols). So, the new way seems a bit more intuitive for me. The user choses if he wants to have hardware BCH support, and such support gets built the right way. If we still consider this highly confusing, and we want to avoid it, then it seems we can only make omap_elm a boolean, which means it'll always be built-in. I crafted this patch in an effort to avoid making it boolean. Finally, the solution is taken from media/usb/stk1160. For good or for bad, we have a precedent in doing things this way. Ultimately, I don't care much as I don't think anyone will build it as a module, except maybe for testing the driver under probe/remove cycles. -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- 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: OMAP3: Fix I/O chain clock line assertion timed out error
We are getting PRM: I/O chain clock line assertion timed out errors
on early omaps for device tree based booting. This is because we are
unconditionally calling reconfigure_io_chain while legacy booting
has omap3_has_io_chain_ctrl() checks in place in omap_hwmod.c.
For device tree based booting, we are calling reconfigure_io_chain
unconditionally from pinctrl framework. So we need to add a check for
omap3_has_io_chain_ctrl() to avoid the errors for trying to access
a register that does not exist.
For es3.0, the documentation in 4.11.2 Device Off-Mode Configuration
just mentions PM_WKEN_WKUP[8] bit. For es3.1, there's a new chapter in
documentation for 4.11.2.2 I/O Wake-Up Mechanism that describes the
PM_WKEN_WKUP[16] ST_IO_CHAIN bit. So PM_WKEN_WKUP[16] bit did not get
added until in es3.1 probaly to fix issues with flakey wake-up events.
We are doing proper checks for ST_IO_CHAIN already in id.c and with
omap3_has_io_chain_ctrl(). For more information, see also commit
b02b917211d5 (ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock
control detection).
Let's fix the issue by selecting the right function during init for
reconfigure_io_chain depending on the omap revision. For es3.0 and
earlier we need to just toggle EN_IO. By doing this, we can move the
check for omap3_has_io_chain_ctrl() from omap_hwmod.c to the init code
in prm_3xxx.c. And then we can unconditionally call reconfigure_io_chain.
Thanks to Paul Walmsley and Nishanth Menon for help with debugging the
issue.
Fixes: 30a69ef785e8 (ARM: OMAP: Move DT wake-up event handling over to use
pinctrl-single-omap)
Cc: Kevin Hilman khil...@kernel.org
Cc: Nishanth Menon n...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Tero Kristo t-kri...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/omap_hwmod.c | 2 +-
arch/arm/mach-omap2/prm3xxx.c| 39 +++
2 files changed, 36 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 8fd87a3..9e91a4e 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -2065,7 +2065,7 @@ static void _reconfigure_io_chain(void)
spin_lock_irqsave(io_chain_lock, flags);
- if (cpu_is_omap34xx() omap3_has_io_chain_ctrl())
+ if (cpu_is_omap34xx())
omap3xxx_prm_reconfigure_io_chain();
else if (cpu_is_omap44xx())
omap44xx_prm_reconfigure_io_chain();
diff --git a/arch/arm/mach-omap2/prm3xxx.c b/arch/arm/mach-omap2/prm3xxx.c
index e0088e0..1c24693 100644
--- a/arch/arm/mach-omap2/prm3xxx.c
+++ b/arch/arm/mach-omap2/prm3xxx.c
@@ -46,7 +46,7 @@ static struct omap_prcm_irq_setup omap3_prcm_irq_setup = {
.ocp_barrier= omap3xxx_prm_ocp_barrier,
.save_and_clear_irqen = omap3xxx_prm_save_and_clear_irqen,
.restore_irqen = omap3xxx_prm_restore_irqen,
- .reconfigure_io_chain = omap3xxx_prm_reconfigure_io_chain,
+ .reconfigure_io_chain = NULL,
};
/*
@@ -370,15 +370,30 @@ void __init omap3_prm_init_pm(bool has_uart4, bool
has_iva)
}
/**
- * omap3xxx_prm_reconfigure_io_chain - clear latches and reconfigure I/O chain
+ * omap3430_pre_es3_1_reconfigure_io_chain - restart wake-up daisy chain
+ *
+ * The ST_IO_CHAIN bit does not exist in 3430 before es3.1. The only
+ * thing we can do is toggle EN_IO bit for earlier omaps.
+ */
+void omap3430_pre_es3_1_reconfigure_io_chain(void)
+{
+ omap2_prm_clear_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
+PM_WKEN);
+ omap2_prm_set_mod_reg_bits(OMAP3430_EN_IO_MASK, WKUP_MOD,
+ PM_WKEN);
+ omap2_prm_read_mod_reg(WKUP_MOD, PM_WKEN);
+}
+
+/**
+ * omap3_prm_reconfigure_io_chain - clear latches and reconfigure I/O chain
*
* Clear any previously-latched I/O wakeup events and ensure that the
* I/O wakeup gates are aligned with the current mux settings. Works
* by asserting WUCLKIN, waiting for WUCLKOUT to be asserted, and then
* deasserting WUCLKIN and clearing the ST_IO_CHAIN WKST bit. No
- * return value.
+ * return value. These registers are only available in 3430 es3.1 and later.
*/
-void omap3xxx_prm_reconfigure_io_chain(void)
+void omap3_prm_reconfigure_io_chain(void)
{
int i = 0;
@@ -401,6 +416,15 @@ void omap3xxx_prm_reconfigure_io_chain(void)
}
/**
+ * omap3xxx_prm_reconfigure_io_chain - reconfigure I/O chain
+ */
+void omap3xxx_prm_reconfigure_io_chain(void)
+{
+ if (omap3_prcm_irq_setup.reconfigure_io_chain)
+ omap3_prcm_irq_setup.reconfigure_io_chain();
+}
+
+/**
* omap3xxx_prm_enable_io_wakeup - enable wakeup events from I/O wakeup latches
*
* Activates the I/O wakeup event latches and allows events logged by
@@ -674,6 +698,13 @@ static int omap3xxx_prm_late_init(void)
}
}
+ if (omap3_has_io_chain_ctrl())
+
[PATCH 1/2] pstore-ram: Fix hangs by using write-combine mappings
From: Rob Herring robherri...@gmail.com
Currently trying to use pstore on at least ARMs can hang as we're
mapping the peristent RAM with pgprot_noncached().
On ARMs, pgprot_noncached() will actually make the memory strongly
ordered, and as the atomic operations pstore uses are implementation
defined for strongly ordered memory, they may not work. So basically
atomic operations have undefined behavior on ARM for device or strongly
ordered memory types.
Let's fix the issue by using write-combine variants for mappings. This
corresponds to normal, non-cacheable memory on ARM. For many other
architectures, this change does not change the mapping type as by
default we have:
#define pgprot_writecombine pgprot_noncached
The reason why pgprot_noncached() was originaly used for pstore
is because Colin Cross ccr...@android.com had observed lost
debug prints right before a device hanging write operation on some
systems. For the platforms supporting pgprot_noncached(), we can
add a an optional configuration option to support that. But let's
get pstore working first before adding new features.
Cc: Arnd Bergmann a...@arndb.de
Cc: Anton Vorontsov cbouatmai...@gmail.com
Cc: Colin Cross ccr...@android.com
Cc: Kees Cook keesc...@chromium.org
Cc: Olof Johansson o...@lixom.net
Cc: Tony Luck tony.l...@intel.com
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Rob Herring rob.herr...@calxeda.com
[t...@atomide.com: updated description]
Signed-off-by: Tony Lindgren t...@atomide.com
---
fs/pstore/ram_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c
index 9d7b9a8..24f94b0 100644
--- a/fs/pstore/ram_core.c
+++ b/fs/pstore/ram_core.c
@@ -392,7 +392,7 @@ static void *persistent_ram_vmap(phys_addr_t start, size_t
size)
page_start = start - offset_in_page(start);
page_count = DIV_ROUND_UP(size + offset_in_page(start), PAGE_SIZE);
- prot = pgprot_noncached(PAGE_KERNEL);
+ prot = pgprot_writecombine(PAGE_KERNEL);
pages = kmalloc_array(page_count, sizeof(struct page *), GFP_KERNEL);
if (!pages) {
@@ -422,7 +422,7 @@ static void *persistent_ram_iomap(phys_addr_t start, size_t
size)
buffer_start_add = buffer_start_add_locked;
buffer_size_add = buffer_size_add_locked;
- return ioremap(start, size);
+ return ioremap_wc(start, size);
}
static int persistent_ram_buffer_map(phys_addr_t start, phys_addr_t size,
--
2.1.0
--
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 2/2] pstore-ram: Allow optional mapping with pgprot_noncached
On some ARMs at least the memory can be mapped pgprot_noncached()
and still be working for atomic operations. As pointed out by
Colin Cross ccr...@android.com, in some cases you do want to use
pgprot_noncached() if the SoC supports it to see a debug printk
just before a write hanging the system.
On ARMs, the atomic operations on strongly ordered memory are
implementation defined. So let's provide an optional kernel parameter
for configuring noncached memory, and use pgprot_writecombine() by
default.
Cc: Arnd Bergmann a...@arndb.de
Cc: Rob Herring robherri...@gmail.com
Cc: Randy Dunlap rdun...@infradead.org
Cc: Anton Vorontsov an...@enomsg.org
Cc: Colin Cross ccr...@android.com
Cc: Kees Cook keesc...@chromium.org
Cc: Olof Johansson o...@lixom.net
Cc: Tony Luck tony.l...@intel.com
Cc: Russell King li...@arm.linux.org.uk
Signed-off-by: Tony Lindgren t...@atomide.com
---
Documentation/ramoops.txt | 12 ++--
fs/pstore/ram.c| 13 +++--
fs/pstore/ram_core.c | 31 ++-
include/linux/pstore_ram.h | 4 +++-
4 files changed, 46 insertions(+), 14 deletions(-)
diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
index 69b3cac..2dab135 100644
--- a/Documentation/ramoops.txt
+++ b/Documentation/ramoops.txt
@@ -14,11 +14,18 @@ survive after a restart.
1. Ramoops concepts
-Ramoops uses a predefined memory area to store the dump. The start and size of
-the memory area are set using two variables:
+Ramoops uses a predefined memory area to store the dump. The start and size
+and type of the memory area are set using three variables:
* mem_address for the start
* mem_size for the size. The memory size will be rounded down to a
power of two.
+ * mem_cached to specifiy if the memory is cached or not.
+
+Note disabling mem_cached may not be supported on all architectures as
+pstore depends on atomic operations. At least on ARM, clearing mem_cached
+will cause the memory to be mapped strongly ordered. And atomic operations
+on strongly ordered memory are implementation defined, and won't work on
+many ARMs such as omap.
The memory area is divided into record_size chunks (also rounded down to
power of two) and each oops/panic writes a record_size chunk of
@@ -55,6 +62,7 @@ Setting the ramoops parameters can be done in 2 different
manners:
static struct ramoops_platform_data ramoops_data = {
.mem_size = ...,
.mem_address= ...,
+.mem_cached = ...,
.record_size= ...,
.dump_oops = ...,
.ecc= ...,
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 3b57443..53ddcb2 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -61,6 +61,11 @@ module_param(mem_size, ulong, 0400);
MODULE_PARM_DESC(mem_size,
size of reserved RAM used to store oops/panic logs);
+static unsigned int mem_cached = 1;
+module_param(mem_cached, uint, 0600);
+MODULE_PARM_DESC(mem_cached,
+ set to 1 to use cached memory, 0 to use uncached (default 1));
+
static int dump_oops = 1;
module_param(dump_oops, int, 0600);
MODULE_PARM_DESC(dump_oops,
@@ -79,6 +84,7 @@ struct ramoops_context {
struct persistent_ram_zone *fprz;
phys_addr_t phys_addr;
unsigned long size;
+ unsigned int cached;
size_t record_size;
size_t console_size;
size_t ftrace_size;
@@ -358,7 +364,8 @@ static int ramoops_init_przs(struct device *dev, struct
ramoops_context *cxt,
size_t sz = cxt-record_size;
cxt-przs[i] = persistent_ram_new(*paddr, sz, 0,
- cxt-ecc_info);
+ cxt-ecc_info,
+ cxt-cached);
if (IS_ERR(cxt-przs[i])) {
err = PTR_ERR(cxt-przs[i]);
dev_err(dev, failed to request mem region
(0x%zx@0x%llx): %d\n,
@@ -388,7 +395,7 @@ static int ramoops_init_prz(struct device *dev, struct
ramoops_context *cxt,
return -ENOMEM;
}
- *prz = persistent_ram_new(*paddr, sz, sig, cxt-ecc_info);
+ *prz = persistent_ram_new(*paddr, sz, sig, cxt-ecc_info, cxt-cached);
if (IS_ERR(*prz)) {
int err = PTR_ERR(*prz);
@@ -435,6 +442,7 @@ static int ramoops_probe(struct platform_device *pdev)
cxt-size = pdata-mem_size;
cxt-phys_addr = pdata-mem_address;
+ cxt-cached = pdata-mem_cached;
cxt-record_size = pdata-record_size;
cxt-console_size = pdata-console_size;
cxt-ftrace_size = pdata-ftrace_size;
@@ -564,6 +572,7 @@ static void ramoops_register_dummy(void)
dummy_data-mem_size = mem_size;
dummy_data-mem_address = mem_address;
+ dummy_data-mem_cached = 1;
dummy_data-record_size = record_size;
dummy_data-console_size
Re: [PATCH] ARM: OMAP3: Fix I/O chain clock line assertion timed out error
On 10:50-20140912, Tony Lindgren wrote: We are getting PRM: I/O chain clock line assertion timed out errors on early omaps for device tree based booting. This is because we are unconditionally calling reconfigure_io_chain while legacy booting has omap3_has_io_chain_ctrl() checks in place in omap_hwmod.c. For device tree based booting, we are calling reconfigure_io_chain unconditionally from pinctrl framework. So we need to add a check for omap3_has_io_chain_ctrl() to avoid the errors for trying to access a register that does not exist. For es3.0, the documentation in 4.11.2 Device Off-Mode Configuration just mentions PM_WKEN_WKUP[8] bit. For es3.1, there's a new chapter in documentation for 4.11.2.2 I/O Wake-Up Mechanism that describes the PM_WKEN_WKUP[16] ST_IO_CHAIN bit. So PM_WKEN_WKUP[16] bit did not get added until in es3.1 probaly to fix issues with flakey wake-up events. We are doing proper checks for ST_IO_CHAIN already in id.c and with omap3_has_io_chain_ctrl(). For more information, see also commit b02b917211d5 (ARM: OMAP3: PM: fix I/O wakeup and I/O chain clock control detection). Let's fix the issue by selecting the right function during init for reconfigure_io_chain depending on the omap revision. For es3.0 and earlier we need to just toggle EN_IO. By doing this, we can move the check for omap3_has_io_chain_ctrl() from omap_hwmod.c to the init code in prm_3xxx.c. And then we can unconditionally call reconfigure_io_chain. Thanks to Paul Walmsley and Nishanth Menon for help with debugging the issue. Fixes: 30a69ef785e8 (ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap) Cc: Kevin Hilman khil...@kernel.org Cc: Nishanth Menon n...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Tero Kristo t-kri...@ti.com Signed-off-by: Tony Lindgren t...@atomide.com 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: [PATCH v3 0/3] OMAP4+: Get rid of internal SRAM handling
On 09/10/2014 11:56 AM, Nishanth Menon wrote: On 11:04-20140910, Dave Gerlach wrote: v3: Fix minor issue in last patch to check for null sram_pool if no sram phandle is given in DT. Make all OMAP DT only platforms (am33xx, am43xx, omap4 and omap5) use drivers/misc/sram.c driver instead of the omap internal implementation for SRAM handling. Previous discussion can be found at [1]. Regards, Dave [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/195588.html Rajendra Nayak (3): ARM: AM335x: Get rid of unused sram init function ARM: OMAP4+: Move SRAM data to DT ARM: OMAP4+: Remove static iotable mappings for SRAM Documentation/devicetree/bindings/arm/omap/mpu.txt | 3 ++ arch/arm/boot/dts/am33xx.dtsi | 5 ++- arch/arm/boot/dts/am4372.dtsi | 5 +++ arch/arm/boot/dts/omap4.dtsi | 6 arch/arm/boot/dts/omap5.dtsi | 8 - arch/arm/configs/omap2plus_defconfig | 1 + arch/arm/mach-omap2/io.c | 17 -- arch/arm/mach-omap2/omap4-common.c | 22 +++- arch/arm/mach-omap2/sram.c | 39 +- arch/arm/mach-omap2/sram.h | 7 10 files changed, 46 insertions(+), 67 deletions(-) Could you please provide logs for the following: a) Low power transition tests for OMAP3,4 on all available platforms as well? b) provide bootlogs on all omap2plus platforms to ensure we have no regressions. Here are logs for low power transition, all platforms passed, properly transitioned power domains with mem sleep using wakeup_timer to wake. Low Power transition on v3.17-rc4 with patches applied, omap2plus_defconfig (OMAP3 and OMAP4): 1: BeagleBoard-XM: http://fpaste.org/133215/ 2: OMAP3430-Labrador(LDP): http://fpaste.org/133225/ 3: n900: http://fpaste.org/133244/ 4: pandaboard-es: http://fpaste.org/133213/ 5: pandaboard-vanilla: http://fpaste.org/133214/ 6: sdp3430: http://fpaste.org/133246/ Boot on v3.17-rc4 with patches applied, omap2plus_defconfig: 1: am335x-evm: Boot PASS: http://fpaste.org/133179/ 2: am335x-sk: Boot PASS: http://fpaste.org/133180/ 3: am3517-evm: Boot PASS: http://fpaste.org/133181/ 4: am37x-evm: Boot PASS: http://fpaste.org/133182/ 5: am43xx-epos: Boot PASS: http://fpaste.org/133183/ 6: am43xx-gpevm: Boot PASS: http://fpaste.org/133184/ 7: BeagleBoard-XM: Boot PASS: http://fpaste.org/133191/ 8: beagleboard-vanilla: Boot PASS: http://fpaste.org/133192/ 9: beaglebone-black: Boot PASS: http://fpaste.org/133193/ 10: beaglebone: Boot PASS: http://fpaste.org/133194/ 11: craneboard: Boot PASS: http://fpaste.org/133186/ 12: dra7xx-evm: Boot PASS: http://fpaste.org/131396/ 13: OMAP3430-Labrador(LDP): Boot PASS: http://fpaste.org/133206/ 14: n900: Boot PASS: http://fpaste.org/133207/ 15: omap5-evm: Boot PASS: http://fpaste.org/133208/ 16: pandaboard-es: Boot PASS: http://fpaste.org/133187/ 17: pandaboard-vanilla: Boot PASS: http://fpaste.org/133188/ 18:sdp2430: Boot PASS: http://fpaste.org/133189/ 19:sdp3430: Boot PASS: http://fpaste.org/133212/ TOTAL = 19 boards, Booted Boards = 19, No Boot boards = 0 Again, all pass. I have also tested with next AM335x Suspend/Resume implementation, next version will use generic sram driver to allocate for low-level assembly code, and that works fine as well. Regards, Dave -- 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
[PATCHv6 4/5] hwspinlock/core: add common OF helpers
This patch adds three new OF helper functions to use/request
locks from a hwspinlock device instantiated through a
device-tree blob.
1. The of_hwspin_lock_get_num_locks() is a common OF helper
function to read the 'hwlock-num-locks' property.
2. The of_hwspin_lock_get_base_id() is a common OF helper
function to read the 'hwlock-base-id' property.
3. The of_hwspin_lock_get_id() API can be used by hwspinlock
clients to get the id for a specific lock using the phandle
+ args specifier, so that it can be requested using the
available hwspin_lock_request_specific() API.
Signed-off-by: Suman Anna s-a...@ti.com
---
Documentation/hwspinlock.txt | 26
drivers/hwspinlock/hwspinlock_core.c | 122 +++
include/linux/hwspinlock.h | 15 -
3 files changed, 160 insertions(+), 3 deletions(-)
diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 640ae47..c15dc9f 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -48,6 +48,16 @@ independent, drivers.
ids for predefined purposes.
Should be called from a process context (might sleep).
+ int of_hwspin_lock_get_id(struct device_node *np, int index);
+ - retrieve the global lock id for an OF phandle-based specific lock.
+ This function provides a means for DT users of a hwspinlock module
+ to get the global lock id of a specific hwspinlock, so that it can
+ be requested using the normal hwspin_lock_request_specific() API.
+ The function returns a valid lock id number on success, -EPROBE_DEFER
+ if the hwspinlock device is not yet registered with the core, or other
+ error values.
+ Should be called from a process context (might sleep).
+
int hwspin_lock_free(struct hwspinlock *hwlock);
- free a previously-assigned hwspinlock; returns 0 on success, or an
appropriate error code on failure (e.g. -EINVAL if the hwspinlock
@@ -243,6 +253,22 @@ int hwspinlock_example2(void)
Returns the address of hwspinlock on success, or NULL on error (e.g.
if the hwspinlock is still in use).
+ int of_hwspin_lock_get_num_locks(struct device_node *dn);
+ - is a common OF helper function that can be used by some underlying
+ vendor-specific implementations. This can be used by implementations
+ that require and define the number of locks supported within a hwspinlock
+ bank as a device tree node property. This function should be called by
+ needed implementations before registering a hwspinlock device with the
+ core.
+
+ int of_hwspin_lock_get_base_id(struct device_node *dn);
+ - is a common OF helper function that can be used by some underlying
+ vendor-specific implementations. This can be used by implementations
+ that require and define the base index for a block of locks present
+ within a hwspinlock bank as a device tree node property. This function
+ should be called by needed implementations before registering a hwspinlock
+ device with the core.
+
5. Important structs
struct hwspinlock_device is a device which usually contains a bank
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 48f7866..7d9f749 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -27,6 +27,7 @@
#include linux/hwspinlock.h
#include linux/pm_runtime.h
#include linux/mutex.h
+#include linux/of.h
#include hwspinlock_internal.h
@@ -262,6 +263,127 @@ void __hwspin_unlock(struct hwspinlock *hwlock, int mode,
unsigned long *flags)
}
EXPORT_SYMBOL_GPL(__hwspin_unlock);
+/**
+ * of_hwspin_lock_simple_xlate - translate hwlock_spec to return a lock id
+ * @bank: the hwspinlock device bank
+ * @hwlock_spec: hwlock specifier as found in the device tree
+ *
+ * This is a simple translation function, suitable for hwspinlock platform
+ * drivers that only has a lock specifier length of 1.
+ *
+ * Returns a negative value on error, and a relative index of the lock within
+ * a specified bank on success.
+ */
+static int of_hwspin_lock_simple_xlate(struct hwspinlock_device *bank,
+ const struct of_phandle_args *hwlock_spec)
+{
+ /* sanity check (these shouldn't happen) */
+ if (WARN_ON(!bank-dev-of_node))
+ return -EINVAL;
+
+ if (WARN_ON(hwlock_spec-args_count != 1))
+ return -EINVAL;
+
+ return hwlock_spec-args[0];
+}
+
+/**
+ * of_hwspin_lock_get_id() - get lock id for an OF phandle-based specific lock
+ * @np: device node from which to request the specific hwlock
+ * @index: index of the hwlock in the list of values
+ *
+ * This function provides a means for DT users of the hwspinlock module to
+ * get the global lock id of a specific hwspinlock using the phandle of the
+ * hwspinlock device, so that it can be requested using the normal
+ * hwspin_lock_request_specific() API.
+ *
+ * Returns the
[PATCHv6 5/5] hwspinlock/omap: add support for dt nodes
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.
Signed-off-by: Suman Anna s-a...@ti.com
[t...@atomide.com: ack for legacy file removal]
Acked-by: Tony Lindgren t...@atomide.com
---
MAINTAINERS | 1 -
arch/arm/mach-omap2/Makefile | 3 --
arch/arm/mach-omap2/hwspinlock.c | 60
drivers/hwspinlock/omap_hwspinlock.c | 23 +++---
4 files changed, 18 insertions(+), 69 deletions(-)
delete mode 100644 arch/arm/mach-omap2/hwspinlock.c
diff --git a/MAINTAINERS b/MAINTAINERS
index cf24bb5..351885e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6531,7 +6531,6 @@ M:Ohad Ben-Cohen o...@wizery.com
L: linux-omap@vger.kernel.org
S: Maintained
F: drivers/hwspinlock/omap_hwspinlock.c
-F: arch/arm/mach-omap2/hwspinlock.c
OMAP MMC SUPPORT
M: Jarkko Lavinen jarkko.lavi...@nokia.com
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 69bbcba..088b6b0 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -286,9 +286,6 @@ obj-y += $(smc91x-m)
$(smc91x-y)
smsc911x-$(CONFIG_SMSC911X):= gpmc-smsc911x.o
obj-y += $(smsc911x-m) $(smsc911x-y)
-ifneq ($(CONFIG_HWSPINLOCK_OMAP),)
-obj-y += hwspinlock.o
-endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
diff --git a/arch/arm/mach-omap2/hwspinlock.c b/arch/arm/mach-omap2/hwspinlock.c
deleted file mode 100644
index ef175ac..000
--- a/arch/arm/mach-omap2/hwspinlock.c
+++ /dev/null
@@ -1,60 +0,0 @@
-/*
- * OMAP hardware spinlock device initialization
- *
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
- *
- * Contact: Simon Que s...@ti.com
- * Hari Kanigeri h-kanige...@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.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- */
-
-#include linux/kernel.h
-#include linux/init.h
-#include linux/err.h
-#include linux/hwspinlock.h
-
-#include soc.h
-#include omap_hwmod.h
-#include omap_device.h
-
-static struct hwspinlock_pdata omap_hwspinlock_pdata __initdata = {
- .base_id = 0,
-};
-
-static int __init hwspinlocks_init(void)
-{
- int retval = 0;
- struct omap_hwmod *oh;
- struct platform_device *pdev;
- const char *oh_name = spinlock;
- const char *dev_name = omap_hwspinlock;
-
- /*
-* Hwmod lookup will fail in case our platform doesn't support the
-* hardware spinlock module, so it is safe to run this initcall
-* on all omaps
-*/
- oh = omap_hwmod_lookup(oh_name);
- if (oh == NULL)
- return -EINVAL;
-
- pdev = omap_device_build(dev_name, 0, oh, omap_hwspinlock_pdata,
- sizeof(struct hwspinlock_pdata));
- if (IS_ERR(pdev)) {
- pr_err(Can't build omap_device for %s:%s\n, dev_name,
- oh_name);
- retval = PTR_ERR(pdev);
- }
-
- return retval;
-}
-/* early board code might need to reserve specific hwspinlock instances */
-omap_postcore_initcall(hwspinlocks_init);
diff --git a/drivers/hwspinlock/omap_hwspinlock.c
b/drivers/hwspinlock/omap_hwspinlock.c
index c1e2cd4..2e8c7c3 100644
--- a/drivers/hwspinlock/omap_hwspinlock.c
+++ b/drivers/hwspinlock/omap_hwspinlock.c
@@ -1,7 +1,7 @@
/*
* OMAP hardware spinlock driver
*
- * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com
+ * Copyright (C) 2010-2014 Texas Instruments Incorporated - http://www.ti.com
*
* Contact: Simon Que s...@ti.com
* Hari Kanigeri h-kanige...@ti.com
@@ -27,6 +27,7 @@
#include linux/slab.h
#include linux/spinlock.h
#include linux/hwspinlock.h
+#include linux/of_device.h
#include linux/platform_device.h
#include hwspinlock_internal.h
@@ -80,16 +81,21 @@ static const struct hwspinlock_ops omap_hwspinlock_ops = {
static int omap_hwspinlock_probe(struct platform_device *pdev)
{
- struct hwspinlock_pdata *pdata = pdev-dev.platform_data;
+ struct device_node *node = pdev-dev.of_node;
struct hwspinlock_device *bank;
struct hwspinlock *hwlock;
struct resource *res;
void __iomem *io_base;
- int num_locks, i, ret;
+
[PATCHv6 1/5] Documentation: dt: add common bindings for hwspinlock
This patch adds the generic common bindings used to represent
a hwlock device and use/request locks in a device-tree build.
All the platform-specific hwlock driver implementations need the
number of locks and associated base id for registering the locks
present within the device with the driver core. This base id
needs to be unique across multiple IP instances of a hwspinlock
device, so that each hwlock can be represented uniquely in a
system.
The number of locks is represented by 'hwlock-num-locks' property,
and the base id is represented by the 'hwlock-base-id' property.
The args specifier length is dependent on each vendor-specific
implementation and is represented through the '#hwlock-cells'
property. Client users need to use the property 'hwlocks' for
requesting specific lock(s).
Note that the document is named hwlock.txt deliberately to keep
it a bit more generic.
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/hwlock.txt | 55 ++
1 file changed, 55 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/hwlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/hwlock.txt
b/Documentation/devicetree/bindings/hwlock/hwlock.txt
new file mode 100644
index 000..24993dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/hwlock.txt
@@ -0,0 +1,55 @@
+Generic hwlock bindings
+===
+
+Generic bindings that are common to all the hwlock platform specific driver
+implementations.
+
+The validity and need of these common properties may vary from one platform
+implementation to another. The platform specific bindings should explicitly
+state if an optional property is used. Please also look through the individual
+platform specific hwlock binding documentations for identifying the applicable
+properties.
+
+Common properties:
+- #hwlock-cells: Specifies the number of cells needed to represent a
+ specific lock. This property is mandatory for all
+ platform implementations.
+- hwlock-num-locks:Number of locks present in a hwlock device. This
+ property is needed on hwlock devices, where the number
+ of supported locks within a hwlock device cannot be
+ read from a register.
+- hwlock-base-id: An unique base Id for the locks for a particular hwlock
+ device. This property is mandatory if a SoC has several
+ hwlock devices.
+
+Hwlock Users:
+=
+
+Nodes that require specific hwlock(s) should specify them using the property
+hwlocks, each containing a phandle to the hwlock node and an args specifier
+value as indicated by #hwlock-cells. Multiple hwlocks can be requested using
+an array of the phandle and hwlock number specifier tuple.
+
+1. Example of a node using a single specific hwlock:
+
+The following example has a node requesting a hwlock in the bank defined by
+the node hwlock1. hwlock1 is a hwlock provider with an argument specifier
+of length 1.
+
+ node {
+ ...
+ hwlocks = hwlock1 2;
+ ...
+ };
+
+2. Example of a node using multiple specific hwlocks:
+
+The following example has a node requesting two hwlocks, a hwlock within
+the hwlock device node 'hwlock1' with #hwlock-cells value of 1, and another
+hwlock within the hwlock device node 'hwlock2' with #hwlock-cells value of 2.
+
+ node {
+ ...
+ hwlocks = hwlock1 2, hwlock2 0 3;
+ ...
+ };
--
2.0.4
--
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
[PATCHv6 3/5] hwspinlock/core: maintain a list of registered hwspinlock banks
The hwspinlock_device structure is used for registering a bank of
locks with the driver core. The structure already contains the
necessary members to identify the bank of locks. The core does not
maintain the hwspinlock_devices itself, but maintains only a radix
tree for all the registered locks. A specific lock can be requested
by users using a global lock id, and any device-specific fields
can be retrieved through a reference to the hwspinlock_device in
each lock.
The global lock id, however, is not friendly to be requested for
users using the device-tree model. The device-tree representation
will typically have each of the hwspinlock devices represented as
a DT node, and a specific lock can be requested using the device's
phandle and a lock specifier. Add support to the core therefore to
maintain all the registered hwspinlock_devices, so that a device
can be looked up and a specific lock belonging to the device
requested through a phandle + args approach.
Signed-off-by: Suman Anna s-a...@ti.com
---
Documentation/hwspinlock.txt | 2 ++
drivers/hwspinlock/hwspinlock_core.c | 51
drivers/hwspinlock/hwspinlock_internal.h | 2 ++
3 files changed, 55 insertions(+)
diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index 62f7d4e..640ae47 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -251,6 +251,7 @@ implementation using the hwspin_lock_register() API.
/**
* struct hwspinlock_device - a device which usually spans numerous hwspinlocks
+ * @list: list element to link hwspinlock devices together
* @dev: underlying device, will be used to invoke runtime PM api
* @ops: platform-specific hwspinlock handlers
* @base_id: id index of the first lock in this device
@@ -258,6 +259,7 @@ implementation using the hwspin_lock_register() API.
* @lock: dynamically allocated array of 'struct hwspinlock'
*/
struct hwspinlock_device {
+ struct list_head list;
struct device *dev;
const struct hwspinlock_ops *ops;
int base_id;
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 461a0d7..48f7866 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -59,6 +59,11 @@ static RADIX_TREE(hwspinlock_tree, GFP_KERNEL);
*/
static DEFINE_MUTEX(hwspinlock_tree_lock);
+/*
+ * A linked list for maintaining all the registered hwspinlock devices.
+ * The list is maintained in an ordered-list of the supported locks group.
+ */
+static LIST_HEAD(hwspinlock_devices);
/**
* __hwspin_trylock() - attempt to lock a specific hwspinlock
@@ -307,6 +312,40 @@ out:
return hwlock;
}
+/*
+ * Add a new hwspinlock device to the global list, keeping the list of
+ * devices sorted by base order.
+ *
+ * Returns 0 on success, or -EBUSY if the new device overlaps with some
+ * other device's lock space.
+ */
+static int hwspinlock_device_add(struct hwspinlock_device *bank)
+{
+ struct list_head *entry = hwspinlock_devices;
+ struct hwspinlock_device *_bank;
+ int ret = 0;
+
+ list_for_each(entry, hwspinlock_devices) {
+ _bank = list_entry(entry, struct hwspinlock_device, list);
+ if (_bank-base_id = bank-base_id + bank-num_locks)
+ break;
+ }
+
+ if (entry != hwspinlock_devices
+ entry-prev != hwspinlock_devices) {
+ _bank = list_entry(entry-prev, struct hwspinlock_device, list);
+ if (_bank-base_id + _bank-num_locks bank-base_id) {
+ dev_err(bank-dev, hwlock space overlap, cannot add
device\n);
+ ret = -EBUSY;
+ }
+ }
+
+ if (!ret)
+ list_add_tail(bank-list, entry);
+
+ return ret;
+}
+
/**
* hwspin_lock_register() - register a new hw spinlock device
* @bank: the hwspinlock device, which usually provides numerous hw locks
@@ -339,6 +378,12 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
bank-base_id = base_id;
bank-num_locks = num_locks;
+ mutex_lock(hwspinlock_tree_lock);
+ ret = hwspinlock_device_add(bank);
+ mutex_unlock(hwspinlock_tree_lock);
+ if (ret)
+ return ret;
+
for (i = 0; i num_locks; i++) {
hwlock = bank-lock[i];
@@ -355,6 +400,9 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
reg_failed:
while (--i = 0)
hwspin_lock_unregister_single(base_id + i);
+ mutex_lock(hwspinlock_tree_lock);
+ list_del(bank-list);
+ mutex_unlock(hwspinlock_tree_lock);
return ret;
}
EXPORT_SYMBOL_GPL(hwspin_lock_register);
@@ -386,6 +434,9 @@ int hwspin_lock_unregister(struct hwspinlock_device *bank)
WARN_ON(tmp != hwlock);
}
+ mutex_lock(hwspinlock_tree_lock);
+
[PATCHv6 2/5] Documentation: dt: add the omap hwspinlock bindings document
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
DT bindings information for OMAP hwspinlock module.
Cc: Rob Herring robh...@kernel.org
Signed-off-by: Suman Anna s-a...@ti.com
---
.../devicetree/bindings/hwlock/omap-hwspinlock.txt | 24 ++
1 file changed, 24 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
diff --git a/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
new file mode 100644
index 000..568eae2
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwlock/omap-hwspinlock.txt
@@ -0,0 +1,24 @@
+OMAP4+ HwSpinlock Driver
+
+
+Required properties:
+- compatible: Should be ti,omap4-hwspinlock for
+ OMAP44xx, OMAP54xx, AM33xx, AM43xx, DRA7xx SoCs
+- reg: Contains the hwspinlock module register address space
+ (base address and length)
+- ti,hwmods: Name of the hwmod associated with the hwspinlock device
+- #hwlock-cells: Should be 1. The OMAP hwspinlock users will use a
+ 0-indexed relative hwlock number as the argument
+ specifier value for requesting a specific hwspinlock
+ within a hwspinlock bank.
+
+
+Example:
+
+/* OMAP4 */
+hwspinlock: spinlock@4a0f6000 {
+ compatible = ti,omap4-hwspinlock;
+ reg = 0x4a0f6000 0x1000;
+ ti,hwmods = spinlock;
+ #hwlock-cells = 1;
+};
--
2.0.4
--
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
[PATCHv6 0/5] hwspinlock core/omap dt support
Hi Ohad, This is an update to the hwspinlock dt support series. The series is rebased onto v3.17-rc3, and addresses the review comments on the previous v5 series. I have also split and left out the RFC patches about the support for reserved locks (will post these as a separate series) and return code convention changes in the hwspinlock core (will not be needed anymore). The support for deferred probing of clients is supported in the new of_hwspin_lock_get_id() function itself. Following are the main changes in v6 w.r.t v5: - [Patch 1] Updated generic hwspinlock bindings after folding back the hwlock-base-id property from v5 Patch 8 [1]. [Patch 1] - [Patch 4] Updated the common OF helpers patch based on review comments on v5. of_hwspin_lock_request_specific() is replaced with of_hwspin_lock_get_id(). of_hwspin_lock_simple_xlate() is made internal, and of_hwspin_lock_get_base_id() is added. - [Patch 5] Updated the OMAP hwspinlock DT support patch to address review comments about hard-coded base-id, it is parsed from DT if present. - Patches 2 and 3 are unchanged from previous version. - Support patches for AM335x and AM437x SoCs (v5 patches 6 and 7) have been dropped as they are merged in separately for 3.17 - RFC patches (v5 patches 9 through 15) adding the concept of reserved locks and return code change convention dropped. I had looked into dropping the patch to maintain the list of registered spinlocks, but had to retain the patch as it was needed to perform the validity of the args-specifier value in of_hwspin_lock_get_id(). The validation logs on all the applicable OMAP SoCs are at: OMAP4 - http://pastebin.ubuntu.com/8329228 OMAP5 - http://pastebin.ubuntu.com/8329301 DRA74x - http://pastebin.ubuntu.com/8329261 AM33xx - http://pastebin.ubuntu.com/8329199 AM43xx - http://pastebin.ubuntu.com/8329273 The above logs are generated with some additional test patches staged here for reference: https://github.com/sumananna/omap-kernel/commits/hwspinlock/test/3.17-rc3-dt-v6 https://github.com/sumananna/omap-kernel/commits/hwspinlock/submit/3.17-rc3-dt-v6 regards Suman [1] https://patchwork.kernel.org/patch/4096741/ --- v5: http://marc.info/?l=linux-omapm=139890478402807w=2 - Rebased v4 patches plus additional RFC patches. - Added back the patch to support DT-based hwlock-base-id property, for registration purposes. - RFC patches introducing the concept of reserved locks. - Staged patches for converting return convention to better support deferred probing of client drivers. v4: - The DT bindings are split into separate patches, and updated to add comments about #hwlock-cells - Fixed a registration issue with repeated module installation and removal. - Added a new OF helper to support #hwlock-cells in addition to the previous OF functions. The OMAP adaptation patch is updated to use the default translate function - Updated hwspinlock documentation to adjust for the structure changes and the new api additions. - Added build support for AM335x, AM43xx and DRA7xx http://marc.info/?l=linux-omapm=138965904015225w=2 v3: - Removed the DT property hwlock-base-id and associated OF helper - Added changes in core to support requesting a specific hwlock using phandle + args approach - Revised both the common and OMAP DT bindings document http://marc.info/?l=linux-omapm=138143992932197w=2 v2: - Added a new common DT binding documentation and OF helpers. - Revised OMAP DT parse support to use the new OF helper (Patch2) - OMAP5 hwspinlock support including the hwmod entry and DT node - Add AM335x support to OMAP hwspinlock driver, including a fix needed in driver given that AM335 spinlock module requires s/w wakeup - AM335 DT node for spinlock, and a hwmod change to enable smart-idle for AM335. - OMAP4 DT node patch is unchanged http://marc.info/?l=linux-omapm=137944644112727w=2 v1: - Add DT parse support to OMAP hwspinlock driver - Add OMAP4 DT node and bindings information http://marc.info/?l=linux-omapm=137823082308009w=2 --- Suman Anna (5): Documentation: dt: add common bindings for hwspinlock Documentation: dt: add the omap hwspinlock bindings document hwspinlock/core: maintain a list of registered hwspinlock banks hwspinlock/core: add common OF helpers hwspinlock/omap: add support for dt nodes .../devicetree/bindings/hwlock/hwlock.txt | 55 +++ .../devicetree/bindings/hwlock/omap-hwspinlock.txt | 24 +++ Documentation/hwspinlock.txt | 28 MAINTAINERS| 1 - arch/arm/mach-omap2/Makefile | 3 - arch/arm/mach-omap2/hwspinlock.c | 60 --- drivers/hwspinlock/hwspinlock_core.c | 173 + drivers/hwspinlock/hwspinlock_internal.h | 2 + drivers/hwspinlock/omap_hwspinlock.c | 23 ++- include/linux/hwspinlock.h | 15 +- 10 files changed, 312
[RFC PATCHv2 0/3] Support for HwSpinlock reserved locks
Hi Ohad, This series is an RFC patchset that adds the support for reserved locks to the HwSpinlock core to restrict the dynamic hwspin_lock_request() API from allocating reserved locks (specific locks requested by DT client users). The patches are split away from the v5 hwspinlock/omap dt series [1] to not block the dt support patches. The series builds on top of the refreshed hwspinlock core/omap dt series [2], and are baselined on 3.17-rc3. Following are the summary of changes: - Patches 1 and 2 are equivalent patches of Patch 9 and 10 from [1]. Only change is an update to hwspinlock.txt documentation. - Patch 3 is an updated version of the reworked patch 12 [3] from v5. Changes include some additional function documentation, switch to internal of_xlate function and a fix for of_node reference maintainance. The validation logs on all the applicable OMAP SoCs are at: OMAP4 - http://pastebin.ubuntu.com/8329417 OMAP5 - http://pastebin.ubuntu.com/8329420 DRA74x - http://pastebin.ubuntu.com/8329519 AM33xx - http://pastebin.ubuntu.com/8329454 AM43xx - http://pastebin.ubuntu.com/8329400 The above logs are generated with some additional test patches staged here for reference: https://github.com/sumananna/omap-kernel/commits/hwspinlock/test/3.17-rc3-dtv6-rsrvdlocks https://github.com/sumananna/omap-kernel/commits/hwspinlock/submit/3.17-rc3-dtv6-rsrvdlocks regards Suman [1] http://marc.info/?l=linux-arm-kernelm=139890465902747w=2 [2] http://marc.info/?l=linux-arm-kernelm=141055363113881w=2 [3] http://marc.info/?l=linux-arm-kernelm=139968477508013w=2 Suman Anna (3): hwspinlock/core: prepare unregister code to support reserved locks hwspinlock/core: prepare core to support reserved locks hwspinlock/core: add support for reserved locks Documentation/hwspinlock.txt | 2 + drivers/hwspinlock/hwspinlock_core.c | 108 --- drivers/hwspinlock/hwspinlock_internal.h | 2 + 3 files changed, 89 insertions(+), 23 deletions(-) -- 2.0.4 -- 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
[RFC PATCHv2 2/3] hwspinlock/core: prepare core to support reserved locks
The HwSpinlock core allows requesting either a specific lock or
an available normal lock. The specific locks are usually reserved
during board init time, while the normal available locks are
intended to be assigned at runtime.
This patch prepares the hwspinlock core to support this concept
of reserved locks. A new element is added to struct hwspinlock
to identify whether it is reserved to be allocated using the
hwspin_lock_request_specific() API or available for dynamic
allocation. A new tag name, HWSPINLOCK_RESERVED, is introduced
to mark the reserved locks as such.
Signed-off-by: Suman Anna s-a...@ti.com
---
Documentation/hwspinlock.txt | 2 ++
drivers/hwspinlock/hwspinlock_core.c | 14 --
drivers/hwspinlock/hwspinlock_internal.h | 2 ++
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/Documentation/hwspinlock.txt b/Documentation/hwspinlock.txt
index c15dc9f..cdcfdff 100644
--- a/Documentation/hwspinlock.txt
+++ b/Documentation/hwspinlock.txt
@@ -300,11 +300,13 @@ of which represents a single hardware lock:
* struct hwspinlock - this struct represents a single hwspinlock instance
* @bank: the hwspinlock_device structure which owns this lock
* @lock: initialized and used by hwspinlock core
+ * @type: type of lock, used to distinguish regular locks from reserved locks
* @priv: private data, owned by the underlying platform-specific hwspinlock
drv
*/
struct hwspinlock {
struct hwspinlock_device *bank;
spinlock_t lock;
+ unsigned int type;
void *priv;
};
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 5fad292..f0d8475 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -33,6 +33,7 @@
/* radix tree tags */
#define HWSPINLOCK_UNUSED (0) /* tags an hwspinlock as unused */
+#define HWSPINLOCK_RESERVED(1) /* tags an hwspinlock as reserved */
/*
* A radix tree is used to maintain the available hwspinlock instances.
@@ -399,7 +400,7 @@ static int hwspin_lock_register_single(struct hwspinlock
*hwlock, int id)
}
/* mark this hwspinlock as available */
- tmp = radix_tree_tag_set(hwspinlock_tree, id, HWSPINLOCK_UNUSED);
+ tmp = radix_tree_tag_set(hwspinlock_tree, id, hwlock-type);
/* self-sanity check which should never fail */
WARN_ON(tmp != hwlock);
@@ -417,7 +418,7 @@ static int hwspin_lock_unregister_single(struct hwspinlock
*hwlock, int id)
mutex_lock(hwspinlock_tree_lock);
/* make sure the hwspinlock is not in use (tag is set) */
- if (!radix_tree_tag_get(hwspinlock_tree, id, HWSPINLOCK_UNUSED)) {
+ if (!radix_tree_tag_get(hwspinlock_tree, id, hwlock-type)) {
pr_err(hwspinlock %d still in use (or not present)\n, id);
ret = -EBUSY;
goto out;
@@ -515,6 +516,7 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
spin_lock_init(hwlock-lock);
hwlock-bank = bank;
+ hwlock-type = HWSPINLOCK_UNUSED;
ret = hwspin_lock_register_single(hwlock, base_id + i);
if (ret)
@@ -599,7 +601,7 @@ static int __hwspin_lock_request(struct hwspinlock *hwlock)
/* mark hwspinlock as used, should not fail */
tmp = radix_tree_tag_clear(hwspinlock_tree, hwlock_to_id(hwlock),
- HWSPINLOCK_UNUSED);
+ hwlock-type);
/* self-sanity check that should never fail */
WARN_ON(tmp != hwlock);
@@ -698,7 +700,7 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned
int id)
WARN_ON(hwlock_to_id(hwlock) != id);
/* make sure this hwspinlock is unused */
- ret = radix_tree_tag_get(hwspinlock_tree, id, HWSPINLOCK_UNUSED);
+ ret = radix_tree_tag_get(hwspinlock_tree, id, hwlock-type);
if (ret == 0) {
pr_warn(hwspinlock %u is already in use\n, id);
hwlock = NULL;
@@ -744,7 +746,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
/* make sure the hwspinlock is used */
ret = radix_tree_tag_get(hwspinlock_tree, hwlock_to_id(hwlock),
- HWSPINLOCK_UNUSED);
+ hwlock-type);
if (ret == 1) {
dev_err(dev, %s: hwlock is already free\n, __func__);
dump_stack();
@@ -759,7 +761,7 @@ int hwspin_lock_free(struct hwspinlock *hwlock)
/* mark this hwspinlock as available */
tmp = radix_tree_tag_set(hwspinlock_tree, hwlock_to_id(hwlock),
- HWSPINLOCK_UNUSED);
+ hwlock-type);
/* sanity check (this shouldn't happen) */
WARN_ON(tmp
[RFC PATCHv2 1/3] hwspinlock/core: prepare unregister code to support reserved locks
Rearrange the code between hwspin_lock_unregister() and the underlying
hwspin_lock_unregister_single() functions so that the semantics are
similar to the _register_ functions. This change prepares the hwspinlock
driver core to support unregistration of reserved locks better.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/hwspinlock_core.c | 37 +++-
1 file changed, 20 insertions(+), 17 deletions(-)
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index 7d9f749..5fad292 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -409,29 +409,33 @@ out:
return 0;
}
-static struct hwspinlock *hwspin_lock_unregister_single(unsigned int id)
+static int hwspin_lock_unregister_single(struct hwspinlock *hwlock, int id)
{
- struct hwspinlock *hwlock = NULL;
- int ret;
+ struct hwspinlock *tmp = NULL;
+ int ret = 0;
mutex_lock(hwspinlock_tree_lock);
/* make sure the hwspinlock is not in use (tag is set) */
- ret = radix_tree_tag_get(hwspinlock_tree, id, HWSPINLOCK_UNUSED);
- if (ret == 0) {
+ if (!radix_tree_tag_get(hwspinlock_tree, id, HWSPINLOCK_UNUSED)) {
pr_err(hwspinlock %d still in use (or not present)\n, id);
+ ret = -EBUSY;
goto out;
}
- hwlock = radix_tree_delete(hwspinlock_tree, id);
- if (!hwlock) {
+ tmp = radix_tree_delete(hwspinlock_tree, id);
+ if (!tmp) {
pr_err(failed to delete hwspinlock %d\n, id);
+ ret = -EIO;
goto out;
}
+ /* self-sanity check that should never fail */
+ WARN_ON(tmp != hwlock);
+
out:
mutex_unlock(hwspinlock_tree_lock);
- return hwlock;
+ return ret;
}
/*
@@ -520,8 +524,10 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
return 0;
reg_failed:
- while (--i = 0)
- hwspin_lock_unregister_single(base_id + i);
+ while (--i = 0) {
+ hwlock = bank-lock[i];
+ hwspin_lock_unregister_single(hwlock, base_id + i);
+ }
mutex_lock(hwspinlock_tree_lock);
list_del(bank-list);
mutex_unlock(hwspinlock_tree_lock);
@@ -542,18 +548,15 @@ EXPORT_SYMBOL_GPL(hwspin_lock_register);
*/
int hwspin_lock_unregister(struct hwspinlock_device *bank)
{
- struct hwspinlock *hwlock, *tmp;
- int i;
+ struct hwspinlock *hwlock;
+ int i, ret;
for (i = 0; i bank-num_locks; i++) {
hwlock = bank-lock[i];
- tmp = hwspin_lock_unregister_single(bank-base_id + i);
- if (!tmp)
+ ret = hwspin_lock_unregister_single(hwlock, bank-base_id + i);
+ if (ret)
return -EBUSY;
-
- /* self-sanity check that should never fail */
- WARN_ON(tmp != hwlock);
}
mutex_lock(hwspinlock_tree_lock);
--
2.0.4
--
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
[RFC PATCHv2 3/3] hwspinlock/core: add support for reserved locks
The HwSpinlock core allows requesting either a specific lock or an
available normal lock. The specific locks are usually reserved during
board init time, while the normal available locks are intended to be
assigned at runtime for clients that do not care about a specific
lock.
The HwSpinlock core has been enhanced to:
1. mark certain locks as 'reserved' by parsing the DT blob for any
locks used by client nodes.
2. restrict the anonymous hwspin_lock_request() API to allocate only
from non-reserved locks for DT boots.
3. limit these reserved locks to be allocated only using the
hwspin_lock_request_specific() API for DT boots.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/hwspinlock/hwspinlock_core.c | 61 ++--
1 file changed, 59 insertions(+), 2 deletions(-)
diff --git a/drivers/hwspinlock/hwspinlock_core.c
b/drivers/hwspinlock/hwspinlock_core.c
index f0d8475..d49a077 100644
--- a/drivers/hwspinlock/hwspinlock_core.c
+++ b/drivers/hwspinlock/hwspinlock_core.c
@@ -474,6 +474,53 @@ static int hwspinlock_device_add(struct hwspinlock_device
*bank)
}
/**
+ * hwspin_mark_reserved_locks() - mark reserved locks
+ *
+ * This is an internal function that mark all the reserved locks within
+ * a hwspinlock device during the registration phase, and is applicable
+ * only for device-tree boots. The locks are marked by browsing through
+ * all the user nodes with the property hwlocks, so that a separate
+ * property is not needed in the hwspinlock device itself. Note that it
+ * also marks locks used on disabled user nodes.
+ */
+static void hwspin_mark_reserved_locks(struct hwspinlock_device *bank)
+{
+ struct device_node *np = bank-dev-of_node;
+ const char *prop_name = hwlocks;
+ const char *cells_name = #hwlock-cells;
+ struct device_node *node = NULL;
+ struct of_phandle_args args;
+ struct hwspinlock *hwlock;
+ int i, id, count, ret;
+
+ for_each_node_with_property(node, prop_name) {
+ count = of_count_phandle_with_args(node, prop_name, cells_name);
+ if (count = 0)
+ continue;
+
+ for (i = 0; i count; i++, of_node_put(args.np)) {
+ args.np = NULL;
+ ret = of_parse_phandle_with_args(node, prop_name,
+cells_name, i, args);
+ if (ret || np != args.np)
+ continue;
+
+ id = of_hwspin_lock_simple_xlate(bank, args);
+ if (id 0 || id = bank-num_locks)
+ continue;
+
+ hwlock = bank-lock[id];
+ if (hwlock-type == HWSPINLOCK_RESERVED) {
+ dev_err(bank-dev, potential reuse of
hwspinlock %d between multiple clients on %s\n,
+ id, np-full_name);
+ continue;
+ }
+ hwlock-type = HWSPINLOCK_RESERVED;
+ }
+ }
+}
+
+/**
* hwspin_lock_register() - register a new hw spinlock device
* @bank: the hwspinlock device, which usually provides numerous hw locks
* @dev: the backing device
@@ -511,12 +558,16 @@ int hwspin_lock_register(struct hwspinlock_device *bank,
struct device *dev,
if (ret)
return ret;
+ if (dev-of_node)
+ hwspin_mark_reserved_locks(bank);
+
for (i = 0; i num_locks; i++) {
hwlock = bank-lock[i];
spin_lock_init(hwlock-lock);
hwlock-bank = bank;
- hwlock-type = HWSPINLOCK_UNUSED;
+ if (hwlock-type != HWSPINLOCK_RESERVED)
+ hwlock-type = HWSPINLOCK_UNUSED;
ret = hwspin_lock_register_single(hwlock, base_id + i);
if (ret)
@@ -699,7 +750,13 @@ struct hwspinlock *hwspin_lock_request_specific(unsigned
int id)
/* sanity check (this shouldn't happen) */
WARN_ON(hwlock_to_id(hwlock) != id);
- /* make sure this hwspinlock is unused */
+ if (hwlock-bank-dev-of_node hwlock-type != HWSPINLOCK_RESERVED) {
+ pr_warn(hwspinlock %u is not a reserved lock\n, id);
+ hwlock = NULL;
+ goto out;
+ }
+
+ /* make sure this hwspinlock is an unused reserved lock */
ret = radix_tree_tag_get(hwspinlock_tree, id, hwlock-type);
if (ret == 0) {
pr_warn(hwspinlock %u is already in use\n, id);
--
2.0.4
--
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 00/16 v9] omap 8250 based uart + DMA
* Sebastian Andrzej Siewior bige...@linutronix.de [140910 12:30]: the diff of v8…v9 is small: - rebased on top's of Greg's tty-next branch - fixed #10 where we might have THRE interrupt enabled for longer than needed - re-did register setup in #10. Before this less file could freeze the am335x-evm. FYI, looks like merging in your uart_v9 branch for testing with my hwmod changes now fails to produce RX characters on omap3. The device wakes up just fine to the wake-up interrupt, and then serial8250_handle_irq() gets called, but I'm not seeing anything in the console getting printed out. It's like all the RX characters are getting lost instead of just the first one. The RX characters work fine when the system is running. So it seems there's been some kind of regression since v8? 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 2/2] pstore-ram: Allow optional mapping with pgprot_noncached
On Fri, Sep 12, 2014 at 11:32:25AM -0700, Tony Lindgren wrote: On some ARMs at least the memory can be mapped pgprot_noncached() and still be working for atomic operations. As pointed out by Colin Cross ccr...@android.com, in some cases you do want to use pgprot_noncached() if the SoC supports it to see a debug printk just before a write hanging the system. On ARMs, the atomic operations on strongly ordered memory are implementation defined. So let's provide an optional kernel parameter for configuring noncached memory, and use pgprot_writecombine() by default. Can we clean up this terminology please? Writecombine memory is not cached - write combine memory bypasses the caches entirely. What it doesn't bypass are store buffers, which may combine two writes together. So, calling it cached is misleading. Secondly, memory returned by ioremap() is not strongly ordered, it is device memory. There's three main classifications of memory on ARM: strongly ordered, device and normal memory. Normal memory has attributes which define whether it is write combining, or cacheable in some way (and if so, how it's cacheable.) Exclusives are always permitted to normal memory. The other two are implementation defined. While an implementation may offer it on strongly ordered, that doesn't mean that it also supports it on device memory. Lastly, aliased mappings are something that ARM has always strongly discouraged on ARMv6+ (it was plain down-right unpredictable, but it's now strongly discouraged) and remapping memory with different memory type should be avoided. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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
