Re: [PATCH] spi: ti-qspi: improve ->remove() callback
Hi, Grygorii Strashko writes: > On 11/02/2015 06:06 PM, Felipe Balbi wrote: >> >> hi, >> >> Grygorii Strashko writes: >>> On 11/02/2015 05:20 PM, Felipe Balbi wrote: Grygorii Strashko writes: > On 10/29/2015 03:57 PM, Felipe Balbi wrote: >> there's no need to call pm_runtime_get_sync() >> followed by pm_runtime_put(). We should, instead, >> just call pm_runtime_put_sync() and pm_runtime_disable(). > > Sry, but why do we need to call pm_runtime_put[_sync]() here? > > My be just pm_runtime_disable() will be ok? and disable with unbalanced pm_runtime_get() ? >>> >>> Which one is unbalanced pm_runtime_get()? >>> There are no pm_runtime_get() in probe, so there you are >>> going to introduce unbalanced pm_runtime_put_sync() actually :( >> >> look at ti_qspi_setup(). I _do_ see, however, that it calls >> pm_runtime_put_autosuspend() in the same function; what happens if >> driver is removed after ti_qspi_setup() runs but before >> put_autosuspend() has time to actually run ? >> > > Seems nothing :) If I understand code in __device_release_driver() > right: the .remove() callback will be called after > pm_runtime_put_sync() and device should be disabled at this moment. > > Also, note that ti_qspi_setup() will be called for each SPI device > attached to SPI master and further PM management of SPI master is > performed by SPI core from __spi_pump_messages(). all right, do you want to send a patch fixing it ? -- balbi signature.asc Description: PGP signature
Re: [PATCH] spi: ti-qspi: improve ->remove() callback
On 11/02/2015 06:06 PM, Felipe Balbi wrote: > > hi, > > Grygorii Strashko writes: >> On 11/02/2015 05:20 PM, Felipe Balbi wrote: >>> Grygorii Strashko writes: >>> On 10/29/2015 03:57 PM, Felipe Balbi wrote: > there's no need to call pm_runtime_get_sync() > followed by pm_runtime_put(). We should, instead, > just call pm_runtime_put_sync() and pm_runtime_disable(). Sry, but why do we need to call pm_runtime_put[_sync]() here? My be just pm_runtime_disable() will be ok? >>> >>> and disable with unbalanced pm_runtime_get() ? >>> >> >> Which one is unbalanced pm_runtime_get()? >> There are no pm_runtime_get() in probe, so there you are >> going to introduce unbalanced pm_runtime_put_sync() actually :( > > look at ti_qspi_setup(). I _do_ see, however, that it calls > pm_runtime_put_autosuspend() in the same function; what happens if > driver is removed after ti_qspi_setup() runs but before > put_autosuspend() has time to actually run ? > Seems nothing :) If I understand code in __device_release_driver() right: the .remove() callback will be called after pm_runtime_put_sync() and device should be disabled at this moment. Also, note that ti_qspi_setup() will be called for each SPI device attached to SPI master and further PM management of SPI master is performed by SPI core from __spi_pump_messages(). -- regards, -grygorii -- 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
OMAP baseline test results for v4.3-rc7
Here are some basic OMAP test results for Linux v4.3-rc7. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v4.3-rc7/20151025181941/ Test summary Build: uImage: Pass ( 3/ 3): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only Build: uImage+dtb: Pass (13/13): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es, omap2plus_defconfig/omap4-var-stk-om44, omap2plus_defconfig/omap3-evm-37xx, omap2plus_defconfig_n800_only_a/omap2420-n800, omap2plus_defconfig/omap2430-sdp, omap2plus_defconfig/am3517-evm, omap2plus_defconfig/omap3-beagle, omap2plus_defconfig/omap3-beagle-xm, omap2plus_defconfig/omap3-sbc-t3517, omap2plus_defconfig/omap5-uevm, omap2plus_defconfig/omap5-sbc-t54 Build: zImage: Pass (17/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only, rmk_omap3430_ldp_oldconfig, rmk_omap3430_ldp_allnoconfig, rmk_omap4430_sdp_oldconfig, rmk_omap4430_sdp_allnoconfig, multi_v7_defconfig Build warnings from toolchain: uImage: (none) Build warnings from toolchain: uImage+dtb: (none) Build warnings from toolchain: zImage: FAIL (10/17): omap2plus_defconfig, omap2plus_defconfig_am33xx_only, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, omap2plus_defconfig_omap5_only, omap2plus_defconfig_dra7xx_only, omap2plus_defconfig_am43xx_only Boot to userspace: FAIL ( 1/17): 2430sdp skip ( 3/17): 5912osk, 3517evm, 5430es2sbct54 Pass (13/17): am335xbonelt, am335xbone, 4430es2panda, 4460pandaes, 4460varsomom, 37xxevm, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm, cmt3517, 5430es2uevm, 2420n800 Kernel warnings during boot to userspace: FAIL ( 2/17): 4430es2panda, cmt3517 PM: chip retention via suspend: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip retention via dynamic idle: FAIL ( 6/11): am335xbonelt, 4430es2panda, 4460varsomom, 37xxevm, 2430sdp, 5430es2uevm Pass ( 5/11): 4460pandaes, 3530es3beagle, 3530es31beagle, 3730beaglexm, 3730es12beaglexm PM: chip off (except CORE, due to errata) via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off (except CORE, due to errata) via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm PM: chip off via dynamic idle: FAIL ( 1/ 4): 37xxevm Pass ( 3/ 4): 3530es3beagle, 3530es31beagle, 3730es12beaglexm Kernel warnings during PM test: FAIL ( 1/17): 4430es2panda Obsolete Kconfig symbols: FAIL ( 2/20): omap2plus_defconfig, multi_v7_defconfig vmlinux object size (delta in bytes from test_v4.3-rc6 (7379047d5585187d1288486d4627873170d0005a)): text data bsstotal kernel +606 +64 +32 +702 omap1_defconfig +606 +32 +32 +670 omap1_defconfig_1510innovator_only +606 +64 +32 +702 omap1_defconfig_5912osk_only +52800 +528 multi_v7_defconfig +868 +640 +932 omap2plus_defconfig +436 +32 +32 +500 omap2plus_defconfig_2430sdp_only +868 +640 +932 omap2plus_defconfig_am33xx_only +868 +640 +932 omap2plus_defconfig_am43xx_only +928 +64 +64+1056 omap2plus_defconfig_cpupm +868 +640 +932 omap2plus_defconfig_dra7xx_only +452 -32 +16 +436 omap2plus_defconfig_n800_multi_omap2xxx +608 +32 +16 +656 omap2plus_defconfig_n800_only_a +932 +960+1028 omap2plus_defconfig_no_pm +860 +72 +64 +996 omap2plus_defconfig_omap2_4_only +868
Re: [PATCH] spi: ti-qspi: improve ->remove() callback
hi, Grygorii Strashko writes: > On 11/02/2015 05:20 PM, Felipe Balbi wrote: >> Grygorii Strashko writes: >> >>> On 10/29/2015 03:57 PM, Felipe Balbi wrote: there's no need to call pm_runtime_get_sync() followed by pm_runtime_put(). We should, instead, just call pm_runtime_put_sync() and pm_runtime_disable(). >>> >>> Sry, but why do we need to call pm_runtime_put[_sync]() here? >>> >>> My be just pm_runtime_disable() will be ok? >> >> and disable with unbalanced pm_runtime_get() ? >> > > Which one is unbalanced pm_runtime_get()? > There are no pm_runtime_get() in probe, so there you are > going to introduce unbalanced pm_runtime_put_sync() actually :( look at ti_qspi_setup(). I _do_ see, however, that it calls pm_runtime_put_autosuspend() in the same function; what happens if driver is removed after ti_qspi_setup() runs but before put_autosuspend() has time to actually run ? -- balbi signature.asc Description: PGP signature
Re: [PATCH v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Vinod, On 11/02/2015 05:40 PM, Vinod Koul wrote: > On Mon, Nov 02, 2015 at 02:13:01PM +0200, Peter Ujfalusi wrote: >> Vinod, >> >> On 11/02/2015 12:04 PM, Vinod Koul wrote: >>> On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote: >>>> Hi, >>>> >>>> 1) This seems to have broken BBB in -next for me, bisected down to this >>>> patch. >>>> >>>> For bootlog: >>>> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html >>>> >>>> 2) Please avoid merging DT/platform code in your driver tree, Vinod, >>>> at least without an ack from the platform maintainer. It can be a a >>>> huge mess if they end up causing conflicts, so we always ask to merge >>>> the DT changes through the platform maintainer (Tony in this case) by >>>> default. >>> >>> I did warn when applying that I am doing so without ACK on ARM code, noone >>> said a thing! >>> >>> I knew Tony was following the work by Peter so assumed he must have been >>> okay >>> with it otherwise would have spoken for ~couple of weeks these were in >>> review >>> >>> Anyway now that we have a regression, I can revert this patch if that fixes, >>> please confirm, but might break edma... peter? >> >> Can you revert or drop the last two DTS patches? >> >> I think I will try a different route to get the split of the tpcc and tptc. >> Without the DT patches the driver will fall back to the legacy mode so things >> will work in a same way they did before. >> Or I can send a followup patch for edma.c, with that there is no need to add >> the HWMOD_INIT_NO_IDLE to hwmod and power management looks better. >> Basically I'm registering a 'dummy' driver for the edma3-tptc so omap hwmod >> code will not shut it down but we will keep the possibility to manage the >> power state still. > > Okay I have reverted the two and applied the edma patch sent, can you please > verify topic/edma_fix before I merge it and send my PULL request. The branch looks good. Thank you! It would have been great if the DTS changes for am335x/am437x would have been in 4.4, but I will send them for 4.5 after rc1 is out. > Would appreciate any tested-by > > Thanks > -- 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] spi: ti-qspi: improve ->remove() callback
On 11/02/2015 05:20 PM, Felipe Balbi wrote: > Grygorii Strashko writes: > >> On 10/29/2015 03:57 PM, Felipe Balbi wrote: >>> there's no need to call pm_runtime_get_sync() >>> followed by pm_runtime_put(). We should, instead, >>> just call pm_runtime_put_sync() and pm_runtime_disable(). >> >> Sry, but why do we need to call pm_runtime_put[_sync]() here? >> >> My be just pm_runtime_disable() will be ok? > > and disable with unbalanced pm_runtime_get() ? > Which one is unbalanced pm_runtime_get()? There are no pm_runtime_get() in probe, so there you are going to introduce unbalanced pm_runtime_put_sync() actually :( -- regards, -grygorii -- 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 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
On Mon, Nov 02, 2015 at 02:13:01PM +0200, Peter Ujfalusi wrote: > Vinod, > > On 11/02/2015 12:04 PM, Vinod Koul wrote: > > On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote: > >> Hi, > >> > >> 1) This seems to have broken BBB in -next for me, bisected down to this > >> patch. > >> > >> For bootlog: > >> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html > >> > >> 2) Please avoid merging DT/platform code in your driver tree, Vinod, > >> at least without an ack from the platform maintainer. It can be a a > >> huge mess if they end up causing conflicts, so we always ask to merge > >> the DT changes through the platform maintainer (Tony in this case) by > >> default. > > > > I did warn when applying that I am doing so without ACK on ARM code, noone > > said a thing! > > > > I knew Tony was following the work by Peter so assumed he must have been > > okay > > with it otherwise would have spoken for ~couple of weeks these were in > > review > > > > Anyway now that we have a regression, I can revert this patch if that fixes, > > please confirm, but might break edma... peter? > > Can you revert or drop the last two DTS patches? > > I think I will try a different route to get the split of the tpcc and tptc. > Without the DT patches the driver will fall back to the legacy mode so things > will work in a same way they did before. > Or I can send a followup patch for edma.c, with that there is no need to add > the HWMOD_INIT_NO_IDLE to hwmod and power management looks better. > Basically I'm registering a 'dummy' driver for the edma3-tptc so omap hwmod > code will not shut it down but we will keep the possibility to manage the > power state still. Okay I have reverted the two and applied the edma patch sent, can you please verify topic/edma_fix before I merge it and send my PULL request. Would appreciate any tested-by Thanks -- ~Vinod -- 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] spi: ti-qspi: improve ->remove() callback
Grygorii Strashko writes: > On 10/29/2015 03:57 PM, Felipe Balbi wrote: >> there's no need to call pm_runtime_get_sync() >> followed by pm_runtime_put(). We should, instead, >> just call pm_runtime_put_sync() and pm_runtime_disable(). > > Sry, but why do we need to call pm_runtime_put[_sync]() here? > > My be just pm_runtime_disable() will be ok? and disable with unbalanced pm_runtime_get() ? -- balbi signature.asc Description: PGP signature
Re: [PATCH] spi: ti-qspi: improve ->remove() callback
On 10/29/2015 03:57 PM, Felipe Balbi wrote:
there's no need to call pm_runtime_get_sync()
followed by pm_runtime_put(). We should, instead,
just call pm_runtime_put_sync() and pm_runtime_disable().
Sry, but why do we need to call pm_runtime_put[_sync]() here?
My be just pm_runtime_disable() will be ok?
Signed-off-by: Felipe Balbi
---
drivers/spi/spi-ti-qspi.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/spi/spi-ti-qspi.c b/drivers/spi/spi-ti-qspi.c
index 69c1a95b0615..64318fcfacf2 100644
--- a/drivers/spi/spi-ti-qspi.c
+++ b/drivers/spi/spi-ti-qspi.c
@@ -554,16 +554,7 @@ free_master:
static int ti_qspi_remove(struct platform_device *pdev)
{
- struct ti_qspi *qspi = platform_get_drvdata(pdev);
- int ret;
-
- ret = pm_runtime_get_sync(qspi->dev);
- if (ret < 0) {
- dev_err(qspi->dev, "pm_runtime_get_sync() failed\n");
- return ret;
- }
-
- pm_runtime_put(qspi->dev);
+ pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
return 0;
--
regards,
-grygorii
--
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] dmaengine: edma: Add dummy driver skeleton for edma3-tptc
The eDMA3 TPTC does not need any software configuration, but it is a
separate IP block in the SoC. In order the omap hwmod core to be able to
handle the TPTC resources correctly in regards of PM we need to have a
driver loaded for it.
This patch will add a dummy driver skeleton without probe or remove
callbacks provided.
Signed-off-by: Peter Ujfalusi
Reported-by: Olof Johansson
---
Hi,
while it would have been possible to add the edma3-tptc compatible to be handled
by the edma-tpcc driver (and when the device is tptc, do nothing) it would
make the driver code a bit harder to follow.
I think having separate structure for the tptc looks better and if we ever need
to have separate driver for the tptc it will be cleaner for us the separate it.
This patch alone w/o any hwmod flag changes will make sure that the edma-tptc is
not powered down after the kernel is finished it's booting.
Regards,
Peter
drivers/dma/edma.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 31722d436a42..6b03e4e84e6b 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -269,6 +269,11 @@ static const struct of_device_id edma_of_ids[] = {
{}
};
+static const struct of_device_id edma_tptc_of_ids[] = {
+ { .compatible = "ti,edma3-tptc", },
+ {}
+};
+
static inline unsigned int edma_read(struct edma_cc *ecc, int offset)
{
return (unsigned int)__raw_readl(ecc->base + offset);
@@ -2399,6 +2404,13 @@ static struct platform_driver edma_driver = {
},
};
+static struct platform_driver edma_tptc_driver = {
+ .driver = {
+ .name = "edma3-tptc",
+ .of_match_table = edma_tptc_of_ids,
+ },
+};
+
bool edma_filter_fn(struct dma_chan *chan, void *param)
{
bool match = false;
@@ -2418,6 +2430,12 @@ EXPORT_SYMBOL(edma_filter_fn);
static int edma_init(void)
{
+ int ret;
+
+ ret = platform_driver_register(&edma_tptc_driver);
+ if (ret)
+ return ret;
+
return platform_driver_register(&edma_driver);
}
subsys_initcall(edma_init);
@@ -2425,6 +2443,7 @@ subsys_initcall(edma_init);
static void __exit edma_exit(void)
{
platform_driver_unregister(&edma_driver);
+ platform_driver_unregister(&edma_tptc_driver);
}
module_exit(edma_exit);
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: hwmod: AM33xx/43xx: Add HWMOD_INIT_NO_IDLE flag to tptc
On 11/02/2015 12:23 PM, Peter Ujfalusi wrote: > On 11/02/2015 12:24 PM, Vinod Koul wrote: >> On Mon, Nov 02, 2015 at 12:11:00PM +0200, Peter Ujfalusi wrote: >>> In Linux we do not have driver for TPTCs of eDMA3 since there is no need to >>> do any configuration within TPTC for the eDMA3 to be operational. All >>> configuration is via the TPCC. >>> To prevent the omap_device_late_idle() to disable the TPTCs when they are >>> no longer bind with the edma driver, the HWMOD_INIT_NO_IDLE need to be >>> added. >>> >>> Signed-off-by: Peter Ujfalusi >>> --- >>> Vinod, Olof, >>> >>> This patch somehow got lost in my working branch. It was mixed within the >>> patches >>> I will have for 4.5 while it should have been within the new eDMA3 binding >>> series.. >> >> Does this fix the issue reported by Olof? Also ACK pls for this > > Yes, it is fixing the issue, I have this in my branch. everything looks fine > on AM335x/AM437x/Dra7xx where I have eDMA in use. Vinod, can you please ignore this patch? I'm going to send a patch agains edma.c which will handle this better. -- 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 v2 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Vinod, On 11/02/2015 12:04 PM, Vinod Koul wrote: > On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote: >> Hi, >> >> 1) This seems to have broken BBB in -next for me, bisected down to this >> patch. >> >> For bootlog: >> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html >> >> 2) Please avoid merging DT/platform code in your driver tree, Vinod, >> at least without an ack from the platform maintainer. It can be a a >> huge mess if they end up causing conflicts, so we always ask to merge >> the DT changes through the platform maintainer (Tony in this case) by >> default. > > I did warn when applying that I am doing so without ACK on ARM code, noone > said a thing! > > I knew Tony was following the work by Peter so assumed he must have been okay > with it otherwise would have spoken for ~couple of weeks these were in > review > > Anyway now that we have a regression, I can revert this patch if that fixes, > please confirm, but might break edma... peter? Can you revert or drop the last two DTS patches? I think I will try a different route to get the split of the tpcc and tptc. Without the DT patches the driver will fall back to the legacy mode so things will work in a same way they did before. Or I can send a followup patch for edma.c, with that there is no need to add the HWMOD_INIT_NO_IDLE to hwmod and power management looks better. Basically I'm registering a 'dummy' driver for the edma3-tptc so omap hwmod code will not shut it down but we will keep the possibility to manage the power state still. -- 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
[PATCH 1/3] arm: plat-omap: dmtimer: Add clock source from DT
Add a function which sets the timer source from the clocks
binding on dm_timer_prepare call.
In case the clocks property is not valid, it falls back to
the set_source() with 32_KHZ clock as default.
Suggested-by: Tony Lindgren
Signed-off-by: Neil Armstrong
---
arch/arm/plat-omap/dmtimer.c | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 8ca94d3..7c7f260 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -137,6 +137,31 @@ static int omap_dm_timer_reset(struct omap_dm_timer *timer)
return 0;
}
+static int omap_dm_timer_of_set_source(struct omap_dm_timer *timer)
+{
+ int ret;
+ struct clk *parent;
+
+ /*
+* FIXME: OMAP1 devices do not use the clock framework for dmtimers so
+* do not call clk_get() for these devices.
+*/
+ if (!timer->fclk)
+ return -ENODEV;
+
+ parent = clk_get(&timer->pdev->dev, NULL);
+ if (IS_ERR(parent))
+ return -ENODEV;
+
+ ret = clk_set_parent(timer->fclk, parent);
+ if (ret < 0)
+ pr_err("%s: failed to set parent\n", __func__);
+
+ clk_put(parent);
+
+ return ret;
+}
+
static int omap_dm_timer_prepare(struct omap_dm_timer *timer)
{
int rc;
@@ -166,7 +191,11 @@ static int omap_dm_timer_prepare(struct omap_dm_timer
*timer)
__omap_dm_timer_enable_posted(timer);
omap_dm_timer_disable(timer);
- return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
+ rc = omap_dm_timer_of_set_source(timer);
+ if (rc == -ENODEV)
+ return omap_dm_timer_set_source(timer, OMAP_TIMER_SRC_32_KHZ);
+
+ return rc;
}
static inline u32 omap_dm_timer_reserved_systimer(int id)
--
1.9.1
--
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 0/3] pwm: omap: Add PWM support using dual-mode timers
This patch is based on an earlier patch by NeilBrown which is based on a older patch from Grant Erickson which provided PWM devices using the 'legacy' interface. The pwm driver was renamed to not be confused with the OMAP4 PWM dedicated hardware and was cleaned with the review from Thierry Reding. The first patch introduces a way to select to dmtimer clock source via a clocks binding and a dedicated function wit the legacy fallback. In order to prepare for the future form of the dmtimer (clksource or whatever), and less rely on specific bindings the first patch introduces the PWM driver with all the dmtimer calls into a platform data structure. The structure is then filled in plat-omap and added as auxdata for the ti,pwm-dmtimer-omap compatible nodes. Suggested-by: Tony Lindgren RFC Thread : http://lkml.kernel.org/r/562505db.3010...@baylibre.com Neil Armstrong (3): arm: plat-omap: dmtimer: Add clock source from DT pwm: Add PWM driver for OMAP using dual-mode timers arm: plat-omap: Add PWM dmtimer platform data quirks .../devicetree/bindings/pwm/pwm-omap-dmtimer.txt | 18 ++ arch/arm/mach-omap2/pdata-quirks.c | 23 ++ arch/arm/plat-omap/dmtimer.c | 31 +- drivers/pwm/Kconfig| 9 + drivers/pwm/Makefile | 1 + drivers/pwm/pwm-omap-dmtimer.c | 322 + include/linux/platform_data/pwm_omap_dmtimer.h | 69 + 7 files changed, 472 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt create mode 100644 drivers/pwm/pwm-omap-dmtimer.c create mode 100644 include/linux/platform_data/pwm_omap_dmtimer.h -- 1.9.1 -- 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 3/3] arm: plat-omap: Add PWM dmtimer platform data quirks
In order to set the currently platform dependent dmtimer
functions pointers as platform data for the pwm-omap-dmtimer
platform driver, add it to plat-omap auxdata_lookup table.
Suggested-by: Tony Lindgren
Signed-off-by: Neil Armstrong
---
arch/arm/mach-omap2/pdata-quirks.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c
b/arch/arm/mach-omap2/pdata-quirks.c
index ea56397..647dec5 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -23,6 +23,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -453,6 +455,24 @@ void omap_auxdata_legacy_init(struct device *dev)
dev->platform_data = &twl_gpio_auxdata;
}
+/* Dual mode timer PWM callbacks platdata */
+#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
+struct pwm_omap_dmtimer_pdata pwm_dmtimer_pdata = {
+ .request_by_node = omap_dm_timer_request_by_node,
+ .free = omap_dm_timer_free,
+ .enable = omap_dm_timer_enable,
+ .disable = omap_dm_timer_disable,
+ .get_fclk = omap_dm_timer_get_fclk,
+ .start = omap_dm_timer_start,
+ .stop = omap_dm_timer_stop,
+ .set_load = omap_dm_timer_set_load,
+ .set_match = omap_dm_timer_set_match,
+ .set_pwm = omap_dm_timer_set_pwm,
+ .set_prescaler = omap_dm_timer_set_prescaler,
+ .write_counter = omap_dm_timer_write_counter,
+};
+#endif
+
/*
* Few boards still need auxdata populated before we populate
* the dev entries in of_platform_populate().
@@ -506,6 +526,9 @@ static struct of_dev_auxdata omap_auxdata_lookup[]
__initdata = {
OF_DEV_AUXDATA("ti,am4372-wkup-m3", 0x44d0, "44d0.wkup_m3",
&wkup_m3_data),
#endif
+#if IS_ENABLED(CONFIG_OMAP_DM_TIMER)
+ OF_DEV_AUXDATA("ti,omap-dmtimer-pwm", 0, NULL, &pwm_dmtimer_pdata),
+#endif
#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
OF_DEV_AUXDATA("ti,omap4-iommu", 0x4a066000, "4a066000.mmu",
&omap4_iommu_pdata),
--
1.9.1
--
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/3] pwm: Add PWM driver for OMAP using dual-mode timers
Adds support for using a OMAP dual-mode timer with PWM capability
as a Linux PWM device. The driver controls the timer by using the
dmtimer API.
Add a platform_data structure for each pwm-omap-dmtimer nodes containing
the dmtimers functions in order to get driver not rely on platform
specific functions.
Cc: Grant Erickson
Cc: NeilBrown
Cc: Joachim Eastwood
Suggested-by: Tony Lindgren
Signed-off-by: Neil Armstrong
---
.../devicetree/bindings/pwm/pwm-omap-dmtimer.txt | 18 ++
drivers/pwm/Kconfig| 9 +
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-omap-dmtimer.c | 322 +
include/linux/platform_data/pwm_omap_dmtimer.h | 69 +
5 files changed, 419 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
create mode 100644 drivers/pwm/pwm-omap-dmtimer.c
create mode 100644 include/linux/platform_data/pwm_omap_dmtimer.h
diff --git a/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
b/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
new file mode 100644
index 000..5befb53
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt
@@ -0,0 +1,18 @@
+* OMAP PWM for dual-mode timers
+
+Required properties:
+- compatible: Shall contain "ti,omap-dmtimer-pwm".
+- ti,timers: phandle to PWM capable OMAP timer. See arm/omap/timer.txt for info
+ about these timers.
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of
+ the cells format.
+
+Optional properties:
+- ti,prescaler: Should be a value between 0 and 7, see the timers datasheet
+
+Example:
+ pwm9: dmtimer-pwm@9 {
+ compatible = "ti,omap-dmtimer-pwm";
+ ti,timers = <&timer9>;
+ #pwm-cells = <3>;
+ };
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 062630a..2da60f8 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -240,6 +240,15 @@ config PWM_MXS
To compile this driver as a module, choose M here: the module
will be called pwm-mxs.
+config PWM_OMAP_DMTIMER
+ tristate "OMAP Dual-Mode Timer PWM support"
+ depends on OF && ARCH_OMAP && OMAP_DM_TIMER
+ help
+ Generic PWM framework driver for OMAP Dual-Mode Timer PWM output
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-omap-dmtimer
+
config PWM_PCA9685
tristate "NXP PCA9685 PWM driver"
depends on OF && I2C
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index a0e00c0..af14774 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_PWM_LPSS)+= pwm-lpss.o
obj-$(CONFIG_PWM_LPSS_PCI) += pwm-lpss-pci.o
obj-$(CONFIG_PWM_LPSS_PLATFORM)+= pwm-lpss-platform.o
obj-$(CONFIG_PWM_MXS) += pwm-mxs.o
+obj-$(CONFIG_PWM_OMAP_DMTIMER) += pwm-omap-dmtimer.o
obj-$(CONFIG_PWM_PCA9685) += pwm-pca9685.o
obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
diff --git a/drivers/pwm/pwm-omap-dmtimer.c b/drivers/pwm/pwm-omap-dmtimer.c
new file mode 100644
index 000..c1a4967
--- /dev/null
+++ b/drivers/pwm/pwm-omap-dmtimer.c
@@ -0,0 +1,322 @@
+/*
+ *Copyright (c) 2015 Neil Armstrong
+ *Copyright (c) 2014 Joachim Eastwood
+ *Copyright (c) 2012 NeilBrown
+ *Heavily based on earlier code which is:
+ *Copyright (c) 2010 Grant Erickson
+ *
+ *Also based on pwm-samsung.c
+ *
+ *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.
+ *
+ *Description:
+ * This file is the core OMAP support for the generic, Linux
+ * PWM driver / controller, using the OMAP's dual-mode timers.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DM_TIMER_LOAD_MIN 0xFFFE
+
+struct pwm_omap_dmtimer_chip {
+ struct pwm_chip chip;
+ struct mutexmutex;
+ pwm_omap_dmtimer*dm_timer;
+ struct pwm_omap_dmtimer_pdata *pdata;
+ struct platform_device *dm_timer_pdev;
+};
+
+#define to_pwm_omap_dmtimer_chip(chip) container_of(chip,\
+ struct pwm_omap_dmtimer_chip, chip)
+
+static int pwm_omap_dmtimer_calc_value(unsigned long clk_rate, int ns)
+{
+ u64 c;
+
+ c = (u64)clk_rate * ns;
+ do_div(c, NSEC_PER_SEC);
+
+ return DM_TIMER_LOAD_MIN - c;
+}
+
+static void pwm_omap_dmtimer_start(struct pwm_omap_dmtimer_chip *omap)
+{
+ /*
+* According to OMAP 4 TRM section 22.2.4.10 the counter should be
+* started at 0xFFFE when overflow and match is used to ensure
+* tha
Re: [PATCH] ARM: OMAP: hwmod: AM33xx/43xx: Add HWMOD_INIT_NO_IDLE flag to tptc
On 11/02/2015 12:24 PM, Vinod Koul wrote: > On Mon, Nov 02, 2015 at 12:11:00PM +0200, Peter Ujfalusi wrote: >> In Linux we do not have driver for TPTCs of eDMA3 since there is no need to >> do any configuration within TPTC for the eDMA3 to be operational. All >> configuration is via the TPCC. >> To prevent the omap_device_late_idle() to disable the TPTCs when they are >> no longer bind with the edma driver, the HWMOD_INIT_NO_IDLE need to be >> added. >> >> Signed-off-by: Peter Ujfalusi >> --- >> Vinod, Olof, >> >> This patch somehow got lost in my working branch. It was mixed within the >> patches >> I will have for 4.5 while it should have been within the new eDMA3 binding >> series.. > > Does this fix the issue reported by Olof? Also ACK pls for this Yes, it is fixing the issue, I have this in my branch. everything looks fine on AM335x/AM437x/Dra7xx where I have eDMA in use. -- 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] ARM: OMAP: hwmod: AM33xx/43xx: Add HWMOD_INIT_NO_IDLE flag to tptc
On Mon, Nov 02, 2015 at 12:11:00PM +0200, Peter Ujfalusi wrote:
> In Linux we do not have driver for TPTCs of eDMA3 since there is no need to
> do any configuration within TPTC for the eDMA3 to be operational. All
> configuration is via the TPCC.
> To prevent the omap_device_late_idle() to disable the TPTCs when they are
> no longer bind with the edma driver, the HWMOD_INIT_NO_IDLE need to be
> added.
>
> Signed-off-by: Peter Ujfalusi
> ---
> Vinod, Olof,
>
> This patch somehow got lost in my working branch. It was mixed within the
> patches
> I will have for 4.5 while it should have been within the new eDMA3 binding
> series..
Does this fix the issue reported by Olof? Also ACK pls for this
--
~Vinod
>
> Regards,
> Peter
>
> arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
> b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
> index 907a452b78ea..3c7106a09801 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
> @@ -1169,7 +1169,8 @@ struct omap_hwmod am33xx_tptc0_hwmod = {
> .name = "tptc0",
> .class = &am33xx_tptc_hwmod_class,
> .clkdm_name = "l3_clkdm",
> - .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
> + .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> +HWMOD_INIT_NO_IDLE),
> .main_clk = "l3_gclk",
> .prcm = {
> .omap4 = {
> @@ -1183,7 +1184,8 @@ struct omap_hwmod am33xx_tptc1_hwmod = {
> .name = "tptc1",
> .class = &am33xx_tptc_hwmod_class,
> .clkdm_name = "l3_clkdm",
> - .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
> + .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> +HWMOD_INIT_NO_IDLE),
> .main_clk = "l3_gclk",
> .prcm = {
> .omap4 = {
> @@ -1197,7 +1199,8 @@ struct omap_hwmod am33xx_tptc2_hwmod = {
> .name = "tptc2",
> .class = &am33xx_tptc_hwmod_class,
> .clkdm_name = "l3_clkdm",
> - .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
> + .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
> +HWMOD_INIT_NO_IDLE),
> .main_clk = "l3_gclk",
> .prcm = {
> .omap4 = {
> --
> 2.6.1
>
--
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 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Hi Olof,
On 11/02/2015 11:21 AM, Olof Johansson wrote:
> Hi,
>
> 1) This seems to have broken BBB in -next for me, bisected down to this patch.
>
> For bootlog:
> http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html
Aargh, I had the patch which should have been included to the series (just
sent it):
https://www.mail-archive.com/linux-omap@vger.kernel.org/msg121134.html
It was mixed with the patches I collected for 4.5, I don't know how this
happened, but this is the reason I have not seen the issue you are seeing.
>
> 2) Please avoid merging DT/platform code in your driver tree, Vinod,
> at least without an ack from the platform maintainer. It can be a a
> huge mess if they end up causing conflicts, so we always ask to merge
> the DT changes through the platform maintainer (Tony in this case) by
> default.
>
>
> Thanks,
>
> -Olof
>
> On Fri, Oct 16, 2015 at 12:18 AM, Peter Ujfalusi
> wrote:
>> Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
>> enable the DMA even crossbar with ti,am335x-edma-crossbar.
>> With the new bindings boards can customize and tweak the DMA channel
>> priority to match their needs. With the new binding the memcpy is safe
>> to be used since with the old binding it was not possible for a driver
>> to know which channel is allowed to be used as non HW triggered channel.
>>
>> Signed-off-by: Peter Ujfalusi
>> ---
>> arch/arm/boot/dts/am335x-evm.dts| 9 +---
>> arch/arm/boot/dts/am335x-pepper.dts | 11 +
>> arch/arm/boot/dts/am33xx.dtsi | 96
>> ++---
>> 3 files changed, 73 insertions(+), 43 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/am335x-evm.dts
>> b/arch/arm/boot/dts/am335x-evm.dts
>> index 1942a5c8132d..507980672c32 100644
>> --- a/arch/arm/boot/dts/am335x-evm.dts
>> +++ b/arch/arm/boot/dts/am335x-evm.dts
>> @@ -743,8 +743,8 @@
>> &mmc3 {
>> /* these are on the crossbar and are outlined in the
>>xbar-event-map element */
>> - dmas = <&edma 12
>> - &edma 13>;
>> + dmas = <&edma_xbar 12 0 1
>> + &edma_xbar 13 0 2>;
>> dma-names = "tx", "rx";
>> status = "okay";
>> vmmc-supply = <&wlan_en_reg>;
>> @@ -766,11 +766,6 @@
>> };
>> };
>>
>> -&edma {
>> - ti,edma-xbar-event-map = /bits/ 16 <1 12
>> - 2 13>;
>> -};
>> -
>> &sham {
>> status = "okay";
>> };
>> diff --git a/arch/arm/boot/dts/am335x-pepper.dts
>> b/arch/arm/boot/dts/am335x-pepper.dts
>> index 7106114c7464..39073b921664 100644
>> --- a/arch/arm/boot/dts/am335x-pepper.dts
>> +++ b/arch/arm/boot/dts/am335x-pepper.dts
>> @@ -339,13 +339,6 @@
>> ti,non-removable;
>> };
>>
>> -&edma {
>> - /* Map eDMA MMC2 Events from Crossbar */
>> - ti,edma-xbar-event-map = /bits/ 16 <1 12
>> -2 13>;
>> -};
>> -
>> -
>> &mmc3 {
>> /* Wifi & Bluetooth on MMC #3 */
>> status = "okay";
>> @@ -354,8 +347,8 @@
>> vmmmc-supply = <&v3v3c_reg>;
>> bus-width = <4>;
>> ti,non-removable;
>> - dmas = <&edma 12
>> - &edma 13>;
>> + dmas = <&edma_xbar 12 0 1
>> + &edma_xbar 13 0 2>;
>> dma-names = "tx", "rx";
>> };
>>
>> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
>> index d23e2524d694..6053e75c6e99 100644
>> --- a/arch/arm/boot/dts/am33xx.dtsi
>> +++ b/arch/arm/boot/dts/am33xx.dtsi
>> @@ -174,12 +174,54 @@
>> };
>>
>> edma: edma@4900 {
>> - compatible = "ti,edma3";
>> - ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
>> - reg = <0x4900 0x1>,
>> - <0x44e10f90 0x40>;
>> + compatible = "ti,edma3-tpcc";
>> + ti,hwmods = "tpcc";
>> + reg = <0x4900 0x1>;
>> + reg-names = "edma3_cc&quo
[PATCH] ARM: OMAP: hwmod: AM33xx/43xx: Add HWMOD_INIT_NO_IDLE flag to tptc
In Linux we do not have driver for TPTCs of eDMA3 since there is no need to
do any configuration within TPTC for the eDMA3 to be operational. All
configuration is via the TPCC.
To prevent the omap_device_late_idle() to disable the TPTCs when they are
no longer bind with the edma driver, the HWMOD_INIT_NO_IDLE need to be
added.
Signed-off-by: Peter Ujfalusi
---
Vinod, Olof,
This patch somehow got lost in my working branch. It was mixed within the
patches
I will have for 4.5 while it should have been within the new eDMA3 binding
series..
Regards,
Peter
arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
index 907a452b78ea..3c7106a09801 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_43xx_ipblock_data.c
@@ -1169,7 +1169,8 @@ struct omap_hwmod am33xx_tptc0_hwmod = {
.name = "tptc0",
.class = &am33xx_tptc_hwmod_class,
.clkdm_name = "l3_clkdm",
- .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+ HWMOD_INIT_NO_IDLE),
.main_clk = "l3_gclk",
.prcm = {
.omap4 = {
@@ -1183,7 +1184,8 @@ struct omap_hwmod am33xx_tptc1_hwmod = {
.name = "tptc1",
.class = &am33xx_tptc_hwmod_class,
.clkdm_name = "l3_clkdm",
- .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+ HWMOD_INIT_NO_IDLE),
.main_clk = "l3_gclk",
.prcm = {
.omap4 = {
@@ -1197,7 +1199,8 @@ struct omap_hwmod am33xx_tptc2_hwmod = {
.name = "tptc2",
.class = &am33xx_tptc_hwmod_class,
.clkdm_name = "l3_clkdm",
- .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY),
+ .flags = (HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY |
+ HWMOD_INIT_NO_IDLE),
.main_clk = "l3_gclk",
.prcm = {
.omap4 = {
--
2.6.1
--
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 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
On Mon, Nov 02, 2015 at 01:21:19AM -0800, Olof Johansson wrote: > Hi, > > 1) This seems to have broken BBB in -next for me, bisected down to this patch. > > For bootlog: > http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html > > 2) Please avoid merging DT/platform code in your driver tree, Vinod, > at least without an ack from the platform maintainer. It can be a a > huge mess if they end up causing conflicts, so we always ask to merge > the DT changes through the platform maintainer (Tony in this case) by > default. I did warn when applying that I am doing so without ACK on ARM code, noone said a thing! I knew Tony was following the work by Peter so assumed he must have been okay with it otherwise would have spoken for ~couple of weeks these were in review Anyway now that we have a regression, I can revert this patch if that fixes, please confirm, but might break edma... peter? -- ~Vinod -- 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 13/14] ARM: DTS: am33xx: Use the new DT bindings for the eDMA3
Hi,
1) This seems to have broken BBB in -next for me, bisected down to this patch.
For bootlog:
http://arm-soc.lixom.net/bootlogs/next/next-20151102/bbb-arm-omap2plus_defconfig.html
2) Please avoid merging DT/platform code in your driver tree, Vinod,
at least without an ack from the platform maintainer. It can be a a
huge mess if they end up causing conflicts, so we always ask to merge
the DT changes through the platform maintainer (Tony in this case) by
default.
Thanks,
-Olof
On Fri, Oct 16, 2015 at 12:18 AM, Peter Ujfalusi wrote:
> Switch to use the ti,edma3-tpcc and ti,edma3-tptc binding for the eDMA3 and
> enable the DMA even crossbar with ti,am335x-edma-crossbar.
> With the new bindings boards can customize and tweak the DMA channel
> priority to match their needs. With the new binding the memcpy is safe
> to be used since with the old binding it was not possible for a driver
> to know which channel is allowed to be used as non HW triggered channel.
>
> Signed-off-by: Peter Ujfalusi
> ---
> arch/arm/boot/dts/am335x-evm.dts| 9 +---
> arch/arm/boot/dts/am335x-pepper.dts | 11 +
> arch/arm/boot/dts/am33xx.dtsi | 96
> ++---
> 3 files changed, 73 insertions(+), 43 deletions(-)
>
> diff --git a/arch/arm/boot/dts/am335x-evm.dts
> b/arch/arm/boot/dts/am335x-evm.dts
> index 1942a5c8132d..507980672c32 100644
> --- a/arch/arm/boot/dts/am335x-evm.dts
> +++ b/arch/arm/boot/dts/am335x-evm.dts
> @@ -743,8 +743,8 @@
> &mmc3 {
> /* these are on the crossbar and are outlined in the
>xbar-event-map element */
> - dmas = <&edma 12
> - &edma 13>;
> + dmas = <&edma_xbar 12 0 1
> + &edma_xbar 13 0 2>;
> dma-names = "tx", "rx";
> status = "okay";
> vmmc-supply = <&wlan_en_reg>;
> @@ -766,11 +766,6 @@
> };
> };
>
> -&edma {
> - ti,edma-xbar-event-map = /bits/ 16 <1 12
> - 2 13>;
> -};
> -
> &sham {
> status = "okay";
> };
> diff --git a/arch/arm/boot/dts/am335x-pepper.dts
> b/arch/arm/boot/dts/am335x-pepper.dts
> index 7106114c7464..39073b921664 100644
> --- a/arch/arm/boot/dts/am335x-pepper.dts
> +++ b/arch/arm/boot/dts/am335x-pepper.dts
> @@ -339,13 +339,6 @@
> ti,non-removable;
> };
>
> -&edma {
> - /* Map eDMA MMC2 Events from Crossbar */
> - ti,edma-xbar-event-map = /bits/ 16 <1 12
> -2 13>;
> -};
> -
> -
> &mmc3 {
> /* Wifi & Bluetooth on MMC #3 */
> status = "okay";
> @@ -354,8 +347,8 @@
> vmmmc-supply = <&v3v3c_reg>;
> bus-width = <4>;
> ti,non-removable;
> - dmas = <&edma 12
> - &edma 13>;
> + dmas = <&edma_xbar 12 0 1
> + &edma_xbar 13 0 2>;
> dma-names = "tx", "rx";
> };
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index d23e2524d694..6053e75c6e99 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -174,12 +174,54 @@
> };
>
> edma: edma@4900 {
> - compatible = "ti,edma3";
> - ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> - reg = <0x4900 0x1>,
> - <0x44e10f90 0x40>;
> + compatible = "ti,edma3-tpcc";
> + ti,hwmods = "tpcc";
> + reg = <0x4900 0x1>;
> + reg-names = "edma3_cc";
> interrupts = <12 13 14>;
> - #dma-cells = <1>;
> + interrupt-names = "edma3_ccint", "emda3_mperr",
> + "edma3_ccerrint";
> + dma-requests = <64>;
> + #dma-cells = <2>;
> +
> + ti,tptcs = <&edma_tptc0 7>, <&edma_tptc1 5>,
> + <&edma_tptc2 0>;
> +
> + ti,edma-memcpy-channels = /bits/ 16 <20 21>;
> + };
> +
> + edma_tptc0: tptc@4980 {
> + compatible = "ti,edma3-tptc";
> +
