Re: [PATCH] ARM: exynos_defconfig: Enable CONFIG_FHANDLE
Hi Kukjin, On 11/28/2014 09:35 PM, Javier Martinez Canillas wrote: Hello Sjoerd, On 11/28/2014 01:06 PM, Sjoerd Simons wrote: CONFIG_FHANDLE is required by systemd, which is the default init system in more and more distributions. So lets enable it for Exynos as well (it's already enabled in multi_v7_defconfig) Signed-off-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk --- arch/arm/configs/exynos_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig index e419fac..d4751ef 100644 --- a/arch/arm/configs/exynos_defconfig +++ b/arch/arm/configs/exynos_defconfig @@ -1,4 +1,5 @@ CONFIG_SYSVIPC=y +CONFIG_FHANDLE=y I also hope merge this, already multi_v7_defconfig supports this. Thanks. This is certainly required for newer systemd and has to be enabled. But it would also be great to have enabled all the config symbols that are listed as requirements in the systemd README file: http://cgit.freedesktop.org/systemd/systemd/tree/README. Tony added that support to OMAP2+ defconfig in commit 673ce00c (ARM: omap2plus_defconfig: Add support for distros with systemd) so the same should be done in exynos_defconfig. That can of course be a follow-up patch though, so for $subject: Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/9] devfreq: Add generic exynos memory-bus frequency driver
Dear Myungjoo and Kukjin,
Could you please review this patchset?
Best Regards,
Chanwoo Choi
On 01/15/2015 10:50 AM, Chanwoo Choi wrote:
This patch-set adds the generic exynos bus frequency driver for memory bus
with DEVFREQ framework. The Samsung Exynos SoCs have the common architecture
for memory bus between DRAM memory and MMC/sub IP in SoC. This driver can
support the memory bus frequency driver for Exynos SoCs.
Each memory bus block has a clock for memory bus speed and frequency
table which is changed according to the utilization of memory bus on runtime.
And then each memory bus group has the one more memory bus blocks and
OPP table (including frequency and voltage), regulator, devfreq-event
devices.
There are a little difference about the number of memory bus because each
Exynos
SoC have the different sub-IP and different memory bus speed. In spite of this
difference among Exynos SoCs, we can support almost Exynos SoC by adding
unique data of memory bus to devicetree file.
Depend on:
- [PATCHv8 0/9] devfreq: Add devfreq-event class to provide raw data for
devfreq device
: https://lkml.org/lkml/2015/1/7/795
Changelog:
Changes from v3:
(https://lkml.org/lkml/2015/1/7/872)
- Change the driver name and path by comment
: drivers/devfreq/exynos-busfreq.c - drivers/devfreq/exynos/exynos-bus.c
- Disable regulator when entering suspend state in exynos-bus.c
and enable it after wake-up from suspend state.
- Add 'exynos,saturation-ratio' property to calibrate the performance count
against cycle count.
- Add new patch to remove unused old driver
: drivers/devfreq/exynos/exynos4_bus.{c|h}
- Clean-up code for minor issue
- Add acked tag by Myungjoo Ham (DEVFREQ maintainer)
Changes from v2:
(https://lkml.org/lkml/2014/12/31/2)
- Support the memory bus frequency feature for Exynos3250-based Monk board
- Fix build warning about variable uninitialized
Changes from v1:
(https://lkml.org/lkml/2014/12/23/178)
- This patchset is rebased on v3.19-rc2.
- Fix bug after wake-up from suspend state. If devfreq device fail to get
event,
exynos-busfreq retry to set the event for starting.
- Add memory bus group of Exynos4x12/Exynos4210
- Add divider clock id for Exynos4 memory bus frequency
- Support memory bus frequency driver on Exynos4412-based TRATS2 board
- This patch-set has the dependency on following patch-set[1]:
[1] [PATCHv6 0/9] devfreq: Add devfreq-event class to provide raw data for
devfreq device
: https://lkml.org/lkml/2014/12/28/139
Chanwoo Choi (9):
devfreq: exynos: Add generic exynos memory bus frequency driver
devfreq: exynos: Add documentation for generic exynos memory bus frequency
driver
ARM: dts: Add memory bus node for Exynos3250
clk: samsung: exynos4: Add divider clock id for memory bus frequency
ARM: dts: Add memory bus node for Exynos4x12
ARM: dts: Add memory bus node for Exynos4210
ARM: dts: Add the support for exynos busfreq on Exynos3250-based
Rinato/Monk board
ARM: dts: Add the support for exynos busfreq on Exynos4412-based TRATS2
board
devfreq: exynos: Remove unused exynos4 memory busfreq driver
.../devicetree/bindings/devfreq/exynos-bus.txt | 188
arch/arm/boot/dts/exynos3250-monk.dts | 12 +
arch/arm/boot/dts/exynos3250-rinato.dts| 12 +
arch/arm/boot/dts/exynos3250.dtsi | 125 +++
arch/arm/boot/dts/exynos4210.dtsi | 93 ++
arch/arm/boot/dts/exynos4412-trats2.dts| 12 +
arch/arm/boot/dts/exynos4x12.dtsi | 121 +++
drivers/clk/samsung/clk-exynos4.c | 10 +-
drivers/devfreq/Kconfig| 17 +-
drivers/devfreq/Makefile |1 +
drivers/devfreq/exynos/Makefile|2 +-
drivers/devfreq/exynos/exynos-bus.c| 598 +++
drivers/devfreq/exynos/exynos4_bus.c | 1055
drivers/devfreq/exynos/exynos4_bus.h | 110 --
include/dt-bindings/clock/exynos4.h|7 +-
15 files changed, 1184 insertions(+), 1179 deletions(-)
create mode 100644 Documentation/devicetree/bindings/devfreq/exynos-bus.txt
create mode 100644 drivers/devfreq/exynos/exynos-bus.c
delete mode 100644 drivers/devfreq/exynos/exynos4_bus.c
delete mode 100644 drivers/devfreq/exynos/exynos4_bus.h
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 0/9] devfreq: Add devfreq-event class to provide raw data for devfreq device
Dear Myungjoo and Kukjin,
Could you please review this patchset?
The some patch of this patchset received the acked message
by Myungjoo Ham (DEVFREQ maintainer). But, this patchset must
need to review. I'd like to merge this patch in next kernel (3.20).
Best Regards,
Chanwoo Choi
On 01/12/2015 09:34 PM, Chanwoo Choi wrote:
This patchset add new devfreq_event class to provide raw data to determine
current utilization of device which is used for devfreq governor.
The following description explains the feature of two kind of devfreq class:
- devfreq class (existing)
: devfreq consumer device use raw data from devfreq_event device for
determining proper current system state and change voltage/frequency
dynamically using various governors.
- devfreq_event class (new)
: Provide measured raw data to devfreq device for governor
-
Changelog:
Changes from v7:
(https://lkml.org/lkml/2015/1/7/795)
- Use EXPORT_SYMBOL_GPL macro instead of EXPORT_SYMBOL
- Fix the binding document of exynos-ppmu.c driver
- Drop the devfreq-event type patch because it isnt' clear
- Fix bug of devfreq_event_add_edev() when fail to execute device_register()
- Modify resource free operation on following functions:
: devfreq_event_remove_edev()
: devfreq_event_release_edev()
Changes from v6:
(https://lkml.org/lkml/2014/12/28/139)
- This patchset is based on v3.19-rc3.
1. devfreq-event class driver
- Fix build break if devfreq-event framework is off
- Add resource-managed function for devfreq-event device
: devm_devfreq_event_add_edev()
: devm_devfreq_event_remove_edev()
Changes from v5:
(https://lkml.org/lkml/2014/12/22/527)
- Rebase these patch-set on v3.19-rc1 and Test it.
1. exynos-ppmu.c
- Change the error value when of_iomap() fail to map the memory
- Remove owner setting of platform_driver
- Add exynos_ppmu_disable() function
2. exynos dts file
- Add PPMU node to Exynos3250-based Monk board
- Remove ppmu_cpu node on Exynos4412-based TRATS2 board and add
ppmu_leftbus/rightbus node
Changes from v4:
(https://lkml.org/lkml/2014/12/16/511)
1. devfreq-event class driver
- Add devfreq_event_get_edev_count() function
- Modify the simple description of devfreq-event framework in devfreq-event.c
- Minimize the usage range of global lock usage in devfreq_event_add_edev()
- Remove '_is_enabled()' function pointer in devfreq_event_ops structure
- Add separte CONFIG_PM_DEVFREQ_EVENT configuration
- Add new devfreq-event.h header file including devfreq-event helper functions
2. exynos dts file
- Add new patch to support PPMU with DEVFREQ-event on Exynos4412-based TRATS2
Changes from v3:
(https://lkml.org/lkml/2014/12/12/219)
1. devfreq-event class driver
- Fix return value of devfreq_event_get_event()
- Add new structure devfreq_event_data for devfreq_event_get_event()
- Modify the prototype of devfreq_event_get_event() function
- Call of_node_put after calling of_parse_phandle() to decrement refcount
2. exynos-ppmu driver
- Modify usage of devfreq_event_get_event() function
according to new prototype of this funciton
- Add the additional description to exynos-ppmu.txt how to add PPMU node
in board dts file
- Use 'PPMU_EVENT' macro to remove duplicate codes
- Add the support of PPMU for Exynos5260
3. exynos dts file
- Add missing PPMU_FSYS node to exynos3250.dtsi
- Fix 'ppmu_mfc_l' node name as 'ppmu_mfc' because exynos3250 has only one
MFC IP.
- Add missing PPMU_ACP/G3D to exynos4.dtsi
4. etc
- Fix wrong abbreviation of PPMU (PPMU :Platform Performance Monitoring Unit)
- Add new patch to support the PPMU of Exynos5260 SoC
Changes from v2:
(https://lkml.org/lkml/2014/12/9/304)
1. devfreq-event class driver
- Rename all the helper functions of devfreq-event device
- Add devfreq_event_remove_edev() instead of devfreq_put_event_dev()
- Add devfreq_event_release_edev() to initialize it before put device
- Add the detailed description of devfreq-event API
- Add the attributes of devfreq-event class (enable_count)
- Check the overflow about event/total_event data in devfreq_event_get_event()
- Remove the 'exclusive flag' feature
- Set set_event()/get_event() functions as mandary
- Add missing of_node_put() call
- Change variable type of 'get_event()' funciton from 'int' to 'u64'
2. exynos-ppmu driver
- Remove un-used field (struct devfreq)
- Use 'of_get_child_by_name()' instead of 'of_find_node_by_name()'
- Add missing of_node_put() call
- Fix wrong clock control
- Use devfreq_event_remove_edev() instead of devfreq_remove_device()
- Add the documentation for exynos-ppmu driver
- Remove 'enable/disable/is_enabled/reset' function of exynos-ppmu driver
3. exynos3250-rinato.dts
- Add ppmu_{leftbus|rightbus} dt node and remove ppmu_cpu dt node
Changes from v1:
(https://lkml.org/lkml/2014/9/5/11)
- Code clean
- Add the description of devfreq-event structure
- Add 'is_enabled' function to devfreq_event_ops structure
Re: [RESEND PATCH v3] clocksource: exynos_mct: Add the support for Exynos 64bit SoC
Dear Daniel and Kukjin,
On 01/15/2015 01:02 AM, Daniel Lezcano wrote:
On 01/14/2015 04:51 PM, Kukjin Kim wrote:
On 01/14/15 14:33, Chanwoo Choi wrote:
Hi,
+ Doug, Olof
This patch adds the support for Exynos 64bit SoC. The delay_timer is only
used
for Exynos 32bit SoC.
Yes, the Exynos MCT(Multi-Core Timer) is 64bit timer and it is available
on 64bit exynos SoC such as exynos7. But basically ARMv8 architecture is
including ARM ARCH timer (ARM Generic Timer) and exynos7 also has
implemented it and additionally its access is faster than using memory
mapped register called SFR for MCT...so Doug submitted patch to use MCT
on 32bit exynos SoCs before.
I know using MCT on 64bit exynos is usefulness for Power Management and
I need to talk to relevant guys in office again. If anything, I'll let
you know.
I will wait for your answer before digging more the patch.
Thanks
-- Daniel
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Kukjin Kim kgene@samsung.com
Cc: Mark Rutland mark.rutl...@arm.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
This patch set is tested on 64-bit Exynos SoC. I send only this patch from
following patchst[1].
[1] https://lkml.org/lkml/2014/12/2/134
Changes from v2:
- None
Changes from v1:
- Use CONFIG_ARM instead of CONFIG_ARM64
drivers/clocksource/Kconfig | 1 -
drivers/clocksource/exynos_mct.c | 4
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index fc01ec2..be38119 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -135,7 +135,6 @@ config CLKSRC_METAG_GENERIC
config CLKSRC_EXYNOS_MCT
def_bool y if ARCH_EXYNOS
-depends on !ARM64
help
Support for Multi Core Timer controller on Exynos SoCs.
diff --git a/drivers/clocksource/exynos_mct.c
b/drivers/clocksource/exynos_mct.c
index 9403061..b840ea1 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -223,6 +223,7 @@ static u64 notrace exynos4_read_sched_clock(void)
return exynos4_read_count_32();
}
+#if defined(CONFIG_ARM)
static struct delay_timer exynos4_delay_timer;
static cycles_t exynos4_read_current_timer(void)
@@ -231,14 +232,17 @@ static cycles_t exynos4_read_current_timer(void)
cycles_t needs to move to 32-bit for ARM64 usage);
return exynos4_read_count_32();
}
+#endif
static void __init exynos4_clocksource_init(void)
{
exynos4_mct_frc_start();
+#if defined(CONFIG_ARM)
exynos4_delay_timer.read_current_timer = exynos4_read_current_timer;
exynos4_delay_timer.freq = clk_rate;
register_current_timer_delay(exynos4_delay_timer);
+#endif
if (clocksource_register_hz(mct_frc, clk_rate))
panic(%s: can't register clocksource\n, mct_frc.name);
Do you have any comment about this patch?
Best Regards,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 17/18] iommu: exynos: init from dt-specific callback instead of initcall
Hi Marek,
Thank you for the patch.
On Friday 16 January 2015 10:13:11 Marek Szyprowski wrote:
This patch introduces IOMMU_OF_DECLARE-based initialization to the
driver, which replaces subsys_initcall-based procedure.
exynos_iommu_of_setup ensures that each sysmmu controller is probed
before its master device.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/iommu/exynos-iommu.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index c53cc8f61176..ea2659159e63 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -13,16 +13,21 @@
#endif
#include linux/clk.h
+#include linux/dma-mapping.h
#include linux/err.h
#include linux/io.h
#include linux/iommu.h
#include linux/interrupt.h
#include linux/list.h
+#include linux/of.h
+#include linux/of_iommu.h
+#include linux/of_platform.h
#include linux/platform_device.h
#include linux/pm_runtime.h
#include linux/slab.h
#include asm/cacheflush.h
+#include asm/dma-iommu.h
#include asm/pgtable.h
typedef u32 sysmmu_iova_t;
@@ -1084,6 +1089,8 @@ static const struct iommu_ops exynos_iommu_ops = {
.pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
};
+static int init_done;
+
static int __init exynos_iommu_init(void)
{
int ret;
@@ -1116,6 +1123,8 @@ static int __init exynos_iommu_init(void)
goto err_set_iommu;
}
+ init_done = true;
+
return 0;
err_set_iommu:
kmem_cache_free(lv2table_kmem_cache, zero_lv2_table);
@@ -1125,4 +1134,21 @@ err_reg_driver:
kmem_cache_destroy(lv2table_kmem_cache);
return ret;
}
-subsys_initcall(exynos_iommu_init);
+
+static int __init exynos_iommu_of_setup(struct device_node *np)
+{
+ struct platform_device *pdev;
+
+ if (!init_done)
+ exynos_iommu_init();
+
+ pdev = of_platform_device_create(np, NULL, platform_bus_type.dev_root);
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
This feels like a hack to me. What happens here is that you're using the
IOMMU_OF_DECLARE mechanism to make sure that the iommu platform device will be
created and registered before the normal OF bus populate mechanism kicks in,
thus ensuring that the iommu gets probed before other devices. In practice
this is pretty similar to using different init levels, which is what Will's
patch set was trying to avoid in the first place. Creating a new kind of init
levels mechanism doesn't sound very good to me.
The existing exynos-iommu driver is based on classic instantiation of a
platform device from DT, using the normal device probing mechanism. As such it
relies on the availability of a struct device for various helper functions. I
thus understand why you want a struct device being registered for the iommu,
instead of initializing the device right from the exynos_iommu_of_setup()
function without a corresponding struct device being registered.
This leads me to question whether we should really introduce IOMMU_OF_DECLARE.
Using regular deferred probing seems more and more like a better solution to
me.
+ of_iommu_set_ops(np, exynos_iommu_ops);
+ return 0;
+}
+
+IOMMU_OF_DECLARE(exynos_iommu_of, samsung,exynos-sysmmu,
+ exynos_iommu_of_setup);
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] i2c: Enhancement of i2c API to address circular lock dependency problem
On Sun, Jan 18, 2015 at 11:54:56AM +0100, Krzysztof Kozlowski wrote: W dniu 18.01.2015 o 07:30, Tomasz Figa pisze: So, the question is, do we actually have hardware that _really_ requires _actual_ preparation or all the clk_prepare_enable()s in I2C drivers (at least in i2c-s3c2410) are just to simplify the code? I completely forgot that you already thought about this deadlock in 2014. I think we can try the no-prepare way for i2c-s3c2410. However this would be only workaround for specific chip. Other buses (like SPI) would require similar changes. Right, and it's every single driver which would need an update too which is a bit icky and sad. On the other hand a more detailed fix is going to involve trying to make the clock API locking more fine grained which isn't fun. I wondered why this was not observed (at least not observed by me with lockdep) on Gear 2 (Rinato) board. This is quite similar case: the S2MPS14 PMIC provides regulators and 32kHz clocks. I think it is exactly the same pattern as for max77686... but somehow lockdep never reported that deadlock there. Mostly the clocks on PMICs never get changed at runtime which helps a lot here. signature.asc Description: Digital signature
Re: [PATCH] ARM: SAMSUNG: remove unused DMA infrastructure
On Thu, Jan 15, 2015 at 04:16:03PM +0100, Arnd Bergmann wrote: Everything uses dmaengine now, so there is no reason to keep this around any longer. Thanks to everyone who was involved in moving the users over to use the dmaengine APIs. Very good indeed :) Acked-by: Vinod Koul vinod.k...@intel.com -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] i2c: Enhancement of i2c API to address circular lock dependency problem
W dniu 18.01.2015 o 07:30, Tomasz Figa pisze:
Hi,
[CCing more people]
2015-01-16 23:39 GMT+09:00 Paul Osmialowski p.osmialo...@samsung.com:
This enhancement of i2c API is designed to address following problem
caused by circular lock dependency:
- #1 (prepare_lock){+.+.+.}:
[2.730502][c0061e50] __lock_acquire+0x3c0/0x8a4
[2.735970][c0062868] lock_acquire+0x6c/0x8c
[2.741090][c04a2724] mutex_lock_nested+0x68/0x464
[2.746733][c0395e84] clk_prepare_lock+0x40/0xe8
[2.752201][c0397698] clk_unprepare+0x18/0x28
[2.757409][c034cbb0] s3c24xx_i2c_xfer+0xc8/0x124
[2.762964][c03457e0] __i2c_transfer+0x74/0x8c
[2.768259][c0347234] i2c_transfer+0x78/0xec
[2.773380][c02a177c] regmap_i2c_read+0x48/0x64
[2.778761][c029d5c0] _regmap_raw_read+0xa8/0xfc
[2.784230][c029d920] _regmap_bus_read+0x28/0x48
[2.789699][c029ce00] _regmap_read+0x74/0xdc
[2.794819][c029d0ec] _regmap_update_bits+0x24/0x70
[2.800549][c029e348] regmap_update_bits+0x40/0x5c
[2.806190][c024c3c4] _regulator_do_disable+0x68/0x7c
[2.812093][c024f4d8] _regulator_disable+0x90/0x12c
[2.817822][c024f5a8] regulator_disable+0x34/0x60
[2.823377][c0363070] mmc_regulator_set_ocr+0x74/0xdc
[2.829279][c03783e8] sdhci_set_power+0x38/0x20c
[2.834748][c0379c10] sdhci_do_set_ios+0x180/0x450
[2.840389][c0379f00] sdhci_set_ios+0x20/0x2c
[2.845597][c0364978] mmc_set_initial_state+0x5c/0xbc
[2.851500][c0364f48] mmc_power_off+0x2c/0x60
[2.856708][c0365c00] mmc_rescan+0x268/0x27c
[2.861829][c003a128] process_one_work+0x18c/0x3f8
[2.867471][c003a400] worker_thread+0x38/0x2f8
[2.872766][c003f66c] kthread+0xe4/0x104
[2.877540][c000f0a8] ret_from_fork+0x14/0x2c
[2.882749]
- #0 (map-mutex){+.+...}:
[2.886828][c0061224] validate_chain.isra.25+0x3bc/0x548
[2.892990][c0061e50] __lock_acquire+0x3c0/0x8a4
[2.898459][c0062868] lock_acquire+0x6c/0x8c
[2.903580][c04a2724] mutex_lock_nested+0x68/0x464
[2.909222][c029ce9c] regmap_read+0x34/0x5c
[2.914257][c039a994] max_gen_clk_is_prepared+0x1c/0x38
[2.920333][c0396ec4] clk_unprepare_unused_subtree+0x64/0x98
[2.926842][c0396f78] clk_disable_unused+0x80/0xd8
[2.932484][c00089d0] do_one_initcall+0xac/0x1f0
[2.937953][c068bd44] do_basic_setup+0x90/0xc8
[2.943248][c068be00] kernel_init_freeable+0x84/0x120
[2.949150][c0491248] kernel_init+0x8/0xec
[2.954097][c000f0a8] ret_from_fork+0x14/0x2c
[2.959307]
[2.959307] other info that might help us debug this:
[2.959307]
[2.967293] Possible unsafe locking scenario:
[2.967293]
[2.973194]CPU0CPU1
[2.977708]
[2.982221] lock(prepare_lock);
[2.985520]lock(map-mutex);
[2.991248]lock(prepare_lock);
[2.997063] lock(map-mutex);
[3.000276]
[3.000276] *** DEADLOCK ***
Apparently regulator and clock try to acquire lock which is protecting the
same regmap. Communication over i2c requires clock to be started. Both things
require access to the same regmap in order to complete.
I stumbled upon this issue (and reported it) quite long time ago
already, but apparently nobody cared too much (including myself,
unfortunately). Please see [1] for details.
[1] https://lkml.org/lkml/2014/7/2/171
We have here a typical ABBA deadlock scenario, between I2C clock
providers and other (logical) devices on the same (physical) I2C
device, for which a regmap is used to share the registers between
drivers. Remaining factor here is I2C controller driver, which must
perform clock gating in I2C ops to trigger this deadlock.
The problem is that any operation on such I2C clock will first try to
acquire clk_prepare_mutex and then, through driver's callback, access
the regmap, acquiring its mutex (then an I2C transfer will happen, but
it irrelevant in this context). On opposite side we have drivers for
other functionality exposed by this I2C device, which will access the
regmap, acquiring its mutex and causing I2C transfers to happen.
The key here is that I2C transfers might require some clocks to be
prepared, so clk_prepare() might get called from this context and
cause a deadlock, because clk_prepare_mutex might have been already
acquired by another context, waiting for regmap mutex, which has been
already acquired by this context.
Now, for the solution, the approach proposed by Paul, as far as I
could understand it by reading the code (it's definitely lacking a
cover letter with detailed explanation), should solve the issue by
enforcing correct locking order at
Exynos4 CONFIG_HZ
With the improvements in upstream support for exynos4 devices I've been looking into adding support odroid devices to Debian's armmp kernel. The kernel config changes needed are quite minimal as can be seen here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774896 Mostly enabling support and various modules. However as Ian Campbell notes, enabling ARCH_EXYNOS4 triggers the following from arch/arm/Kconfig: config HZ_FIXED int default 200 if ARCH_EBSA110 || ARCH_S3C24XX || \ ARCH_S5PV210 || ARCH_EXYNOS4 default AT91_TIMER_HZ if ARCH_AT91 default SHMOBILE_TIMER_HZ if ARCH_SHMOBILE_LEGACY default 0 This forces CONFIG_HZ=200 for the entire armmp kernel, which is undesirable. The reason for this setting isn't very clear to either me or Ian. I personally have verified that HZ=250 (the default for debian armmp kernels) boots fine. Is there a particular reason for this setting? Would a patch removing this requirement for ARCH_EXYNOS4 be accepted? -- Sten Spans There is a crack in everything, that's how the light gets in. Leonard Cohen - Anthem -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/23] ohci-s3c2410: use HUB_CHAR_*
Fix using the bare numbers to set the 'wHubCharacteristics' field of the Hub
Descriptor while the values are #define'd in linux/usb/ch11.h.
While at it, stop setting already set HUB_CHAR_INDV_PORT_LPSM once again.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
drivers/usb/host/ohci-s3c2410.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: usb/drivers/usb/host/ohci-s3c2410.c
===
--- usb.orig/drivers/usb/host/ohci-s3c2410.c
+++ usb/drivers/usb/host/ohci-s3c2410.c
@@ -249,14 +249,14 @@ static int ohci_s3c2410_hub_control(
*/
desc-wHubCharacteristics = ~cpu_to_le16(HUB_CHAR_LPSM);
- desc-wHubCharacteristics |= cpu_to_le16(0x0001);
+ desc-wHubCharacteristics |= cpu_to_le16(
+ HUB_CHAR_INDV_PORT_LPSM);
if (info-enable_oc) {
desc-wHubCharacteristics = ~cpu_to_le16(
HUB_CHAR_OCPM);
desc-wHubCharacteristics |= cpu_to_le16(
- 0x0008 |
- 0x0001);
+ HUB_CHAR_INDV_PORT_OCPM);
}
dev_dbg(hcd-self.controller, wHubCharacteristics after
0x%04x\n,
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
