Re: [PATCH v9 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
Hello,
On 2014-11-27 23:51, Russell King - ARM Linux wrote:
On Mon, Nov 17, 2014 at 12:48:22PM +0100, Marek Szyprowski wrote:
This is an updated patchset, which intends to add support for L2 cache
on Exynos4 SoCs on boards running under secure firmware, which requires
certain initialization steps to be done with help of firmware, as
selected registers are writable only from secure mode.
First four patches extend existing support for secure write in L2C driver
to account for design of secure firmware running on Exynos. Namely:
1) direct read access to certain registers is needed on Exynos, because
secure firmware calls set several registers at once,
2) not all boards are running secure firmware, so .write_sec callback
needs to be installed in Exynos firmware ops initialization code,
3) write access to {DATA,TAG}_LATENCY_CTRL registers fron non-secure world
is not allowed and so must use l2c_write_sec as well,
4) on certain boards, default value of prefetch register is incorrect
and must be overridden at L2C initialization.
For boards running with firmware that provides access to individual
L2C registers this series should introduce no functional changes. However
since the driver is widely used on other platforms I'd like to kindly ask
any interested people for testing.
Further three patches add implementation of .write_sec and .configure
callbacks for Exynos secure firmware and necessary DT nodes to enable
L2 cache.
Changes in this version tested on Exynos4412-based TRATS2 and OdroidU3+
boards (both with secure firmware). There should be no functional change
for Exynos boards running without secure firmware. I do not have access
to affected non-Exynos boards, so I could not test on them.
So, I applied this series, and now I get a conflicts between my tree and
arm-soc for:
arch/arm/mach-exynos/firmware.c
arch/arm/mach-exynos/sleep.S
So, I'm going to un-stage the exynos bits, and we'll have to work out
some way to handle those.
I've already pointed that those patches depend on other previously merged to
exynos and arm-soc trees, but both Arnd and Kukjin said that those patch
series
should go via your kernel tree:
https://lkml.org/lkml/2014/11/15/158
That's why in v9 I rebased patches once again onto vanilla v3.18-rc4 and
uploaded
to your patch tracker. I see the following two possibilities to get them
merged:
1. Merge patches to rmk tree and resolve the merge conflict. The
conflict IS quite
easy to resolve - both trees, arm-soc and rmk only adds some code and
the goal is
simply to have both chunks added.
2. Merge the previous version (v8 from the above link) to arm-soc tree,
where it
applies cleanly on for-next, preferably with Russell's Acked-by.
Arnd, Russell: which approach do you prefer? How can I help to get it
merged?
Best regards
--
Marek Szyprowski, PhD
Samsung RD Institute Poland
--
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 v7 6/8] net: can: c_can: Disable pins when CAN interface is down
On 27/11/14 23:19, Marc Kleine-Budde wrote: On 11/27/2014 02:26 PM, Linus Walleij wrote: On Fri, Nov 14, 2014 at 4:40 PM, Roger Quadros rog...@ti.com wrote: DRA7 CAN IP suffers from a problem which causes it to be prevented from fully turning OFF (i.e. stuck in transition) if the module was disabled while there was traffic on the CAN_RX line. To work around this issue we select the SLEEP pin state by default on probe and use the DEFAULT pin state on CAN up and back to the SLEEP pin state on CAN down. Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Linus Walleij linus.wall...@linaro.org Thanks, however the patch is already upstream. I see you figured it out all by yourselves :D (Sorry for being absent.) +#include linux/pinctrl/consumer.h + pinctrl_pm_select_default_state(dev-dev.parent); + pinctrl_pm_select_sleep_state(dev-dev.parent); + pinctrl_pm_select_sleep_state(dev-dev.parent); NB: in drivers/base/pinctrl.c: #ifdef CONFIG_PM /* * If power management is enabled, we also look for the optional * sleep and idle pin states, with semantics as defined in * linux/pinctrl/pinctrl-state.h */ dev-pins-sleep_state = pinctrl_lookup_state(dev-pins-p, PINCTRL_STATE_SLEEP); So if these states are necessary for the driver to work, put depends on PM or select PM in the Kconfig. Roger, you can prepare a patch, if needed. As pinctrl sleep is an optional driver feature we don't need to do any changes. For the DRA7 specific case, the platform configs ensure that PM is enabled. 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: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
On Wed, Nov 19, 2014 at 6:53 PM, Tony Lindgren t...@atomide.com wrote: * Enric Balletbo Serra eballe...@gmail.com [141119 03:14]: 2014-11-18 16:42 GMT+01:00 Tony Lindgren t...@atomide.com: Checked again, and no luck. It's very weird because from the OTG point of view, OTG is exactly the same between Beagleboard-XM and IGEPv2. Can you confirm that you're using kernel 3.18-rc5 without other patches applied ? At this moment, I don't have a Beagleboard-XM to test, I'll try to get one because at this moment I'm a bit stuck with this problem. Yes it was with v3.18-rc5 and the defconfig patch I posted except I had to disable all the other MUSB platforms. Also tested it with built in modules. Maybe you need to check the .dts pinctrl entries for hsusb0_* lines? Just my 2 cents, My am335x based board shows similar symptoms (CONFIG_USB_MUSB_DUAL_ROLE enabled). Only if I specify dr_mode = host; in my DTS I get device enumerated. 3.15, that I had before made no problems as OTG. Yegor -- 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] ARM: edma: Rename header file for dmaengine filter function definition
On Friday 28 November 2014 09:16:24 Peter Ujfalusi wrote: On 11/27/2014 11:52 PM, Arnd Bergmann wrote: On Thursday 27 November 2014 20:46:12 Peter Ujfalusi wrote: I see. With this series I did not planed to fix all edma related issues, just as a start clean up the related header files. I would rather not add fixes to mmc, spi, etc drivers since while you have valid point it is not in the scope of this series. Can we do the changes you are suggesting in an incremental manner? Sure, but I'd leave the existing filter function declaration alone then and not move it, since we wouldn't want to keep it in the long run. but if you want to reference the filter function (which is in drivers/dma/edma.c) in arch/arm/mach-davinci/ directory, we will need it. Don't we? Yes, unless you move the definition of the filter function into arch/arm/common/edma.c or arch/arm/mach-davinci/devices.c, but that would require other changes. If I leave the header as it is, then how would we clean up the edma headers? I would not put the API definitions for the arch code into the same file as we have the filter definition. Ok, just go ahead with your current patch then, we can always follow up. The most important cleanup for edma is elsewhere anyway, so once the asoc drivers can use the dmaengine interface, this should be easier. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: edma: Rename header file for dmaengine filter function definition
On 27 November 2014 at 11:41, Peter Ujfalusi peter.ujfal...@ti.com wrote:
Rename the include/linux/edma.h to include/linux/edma-dmaengine.h
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
For the mmc parts:
Acked-by: Ulf Hansson ulf.hans...@linaro.org
---
arch/arm/common/edma.c | 2 +-
drivers/mmc/host/davinci_mmc.c | 3 +--
drivers/spi/spi-davinci.c | 2 +-
include/linux/edma-dmaengine.h | 29 +
include/linux/edma.h | 29 -
sound/soc/davinci/edma-pcm.c | 2 +-
6 files changed, 33 insertions(+), 34 deletions(-)
create mode 100644 include/linux/edma-dmaengine.h
delete mode 100644 include/linux/edma.h
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 5662a872689b..bac677e65c76 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -25,7 +25,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/slab.h
-#include linux/edma.h
+#include linux/edma-dmaengine.h
#include linux/dma-mapping.h
#include linux/of_address.h
#include linux/of_device.h
diff --git a/drivers/mmc/host/davinci_mmc.c b/drivers/mmc/host/davinci_mmc.c
index 1625f908dc70..47323662c818 100644
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -32,12 +32,11 @@
#include linux/delay.h
#include linux/dmaengine.h
#include linux/dma-mapping.h
-#include linux/edma.h
+#include linux/edma-dmaengine.h
#include linux/mmc/mmc.h
#include linux/of.h
#include linux/of_device.h
-#include linux/platform_data/edma.h
#include linux/platform_data/mmc-davinci.h
/*
diff --git a/drivers/spi/spi-davinci.c b/drivers/spi/spi-davinci.c
index b3707badb1e5..d61b7cdb2deb 100644
--- a/drivers/spi/spi-davinci.c
+++ b/drivers/spi/spi-davinci.c
@@ -27,7 +27,7 @@
#include linux/clk.h
#include linux/dmaengine.h
#include linux/dma-mapping.h
-#include linux/edma.h
+#include linux/edma-dmaengine.h
#include linux/of.h
#include linux/of_device.h
#include linux/of_gpio.h
diff --git a/include/linux/edma-dmaengine.h b/include/linux/edma-dmaengine.h
new file mode 100644
index ..8a2602809a77
--- /dev/null
+++ b/include/linux/edma-dmaengine.h
@@ -0,0 +1,29 @@
+/*
+ * TI EDMA DMA engine driver
+ *
+ * Copyright 2012 Texas Instruments
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#ifndef __LINUX_EDMA_DMAENGINE_H
+#define __LINUX_EDMA_DMAENGINE_H
+
+struct dma_chan;
+
+#if defined(CONFIG_TI_EDMA) || defined(CONFIG_TI_EDMA_MODULE)
+bool edma_filter_fn(struct dma_chan *, void *);
+#else
+static inline bool edma_filter_fn(struct dma_chan *chan, void *param)
+{
+ return false;
+}
+#endif
+
+#endif
diff --git a/include/linux/edma.h b/include/linux/edma.h
deleted file mode 100644
index a1307e7827e8..
--- a/include/linux/edma.h
+++ /dev/null
@@ -1,29 +0,0 @@
-/*
- * TI EDMA DMA engine driver
- *
- * Copyright 2012 Texas Instruments
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License as
- * published by the Free Software Foundation version 2.
- *
- * This program is distributed as is WITHOUT ANY WARRANTY of any
- * kind, whether express or implied; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- */
-#ifndef __LINUX_EDMA_H
-#define __LINUX_EDMA_H
-
-struct dma_chan;
-
-#if defined(CONFIG_TI_EDMA) || defined(CONFIG_TI_EDMA_MODULE)
-bool edma_filter_fn(struct dma_chan *, void *);
-#else
-static inline bool edma_filter_fn(struct dma_chan *chan, void *param)
-{
- return false;
-}
-#endif
-
-#endif
diff --git a/sound/soc/davinci/edma-pcm.c b/sound/soc/davinci/edma-pcm.c
index 59e588abe54b..873c8a090427 100644
--- a/sound/soc/davinci/edma-pcm.c
+++ b/sound/soc/davinci/edma-pcm.c
@@ -23,7 +23,7 @@
#include sound/pcm_params.h
#include sound/soc.h
#include sound/dmaengine_pcm.h
-#include linux/edma.h
+#include linux/edma-dmaengine.h
#include edma-pcm.h
--
2.1.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 v9 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
On Friday 28 November 2014 09:55:53 Marek Szyprowski wrote: On 2014-11-27 23:51, Russell King - ARM Linux wrote: On Mon, Nov 17, 2014 at 12:48:22PM +0100, Marek Szyprowski wrote: Changes in this version tested on Exynos4412-based TRATS2 and OdroidU3+ boards (both with secure firmware). There should be no functional change for Exynos boards running without secure firmware. I do not have access to affected non-Exynos boards, so I could not test on them. So, I applied this series, and now I get a conflicts between my tree and arm-soc for: arch/arm/mach-exynos/firmware.c arch/arm/mach-exynos/sleep.S So, I'm going to un-stage the exynos bits, and we'll have to work out some way to handle those. Ok I've already pointed that those patches depend on other previously merged to exynos and arm-soc trees, but both Arnd and Kukjin said that those patch series should go via your kernel tree: https://lkml.org/lkml/2014/11/15/158 That's why in v9 I rebased patches once again onto vanilla v3.18-rc4 and uploaded to your patch tracker. I see the following two possibilities to get them merged: 1. Merge patches to rmk tree and resolve the merge conflict. The conflict IS quite easy to resolve - both trees, arm-soc and rmk only adds some code and the goal is simply to have both chunks added. 2. Merge the previous version (v8 from the above link) to arm-soc tree, where it applies cleanly on for-next, preferably with Russell's Acked-by. Arnd, Russell: which approach do you prefer? How can I help to get it merged? I'm fine with it either way. Russell, if you like you can merge http://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung v3.19-next/pm-samsung-2 into your tree and resolve the conflict on your end, we have a stable copy of that branch queued in next/soc. If you prefer v8 to go through arm-soc, that's fine with me too, or we could share a branch with v9 of Marek's series and have that merged into arm-soc/next/soc to resolve the conflict. arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] move omap gpmc to drivers finally
On Wednesday 26 November 2014, Tony Lindgren wrote: The following changes since commit 6f8782a7a1c826e1c013d6b7d5504af6bcc079e6: ARM: OMAP2+: Remove unnecesary include in GPMC driver (2014-11-06 10:51:06 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.19/gpmc-move for you to fetch changes up to d2c70f553d7203b9bb37730e577be29794ae3169: memory: gpmc: Move omap gpmc code to live under drivers (2014-11-26 11:11:19 -0800) We can finally move the GPMC code to live in drivers/memory for further clean up work. This series does the move with minimal changes to the code. I just looked at this branch. It's definitely nice to move the code to drivers/memory, but I don't like the idea of having lots of function declarations and internal data structures in a linux/platform_data/*.h file. We can still merge this for 3.19, but I want to make sure you have a plan for getting rid of this (and put that into the tag description). Does this header file get removed once all non-DT board files are gone? How about moving the declarations into include/linux/omap-gpmc.h instead? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] ARM: edma: Rename header file for dmaengine filter function definition
On 11/28/2014 12:51 PM, Arnd Bergmann wrote: On Friday 28 November 2014 09:16:24 Peter Ujfalusi wrote: On 11/27/2014 11:52 PM, Arnd Bergmann wrote: On Thursday 27 November 2014 20:46:12 Peter Ujfalusi wrote: I see. With this series I did not planed to fix all edma related issues, just as a start clean up the related header files. I would rather not add fixes to mmc, spi, etc drivers since while you have valid point it is not in the scope of this series. Can we do the changes you are suggesting in an incremental manner? Sure, but I'd leave the existing filter function declaration alone then and not move it, since we wouldn't want to keep it in the long run. but if you want to reference the filter function (which is in drivers/dma/edma.c) in arch/arm/mach-davinci/ directory, we will need it. Don't we? Yes, unless you move the definition of the filter function into arch/arm/common/edma.c or arch/arm/mach-davinci/devices.c, but that would require other changes. At the end the aim is to get rid of the edma code form arch/arm and have only dmaengine API towards eDMA. The ASoC davinci-pcm is the only user of the legacy API AFAIK. It has a mode called ping-pong which is not possible with the dmaeingine at all. This is to overcome underflow situations on parts where the audio IP does not have FIFO. My edma-pcm (which is using dmaengine) should be able to handle this situation, but I need to verify it before I can remove the davinci-pcm and then we can get rid of the direct eDMA API and code. If I leave the header as it is, then how would we clean up the edma headers? I would not put the API definitions for the arch code into the same file as we have the filter definition. Ok, just go ahead with your current patch then, we can always follow up. The most important cleanup for edma is elsewhere anyway, so once the asoc drivers can use the dmaengine interface, this should be easier. Arnd -- Péter -- 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 6/8] usb: musb: Pass fifo_mode in platform data
On Mon, Nov 24, 2014 at 8:05 PM, Tony Lindgren t...@atomide.com wrote: This allows setting the correct fifo_mode when multiple MUSB glue layers are built-in. Cc: Fabio Baltieri fabio.balti...@linaro.org Cc: Lee Jones lee.jo...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Apelete Seketeli apel...@seketeli.net Cc: Lars-Peter Clausen l...@metafoo.de Signed-off-by: Tony Lindgren t...@atomide.com Reviewed-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- 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 5/8] usb: musb: Change end point selection to use new IO access
On Mon, Nov 24, 2014 at 8:05 PM, Tony Lindgren t...@atomide.com wrote: This allows the endpoints to work when multiple MUSB glue layers are built in. Cc: Fabio Baltieri fabio.balti...@linaro.org Cc: Lee Jones lee.jo...@linaro.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Apelete Seketeli apel...@seketeli.net Cc: Lars-Peter Clausen l...@metafoo.de Signed-off-by: Tony Lindgren t...@atomide.com Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 1/2] part 2 of omap soc changes for v3.19
On Sunday 23 November 2014, Tony Lindgren wrote: The following changes since commit 9889278181bcdbae882664d8cee5bb0e064397e4: Merge tag 'for-v3.19/omap-a' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.19/soc (2014-11-14 10:25:12 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.19/hwmod-and-defconfig for you to fetch changes up to 374a735894fe2fb82ba07c6e6b7d326640c1c17f: ARM: omap2plus_defconfig: enable ECAP and EHRPWM (2014-11-21 16:30:28 -0800) SoC related changes for omaps including hwmod clean-up for DSS, and hwmod data for more UARTs and ADC. Also few defconfig changes to enable devices found on am335x and am437x. Hi Tony, We have started doing the defconfig changes in a separate branch a while ago. I normally don't mess with the tags I got, but this one seemed easy enough to redo, as the defconfig changes are all on top. I ended up pulling in only the commits before the defconfig changes into next/soc, and am cherry-picking the defconfig bits onto the next/defconfig branch. Hope that's ok for you. I checked that the defconfig changes are all harmless and do not depend on the other changes, but I may have missed something subtle, so please confirm that this is ok for you. Thanks, Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 2/2] part 2 of omap dts changes for v3.19
On Monday 24 November 2014, Tony Lindgren wrote: More dts changes for omaps to add support for new devices: - Add DCAN support am335x, am437x and dra7 - Add devices for sb-t3x computers - Add support for NovaTech OrionLXm - Add n900 battery and si4713 support Pulled into next/dt, thanks! Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 6/7] clk: Make clk API return per-user struct clk instances
Moves clock state to struct clk_core, but takes care to change as little API as
possible.
struct clk_hw still has a pointer to a struct clk, which is the
implementation's per-user clk instance, for backwards compatibility.
The struct clk that clk_get_parent() returns isn't owned by the caller, but by
the clock implementation, so the former shouldn't call clk_put() on it.
Because some boards in mach-omap2 still register clocks statically, their clock
registration had to be updated to take into account that the clock information
is stored in struct clk_core now.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
v6: * Guard against NULL pointer
v4: * Remove unused function __clk_core_to_clk
* Use core more often as the name for struct clk_core* variables
* Make sure we don't lose information about the caller in of_clk_get_*
v3: * Rebase on top of linux-next 20141009
v2: * Remove exported functions that aren't really used outside clk.c
* Rename new internal functions to clk_core_ prefix
* Remove redundant checks for error pointers in *_get_parent
* Change __clk_create_clk to take a struct clk_hw instead
* Match the original error behavior in clk_get_sys
---
arch/arm/mach-omap2/cclock3xxx_data.c | 108 --
arch/arm/mach-omap2/clock.h | 11 +-
arch/arm/mach-omap2/clock_common_data.c | 5 +-
drivers/clk/clk.c | 644
drivers/clk/clk.h | 5 +
drivers/clk/clkdev.c| 73 +++-
include/linux/clk-private.h | 35 +-
include/linux/clk-provider.h| 9 +-
8 files changed, 577 insertions(+), 313 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 5c5ebb4..fe722d8 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -82,7 +82,7 @@ DEFINE_CLK_MUX(osc_sys_ck, osc_sys_ck_parent_names, NULL, 0x0,
OMAP3430_PRM_CLKSEL, OMAP3430_SYS_CLKIN_SEL_SHIFT,
OMAP3430_SYS_CLKIN_SEL_WIDTH, 0x0, NULL);
-DEFINE_CLK_DIVIDER(sys_ck, osc_sys_ck, osc_sys_ck, 0x0,
+DEFINE_CLK_DIVIDER(sys_ck, osc_sys_ck, osc_sys_ck_core, 0x0,
OMAP3430_PRM_CLKSRC_CTRL, OMAP_SYSCLKDIV_SHIFT,
OMAP_SYSCLKDIV_WIDTH, CLK_DIVIDER_ONE_BASED, NULL);
@@ -131,7 +131,7 @@ static struct clk_hw_omap dpll3_ck_hw = {
DEFINE_STRUCT_CLK(dpll3_ck, dpll3_ck_parent_names, dpll3_ck_ops);
-DEFINE_CLK_DIVIDER(dpll3_m2_ck, dpll3_ck, dpll3_ck, 0x0,
+DEFINE_CLK_DIVIDER(dpll3_m2_ck, dpll3_ck, dpll3_ck_core, 0x0,
OMAP_CM_REGADDR(PLL_MOD, CM_CLKSEL1),
OMAP3430_CORE_DPLL_CLKOUT_DIV_SHIFT,
OMAP3430_CORE_DPLL_CLKOUT_DIV_WIDTH,
@@ -148,12 +148,12 @@ static const struct clk_ops core_ck_ops = {};
DEFINE_STRUCT_CLK_HW_OMAP(core_ck, NULL);
DEFINE_STRUCT_CLK(core_ck, core_ck_parent_names, core_ck_ops);
-DEFINE_CLK_DIVIDER(l3_ick, core_ck, core_ck, 0x0,
+DEFINE_CLK_DIVIDER(l3_ick, core_ck, core_ck_core, 0x0,
OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
OMAP3430_CLKSEL_L3_SHIFT, OMAP3430_CLKSEL_L3_WIDTH,
CLK_DIVIDER_ONE_BASED, NULL);
-DEFINE_CLK_DIVIDER(l4_ick, l3_ick, l3_ick, 0x0,
+DEFINE_CLK_DIVIDER(l4_ick, l3_ick, l3_ick_core, 0x0,
OMAP_CM_REGADDR(CORE_MOD, CM_CLKSEL),
OMAP3430_CLKSEL_L4_SHIFT, OMAP3430_CLKSEL_L4_WIDTH,
CLK_DIVIDER_ONE_BASED, NULL);
@@ -274,9 +274,9 @@ static struct clk_hw_omap dpll1_ck_hw = {
DEFINE_STRUCT_CLK(dpll1_ck, dpll3_ck_parent_names, dpll1_ck_ops);
-DEFINE_CLK_FIXED_FACTOR(dpll1_x2_ck, dpll1_ck, dpll1_ck, 0x0, 2, 1);
+DEFINE_CLK_FIXED_FACTOR(dpll1_x2_ck, dpll1_ck, dpll1_ck_core, 0x0, 2, 1);
-DEFINE_CLK_DIVIDER(dpll1_x2m2_ck, dpll1_x2_ck, dpll1_x2_ck, 0x0,
+DEFINE_CLK_DIVIDER(dpll1_x2m2_ck, dpll1_x2_ck, dpll1_x2_ck_core, 0x0,
OMAP_CM_REGADDR(MPU_MOD, OMAP3430_CM_CLKSEL2_PLL),
OMAP3430_MPU_DPLL_CLKOUT_DIV_SHIFT,
OMAP3430_MPU_DPLL_CLKOUT_DIV_WIDTH,
@@ -291,7 +291,7 @@ static const char *mpu_ck_parent_names[] = {
DEFINE_STRUCT_CLK_HW_OMAP(mpu_ck, mpu_clkdm);
DEFINE_STRUCT_CLK(mpu_ck, mpu_ck_parent_names, core_l4_ick_ops);
-DEFINE_CLK_DIVIDER(arm_fck, mpu_ck, mpu_ck, 0x0,
+DEFINE_CLK_DIVIDER(arm_fck, mpu_ck, mpu_ck_core, 0x0,
OMAP_CM_REGADDR(MPU_MOD, OMAP3430_CM_IDLEST_PLL),
OMAP3430_ST_MPU_CLK_SHIFT, OMAP3430_ST_MPU_CLK_WIDTH,
0x0, NULL);
@@ -423,7 +423,7 @@ static const struct clk_div_table dpll4_mx_ck_div_table[] =
{
{ .div = 0 },
};
-DEFINE_CLK_DIVIDER(dpll4_m5_ck, dpll4_ck, dpll4_ck, 0x0,
+DEFINE_CLK_DIVIDER(dpll4_m5_ck, dpll4_ck, dpll4_ck_core, 0x0,
OMAP_CM_REGADDR(OMAP3430_CAM_MOD, CM_CLKSEL),
OMAP3430_CLKSEL_CAM_SHIFT,
[PATCH v6 7/7] clk: Add floor and ceiling constraints to clock rates
Adds a way for clock consumers to set maximum and minimum rates. This can be
used for thermal drivers to set ceiling rates, or by misc. drivers to set
floor rates to assure a minimum performance level.
Signed-off-by: Tomeu Vizoso tomeu.viz...@collabora.com
---
v6: * Take the prepare lock before removing a per-user clk
* Init per-user clks list before adding the first clk
* Pass the constraints to determine_rate and let clk
implementations deal with constraints
* Add clk_set_rate_range
v5: * Initialize clk.ceiling_constraint to ULONG_MAX
* Warn about inconsistent constraints
v4: * Copy function docs from header
* Move WARN out of critical section
* Refresh rate after removing a per-user clk
* Rename clk_core.per_user_clks to clk_core.clks
* Store requested rate and re-apply it when constraints are updated
---
Documentation/clk.txt | 2 +
arch/arm/mach-omap2/dpll3xxx.c | 2 +
arch/arm/mach-omap2/dpll44xx.c | 2 +
arch/mips/alchemy/common/clock.c| 8 ++
drivers/clk/at91/clk-programmable.c | 2 +
drivers/clk/bcm/clk-kona.c | 2 +
drivers/clk/clk-composite.c | 9 +-
drivers/clk/clk.c | 160 +---
drivers/clk/hisilicon/clk-hi3620.c | 2 +
drivers/clk/qcom/clk-pll.c | 1 +
drivers/clk/qcom/clk-rcg.c | 4 +
drivers/clk/qcom/clk-rcg2.c | 6 ++
drivers/clk/sunxi/clk-factors.c | 2 +
drivers/clk/sunxi/clk-sun6i-ar100.c | 2 +
include/linux/clk-private.h | 6 ++
include/linux/clk-provider.h| 11 ++-
include/linux/clk.h | 28 +++
include/linux/clk/ti.h | 4 +
18 files changed, 218 insertions(+), 35 deletions(-)
diff --git a/Documentation/clk.txt b/Documentation/clk.txt
index 4ff8462..8ebd665 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -73,6 +73,8 @@ the operations defined in clk.h:
unsigned long *parent_rate);
long(*determine_rate)(struct clk_hw *hw,
unsigned long rate,
+ unsigned long floor_rate,
+ unsigned long ceiling_rate,
unsigned long *best_parent_rate,
struct clk_hw
**best_parent_clk);
int (*set_parent)(struct clk_hw *hw, u8 index);
diff --git a/arch/arm/mach-omap2/dpll3xxx.c b/arch/arm/mach-omap2/dpll3xxx.c
index 20e120d..97084cb 100644
--- a/arch/arm/mach-omap2/dpll3xxx.c
+++ b/arch/arm/mach-omap2/dpll3xxx.c
@@ -473,6 +473,8 @@ void omap3_noncore_dpll_disable(struct clk_hw *hw)
* in failure.
*/
long omap3_noncore_dpll_determine_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long floor_rate,
+ unsigned long ceiling_rate,
unsigned long *best_parent_rate,
struct clk **best_parent_clk)
{
diff --git a/arch/arm/mach-omap2/dpll44xx.c b/arch/arm/mach-omap2/dpll44xx.c
index 535822f..67d9bd0 100644
--- a/arch/arm/mach-omap2/dpll44xx.c
+++ b/arch/arm/mach-omap2/dpll44xx.c
@@ -222,6 +222,8 @@ out:
* in failure.
*/
long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long floor_rate,
+ unsigned long ceiling_rate,
unsigned long *best_parent_rate,
struct clk **best_parent_clk)
{
diff --git a/arch/mips/alchemy/common/clock.c b/arch/mips/alchemy/common/clock.c
index 48a9dfc..731bedd 100644
--- a/arch/mips/alchemy/common/clock.c
+++ b/arch/mips/alchemy/common/clock.c
@@ -373,6 +373,8 @@ static long alchemy_calc_div(unsigned long rate, unsigned
long prate,
}
static long alchemy_clk_fgcs_detr(struct clk_hw *hw, unsigned long rate,
+ unsigned long floor_rate,
+ unsigned long ceiling_rate,
unsigned long *best_parent_rate,
struct clk_hw **best_parent_clk,
int scale, int maxdiv)
@@ -546,6 +548,8 @@ static unsigned long alchemy_clk_fgv1_recalc(struct clk_hw
*hw,
}
static long alchemy_clk_fgv1_detr(struct clk_hw *hw, unsigned long rate,
+ unsigned long floor_rate,
+ unsigned long ceiling_rate,
unsigned long *best_parent_rate,
struct clk_hw **best_parent_clk)
{
@@ -678,6
[PATCH v6 0/7] Per-user clock constraints
Hello, this sixth version of the series has a small fix in the per-user clks commit and the following changes in the clk constraints patch: * Take the prepare lock before removing a per-user clk * Init per-user clks list before adding the first clk * Pass the constraints to determine_rate and let clk implementations deal with constraints * Add clk_set_rate_range A rough test module was used to test this: http://cgit.collabora.com/git/user/tomeu/linux.git/commit/?h=per-user-clk-constraints-v6id=1bada453ab690a1c5be28667d94a4861bc84f8ef The first five patches are just cleanups that should be desirable on their own, and that should make easier to review the actual per-user clock patch. The sixth patch actually moves the per-clock data that was stored in struct clk to a new struct clk_core and adds references to it from both struct clk and struct clk_hw. struct clk is now ready to contain information that is specific to a given clk consumer. The seventh patch adds API for setting floor and ceiling constraints and stores that information on the per-user struct clk, which is iterable from struct clk_core. They are based on top of linux-next 20141128. http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=per-user-clk-constraints-v6 Thanks, Tomeu Tomeu Vizoso (7): clk: Remove unused function __clk_get_prepare_count clk: Don't try to use a struct clk* after it could have been freed clk: Don't expose __clk_get_accuracy clk: change clk_debugfs_add_file to take a struct clk_hw clk: Change clk_ops-determine_rate to return a clk_hw as the best parent clk: Make clk API return per-user struct clk instances clk: Add floor and ceiling constraints to clock rates Documentation/clk.txt | 4 +- arch/arm/mach-omap2/cclock3xxx_data.c | 108 +++-- arch/arm/mach-omap2/clock.h | 11 +- arch/arm/mach-omap2/clock_common_data.c | 5 +- arch/arm/mach-omap2/dpll3xxx.c | 2 + arch/arm/mach-omap2/dpll44xx.c | 2 + arch/mips/alchemy/common/clock.c| 18 +- drivers/clk/at91/clk-programmable.c | 6 +- drivers/clk/bcm/clk-kona.c | 6 +- drivers/clk/clk-composite.c | 18 +- drivers/clk/clk.c | 807 +--- drivers/clk/clk.h | 5 + drivers/clk/clkdev.c| 73 ++- drivers/clk/hisilicon/clk-hi3620.c | 4 +- drivers/clk/qcom/clk-pll.c | 1 + drivers/clk/qcom/clk-rcg.c | 24 +- drivers/clk/qcom/clk-rcg2.c | 34 +- drivers/clk/sunxi/clk-factors.c | 6 +- drivers/clk/sunxi/clk-sun6i-ar100.c | 6 +- include/linux/clk-private.h | 41 +- include/linux/clk-provider.h| 26 +- include/linux/clk.h | 28 ++ include/linux/clk/ti.h | 4 + 23 files changed, 849 insertions(+), 390 deletions(-) -- 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: [PATCHv2] rpmsg: compute number of buffers to allocate from vrings
On Thu, Nov 27, 2014 at 12:30 AM, Suman Anna s-a...@ti.com wrote: Yep, I have reviewed and verified the changes, it is good to go. Applied, thanks! -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL 1/2] part 2 of omap soc changes for v3.19
* Arnd Bergmann a...@arndb.de [141128 05:57]: On Sunday 23 November 2014, Tony Lindgren wrote: The following changes since commit 9889278181bcdbae882664d8cee5bb0e064397e4: Merge tag 'for-v3.19/omap-a' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.19/soc (2014-11-14 10:25:12 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.19/hwmod-and-defconfig for you to fetch changes up to 374a735894fe2fb82ba07c6e6b7d326640c1c17f: ARM: omap2plus_defconfig: enable ECAP and EHRPWM (2014-11-21 16:30:28 -0800) SoC related changes for omaps including hwmod clean-up for DSS, and hwmod data for more UARTs and ADC. Also few defconfig changes to enable devices found on am335x and am437x. Hi Tony, We have started doing the defconfig changes in a separate branch a while ago. I normally don't mess with the tags I got, but this one seemed easy enough to redo, as the defconfig changes are all on top. I ended up pulling in only the commits before the defconfig changes into next/soc, and am cherry-picking the defconfig bits onto the next/defconfig branch. Hope that's ok for you. Sure that's fine with me, I only have fixes coming up after the pending pull requests. I checked that the defconfig changes are all harmless and do not depend on the other changes, but I may have missed something subtle, so please confirm that this is ok for you. Should be just fine thanks. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
* Pali Rohár pali.ro...@gmail.com [141127 03:34]: On Thursday 27 November 2014 02:12:04 Tony Lindgren wrote: Thinking about this probably the best long term solution is to pass optional board_revision in the kernel cmdline that can be parsed early and copied to system_rev variable. Not possible. Our bootloader is closed proprietary. I tried to replace it with u-boot I was not able to do that. So we will use that Nokia closed bootloader forever and it can provide data only in ATAG structure. I'm using just mainline u-boot flashed as kernel for nolo that then loads the kernel. For passing the board revision using the pass through u-boot is probably the best long term solution. U-boot can read the ATAGs from nolo and modify the .dtb for the revision information. Are you saying there are some issues with that? Or if you can think of some other way to get it, we can set system_rev in pdata-quirks.c. Or maybe add some code to copy the ATAGs somewhere where they are out of the way and don't conflict with the device tree data? Then we can query ATAG_REVISION from pdata-quirks.c and set system_rev. If we are able to read ATAG from pdata-quirks, then we can parse it there and fix problems... But I do not know if address of ATAG structure is available there... Are there other ATAGs needed beyond the ATAG_REVISION? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
On Friday 28 November 2014 21:27:19 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [141127 03:34]:
On Thursday 27 November 2014 02:12:04 Tony Lindgren wrote:
Thinking about this probably the best long term solution
is to pass optional board_revision in the kernel cmdline
that can be parsed early and copied to system_rev
variable.
Not possible. Our bootloader is closed proprietary. I
tried to replace it with u-boot I was not able to do that.
So we will use that Nokia closed bootloader forever and it
can provide data only in ATAG structure.
I'm using just mainline u-boot flashed as kernel for nolo that
then loads the kernel.
Yes, this working. I wrote tested more those n900 uboot parts.
For passing the board revision using the pass through u-boot
is probably the best long term solution. U-boot can read the
ATAGs from nolo and modify the .dtb for the revision
information.
Yes, this is possible. Current uboot rx51 code already parse
ATAGs from previous bootloader, so is also able to modify dtb.
Are you saying there are some issues with that?
uboot (in mode when is loaded from NOLO) has those issues:
1) uboot cannot read n900 onenand mtd (uboot onenand driver not
working, do not know why)
2) missing support for battery charging (can totally discharge
battery)
3) missing support for panel panel (so sometimes screen is
totally black until kernel is booted and loaded own drivers)
4) limit for storing both uboot and kernel into MTD is limited by
2MB (size of kernel nand partition)
Basically you can use uboot if you accept all above issues.
But there are people (Pavel CCed) who prefer to work without
uboot when testing kernel. So it is not good idea to lock new
kernel versions to depends on new uboot version.
Or if you can think of some other way to get it, we can
set system_rev in pdata-quirks.c.
Or maybe add some code to copy the ATAGs somewhere where
they are out of the way and don't conflict with the device
tree data? Then we can query ATAG_REVISION from
pdata-quirks.c and set system_rev.
If we are able to read ATAG from pdata-quirks, then we can
parse it there and fix problems... But I do not know if
address of ATAG structure is available there...
Are there other ATAGs needed beyond the ATAG_REVISION?
Regards,
Tony
Sorry for longer email. I will provide some more info about it.
First I will describe that informations are passed from NOLO
to kernel. Note that all those informations are passed also from
uboot to kernel (uboot just reuse non static data from NOLO).
Then I will describe that we need in userspace.
Here are all ATAGs from NOLO:
- 0005:54410001 ATAG CORE flags= pagesize=1000 rootdev=
0020 - 0004:54410002 ATAG MEM size=1000 start=8000
0036 - 0003:54410007 ATAG REVISION revision=2204
0048 - 0181:414f4d50 OMAP table (724 bytes)
- 0004:4f07 UART: enabled uarts (bitmask)
0008 - 0024:4f05 LCD: panel=acx565akm controller=internal
nreset_gpio=005a
data_lines=0018
0048 - 0014:4f06 GPIO SWITCH: cam_focus: gpio=0044 flags=01 type=02
keycode=
0072 - 0014:4f06 GPIO SWITCH: cam_launch : gpio=0045 flags=01 type=02
keycode=
0096 - 0014:4f06 GPIO SWITCH: cam_shutter : gpio=006e flags=01 type=00
keycode=
0120 - 0014:4f06 GPIO SWITCH: cmt_apeslpx : gpio=0046 flags=02 type=02
keycode=
0144 - 0014:4f06 GPIO SWITCH: cmt_bsi : gpio=009d flags=02 type=02
keycode=
0168 - 0014:4f06 GPIO SWITCH: cmt_en : gpio=004a flags=02 type=02
keycode=
0192 - 0014:4f06 GPIO SWITCH: cmt_rst : gpio=004b flags=06 type=02
keycode=
0216 - 0014:4f06 GPIO SWITCH: cmt_rst_rq : gpio=0049 flags=06 type=02
keycode=
0240 - 0014:4f06 GPIO SWITCH: cmt_wddis: gpio=000d flags=02 type=02
keycode=
0264 - 0014:4f06 GPIO SWITCH: headphone: gpio=00b1 flags=01 type=01
keycode=
0288 - 0014:4f06 GPIO SWITCH: kb_lock : gpio=0071 flags=01 type=00
keycode=
0312 - 0014:4f06 GPIO SWITCH: proximity: gpio=0059 flags=00 type=00
keycode=
0336 - 0014:4f06 GPIO SWITCH: sleep_ind: gpio=00a2 flags=02 type=02
keycode=
0360 - 0014:4f06 GPIO SWITCH: slide: gpio=0047 flags=00 type=00
keycode=
0384 - 0008:4e02 WLAN CX3110X: chip_type=25 power_gpio=0057
irq_gpio=002a spi_cs_gpio=
0396 - 001c:4f0b PARTITION:bootloader : size=0002
offset= mask=0003
0428 - 001c:4f0b PARTITION:config : size=0006
offset=0002 mask=
0460 - 001c:4f0b PARTITION:log : size=0004
offset=0008 mask=
0492 - 001c:4f0b PARTITION:kernel : size=0020
offset=000c mask=
0524 - 001c:4f0b
Re: [GIT PULL] move omap gpmc to drivers finally
* Arnd Bergmann a...@arndb.de [141128 03:31]: On Wednesday 26 November 2014, Tony Lindgren wrote: We can finally move the GPMC code to live in drivers/memory for further clean up work. This series does the move with minimal changes to the code. I just looked at this branch. It's definitely nice to move the code to drivers/memory, but I don't like the idea of having lots of function declarations and internal data structures in a linux/platform_data/*.h file. We can still merge this for 3.19, but I want to make sure you have a plan for getting rid of this (and put that into the tag description). Does this header file get removed once all non-DT board files are gone? Yes that will become driver internal data at that point. How about moving the declarations into include/linux/omap-gpmc.h instead? OK. Below is an updated pull request with the platform_data/omap-gpmc.h dropped. Regards, Tony 8 --- The following changes since commit 6f8782a7a1c826e1c013d6b7d5504af6bcc079e6: ARM: OMAP2+: Remove unnecesary include in GPMC driver (2014-11-06 10:51:06 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.19/gpmc-move-v2 for you to fetch changes up to 186401937927426f85a28bd798e82ca18e4e5549: memory: gpmc: Move omap gpmc code to live under drivers (2014-11-28 12:54:39 -0800) We can finally move the GPMC code to live in drivers/memory for further clean up work. Note that we still have dependencies to the legacy booting for omap3 board-*.c files for setting up the board specific memory timings. For that we need the timing related things still exposed in include/linux/omap-gpmc.h. This will all become private data to the GPMC driver once the legacy booting support can be dropped. Tony Lindgren (3): ARM: OMAP2+: Prepare to move GPMC to drivers by platform data header ARM: OMAP2+: Move GPMC initcall to devices.c memory: gpmc: Move omap gpmc code to live under drivers MAINTAINERS| 8 + arch/arm/mach-omap2/Kconfig| 2 + arch/arm/mach-omap2/Makefile | 2 +- arch/arm/mach-omap2/board-am3517crane.c| 1 + arch/arm/mach-omap2/board-cm-t35.c | 3 +- arch/arm/mach-omap2/board-cm-t3517.c | 3 +- arch/arm/mach-omap2/board-flash.c | 3 +- arch/arm/mach-omap2/board-flash.h | 1 - arch/arm/mach-omap2/board-n8x0.c | 2 - arch/arm/mach-omap2/board-omap3pandora.c | 2 +- arch/arm/mach-omap2/board-rx51-peripherals.c | 3 +- arch/arm/mach-omap2/devices.c | 26 +++ arch/arm/mach-omap2/gpmc-nand.c| 3 +- arch/arm/mach-omap2/gpmc-nand.h| 27 --- arch/arm/mach-omap2/gpmc-onenand.c | 3 +- arch/arm/mach-omap2/gpmc-onenand.h | 24 --- arch/arm/mach-omap2/gpmc.h | 227 + arch/arm/mach-omap2/pm34xx.c | 2 +- drivers/memory/Kconfig | 8 + drivers/memory/Makefile| 1 + .../gpmc.c = drivers/memory/omap-gpmc.c | 90 +--- include/linux/omap-gpmc.h | 199 ++ 22 files changed, 316 insertions(+), 324 deletions(-) delete mode 100644 arch/arm/mach-omap2/gpmc-nand.h delete mode 100644 arch/arm/mach-omap2/gpmc-onenand.h rename arch/arm/mach-omap2/gpmc.c = drivers/memory/omap-gpmc.c (95%) create mode 100644 include/linux/omap-gpmc.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] i2c: omap: TEST: do IP reset during probe.
* Kevin Hilman khil...@kernel.org [141126 13:27]: Alexander Kochetkov al.koc...@gmail.com writes: NOT FOR UPSTREAM The patch checks if IP reset during probe could bring I2C bus to a free state on omap2430 - omap3530 boards. I guess, IP hold one of I2C lines in a low state. I guess, u-boot haven't sent a stop condition. The patch is rebased on branch 'i2c/for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux (6e79807443cba7397cd855ed29d6faba51d4c893) Signed-off-by: Alexander Kochetkov al.koc...@gmail.com Reported-by: Kevin Hilman khil...@kernel.org Tested-by: Kevin Hilman khil...@kernel.org Built for omap2plus_defconfig and tested on all my OMAP boards. Results here: http://people.linaro.org/~khilman/tmp/next-20141126-1-g760388ee02e4/arm-omap2plus_defconfig/ And below is the output from 2430sdp with linux next plus Alexander's test patch. Looks like for some time 2430 i2c has not been behaving reliably unless I force compatible to ti,omap2420-i2c instead of ti,omap2430-i2c.. The output below is with ti,omap2430-i2c. Regards, Tony 8 - [0.913574] omap_i2c 4807.i2c: init0: STAT=0x; IE=0x601f; CON=0x8000; SYSTEST=0x; SDA=00 [OI]; SCL=00 [OI] (omap_i2c_init:493) [1.931365] omap_i2c 4807.i2c: timeout waiting for bus ready [1.931457] omap_i2c 4807.i2c: init1: STAT=0x; IE=0x601f; CON=0x8000; SYSTEST=0x; SDA=00 [OI]; SCL=00 [OI] (omap_i2c_init:497) [1.931518] omap_i2c 4807.i2c: init1: bb_valid=0 [2.949249] omap_i2c 4807.i2c: timeout waiting for bus ready [2.949340] omap_i2c 4807.i2c: init2: STAT=0x; IE=0x601f; CON=0x8000; SYSTEST=0x; SDA=00 [OI]; SCL=00 [OI] (omap_i2c_init:504) [2.949401] omap_i2c 4807.i2c: init2: bb_valid=0 [2.952941] omap_i2c 4807.i2c: bus 0 rev3.3 at 100 kHz (rev 0036) [2.969299] omap_i2c 48072000.i2c: init0: STAT=0x; IE=0x601f; CON=0x8000; SYSTEST=0x; SDA=00 [OI]; SCL=00 [OI] (omap_i2c_init:493) [3.987091] omap_i2c 48072000.i2c: timeout waiting for bus ready [3.987182] omap_i2c 48072000.i2c: init1: STAT=0x; IE=0x601f; CON=0x8000; SYSTEST=0x; SDA=00 [OI]; SCL=00 [OI] (omap_i2c_init:497) [3.987243] omap_i2c 48072000.i2c: init1: bb_valid=0 [5.004974] omap_i2c 48072000.i2c: timeout waiting for bus ready [5.005096] omap_i2c 48072000.i2c: init2: STAT=0x; IE=0x601f; CON=0x8000; SYSTEST=0x; SDA=00 [OI]; SCL=00 [OI] (omap_i2c_init:504) [5.005126] omap_i2c 48072000.i2c: init2: bb_valid=0 [5.017517] omap_i2c 48072000.i2c: bus 1 rev3.3 at 100 kHz (rev 0036) [7.555419] twl4030_keypad 48072000.i2c:twl@48:keypad: OF: linux,keymap property not defined in /ocp/i2c@48072000/twl@48/keypad [7.567626] twl4030_keypad 48072000.i2c:twl@48:keypad: Failed to build keymap [7.575439] twl4030_keypad: probe of 48072000.i2c:twl@48:keypad failed with error -2 [7.599639] input: twl4030_pwrbutton as /devices/platform/ocp/48072000.i2c/i2c-1/1-0048/48072000.i2c:twl@48:pwrbutton/input/input1 [7.624450] twl_rtc 48072000.i2c:twl@48:rtc: Power up reset detected. [7.631988] twl_rtc 48072000.i2c:twl@48:rtc: Enabling TWL-RTC [7.655456] twl_rtc 48072000.i2c:twl@48:rtc: rtc core: registered 48072000.i2c:twl@48 as rtc0 [7.923187] i2c /dev entries driver [8.246795] twl_rtc 48072000.i2c:twl@48:rtc: hctosys: unable to read the hardware clock [9.675994] omap_i2c 48072000.i2c: controller timed out [ 10.704010] omap_i2c 48072000.i2c: controller timed out [ 11.734069] omap_i2c 48072000.i2c: controller timed out root@omap2430sdp:/# [ 12.823638] omap_i2c 48072000.i2c: controller timed out [ 12.834747] twl4030: I2C error -110 reading PIH ISR -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
Hi, On Fri, Nov 28, 2014 at 10:41:12PM +0100, Pali Rohár wrote: Does kernel provide some interface for telling userspace applications something like bootreason (e.g power key, software reset, rtc alarm, charger connected, ...)? In N950/N9, NOLO passes this information using kernel command line and applications are reading /proc/cmdline. If I remember correctly all those custom proc files were removed from Nokia kernel, and everything was passed via command line. A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
* Pali Rohár pali.ro...@gmail.com [141128 13:43]: On Friday 28 November 2014 21:27:19 Tony Lindgren wrote: Are you saying there are some issues with that? uboot (in mode when is loaded from NOLO) has those issues: 1) uboot cannot read n900 onenand mtd (uboot onenand driver not working, do not know why) 2) missing support for battery charging (can totally discharge battery) 3) missing support for panel panel (so sometimes screen is totally black until kernel is booted and loaded own drivers) 4) limit for storing both uboot and kernel into MTD is limited by 2MB (size of kernel nand partition) Basically you can use uboot if you accept all above issues. But there are people (Pavel CCed) who prefer to work without uboot when testing kernel. So it is not good idea to lock new kernel versions to depends on new uboot version. OK thanks for the update, I was not aware of the issues above. Are there other ATAGs needed beyond the ATAG_REVISION? Sorry for longer email. I will provide some more info about it. First I will describe that informations are passed from NOLO to kernel. Note that all those informations are passed also from uboot to kernel (uboot just reuse non static data from NOLO). Then I will describe that we need in userspace. Here are all ATAGs from NOLO: ... These we should not need, it's all coming from the .dts files. 0036 - 0003:54410007 ATAG REVISION revision=2204 0588 - 000c:4f80 BOOTREASON: pwr_key 0604 - 0018:4f82 VERSION: product = RX-51 0632 - 0018:4f82 VERSION: hw-build = 2204 0660 - 0018:4f82 VERSION: nolo = 1.4.14 0688 - 0018:4f82 VERSION: boot-mode= normal Seems like these are the ones we should somehow get. The others should be coming in the .dts file already, or can be deciphered based on the above in the kernel. ATAG MEM is generated by NOLO and also uboot at runtime. But we have hardcoded memory values in n900 DT file. Maybe we should use those generated by uboot bootloader (or reuse uboot code for generating) instead using hardcoded one? Yes we should not need ATAG MEM. ATAG REVISION is that which is magically generated by NOLO and which we want to reuse. Better would be understand how and why it NOLO generate (maybe there is something secret register which can tell it?). But I was not able to find out it. I would assume that's also somewhere in the cal area. OMAP table is one big ATAG structure which contains lot of other values. Basically all values (except uart, bootreason and version) are static and on all n900 devices are same. Partitions are generated by NOLO from CAL (/dev/mtd1) data, but I think nobody ever changed them (but it is possible!). AFAIK it's safe to assume they are coming in the .dts file. Uart is enabled when serial console is enabled via NOLO. We can keep the UART enabled all the time no problem. It's timeouts just need to be configured for idle. Bootreason contains omap3 bootreason value from special register (plus magic from NOLO) which is cleared automatically by NOLO (so no way to read it from kernel). Version contains some key-value data. Product is always RX-51, hw-build is same as ATAG REVISION, nolo is nolo version and value for boot-mode is ether normal or update. OK What we need in userspace: In file /proc/cpuinfo: Hardware: Nokia RX-51 board Revision: hw_revision_number And in any file and any format (does not matter if text, binary, whatever...) we need value from bootreason, boot-mode (and maybe nolo version). OK Current maemo applications are using files /proc/bootreason (for bootreason) and /proc/component_version (for all version) which are specific for Nokia 2.6.28 kernel. All those applications (which reading ether bootreason or bootmode proc files) are either shell scripts or open source, so editing them is possible. I will start fixing them once there will be *stable* ABI for those data. With non DT (legacy) boot all above atags are present in binary file /proc/atags. But because DT boot does not provide /proc/atags file I need some interface how to read above needed strings. So I would like to know what is possible and how? How about patch things so we see /proc/atags also for DT based booting, but in a way where the ATAGs don't do anything? Does kernel provide some interface for telling userspace applications something like bootreason (e.g power key, software reset, rtc alarm, charger connected, ...)? I don't think we have anything like that currently. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] move omap gpmc to drivers finally
On Friday 28 November 2014 13:39:16 Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [141128 03:31]: On Wednesday 26 November 2014, Tony Lindgren wrote: We can finally move the GPMC code to live in drivers/memory for further clean up work. This series does the move with minimal changes to the code. I just looked at this branch. It's definitely nice to move the code to drivers/memory, but I don't like the idea of having lots of function declarations and internal data structures in a linux/platform_data/*.h file. We can still merge this for 3.19, but I want to make sure you have a plan for getting rid of this (and put that into the tag description). Does this header file get removed once all non-DT board files are gone? Yes that will become driver internal data at that point. Ok, cool. How about moving the declarations into include/linux/omap-gpmc.h instead? OK. Below is an updated pull request with the platform_data/omap-gpmc.h dropped. Pulled into next/omap-gpmc, thanks! I guess we'll end up merging this branch into next/drivers before submitting, but I have to see the relative sizes first. If it's a significant chunk of the drivers changes, we might submit it as one branch to Linus. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
Hi, On Fri, Nov 28, 2014 at 10:41:12PM +0100, Pali Rohár wrote: uboot (in mode when is loaded from NOLO) has those issues: 1) uboot cannot read n900 onenand mtd (uboot onenand driver not working, do not know why) 2) missing support for battery charging (can totally discharge battery) NOLO enables watchdogs when booting. So if you get stuck in the U-boot for whatever reason the device will power off after ~30 secs or so. A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
On Friday 28 November 2014 23:24:26 Tony Lindgren wrote: * Pali Rohár pali.ro...@gmail.com [141128 13:43]: On Friday 28 November 2014 21:27:19 Tony Lindgren wrote: Are you saying there are some issues with that? uboot (in mode when is loaded from NOLO) has those issues: 1) uboot cannot read n900 onenand mtd (uboot onenand driver not working, do not know why) 2) missing support for battery charging (can totally discharge battery) 3) missing support for panel panel (so sometimes screen is totally black until kernel is booted and loaded own drivers) 4) limit for storing both uboot and kernel into MTD is limited by 2MB (size of kernel nand partition) Basically you can use uboot if you accept all above issues. But there are people (Pavel CCed) who prefer to work without uboot when testing kernel. So it is not good idea to lock new kernel versions to depends on new uboot version. OK thanks for the update, I was not aware of the issues above. Are there other ATAGs needed beyond the ATAG_REVISION? Sorry for longer email. I will provide some more info about it. First I will describe that informations are passed from NOLO to kernel. Note that all those informations are passed also from uboot to kernel (uboot just reuse non static data from NOLO). Then I will describe that we need in userspace. Here are all ATAGs from NOLO: ... These we should not need, it's all coming from the .dts files. 0036 - 0003:54410007 ATAG REVISION revision=2204 0588 - 000c:4f80 BOOTREASON: pwr_key 0604 - 0018:4f82 VERSION: product = RX-51 0632 - 0018:4f82 VERSION: hw-build = 2204 0660 - 0018:4f82 VERSION: nolo = 1.4.14 0688 - 0018:4f82 VERSION: boot-mode= normal Seems like these are the ones we should somehow get. The others should be coming in the .dts file already, or can be deciphered based on the above in the kernel. ATAG MEM is generated by NOLO and also uboot at runtime. But we have hardcoded memory values in n900 DT file. Maybe we should use those generated by uboot bootloader (or reuse uboot code for generating) instead using hardcoded one? Yes we should not need ATAG MEM. Ok. ATAG REVISION is that which is magically generated by NOLO and which we want to reuse. Better would be understand how and why it NOLO generate (maybe there is something secret register which can tell it?). But I was not able to find out it. I would assume that's also somewhere in the cal area. In CAL can be stored forced value which overwrite that one automagically detected. OMAP table is one big ATAG structure which contains lot of other values. Basically all values (except uart, bootreason and version) are static and on all n900 devices are same. Partitions are generated by NOLO from CAL (/dev/mtd1) data, but I think nobody ever changed them (but it is possible!). AFAIK it's safe to assume they are coming in the .dts file. Yes, using DTS values is OK. I did not heard about anybody who modifying partition table. Personally, sometimes I'm doing it -- but only in qemu and only to increase kernel partition with decreasing size of initfs partition (which is not used) to make sure that offset of root partition is same (so nothing breaks). Uart is enabled when serial console is enabled via NOLO. We can keep the UART enabled all the time no problem. It's timeouts just need to be configured for idle. Probably we can ignore it. Serial console is used now maybe only in qemu. No idea if UART is even used. Bootreason contains omap3 bootreason value from special register (plus magic from NOLO) which is cleared automatically by NOLO (so no way to read it from kernel). Version contains some key-value data. Product is always RX-51, hw-build is same as ATAG REVISION, nolo is nolo version and value for boot-mode is ether normal or update. OK What we need in userspace: In file /proc/cpuinfo: Hardware: Nokia RX-51 board Revision: hw_revision_number And in any file and any format (does not matter if text, binary, whatever...) we need value from bootreason, boot-mode (and maybe nolo version). OK Current maemo applications are using files /proc/bootreason (for bootreason) and /proc/component_version (for all version) which are specific for Nokia 2.6.28 kernel. All those applications (which reading ether bootreason or bootmode proc files) are either shell scripts or open source, so editing them is possible. I will start fixing them once there will be *stable* ABI for those data. With non DT (legacy) boot all above atags are present in binary file /proc/atags. But because DT boot does not provide /proc/atags file I need some interface how to read above needed strings. So I would like to know what is possible and how? How about patch things so we
Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
On Friday 28 November 2014 23:26:30 Aaro Koskinen wrote: Hi, On Fri, Nov 28, 2014 at 10:41:12PM +0100, Pali Rohár wrote: Does kernel provide some interface for telling userspace applications something like bootreason (e.g power key, software reset, rtc alarm, charger connected, ...)? In N950/N9, NOLO passes this information using kernel command line and applications are reading /proc/cmdline. If I remember correctly all those custom proc files were removed from Nokia kernel, and everything was passed via command line. A. Yes, you are right. But NOLO on N900 pass all those data via ATAGs only and does not pass it in /proc/cmdline :-( -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
On Friday 28 November 2014 23:41:35 Aaro Koskinen wrote: Hi, On Fri, Nov 28, 2014 at 10:41:12PM +0100, Pali Rohár wrote: uboot (in mode when is loaded from NOLO) has those issues: 1) uboot cannot read n900 onenand mtd (uboot onenand driver not working, do not know why) 2) missing support for battery charging (can totally discharge battery) NOLO enables watchdogs when booting. So if you get stuck in the U-boot for whatever reason the device will power off after ~30 secs or so. A. Not truth! Uboot RX51 code periodically kick watchdogs if are enabled. I implemented that before RX51 uboot was merged into mainline. -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] ARM: OMAP2+: Warn about deprecated legacy booting mode
Hi, On Fri, Nov 28, 2014 at 11:49:00PM +0100, Pali Rohár wrote: On Friday 28 November 2014 23:41:35 Aaro Koskinen wrote: On Fri, Nov 28, 2014 at 10:41:12PM +0100, Pali Rohár wrote: uboot (in mode when is loaded from NOLO) has those issues: 1) uboot cannot read n900 onenand mtd (uboot onenand driver not working, do not know why) 2) missing support for battery charging (can totally discharge battery) NOLO enables watchdogs when booting. So if you get stuck in the U-boot for whatever reason the device will power off after ~30 secs or so. Not truth! Uboot RX51 code periodically kick watchdogs if are enabled. I implemented that before RX51 uboot was merged into mainline. Maybe then it shouldn't do that. A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] i2c: omap: TEST: do IP reset during probe.
Hello, Tony! I just want to know, is multimaster i2c feature is interesting for TI SOC, so I could send another patches? Or it's better to leave the thing without changes, as current single master version well tested and work? Also I have a draft version of mixed multimaster/slave version. But it could introduce new bugs. Are we ready for that? Thats because IP behavior, sometimes, doesn't correspond to TRMs[4][5]. It's the one of strange IP I ever seen on TI SOC. And TRM not as detailed as DSP TRMs. Yes, I test the patch. But IP handling is really tricky. So, I doubt. Looks, like you haven't seen my response in another thread[1]. So, duplicate it here. 24.11.2014 22:47, Tony Lindgren t...@atomide.com *: If you post a patch, I can test boot with it. Looks like the failing ones have i2c rev3.3 on 34xx vs rev4.4 on 36xx. So I doubt we just want to change the test for for a higher rev number for OMAP_I2C_REV_ON_3430_3530. You 100% right here. My fault. Thank you for giving right directions. Thanks Kevin for running test, so I could debug the reason. Functional mode bits are unimplemented in the SYSTEST register on omap3530. 10:5 Reserved Write 0s for future compatibility. Read returns 0. That was the reason. SYSTEST always 0. It is possible (and I could do it) to implement the bus check using SYSTEST SDA/SCL loopback mode. One more problem, I found that BB-check from the patch[2] sometimes (very rarely) doesn't work as expected. Sometimes the master start transfer while bus is in use by another master. It happens if another master continuously read from eeprom array of 0xff. So, one of problems on the way of running IP in a multimaster mode, is BB-bit behavior. I reported the problem to ti forum[3] and expect some response. Regards, Alexander. [1] http://www.spinics.net/lists/linux-i2c/msg17797.html [2] http://www.spinics.net/lists/linux-i2c/msg17678.html [3] http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/537/t/383876.aspx [4] omap3530 - TRM - spruf98y [5] AM-DM37x Multimedia Device Silicon Revision 1.x - sprugn4r -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] i2c: omap: TEST: do IP reset during probe.
29 нояб. 2014 г., в 1:13, Tony Lindgren t...@atomide.com написал(а):
Looks like for some time 2430 i2c has not been behaving
reliably
commit dd74548ddece4b9d68e5528287a272fa552c81d0 (i2c: omap:
resize fifos before each message) dropped check for dev-buf_len.
As result, data processing loop cause dev-buf overruns for
devices with 16-bit data register (omap2420 only).
Found by code review.
I have the patch for that. omap2420 actually broken at all.
But I'm not ready to send it right now.
Part of the patch:
- while (num_bytes--) {
+ while (num_bytes) {
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
*dev-buf++ = w;
dev-buf_len--;
+ num_bytes--;
/*
* Data reg in 2430, omap3 and
* omap4 is 8 bit wide
*/
if (dev-flags OMAP_I2C_FLAG_16BIT_DATA_REG) {
- *dev-buf++ = w 8;
- dev-buf_len--;
+ if (num_bytes) {
+ *dev-buf++ = w 8;
+ dev-buf_len--;
+ num_bytes--;
+ }
}
}
- while (num_bytes--) {
+ while (num_bytes) {
if (dev-errata I2C_OMAP_ERRATA_I462) {
int ret;
@@ -931,14 +947,18 @@ static int omap_i2c_transmit_data(struct omap_i2c_dev
*dev, u8 num_bytes,
w = *dev-buf++;
dev-buf_len--;
+ num_bytes--;
/*
* Data reg in 2430, omap3 and
* omap4 is 8 bit wide
*/
if (dev-flags OMAP_I2C_FLAG_16BIT_DATA_REG) {
- w |= *dev-buf++ 8;
- dev-buf_len--;
+ if (num_bytes) {
+ w |= *dev-buf++ 8;
+ dev-buf_len--;
+ num_bytes--;
+ }
}
--
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
