Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Vivek, On 11/20/2014 08:51 AM, Vivek Gautam wrote: I tested linux-next on Exynos5800 peach-pi board with linux-next and and the two patches $Subject and [0]. Below is my git hash: 4d9e6ee drm/exynos: Move platform drivers registration to module init 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36391a5 Add linux-next specific files for 20141119 9b1ced1 Merge branch 'akpm/master' 282497e mm: add strictlimit knob used exynos_defconfig Same here. With this display works for me. Without $Subject patch i get lookup in drm. I tested with today linux-next (next-20141120) and display is indeed working for me. So it seems that whatever caused the error in the phy-exynos-mipi-video driver reported by Paolo, got fixed recently. My working git hash is: 65a8d01 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy a9b43cb drm/exynos: Move platform drivers registration to module init 5b83d7a Add linux-next specific files for 20141120 1172916 mm: add strictlimit knob I did have to disable CONFIG_SND_SOC_SNOW though, otherwise the kernel did not boot due the issue reported previously by Kevin. Javier can you tell me your git hash. Was it on yesterday's linux-next ? In fact, my branch where I could reproduce the phy-exynos-mipi-video issue was not based on yesterday's next but next-20141117. The git hash is: 9fb5d7c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy f740096 drm/exynos: Move platform drivers registration to module init efefb5c Add linux-next specific files for 20141117 8c944d7 mm: add strictlimit knob With 3.18-rc5 i could see display on Exynos5800 peach-pi with following git hash: b6dca11 drm/exynos: dp: Remove support for unused dptx-phy 7cc5c2d ARM: exynos_defconfig: Enable options for display panel support d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy fc14f9c Linux 3.18-rc5 e35c5a2 Merge tag 'armsoc-for-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig). Yes, that works because the commit that caused the Exynos DRM lockup was: 43c0767 (of/platform: Move platform devices under /sys/devices/platform) which landed in next-20141105. Reverting 43c0767 and only applying [0] should have the same effect. I am checking further with linux-samsung, coz i could see weird behavior as mentioned in [1] with linux-samsun/for-next merged with above git hash. Great, it should be good to know what caused: exynos-mipi-video-phy 10040714.video-phy: can't request region for resource [mem 0x10040714-0x1004071f] even when I could not reproduce it anymore with today's linux-next. [0]: https://lkml.org/lkml/2014/10/30/394 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html 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
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi Javier, On Thu, Nov 20, 2014 at 2:15 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Hello Vivek, On 11/20/2014 08:51 AM, Vivek Gautam wrote: I tested linux-next on Exynos5800 peach-pi board with linux-next and and the two patches $Subject and [0]. Below is my git hash: 4d9e6ee drm/exynos: Move platform drivers registration to module init 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36391a5 Add linux-next specific files for 20141119 9b1ced1 Merge branch 'akpm/master' 282497e mm: add strictlimit knob used exynos_defconfig Same here. With this display works for me. Without $Subject patch i get lookup in drm. I tested with today linux-next (next-20141120) and display is indeed working for me. So it seems that whatever caused the error in the phy-exynos-mipi-video driver reported by Paolo, got fixed recently. My working git hash is: 65a8d01 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy a9b43cb drm/exynos: Move platform drivers registration to module init 5b83d7a Add linux-next specific files for 20141120 1172916 mm: add strictlimit knob I did have to disable CONFIG_SND_SOC_SNOW though, otherwise the kernel did not boot due the issue reported previously by Kevin. Javier can you tell me your git hash. Was it on yesterday's linux-next ? In fact, my branch where I could reproduce the phy-exynos-mipi-video issue was not based on yesterday's next but next-20141117. The git hash is: 9fb5d7c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy f740096 drm/exynos: Move platform drivers registration to module init efefb5c Add linux-next specific files for 20141117 8c944d7 mm: add strictlimit knob With 3.18-rc5 i could see display on Exynos5800 peach-pi with following git hash: b6dca11 drm/exynos: dp: Remove support for unused dptx-phy 7cc5c2d ARM: exynos_defconfig: Enable options for display panel support d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy fc14f9c Linux 3.18-rc5 e35c5a2 Merge tag 'armsoc-for-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig). Yes, that works because the commit that caused the Exynos DRM lockup was: 43c0767 (of/platform: Move platform devices under /sys/devices/platform) which landed in next-20141105. Reverting 43c0767 and only applying [0] should have the same effect. I am checking further with linux-samsung, coz i could see weird behavior as mentioned in [1] with linux-samsun/for-next merged with above git hash. Great, it should be good to know what caused: On linux-samsung tree the only patch that's missing apart from dptx-phy patches is the syscon patch from Pankaj Dubey: b784b98 mfd: syscon: Decouple syscon interface from platform devices So with below git hash, linux-samsung/for-next display works fine along with other devices that request PMU system controller : 7bd219e drm/exynos: dp: Remove support for unused dptx-phy e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 7099bde Revert Revert ARM: exynos_defconfig: Enable options for display panel support 713a994 mfd: syscon: Decouple syscon interface from platform devices 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support /* This is Kukjin's for-next today */ ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow fc14f9c Linux 3.18-rc5 exynos-mipi-video-phy 10040714.video-phy: can't request region for resource [mem 0x10040714-0x1004071f] The only reason i see this fails is since PMU is now requesting the entire memory region with base 0x1004. We should convert the mipi-phy pmu register handling too through syscon. even when I could not reproduce it anymore with today's linux-next. [0]: https://lkml.org/lkml/2014/10/30/394 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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] ASoC: samsung: In the i2s_set_sysclk() callback we are currently clearing all bits of the IISMOD register in i2s_set_sysclk. It's due to an incorrect mask used for the AND operation which is i
Cc: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Padmavathi Venna padm...@samsung.com --- sound/soc/samsung/i2s.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index 0df6547..e1ace52 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai, if (dir == SND_SOC_CLOCK_IN) mod |= 1 i2s_regs-cdclkcon_off; else - mod = 0 i2s_regs-cdclkcon_off; + mod = ~(1 i2s_regs-cdclkcon_off); i2s-rfs = rfs; break; @@ -551,10 +551,11 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai, } if (clk_id == 0) - mod = 0 i2s_regs-rclksrc_off; + mod = ~(1 i2s_regs-rclksrc_off); else mod |= 1 i2s_regs-rclksrc_off; + break; default: dev_err(i2s-pdev-dev, We don't serve that!\n); return -EINVAL; -- 1.7.4.4 -- 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: [alsa-devel] [PATCH] ASoC: samsung: In the i2s_set_sysclk() callback we are currently clearing all bits of the IISMOD register in i2s_set_sysclk. It's due to an incorrect mask used for the AND ope
Hi, On 11/20/14, Padmavathi Venna padm...@samsung.com wrote: Cc: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Padmavathi Venna padm...@samsung.com --- sound/soc/samsung/i2s.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index 0df6547..e1ace52 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai, if (dir == SND_SOC_CLOCK_IN) mod |= 1 i2s_regs-cdclkcon_off; else - mod = 0 i2s_regs-cdclkcon_off; + mod = ~(1 i2s_regs-cdclkcon_off); i2s-rfs = rfs; break; @@ -551,10 +551,11 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai, } if (clk_id == 0) - mod = 0 i2s_regs-rclksrc_off; + mod = ~(1 i2s_regs-rclksrc_off); else mod |= 1 i2s_regs-rclksrc_off; + break; default: dev_err(i2s-pdev-dev, We don't serve that!\n); return -EINVAL; -- 1.7.4.4 Please ignore this patch as subject line is not proper. Thanks Padma ___ Alsa-devel mailing list alsa-de...@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel -- 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] ASoC: samsung: ASoC: samsung: Fix IISMOD setting in i2s_set_sysclk()
In the i2s_set_sysclk() callback we are currently clearing all bits of the IISMOD register in i2s_set_sysclk. It's due to an incorrect mask used for the AND operation which is introduced in commit a5a56871f804edac93a53b5e871c0e9818fb9033 (ASoC: samsung: add support for exynos7 I2S controller) and also adds the missing break statement. Cc: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Padmavathi Venna padm...@samsung.com --- sound/soc/samsung/i2s.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index 0df6547..e1ace52 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai, if (dir == SND_SOC_CLOCK_IN) mod |= 1 i2s_regs-cdclkcon_off; else - mod = 0 i2s_regs-cdclkcon_off; + mod = ~(1 i2s_regs-cdclkcon_off); i2s-rfs = rfs; break; @@ -551,10 +551,11 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai, } if (clk_id == 0) - mod = 0 i2s_regs-rclksrc_off; + mod = ~(1 i2s_regs-rclksrc_off); else mod |= 1 i2s_regs-rclksrc_off; + break; default: dev_err(i2s-pdev-dev, We don't serve that!\n); return -EINVAL; -- 1.7.4.4 -- 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: [alsa-devel] [PATCH] ASoC: samsung: Fix IISMOD setting in i2s_set_sysclk()
Hi, On 20/11/14 08:04, Padma Venkat wrote: diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index 947352d..8db8c66 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai, if (dir == SND_SOC_CLOCK_IN) mod |= 1 i2s_regs-cdclkcon_off; else - mod = 0 i2s_regs-cdclkcon_off; + mod = ~(1 i2s_regs-cdclkcon_off); Thanks for pointing this. In my local machine it was properly done but while rebasing on linux-next I did some mistake. There is one more place in set_sysclk which need to be corrected here mod = 0 i2s_regs-rclksrc_off can you include this change also in your patch or should I post a new patch for all? OK, I'll also correct this and resend the patch. -- Regards, Sylwester -- 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 v3 2/5] drivers: soc: Add support for Exynos PMU driver
On Thu, Nov 20, 2014 at 11:09:25AM +0530, Amit Daniel Kachhap wrote: diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 063113d..44d220d 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -6,3 +6,4 @@ obj-$(CONFIG_ARCH_QCOM) += qcom/ obj-$(CONFIG_ARCH_TEGRA) += tegra/ obj-$(CONFIG_SOC_TI) += ti/ obj-$(CONFIG_PLAT_VERSATILE) += versatile/ +obj-$(CONFIG_ARCH_EXYNOS)+= samsung/ Is ARCH_EXYNOS appropriate here, or is your new SOC_SAMSUNG better? diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig new file mode 100644 index 000..a424ebc --- /dev/null +++ b/drivers/soc/samsung/Kconfig @@ -0,0 +1,20 @@ +# +# SAMSUNG SOC drivers +# +menuconfig SOC_SAMSUNG + bool Samsung SOC drivers support If you intend to select SOC_SAMSUNG, is there any point in making this a user-visible symbol? -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe linux-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] PM / Domains: Power on the PM domain right after attach completes
On 20 November 2014 01:35, Rafael J. Wysocki r...@rjwysocki.net wrote: On Wednesday, November 19, 2014 09:54:00 AM Ulf Hansson wrote: [...] Scenario 5), a platform driver with/without runtime PM callbacks. -probe() - do some initialization - may fetch handles to runtime PM resources - pm_runtime_enable() Well, and now how the driver knows if the device is on before accessing it? In this case the driver don't need to access the device during -probe(). That's postponed until sometime later. If this is a platform driver, it rather does need to access the device, precisely because it doesn't know what power state the device is in otherwise. See below. Note 1) Scenario 1) and 2), both relies on the approach to power on the PM domain by using pm_runtime_get_sync(). That approach didn't work when CONFIG_PM_RUNTIME was unset, but we recently decided to fixed that by the below patch, so that's good! [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled Note 2) Scenario 3) and 4) use the same principles for managing runtime PM. These scenarios needs a way to power on the generic PM domain prior probing the device. The call to pm_runtime_set_active(), prevents an already powered PM domain from power off until after probe, but that's not enough. Note 3) The $subject patch, tried to address the issues for scenario 3) and 4). It does so, but will affect scenario 5) which was working nicely before. In scenario 5), the $subject patch will cause the generic PM domain to potentially stay powered after -probe() even if the device is runtime PM suspended. Why would it? If the device is runtime-suspended, the domain will know that, because its callbacks will be used for that. At least, that's what I'd expect to happen, so is there a problem here? Genpd do knows about the device but it doesn’t get a notification to power off. There are no issues whatsoever for driver. Except that the driver is arguably buggy. This is a somewhat special case. Let's go through an example. 1. The PM domain is initially in powered off state. 2. The bus -probe() invokes dev_pm_domain_attach() and then the PM domain gets attached to the device. 3. $subject patch causes the PM domain to power on. 4. A driver -probe() sequence start, following the Scenario 5). 5. The device is initially in runtime PM suspended state and it will remain so during -probe(). But is it physically suspended? The runtime PM status of the device after -probe is required to reflect its real state if runtime PM is enabled. If that's not the case, it is a bug. Agree. While I was searching for drivers that behave as in scenario 5), they tend to register some subsystem specific callbacks and don't access the device until some of those callbacks are invoked. At least that was my interpretation of their -probe() methods, but it's not always easy to tell how those callbacks are being used for each subsystem. Now, for platform drivers, the driver can't really assume anything in particular about the current power state of the device at -probe time, because different platforms including devices handled by that driver may behave differently. A good example would be two platforms A and B where the same device X is in a power domain such that A boots with the domain (physically) on, while B boots with the domain off. If the driver for X assumes anything about the initial power state of the device, it may not work on either A or B. I get your point and agree! 6. The pm_request_idle() invoked after really_probe() in driver core, won't trigger a runtime PM suspend callback to be invoked. In other words, genpd don't get a notification that it may power off. In this state, genpd will either power off from the late_initcall, genpd_poweroff_unused() (depending on when the driver was probed) or wait until some device's runtime PM suspend callback is invoked at any later point. Which sounds OK to me, so why is it a problem? The late_initcall doesn't work for modules. Also, suppose the PM domain only holds this inactive device that was probed as in scenario 5). Then, you could end up having the PM domain powered, even if it isn't needed. Anyway, I can live with this. It's likely the driver that behave as in scenario 5) that should be fixed as you stated. I see three options going forward. Option 1) Convert scenario 3) and 4) into using the pm_runtime_get_sync() approach. There are no theoretical obstacles to do this, but pure practical. There are a lot of drivers that needs to be converted and we also need to teach driver authors future wise to not use pm_runtime_set_active() in this manner. I'd say we need to do something like this anyway. That is, standardize on *one* approach. I'm actually not sure what approach is the most useful, but the pm_runtime_get_sync() one seems to be the most popular to me. Option 2)
Re: [alsa-devel] [PATCH] ASoC: samsung: Fix IISMOD setting in i2s_set_sysclk()
Hi Sylwester, On 11/20/14, Sylwester Nawrocki s.nawro...@samsung.com wrote: Hi, On 20/11/14 08:04, Padma Venkat wrote: diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index 947352d..8db8c66 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai, if (dir == SND_SOC_CLOCK_IN) mod |= 1 i2s_regs-cdclkcon_off; else - mod = 0 i2s_regs-cdclkcon_off; + mod = ~(1 i2s_regs-cdclkcon_off); Thanks for pointing this. In my local machine it was properly done but while rebasing on linux-next I did some mistake. There is one more place in set_sysclk which need to be corrected here mod = 0 i2s_regs-rclksrc_off can you include this change also in your patch or should I post a new patch for all? OK, I'll also correct this and resend the patch. As I found one more break statement missing. So posted a new patch with all corrected code with your signed-off. Please do review of the same. Thanks for you support. Padma -- Regards, Sylwester -- 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 0/3] PM / Domains: Add initial PM clock support to genpd
On 20 November 2014 01:33, Kevin Hilman khil...@kernel.org wrote: Ulf Hansson ulf.hans...@linaro.org writes: It's quite common for PM domains to use PM clocks. Typically from SOC specific code, the per device PM clock list is created and pm_clk_suspend|resume() are invoked to handle clock gating/ungating. A step towards consolidation is to integrate PM clock support into genpd, which is what this patchset does. In this initial step, the calls to the pm_clk_suspend|resume() are handled within genpd, but the per device PM clock list still needs to be created from SOC specific code. It seems reasonable to have gendp to handle that as well, but that left to future patchsets to address. I think we need to get rid of the SoC specific code already. For example, we're already seeing SoCs where the arm32 core is being replaced by an arm64 core but the other IPs, and power-domain logic is staying more or less the same. It's not every users of genpd that are keen on using PM clocks thus we need to provide this a configuration option for genpd. Or more likely, probably some compatible string, or property in the domain node. Grygorii, Arnd and myself were discussing this elsewhere in the context of the TI Keystone2 PM domain support[1]. Thanks for pointing that out. It was actually the reason to why I posted this patchset now, I have been keeping the patches locally in my tree for too long. :-) Let me comment of that thread, instead of here. Kind regards Uffe -- 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
[RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers
This patch makes kms drivers to be independent drivers. For this, it removes all register codes to kms drivers from exynos_drm_drv module and adds module_init/exit for each kms driver so that each kms driver can be called independently. Changelog v3: - Use module_platform_driver macro instead module_init/exit. - Configure all kms drivers to be built in kernel image. Changelog v2: - none Signed-off-by: Inki Dae inki@samsung.com --- drivers/gpu/drm/exynos/exynos_dp_core.c |2 ++ drivers/gpu/drm/exynos/exynos_drm_drv.c | 43 +++--- drivers/gpu/drm/exynos/exynos_drm_drv.h |5 drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 ++ drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++ drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++ drivers/gpu/drm/exynos/exynos_mixer.c|2 ++ 7 files changed, 13 insertions(+), 45 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index ed818b9..30ebf5d 100644 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c @@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = { }, }; +module_platform_driver(dp_driver); + MODULE_AUTHOR(Jingoo Han jg1@samsung.com); MODULE_DESCRIPTION(Samsung SoC DP Driver); MODULE_LICENSE(GPL v2); diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index eab12f0..02d4772 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -484,12 +484,6 @@ static struct component_match *exynos_drm_match_add(struct device *dev) mutex_lock(drm_component_lock); - /* Do not retry to probe if there is no any kms driver regitered. */ - if (list_empty(drm_component_list)) { - mutex_unlock(drm_component_lock); - return ERR_PTR(-ENODEV); - } - list_for_each_entry(cdev, drm_component_list, list) { /* * Add components to master only in case that crtc and @@ -545,22 +539,6 @@ static const struct component_master_ops exynos_drm_ops = { .unbind = exynos_drm_unbind, }; -static struct platform_driver *const exynos_drm_kms_drivers[] = { -#ifdef CONFIG_DRM_EXYNOS_FIMD - fimd_driver, -#endif -#ifdef CONFIG_DRM_EXYNOS_DP - dp_driver, -#endif -#ifdef CONFIG_DRM_EXYNOS_DSI - dsi_driver, -#endif -#ifdef CONFIG_DRM_EXYNOS_HDMI - mixer_driver, - hdmi_driver, -#endif -}; - static struct platform_driver *const exynos_drm_non_kms_drivers[] = { #ifdef CONFIG_DRM_EXYNOS_G2D g2d_driver, @@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32); exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls); - for (i = 0; i ARRAY_SIZE(exynos_drm_kms_drivers); ++i) { - ret = platform_driver_register(exynos_drm_kms_drivers[i]); - if (ret 0) - goto err_unregister_kms_drivers; - } - match = exynos_drm_match_add(pdev-dev); - if (IS_ERR(match)) { - ret = PTR_ERR(match); - goto err_unregister_kms_drivers; - } + if (IS_ERR(match)) + return PTR_ERR(match); ret = component_master_add_with_match(pdev-dev, exynos_drm_ops, match); if (ret 0) - goto err_unregister_kms_drivers; + return ret; for (j = 0; j ARRAY_SIZE(exynos_drm_non_kms_drivers); ++j) { ret = platform_driver_register(exynos_drm_non_kms_drivers[j]); @@ -632,10 +602,6 @@ err_unregister_non_kms_drivers: err_del_component_master: component_master_del(pdev-dev, exynos_drm_ops); -err_unregister_kms_drivers: - while (--i = 0) - platform_driver_unregister(exynos_drm_kms_drivers[i]); - return ret; } @@ -654,9 +620,6 @@ static int exynos_drm_platform_remove(struct platform_device *pdev) component_master_del(pdev-dev, exynos_drm_ops); - for (i = ARRAY_SIZE(exynos_drm_kms_drivers) - 1; i = 0; --i) - platform_driver_unregister(exynos_drm_kms_drivers[i]); - return 0; } diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h b/drivers/gpu/drm/exynos/exynos_drm_drv.h index 262a459..352a9f9 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h @@ -331,11 +331,6 @@ int exynos_drm_component_add(struct device *dev, void exynos_drm_component_del(struct device *dev, enum exynos_drm_device_type dev_type); -extern struct platform_driver fimd_driver; -extern struct platform_driver dp_driver; -extern struct platform_driver dsi_driver; -extern struct platform_driver mixer_driver; -extern struct platform_driver hdmi_driver; extern struct platform_driver
[RFC PATCH v3 2/4] drm/exynos: make non kms drivers to be indenpendent drivers
This patch makes non kms drivers to be independent drivers. For this, it removes all register codes to non kms drivers from exynos_drm_drv module and adds module_init/exit for each non kms driver so that each non kms driver can be called independently. In addition, this patch adds non kms register/unregister functions to exynos_drm_core module and also modifies existing codes relevant to sub driver. The idea is that non kms driver is registered by entry point, module_init, of each non kms driver and sets its own sub driver to registered non kms driver object when the sub driver is probed. For this, this patch adds a new structure, exynos_drm_non_kms_dev, to exynos_drm_core module. Changelog v3: - fix the use of mutex lock. - fix g2d device node check. - use module_platform_driver macro instead of module_init/exit. Changelog v2: - check if available g2d device node. - return 0 instead of -EPROBE_DEFER in case of no non kms device registered. This case is not error. Signed-off-by: Inki Dae inki@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_core.c| 164 +++ drivers/gpu/drm/exynos/exynos_drm_drv.c | 50 +--- drivers/gpu/drm/exynos/exynos_drm_drv.h | 28 ++--- drivers/gpu/drm/exynos/exynos_drm_fimc.c|1 + drivers/gpu/drm/exynos/exynos_drm_g2d.c | 48 drivers/gpu/drm/exynos/exynos_drm_gsc.c |1 + drivers/gpu/drm/exynos/exynos_drm_ipp.c | 39 ++- drivers/gpu/drm/exynos/exynos_drm_rotator.c |2 + 8 files changed, 243 insertions(+), 90 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_core.c b/drivers/gpu/drm/exynos/exynos_drm_core.c index 4c9f972..6c38308 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_core.c +++ b/drivers/gpu/drm/exynos/exynos_drm_core.c @@ -19,6 +19,13 @@ #include exynos_drm_fbdev.h static LIST_HEAD(exynos_drm_subdrv_list); +DEFINE_MUTEX(list_lock); + +struct exynos_drm_non_kms_dev { + struct list_head list; + struct exynos_drm_subdrv *subdrv; + unsigned int device_type; +}; int exynos_drm_create_enc_conn(struct drm_device *dev, struct exynos_drm_display *display) @@ -55,12 +62,66 @@ err_destroy_encoder: return ret; } +int exynos_drm_non_kms_register(unsigned int device_type) +{ + struct exynos_drm_non_kms_dev *dev; + + dev = kzalloc(sizeof(*dev), GFP_KERNEL); + if (!dev) + return -ENOMEM; + + dev-device_type = device_type; + + mutex_lock(list_lock); + list_add_tail(dev-list, exynos_drm_subdrv_list); + mutex_unlock(list_lock); + + return 0; +} + +void exynos_drm_non_kms_unregister(unsigned int device_type) +{ + struct exynos_drm_non_kms_dev *dev, *next; + + mutex_lock(list_lock); + list_for_each_entry_safe(dev, next, exynos_drm_subdrv_list, list) { + mutex_unlock(list_lock); + if (dev-device_type == device_type) { + list_del_init(dev-list); + kfree(dev); + mutex_lock(list_lock); + break; + } + mutex_lock(list_lock); + } + mutex_unlock(list_lock); +} + int exynos_drm_subdrv_register(struct exynos_drm_subdrv *subdrv) { + struct exynos_drm_non_kms_dev *dev; + if (!subdrv) return -EINVAL; - list_add_tail(subdrv-list, exynos_drm_subdrv_list); + mutex_lock(list_lock); + if (list_empty(exynos_drm_subdrv_list)) { + mutex_unlock(list_lock); + return -ENODEV; + } + mutex_unlock(list_lock); + + mutex_lock(list_lock); + list_for_each_entry(dev, exynos_drm_subdrv_list, list) { + mutex_unlock(list_lock); + if (dev-device_type == subdrv-device_type) { + dev-subdrv = subdrv; + mutex_lock(list_lock); + break; + } + mutex_lock(list_lock); + } + mutex_unlock(list_lock); return 0; } @@ -68,94 +129,149 @@ EXPORT_SYMBOL_GPL(exynos_drm_subdrv_register); int exynos_drm_subdrv_unregister(struct exynos_drm_subdrv *subdrv) { + struct exynos_drm_non_kms_dev *dev; + if (!subdrv) return -EINVAL; - list_del(subdrv-list); + mutex_lock(list_lock); + list_for_each_entry(dev, exynos_drm_subdrv_list, list) { + mutex_unlock(list_lock); + if (dev-device_type == subdrv-device_type) { + dev-subdrv = NULL; + break; + } + mutex_lock(list_lock); + } + mutex_unlock(list_lock); return 0; } EXPORT_SYMBOL_GPL(exynos_drm_subdrv_unregister); -int exynos_drm_device_subdrv_probe(struct drm_device *dev) +int exynos_drm_device_subdrv_probe(struct drm_device *drm_dev) { - struct exynos_drm_subdrv
[RFC PATCH v3 0/4] separeate sub drivers into independent drivers
Hi all, This patch set separeates sub drivers into independent drivers. patch 1/4: - make all kms drivers - fimd, hdmi, dp and dsi - to be independent drivers. patch 2/4: - make all non kms drivers - g2d and ipp - to be independent drivers. patch 3/4: - make vidi driver to be independent driver. patch 4/4: - just clean up codes for checking if it's Exynos SoC. This patch series had been posted like below with different subject, v1: http://www.spinics.net/lists/linux-samsung-soc/msg39116.html v2: http://www.spinics.net/lists/linux-samsung-soc/msg39145.html, and only one modified patch was posted. DRM driver should be single driver so it's not reasonable for sub drivers to be built as independent modules. So I changed previous subjects to new ones by reverting existing Kconfig. With this change, all sub drivers will be built-in kernel image. Thanks, Inki Dae Inki Dae (4): drm/exynos: make kms drivers to be independent drivers drm/exynos: make non kms drivers to be indenpendent drivers drm/exynos: make vidi driver to be independent driver drm/exynos: clean up machine compatible string check drivers/gpu/drm/exynos/exynos_dp_core.c |2 + drivers/gpu/drm/exynos/exynos_drm_core.c| 164 +++ drivers/gpu/drm/exynos/exynos_drm_drv.c | 125 drivers/gpu/drm/exynos/exynos_drm_drv.h | 42 ++- drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 + drivers/gpu/drm/exynos/exynos_drm_fimc.c|1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c|2 + drivers/gpu/drm/exynos/exynos_drm_g2d.c | 48 drivers/gpu/drm/exynos/exynos_drm_gsc.c |1 + drivers/gpu/drm/exynos/exynos_drm_ipp.c | 39 ++- drivers/gpu/drm/exynos/exynos_drm_rotator.c |2 + drivers/gpu/drm/exynos/exynos_drm_vidi.c| 81 - drivers/gpu/drm/exynos/exynos_hdmi.c|2 + drivers/gpu/drm/exynos/exynos_mixer.c |2 + 14 files changed, 326 insertions(+), 187 deletions(-) -- 1.7.9.5 -- 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
[RFC PATCH v3 3/4] drm/exynos: make vidi driver to be independent driver
This patch makes vidi driver to be independent driver. For this, it removes register codes to vidi driver from exynos_drm_drv module and adds module_init/exit for vidi driver so that this driver can be called independently. In addition, this patch adds component support to vidi driver so that this driver can be bound independently. Changelog v3: - none Changelog v2: - none Signed-off-by: Inki Dae inki@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 + drivers/gpu/drm/exynos/exynos_drm_drv.h |9 drivers/gpu/drm/exynos/exynos_drm_vidi.c | 81 +++--- 3 files changed, 54 insertions(+), 48 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 7f1186e..3ac39b6 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -608,19 +608,12 @@ static int exynos_drm_init(void) if (IS_ERR(exynos_drm_pdev)) return PTR_ERR(exynos_drm_pdev); - ret = exynos_drm_probe_vidi(); - if (ret 0) - goto err_unregister_pd; - ret = platform_driver_register(exynos_drm_platform_driver); if (ret) - goto err_remove_vidi; + goto err_unregister_pd; return 0; -err_remove_vidi: - exynos_drm_remove_vidi(); - err_unregister_pd: platform_device_unregister(exynos_drm_pdev); @@ -630,9 +623,6 @@ err_unregister_pd: static void exynos_drm_exit(void) { platform_driver_unregister(exynos_drm_platform_driver); - - exynos_drm_remove_vidi(); - platform_device_unregister(exynos_drm_pdev); } diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h b/drivers/gpu/drm/exynos/exynos_drm_drv.h index 5b3305c..7c2ba06 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h @@ -310,14 +310,6 @@ exynos_dpi_probe(struct device *dev) { return NULL; } static inline int exynos_dpi_remove(struct device *dev) { return 0; } #endif -#ifdef CONFIG_DRM_EXYNOS_VIDI -int exynos_drm_probe_vidi(void); -void exynos_drm_remove_vidi(void); -#else -static inline int exynos_drm_probe_vidi(void) { return 0; } -static inline void exynos_drm_remove_vidi(void) {} -#endif - /* This function creates a encoder and a connector, and initializes them. */ int exynos_drm_create_enc_conn(struct drm_device *dev, struct exynos_drm_display *display); @@ -333,5 +325,4 @@ extern int exynos_drm_non_kms_register(unsigned int device_type); extern void exynos_drm_non_kms_unregister(unsigned int device_type); extern struct platform_driver exynos_drm_common_hdmi_driver; -extern struct platform_driver vidi_driver; #endif diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c index 50faf91..e1153aa 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c @@ -14,6 +14,7 @@ #include linux/kernel.h #include linux/platform_device.h +#include linux/component.h #include drm/exynos_drm.h @@ -48,10 +49,10 @@ struct vidi_win_data { struct vidi_context { struct drm_device *drm_dev; + struct platform_device *pdev; struct drm_crtc *crtc; struct drm_encoder *encoder; struct drm_connectorconnector; - struct exynos_drm_subdrvsubdrv; struct vidi_win_datawin_data[WINDOWS_NR]; struct edid *raw_edid; unsigned intclkdiv; @@ -561,14 +562,13 @@ static struct exynos_drm_display vidi_display = { .ops = vidi_display_ops, }; -static int vidi_subdrv_probe(struct drm_device *drm_dev, struct device *dev) +static int vidi_bind(struct device *dev, struct device *master, void *data) { - struct exynos_drm_manager *mgr = get_vidi_mgr(dev); - struct vidi_context *ctx = mgr-ctx; - struct drm_crtc *crtc = ctx-crtc; + struct drm_crtc *crtc = vidi_manager.crtc; + struct drm_device *drm_dev = data; int ret; - vidi_mgr_initialize(mgr, drm_dev); + vidi_mgr_initialize(vidi_manager, drm_dev); ret = exynos_drm_crtc_create(vidi_manager); if (ret) { @@ -586,20 +586,42 @@ static int vidi_subdrv_probe(struct drm_device *drm_dev, struct device *dev) return 0; } +static void vidi_unbind(struct device *dev, struct device *master, + void *data) +{ +} + +static const struct component_ops vidi_component_ops = { + .bind = vidi_bind, + .unbind = vidi_unbind, +}; + static int vidi_probe(struct platform_device *pdev) { - struct exynos_drm_subdrv *subdrv; struct vidi_context *ctx; int ret; + ret = exynos_drm_component_add(pdev-dev, EXYNOS_DEVICE_TYPE_CRTC, + vidi_manager.type); + if
[RFC PATCH v3 4/4] drm/exynos: clean up machine compatible string check
Use 'for' statemant instead of hard-coded 'if' statement. Changelog v3: - none Changelog v2: - none Signed-off-by: Inki Dae inki@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 20 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 3ac39b6..4579186 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -587,9 +587,16 @@ static struct platform_driver exynos_drm_platform_driver = { }, }; +static const char * const strings[] = { + samsung,exynos3, + samsung,exynos4, + samsung,exynos5, +}; + static int exynos_drm_init(void) { - int ret; + bool is_exynos = false; + int ret, i; /* * Register device object only in case of Exynos SoC. @@ -598,9 +605,14 @@ static int exynos_drm_init(void) * by Exynos drm driver when using multi-platform kernel. * So these codes will be replaced with more generic way later. */ - if (!of_machine_is_compatible(samsung,exynos3) - !of_machine_is_compatible(samsung,exynos4) - !of_machine_is_compatible(samsung,exynos5)) + for (i = 0; i ARRAY_SIZE(strings); i++) { + if (of_machine_is_compatible(strings[i])) { + is_exynos = true; + break; + } + } + + if (!is_exynos) return -ENODEV; exynos_drm_pdev = platform_device_register_simple(exynos-drm, -1, -- 1.7.9.5 -- 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: [alsa-devel] [PATCH] ASoC: samsung: ASoC: samsung: Fix IISMOD setting in i2s_set_sysclk()
On 20/11/14 11:03, Padmavathi Venna wrote: In the i2s_set_sysclk() callback we are currently clearing all bits of the IISMOD register in i2s_set_sysclk. It's due to an incorrect mask used for the AND operation which is introduced in commit a5a56871f804edac93a53b5e871c0e9818fb9033 (ASoC: samsung: add support for exynos7 I2S controller) and also adds the missing The patch looks good to me, I'd just write about the missing break in a separate sentence, i.e. s/and also adds/. Also add/ break statement. Cc: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Padmavathi Venna padm...@samsung.com --- sound/soc/samsung/i2s.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/sound/soc/samsung/i2s.c b/sound/soc/samsung/i2s.c index 0df6547..e1ace52 100644 --- a/sound/soc/samsung/i2s.c +++ b/sound/soc/samsung/i2s.c @@ -494,7 +494,7 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai, if (dir == SND_SOC_CLOCK_IN) mod |= 1 i2s_regs-cdclkcon_off; else - mod = 0 i2s_regs-cdclkcon_off; + mod = ~(1 i2s_regs-cdclkcon_off); i2s-rfs = rfs; break; @@ -551,10 +551,11 @@ static int i2s_set_sysclk(struct snd_soc_dai *dai, } if (clk_id == 0) - mod = 0 i2s_regs-rclksrc_off; + mod = ~(1 i2s_regs-rclksrc_off); else mod |= 1 i2s_regs-rclksrc_off; + break; default: dev_err(i2s-pdev-dev, We don't serve that!\n); return -EINVAL; -- Regards, Sylwester -- 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 1/1] [media] platform: Deletion of unnecessary checks before two function calls
From: Markus Elfring elfr...@users.sourceforge.net Date: Thu, 20 Nov 2014 11:44:20 +0100 The functions i2c_put_adapter() and release_firmware() test whether their argument is NULL and then return immediately. Thus the test around the call is not needed. This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring elfr...@users.sourceforge.net --- drivers/media/platform/exynos4-is/fimc-is.c | 6 ++ drivers/media/platform/s3c-camif/camif-core.c | 3 +-- 2 files changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/media/platform/exynos4-is/fimc-is.c b/drivers/media/platform/exynos4-is/fimc-is.c index 5476dce..a1db27b 100644 --- a/drivers/media/platform/exynos4-is/fimc-is.c +++ b/drivers/media/platform/exynos4-is/fimc-is.c @@ -428,8 +428,7 @@ static void fimc_is_load_firmware(const struct firmware *fw, void *context) * needed around for copying to the IS working memory every * time before the Cortex-A5 is restarted. */ - if (is-fw.f_w) - release_firmware(is-fw.f_w); + release_firmware(is-fw.f_w); is-fw.f_w = fw; done: mutex_unlock(is-lock); @@ -937,8 +936,7 @@ static int fimc_is_remove(struct platform_device *pdev) vb2_dma_contig_cleanup_ctx(is-alloc_ctx); fimc_is_put_clocks(is); fimc_is_debugfs_remove(is); - if (is-fw.f_w) - release_firmware(is-fw.f_w); + release_firmware(is-fw.f_w); fimc_is_free_cpu_memory(is); return 0; diff --git a/drivers/media/platform/s3c-camif/camif-core.c b/drivers/media/platform/s3c-camif/camif-core.c index b385747..3b09b5b 100644 --- a/drivers/media/platform/s3c-camif/camif-core.c +++ b/drivers/media/platform/s3c-camif/camif-core.c @@ -256,8 +256,7 @@ static void camif_unregister_sensor(struct camif_dev *camif) v4l2_device_unregister_subdev(sd); camif-sensor.sd = NULL; i2c_unregister_device(client); - if (adapter) - i2c_put_adapter(adapter); + i2c_put_adapter(adapter); } static int camif_create_media_links(struct camif_dev *camif) -- 2.1.3 -- 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 1/3] PM / Domains: Initial PM clock support for genpd
On 19 November 2014 18:25, Dmitry Torokhov dmitry.torok...@gmail.com wrote: On Wed, Nov 19, 2014 at 03:00:36PM +0100, Ulf Hansson wrote: It's quite common for PM domains to use PM clocks. Typically from SOC specific code, the per device PM clock list is created and pm_clk_suspend|resume() are invoked to handle clock gating/ungating. A step towards consolidation is to integrate PM clock support into genpd, which is what this patch does. In this initial step, the calls to the pm_clk_suspend|resume() are handled within genpd, but the per device PM clock list still needs to be created from SOC specific code. It seems reasonable to have gendp to handle that as well, but that left to future patches to address. It's not every users of genpd that are keen on using PM clocks thus we need to provide this a configuration option for genpd. Therefore let's add flag field in the genpd struct to keep this information and define a new PM_DOMAIN_PM_CLK bit can then be set at initialization. Signed-off-by: Ulf Hansson ulf.hans...@linaro.org --- drivers/base/power/domain.c | 7 +++ include/linux/pm_domain.h | 3 +++ 2 files changed, 10 insertions(+) diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c index 3989eb6..42e328c 100644 --- a/drivers/base/power/domain.c +++ b/drivers/base/power/domain.c @@ -12,6 +12,7 @@ #include linux/pm_runtime.h #include linux/pm_domain.h #include linux/pm_qos.h +#include linux/pm_clock.h #include linux/slab.h #include linux/err.h #include linux/sched.h @@ -1948,6 +1949,12 @@ void pm_genpd_init(struct generic_pm_domain *genpd, genpd-domain.ops.complete = pm_genpd_complete; genpd-dev_ops.save_state = pm_genpd_default_save_state; genpd-dev_ops.restore_state = pm_genpd_default_restore_state; + + if (genpd-flags PM_DOMAIN_PM_CLK) { + genpd-dev_ops.stop = pm_clk_suspend; + genpd-dev_ops.start = pm_clk_suspend; The 2nd one is wrong. Huh, thanks for spotting this. + } + mutex_lock(gpd_list_lock); list_add(genpd-gpd_list_node, gpd_list); mutex_unlock(gpd_list_lock); diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h index 9d254e2..44c6931 100644 --- a/include/linux/pm_domain.h +++ b/include/linux/pm_domain.h @@ -14,6 +14,7 @@ #include linux/pm.h #include linux/err.h #include linux/of.h +#include linux/bitops.h #include linux/notifier.h #include linux/cpuidle.h @@ -76,6 +77,8 @@ struct generic_pm_domain { struct device *dev); void (*detach_dev)(struct generic_pm_domain *domain, struct device *dev); + unsigned int flags; /* Bit field of configs for genpd */ +#define PM_DOMAIN_PM_CLK BIT(0) /* PM domain use PM clk */ s/use/uses ? Are you planning on adding a separate flag for collecting clocks from OF on attach/detach? Yes, I am thinking on that approach. Do you have any suggestions around this? Kind regards Uffe -- 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 v2 00/33] thermal: exynos: convert the driver to use per-SoC type operations
Hi Eduardo, Hi, This patch series replaces the hardware registers abstractions in the Exynos thermal driver by the usage of per-SoC type operations. Such solution provides simpler, easier to understand code and allows removal of ~250 LOCs (~11% of the whole source code) from the driver. Some other driver improvements are now also possible thanks to these changes but are scheduled at later time (like consolidating code for clearing IRQs using INTCLEAR register). The patchset should not cause any functionality changes. This means that unless there are some bugs in the patches itself there should be no behavior changes for the driver (this also includes lack of changes in the way hardware is accessed by the driver). All testing was done on (Exynos4412 SoC based) ODROID U3 board (some additional patches are needed to make the Exynos thermal driver work on this hardware). For the whole patch series: Repository: kernel_linux-soc-thermal/next SHA1: 4027494124fd88e5d51127eebba315de5d8d57c8 Test HW: Trats2 - Exynos4412 Tested-by: Lukasz Majewski l.majew...@samsung.com Trats - Exynos4210 Tested-by: Lukasz Majewski l.majew...@samsung.com ARNDALE(SMDK) - Exynos5250 Tested-by: Lukasz Majewski l.majew...@samsung.com ARNDALE OCTA - Exynos5420 Tested-by: Lukasz Majewski l.majew...@samsung.com Depends on: - 'next' branch of linux-soc-thermal.git kernel tree from Eduardo Changes since v1 (https://lkml.org/lkml/2014/9/18/305): - rebased on top of the current linux-soc-thermal kernel Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (33): thermal: exynos: remove needless triminfo_data abstraction thermal: exynos: remove needless tmu_status abstraction thermal: exynos: remove needless threshold_temp abstraction thermal: exynos: remove needless triminfo_ctrl abstraction thermal: exynos: remove needless test_mux_addr_shift abstraction thermal: exynos: remove needless therm_trip_[mode,mask]_shift abstractions thermal: exynos: remove needless therm_trip_en_shift abstraction thermal: exynos: remove needless emul_temp_shift abstraction thermal: exynos: remove needless emul_time_shift abstraction thermal: exynos: replace tmu_irqstatus check by Exynos5440 one thermal: exynos: replace tmu_pmin check by Exynos5440 one thermal: exynos: simplify HW_TRIP level setting thermal: exynos: replace threshold_falling check by Exynos SoC type one thermal: exynos: remove TMU_SUPPORT_READY_STATUS flag thermal: exynos: remove TMU_SUPPORT_TRIM_RELOAD flag thermal: exynos: add sanitize_temp_error() helper thermal: exynos: add get_th_reg() helper thermal: exynos: add -tmu_initialize method thermal: exynos: add get_con_reg() helper thermal: exynos: add -tmu_control method thermal: exynos: add -tmu_read method thermal: exynos: add get_emul_con_reg() helper thermal: exynos: add -tmu_set_emulation method thermal: exynos: add -tmu_clear_irqs method thermal: exynos: remove TMU_SUPPORT_FALLING_TRIP flag thermal: exynos: remove TMU_SUPPORT_EMUL_TIME flag thermal: exynos: remove TMU_SUPPORT_EMULATION flag thermal: exynos: remove TMU_SUPPORT_ADDRESS_MULTIPLE flag thermal: exynos: remove TMU_SUPPORT_MULTI_INST flag thermal: exynos: remove test_mux pdata field thermal: exynos: remove SoC type ifdefs thermal: exynos: remove __EXYNOS5420_TMU_DATA macro thermal: exynos: remove exynos_tmu_data.h include drivers/thermal/samsung/exynos_thermal_common.h | 1 - drivers/thermal/samsung/exynos_tmu.c| 692 drivers/thermal/samsung/exynos_tmu.h| 123 + drivers/thermal/samsung/exynos_tmu_data.c | 239 +--- drivers/thermal/samsung/exynos_tmu_data.h | 159 -- 5 files changed, 485 insertions(+), 729 deletions(-) delete mode 100644 drivers/thermal/samsung/exynos_tmu_data.h -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- 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] PM / Domains: Power on the PM domain right after attach completes
On 11/19/2014 10:54 AM, Ulf Hansson wrote: [...] Scenario 5), a platform driver with/without runtime PM callbacks. -probe() - do some initialization - may fetch handles to runtime PM resources - pm_runtime_enable() Well, and now how the driver knows if the device is on before accessing it? In this case the driver don't need to access the device during -probe(). That's postponed until sometime later. Note 1) Scenario 1) and 2), both relies on the approach to power on the PM domain by using pm_runtime_get_sync(). That approach didn't work when CONFIG_PM_RUNTIME was unset, but we recently decided to fixed that by the below patch, so that's good! [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled Note 2) Scenario 3) and 4) use the same principles for managing runtime PM. These scenarios needs a way to power on the generic PM domain prior probing the device. The call to pm_runtime_set_active(), prevents an already powered PM domain from power off until after probe, but that's not enough. Note 3) The $subject patch, tried to address the issues for scenario 3) and 4). It does so, but will affect scenario 5) which was working nicely before. In scenario 5), the $subject patch will cause the generic PM domain to potentially stay powered after -probe() even if the device is runtime PM suspended. Why would it? If the device is runtime-suspended, the domain will know that, because its callbacks will be used for that. At least, that's what I'd expect to happen, so is there a problem here? Genpd do knows about the device but it doesn’t get a notification to power off. There are no issues whatsoever for driver. This is a somewhat special case. Let's go through an example. 1. The PM domain is initially in powered off state. 2. The bus -probe() invokes dev_pm_domain_attach() and then the PM domain gets attached to the device. 3. $subject patch causes the PM domain to power on. 4. A driver -probe() sequence start, following the Scenario 5). 5. The device is initially in runtime PM suspended state and it will remain so during -probe(). 6. The pm_request_idle() invoked after really_probe() in driver core, won't trigger a runtime PM suspend callback to be invoked. In other words, genpd don't get a notification that it may power off. In this state, genpd will either power off from the late_initcall, genpd_poweroff_unused() (depending on when the driver was probed) or wait until some device's runtime PM suspend callback is invoked at any later point. if I understand things right (thanks to Russell), the Power domain may not be powered off not only in above case, but also in some cases when driver is unloaded. AMBA bus for example: static int amba_remove(struct device *dev) { pm_runtime_get_sync(dev); -- GPD=on, dev is active, usage_count = 1 ret = drv-remove(pcdev); --- GPD=on, should do balancing put() to compensate all get() made by driver, usage_count == 1 --- GPD=on, should do balancing get() to compensate put() in probe, usage_count == 2 pm_runtime_put_noidle(dev); -- GPD=on, dev is active, usage_count == 1 /* Undo the runtime PM settings in amba_probe() */ pm_runtime_disable(dev); -- GPD=on, dev is active, usage_count == 1 pm_runtime_set_suspended(dev); -- GPD=on, dev is suspended, usage_count == 1 pm_runtime_put_noidle(dev); -- GPD=on, dev is suspended, usage_count == 0 amba_put_disable_pclk(pcdev); dev_pm_domain_detach(dev, true); -- GPD=on, dev is suspended, usage_count == 0 also: i2c-qup.c i2c-hix5hd2.c exynos_drm_gsc.c exynos_drm_fimc.c ab8500-gpadc.c ... Is it? I see three options going forward. Option 1) Convert scenario 3) and 4) into using the pm_runtime_get_sync() approach. There are no theoretical obstacles to do this, but pure practical. There are a lot of drivers that needs to be converted and we also need to teach driver authors future wise to not use pm_runtime_set_active() in this manner. I'd say we need to do something like this anyway. That is, standardize on *one* approach. I'm actually not sure what approach is the most useful, but the pm_runtime_get_sync() one seems to be the most popular to me. Option 2) Add some kind of get/put API for PM domains. The buses invokes it to control the power to the PM domain. From what I understand, that's also what Dmitry think is needed!? Anyway, that somehow means to proceed with the approach I took in the below patchset. [PATCH v3 0/9] PM / Domains: Fix race conditions during boot http://marc.info/?t=14132090703r=1w=2 I don't like that. The API is already quite complicated in my view and adding even more complexity to it is not going to help in the long run. I absolutely agree that we shouldn't add unnecessary APIs and keep APIs as simple as
Re: [PATCH] MAINTAINERS: update email address and cleanup for exynos entry
On Monday 17 November 2014, Ben Dooks wrote: On 14/11/14 07:54, Kukjin Kim wrote: Use kernel.org account instead of samsung.com and cleanup for Samsung s3c, s5p and exynos SoCs. Cc: Ben Dooks ben.do...@codethink.co.uk I do wish these would be sent to the mail address I use for Linux related issues. I only want to see work related Linux issues to my ben.do...@codethink.co.uk address. It is sad to see my entries removed, but I no longer have time to maintain these. Signed-off-by: Kukjin Kim kg...@kernel.org Acked-by: Ben Dooks ben-li...@fluff.org Applied to next/fixes-non-critical, thanks! Arnd -- 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] PM / Domains: Power on the PM domain right after attach completes
On 20 November 2014 13:17, Grygorii Strashko grygorii.stras...@ti.com wrote: On 11/19/2014 10:54 AM, Ulf Hansson wrote: [...] Scenario 5), a platform driver with/without runtime PM callbacks. -probe() - do some initialization - may fetch handles to runtime PM resources - pm_runtime_enable() Well, and now how the driver knows if the device is on before accessing it? In this case the driver don't need to access the device during -probe(). That's postponed until sometime later. Note 1) Scenario 1) and 2), both relies on the approach to power on the PM domain by using pm_runtime_get_sync(). That approach didn't work when CONFIG_PM_RUNTIME was unset, but we recently decided to fixed that by the below patch, so that's good! [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled Note 2) Scenario 3) and 4) use the same principles for managing runtime PM. These scenarios needs a way to power on the generic PM domain prior probing the device. The call to pm_runtime_set_active(), prevents an already powered PM domain from power off until after probe, but that's not enough. Note 3) The $subject patch, tried to address the issues for scenario 3) and 4). It does so, but will affect scenario 5) which was working nicely before. In scenario 5), the $subject patch will cause the generic PM domain to potentially stay powered after -probe() even if the device is runtime PM suspended. Why would it? If the device is runtime-suspended, the domain will know that, because its callbacks will be used for that. At least, that's what I'd expect to happen, so is there a problem here? Genpd do knows about the device but it doesn’t get a notification to power off. There are no issues whatsoever for driver. This is a somewhat special case. Let's go through an example. 1. The PM domain is initially in powered off state. 2. The bus -probe() invokes dev_pm_domain_attach() and then the PM domain gets attached to the device. 3. $subject patch causes the PM domain to power on. 4. A driver -probe() sequence start, following the Scenario 5). 5. The device is initially in runtime PM suspended state and it will remain so during -probe(). 6. The pm_request_idle() invoked after really_probe() in driver core, won't trigger a runtime PM suspend callback to be invoked. In other words, genpd don't get a notification that it may power off. In this state, genpd will either power off from the late_initcall, genpd_poweroff_unused() (depending on when the driver was probed) or wait until some device's runtime PM suspend callback is invoked at any later point. if I understand things right (thanks to Russell), the Power domain may not be powered off not only in above case, but also in some cases when driver is unloaded. AMBA bus for example: static int amba_remove(struct device *dev) { pm_runtime_get_sync(dev); -- GPD=on, dev is active, usage_count = 1 ret = drv-remove(pcdev); --- GPD=on, should do balancing put() to compensate all get() made by driver, usage_count == 1 --- GPD=on, should do balancing get() to compensate put() in probe, usage_count == 2 pm_runtime_put_noidle(dev); -- GPD=on, dev is active, usage_count == 1 /* Undo the runtime PM settings in amba_probe() */ pm_runtime_disable(dev); -- GPD=on, dev is active, usage_count == 1 pm_runtime_set_suspended(dev); -- GPD=on, dev is suspended, usage_count == 1 pm_runtime_put_noidle(dev); -- GPD=on, dev is suspended, usage_count == 0 amba_put_disable_pclk(pcdev); dev_pm_domain_detach(dev, true); -- GPD=on, dev is suspended, usage_count == 0 For the generic OF-based PM domain look-up case: -dev_pm_domain_detach() -genpd_dev_pm_detach() - to remove the device from the PM domain. -genpd_queue_power_off_work() - to power off unused PM domains. That does the trick, right!? Kind regards Uffe -- 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 PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers
On 11/20/2014 11:24 AM, Inki Dae wrote: This patch makes kms drivers to be independent drivers. For this, it removes all register codes to kms drivers from exynos_drm_drv module and adds module_init/exit for each kms driver so that each kms driver can be called independently. Changelog v3: - Use module_platform_driver macro instead module_init/exit. - Configure all kms drivers to be built in kernel image. Changelog v2: - none Signed-off-by: Inki Dae inki@samsung.com --- drivers/gpu/drm/exynos/exynos_dp_core.c |2 ++ drivers/gpu/drm/exynos/exynos_drm_drv.c | 43 +++--- drivers/gpu/drm/exynos/exynos_drm_drv.h |5 drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 ++ drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++ drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++ drivers/gpu/drm/exynos/exynos_mixer.c|2 ++ 7 files changed, 13 insertions(+), 45 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index ed818b9..30ebf5d 100644 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c @@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = { }, }; +module_platform_driver(dp_driver); If you try to build exynosdrm as module you will receive errors due to multiple definitions of init_module, ie module_init/module_*_driver macros can be used once per module. Anyway I am afraid exynosdrm seems to be still fragile to order of successful probes of their components. It can be easily observed on the system with two display pipelines with one of them probe deferring. For example universal with fimd/dpi + vidi: 1. fimd defers probe because panel is not yet probed. 2. vidi probes ok. 3. drmdev is initialized. 4. fimd probes ok, but it is too late!!! So you can reproduce the scenario on any target when one of the components defers and vidi is present (vidi never defers I suppose). Regards Andrzej + MODULE_AUTHOR(Jingoo Han jg1@samsung.com); MODULE_DESCRIPTION(Samsung SoC DP Driver); MODULE_LICENSE(GPL v2); diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index eab12f0..02d4772 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -484,12 +484,6 @@ static struct component_match *exynos_drm_match_add(struct device *dev) mutex_lock(drm_component_lock); - /* Do not retry to probe if there is no any kms driver regitered. */ - if (list_empty(drm_component_list)) { - mutex_unlock(drm_component_lock); - return ERR_PTR(-ENODEV); - } - list_for_each_entry(cdev, drm_component_list, list) { /* * Add components to master only in case that crtc and @@ -545,22 +539,6 @@ static const struct component_master_ops exynos_drm_ops = { .unbind = exynos_drm_unbind, }; -static struct platform_driver *const exynos_drm_kms_drivers[] = { -#ifdef CONFIG_DRM_EXYNOS_FIMD - fimd_driver, -#endif -#ifdef CONFIG_DRM_EXYNOS_DP - dp_driver, -#endif -#ifdef CONFIG_DRM_EXYNOS_DSI - dsi_driver, -#endif -#ifdef CONFIG_DRM_EXYNOS_HDMI - mixer_driver, - hdmi_driver, -#endif -}; - static struct platform_driver *const exynos_drm_non_kms_drivers[] = { #ifdef CONFIG_DRM_EXYNOS_G2D g2d_driver, @@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32); exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls); - for (i = 0; i ARRAY_SIZE(exynos_drm_kms_drivers); ++i) { - ret = platform_driver_register(exynos_drm_kms_drivers[i]); - if (ret 0) - goto err_unregister_kms_drivers; - } - match = exynos_drm_match_add(pdev-dev); - if (IS_ERR(match)) { - ret = PTR_ERR(match); - goto err_unregister_kms_drivers; - } + if (IS_ERR(match)) + return PTR_ERR(match); ret = component_master_add_with_match(pdev-dev, exynos_drm_ops, match); if (ret 0) - goto err_unregister_kms_drivers; + return ret; for (j = 0; j ARRAY_SIZE(exynos_drm_non_kms_drivers); ++j) { ret = platform_driver_register(exynos_drm_non_kms_drivers[j]); @@ -632,10 +602,6 @@ err_unregister_non_kms_drivers: err_del_component_master: component_master_del(pdev-dev, exynos_drm_ops); -err_unregister_kms_drivers: - while (--i = 0) - platform_driver_unregister(exynos_drm_kms_drivers[i]); - return ret; } @@ -654,9 +620,6 @@ static int exynos_drm_platform_remove(struct platform_device *pdev) component_master_del(pdev-dev, exynos_drm_ops); - for (i =
[PATCH 0/2] Add regulator-haptic driver
This patch series adds regulator-haptic driver. The regulator-haptic has haptic motor and it is controlled by voltage of regulator via force feedback framework. Jaewon Kim (2): Input: add regulator haptic driver ARM: dts: Add regulator-haptic device node for exynos3250-rinato .../devicetree/bindings/input/regulator-haptic.txt | 24 ++ arch/arm/boot/dts/exynos3250-rinato.dts|7 + drivers/input/misc/Kconfig | 11 + drivers/input/misc/Makefile|1 + drivers/input/misc/regulator-haptic.c | 241 5 files changed, 284 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/regulator-haptic.txt create mode 100644 drivers/input/misc/regulator-haptic.c -- 1.7.9.5 -- 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 2/2] ARM: dts: Add regulator-haptic device node for exynos3250-rinato
This patch adds regulator-haptic device node controlled by regulator. Signed-off-by: Jaewon Kim jaewon02@samsung.com --- arch/arm/boot/dts/exynos3250-rinato.dts |7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/exynos3250-rinato.dts b/arch/arm/boot/dts/exynos3250-rinato.dts index 84380fa..8172815 100644 --- a/arch/arm/boot/dts/exynos3250-rinato.dts +++ b/arch/arm/boot/dts/exynos3250-rinato.dts @@ -104,6 +104,13 @@ }; }; }; + + regulator-haptic { + compatible = regulator-haptic; + haptic-supply = motor_reg; + min-microvolt = 110; + max-microvolt = 270; + }; }; adc { -- 1.7.9.5 -- 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 1/2] Input: add regulator haptic driver
This patch adds support for haptic driver controlled by voltage of regulator. And this driver support for Force Feedback interface from input framework Signed-off-by: Jaewon Kim jaewon02@samsung.com Signed-off-by: Hyunhee Kim hyunhee@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/input/regulator-haptic.txt | 24 ++ drivers/input/misc/Kconfig | 11 + drivers/input/misc/Makefile|1 + drivers/input/misc/regulator-haptic.c | 241 4 files changed, 277 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/regulator-haptic.txt create mode 100644 drivers/input/misc/regulator-haptic.c diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt b/Documentation/devicetree/bindings/input/regulator-haptic.txt new file mode 100644 index 000..9f60e17 --- /dev/null +++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt @@ -0,0 +1,24 @@ +* Requlator Haptic Device Tree Bindings + +The regulator haptic driver controlled by voltage of regulator. +This driver implemented via Force Feedback interface. + +Required Properties: + - compatible : Should be regulator-haptic + - haptic-supply : Power supply for the haptic motor. + [*] refer Documentation/devicetree/bindings/regulator/regulator.txt + + - max-microvolt : The maximum voltage value supplied to haptic motor. + [The unit of the voltage is a micro] + + - min-microvolt : The minimum voltage value in which haptic motor reacts. + [The unit of the voltage is a micro] + +Example: + + regulator-haptic { + compatible = regulator-haptic; + haptic-supply = motor_regulator; + max-microvolt = 270; + min-microvolt = 110; + }; diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 23297ab..e5e556d 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -394,6 +394,17 @@ config INPUT_CM109 To compile this driver as a module, choose M here: the module will be called cm109. +config INPUT_REGULATOR_HAPTIC + tristate regulator haptics support + select INPUT_FF_MEMLESS + help + This option enables device driver support for the haptic controlled + by regulator. This driver supports ff-memless interface + from input framework. + + To compile this driver as a module, choose M here: the + module will be called regulator-haptic. + config INPUT_RETU_PWRBUTTON tristate Retu Power button Driver depends on MFD_RETU diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile index 19c7603..1f135af 100644 --- a/drivers/input/misc/Makefile +++ b/drivers/input/misc/Makefile @@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o obj-$(CONFIG_INPUT_POWERMATE) += powermate.o obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o +obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o diff --git a/drivers/input/misc/regulator-haptic.c b/drivers/input/misc/regulator-haptic.c new file mode 100644 index 000..1a83ecb --- /dev/null +++ b/drivers/input/misc/regulator-haptic.c @@ -0,0 +1,241 @@ +/* + * Regulator haptic driver + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * Author: Jaewon Kim jaewon02@samsung.com + * Author: Hyunhee Kim hyunhee@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/input.h +#include linux/slab.h +#include linux/regulator/consumer.h +#include linux/of.h + +#define MAX_MAGNITUDE_SHIFT16 + +struct regulator_haptic { + struct device *dev; + struct input_dev *input_dev; + struct regulator *regulator; + struct work_struct work; + + bool enabled; + bool suspend_state; + unsigned int max_volt; + unsigned int min_volt; + unsigned int intensity; + unsigned int magnitude; +}; + +static void regulator_haptic_enable(struct regulator_haptic *haptic) +{ + int error; + + if (haptic-enabled) + return; + + error = regulator_enable(haptic-regulator); + if (error) { + dev_err(haptic-dev, cannot enable regulator\n); + return; + } + + haptic-enabled = true; +} + +static void regulator_haptic_disable(struct regulator_haptic *haptic) +{ + int error; + + if (!haptic-enabled) +
Re: [RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers
On 2014년 11월 20일 22:19, Andrzej Hajda wrote: On 11/20/2014 11:24 AM, Inki Dae wrote: This patch makes kms drivers to be independent drivers. For this, it removes all register codes to kms drivers from exynos_drm_drv module and adds module_init/exit for each kms driver so that each kms driver can be called independently. Changelog v3: - Use module_platform_driver macro instead module_init/exit. - Configure all kms drivers to be built in kernel image. Changelog v2: - none Signed-off-by: Inki Dae inki@samsung.com --- drivers/gpu/drm/exynos/exynos_dp_core.c |2 ++ drivers/gpu/drm/exynos/exynos_drm_drv.c | 43 +++--- drivers/gpu/drm/exynos/exynos_drm_drv.h |5 drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 ++ drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++ drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++ drivers/gpu/drm/exynos/exynos_mixer.c|2 ++ 7 files changed, 13 insertions(+), 45 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index ed818b9..30ebf5d 100644 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c @@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = { }, }; +module_platform_driver(dp_driver); If you try to build exynosdrm as module you will receive errors due to multiple definitions of init_module, ie module_init/module_*_driver macros can be used once per module. Ah, right. we had ever tried same way before but failed in same problem. I didn't realize that. Anyway, I will try to find out a better way. I'd really like to remove all register codes of sub drivers from exynos_drm_drv somehow. Anyway I am afraid exynosdrm seems to be still fragile to order of successful probes of their components. It can be easily observed on the system with two display pipelines with one of them probe deferring. For example universal with fimd/dpi + vidi: 1. fimd defers probe because panel is not yet probed. 2. vidi probes ok. 3. drmdev is initialized. 4. fimd probes ok, but it is too late!!! So you can reproduce the scenario on any target when one of the components defers and vidi is present (vidi never defers I suppose). Thanks for checking, Inki Dae Regards Andrzej + MODULE_AUTHOR(Jingoo Han jg1@samsung.com); MODULE_DESCRIPTION(Samsung SoC DP Driver); MODULE_LICENSE(GPL v2); diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index eab12f0..02d4772 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -484,12 +484,6 @@ static struct component_match *exynos_drm_match_add(struct device *dev) mutex_lock(drm_component_lock); -/* Do not retry to probe if there is no any kms driver regitered. */ -if (list_empty(drm_component_list)) { -mutex_unlock(drm_component_lock); -return ERR_PTR(-ENODEV); -} - list_for_each_entry(cdev, drm_component_list, list) { /* * Add components to master only in case that crtc and @@ -545,22 +539,6 @@ static const struct component_master_ops exynos_drm_ops = { .unbind = exynos_drm_unbind, }; -static struct platform_driver *const exynos_drm_kms_drivers[] = { -#ifdef CONFIG_DRM_EXYNOS_FIMD -fimd_driver, -#endif -#ifdef CONFIG_DRM_EXYNOS_DP -dp_driver, -#endif -#ifdef CONFIG_DRM_EXYNOS_DSI -dsi_driver, -#endif -#ifdef CONFIG_DRM_EXYNOS_HDMI -mixer_driver, -hdmi_driver, -#endif -}; - static struct platform_driver *const exynos_drm_non_kms_drivers[] = { #ifdef CONFIG_DRM_EXYNOS_G2D g2d_driver, @@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32); exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls); -for (i = 0; i ARRAY_SIZE(exynos_drm_kms_drivers); ++i) { -ret = platform_driver_register(exynos_drm_kms_drivers[i]); -if (ret 0) -goto err_unregister_kms_drivers; -} - match = exynos_drm_match_add(pdev-dev); -if (IS_ERR(match)) { -ret = PTR_ERR(match); -goto err_unregister_kms_drivers; -} +if (IS_ERR(match)) +return PTR_ERR(match); ret = component_master_add_with_match(pdev-dev, exynos_drm_ops, match); if (ret 0) -goto err_unregister_kms_drivers; +return ret; for (j = 0; j ARRAY_SIZE(exynos_drm_non_kms_drivers); ++j) { ret = platform_driver_register(exynos_drm_non_kms_drivers[j]); @@ -632,10 +602,6 @@ err_unregister_non_kms_drivers: err_del_component_master: component_master_del(pdev-dev, exynos_drm_ops); -err_unregister_kms_drivers: -while (--i = 0)
Re: [RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers
Hello Inki, On Thu, Nov 20, 2014 at 2:56 PM, Inki Dae inki@samsung.com wrote: If you try to build exynosdrm as module you will receive errors due to multiple definitions of init_module, ie module_init/module_*_driver macros can be used once per module. Ah, right. we had ever tried same way before but failed in same problem. I didn't realize that. Anyway, I will try to find out a better way. I'd really like to remove all register codes of sub drivers from exynos_drm_drv somehow. Maybe as an immediate fix we can move the platform driver registration out of probe as suggested by Andrzej? I posted an RFC patch a couple of days ago [0] that fixes both the deadlock and the infinite loop bug so it would be great if you can review/test so I can post a proper patch. And then we can look how to better refactor the exynos drm driver. Best regards, Javier [0]: http://www.spinics.net/lists/linux-samsung-soc/msg39106.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: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi Javier, On 2014년 11월 18일 22:53, Javier Martinez Canillas wrote: The Exynos DRM driver register its sub-devices platform drivers in the probe function but after commit 43c0767 (of/platform: Move platform devices under /sys/devices/platform), this is causing a deadlock in __driver_attach(). Fix this by moving the platform drivers registration to exynos_drm_init(). Could you re-base this patch on top of exynos-drm-next? I tried to separate sub drivers into independent drivers but it seems that we need more times. So I will merge your patch. Thanks, Inki Dae Suggested-by: Andrzej Hajda a.ha...@samsung.com Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- This issue was reported by both Krzysztof Kozlowski [0] and Kevin Hilman [1]. Inki Dae said that he will fix it property by separating the Exynos DRM driver in different sub-modules but I post this patch as RFC anyways so others can test if this fixes their boot issue. [0]: https://lkml.org/lkml/2014/11/6/125 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39050.html drivers/gpu/drm/exynos/exynos_drm_drv.c | 163 1 file changed, 79 insertions(+), 84 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index e277d4f..5386fea 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -559,15 +559,58 @@ static const struct component_master_ops exynos_drm_ops = { static int exynos_drm_platform_probe(struct platform_device *pdev) { struct component_match *match; - int ret; pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32); exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls); + match = exynos_drm_match_add(pdev-dev); + if (IS_ERR(match)) + return PTR_ERR(match); + + return component_master_add_with_match(pdev-dev, exynos_drm_ops, +match); +} + +static int exynos_drm_platform_remove(struct platform_device *pdev) +{ + component_master_del(pdev-dev, exynos_drm_ops); + return 0; +} + +static struct platform_driver exynos_drm_platform_driver = { + .probe = exynos_drm_platform_probe, + .remove = exynos_drm_platform_remove, + .driver = { + .name = exynos-drm, + .pm = exynos_drm_pm_ops, + }, +}; + +static int exynos_drm_init(void) +{ + int ret; + + /* + * Register device object only in case of Exynos SoC. + * + * Below codes resolves temporarily infinite loop issue incurred + * by Exynos drm driver when using multi-platform kernel. + * So these codes will be replaced with more generic way later. + */ + if (!of_machine_is_compatible(samsung,exynos3) + !of_machine_is_compatible(samsung,exynos4) + !of_machine_is_compatible(samsung,exynos5)) + return -ENODEV; + + exynos_drm_pdev = platform_device_register_simple(exynos-drm, -1, + NULL, 0); + if (IS_ERR(exynos_drm_pdev)) + return PTR_ERR(exynos_drm_pdev); + #ifdef CONFIG_DRM_EXYNOS_FIMD ret = platform_driver_register(fimd_driver); if (ret 0) - return ret; + goto err_unregister_pdev; #endif #ifdef CONFIG_DRM_EXYNOS_DP @@ -591,21 +634,10 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) goto err_unregister_mixer_drv; #endif - match = exynos_drm_match_add(pdev-dev); - if (IS_ERR(match)) { - ret = PTR_ERR(match); - goto err_unregister_hdmi_drv; - } - - ret = component_master_add_with_match(pdev-dev, exynos_drm_ops, - match); - if (ret 0) - goto err_unregister_hdmi_drv; - #ifdef CONFIG_DRM_EXYNOS_G2D ret = platform_driver_register(g2d_driver); if (ret 0) - goto err_del_component_master; + goto err_unregister_hdmi_drv; #endif #ifdef CONFIG_DRM_EXYNOS_FIMC @@ -636,9 +668,27 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) goto err_unregister_ipp_drv; #endif - return ret; +#ifdef CONFIG_DRM_EXYNOS_VIDI + ret = exynos_drm_probe_vidi(); + if (ret 0) + goto err_unregister_ipp_dev; +#endif + + ret = platform_driver_register(exynos_drm_platform_driver); + if (ret) + goto err_remove_vidi; + + return 0; + +err_remove_vidi: +#ifdef CONFIG_DRM_EXYNOS_VIDI + exynos_drm_remove_vidi(); +err_unregister_pd: +#endif #ifdef CONFIG_DRM_EXYNOS_IPP +err_unregister_ipp_dev: + exynos_platform_device_ipp_unregister(); err_unregister_ipp_drv: platform_driver_unregister(ipp_driver);
Re: [RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers
Hi Javier, On 2014년 11월 20일 23:06, Javier Martinez Canillas wrote: Hello Inki, On Thu, Nov 20, 2014 at 2:56 PM, Inki Dae inki@samsung.com wrote: If you try to build exynosdrm as module you will receive errors due to multiple definitions of init_module, ie module_init/module_*_driver macros can be used once per module. Ah, right. we had ever tried same way before but failed in same problem. I didn't realize that. Anyway, I will try to find out a better way. I'd really like to remove all register codes of sub drivers from exynos_drm_drv somehow. Maybe as an immediate fix we can move the platform driver registration out of probe as suggested by Andrzej? I posted an RFC patch a couple of days ago [0] that fixes both the deadlock and the infinite loop bug so it would be great if you can review/test so I can post a proper patch. Fantastical timing.:) I gave you a same opinion almost simultaneous. Check your email thread. Thanks, Inki Dae And then we can look how to better refactor the exynos drm driver. Best regards, Javier [0]: http://www.spinics.net/lists/linux-samsung-soc/msg39106.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: [RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers
On 11/20/2014 02:56 PM, Inki Dae wrote: On 2014년 11월 20일 22:19, Andrzej Hajda wrote: On 11/20/2014 11:24 AM, Inki Dae wrote: This patch makes kms drivers to be independent drivers. For this, it removes all register codes to kms drivers from exynos_drm_drv module and adds module_init/exit for each kms driver so that each kms driver can be called independently. Changelog v3: - Use module_platform_driver macro instead module_init/exit. - Configure all kms drivers to be built in kernel image. Changelog v2: - none Signed-off-by: Inki Dae inki@samsung.com --- drivers/gpu/drm/exynos/exynos_dp_core.c |2 ++ drivers/gpu/drm/exynos/exynos_drm_drv.c | 43 +++--- drivers/gpu/drm/exynos/exynos_drm_drv.h |5 drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 ++ drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++ drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++ drivers/gpu/drm/exynos/exynos_mixer.c|2 ++ 7 files changed, 13 insertions(+), 45 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index ed818b9..30ebf5d 100644 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c @@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = { }, }; +module_platform_driver(dp_driver); If you try to build exynosdrm as module you will receive errors due to multiple definitions of init_module, ie module_init/module_*_driver macros can be used once per module. Ah, right. we had ever tried same way before but failed in same problem. I didn't realize that. Anyway, I will try to find out a better way. I'd really like to remove all register codes of sub drivers from exynos_drm_drv somehow. I have proposed once solution with sparse arrays, using linker scripts [1]. Something similar is used with clock controllers as I remember. I do not see other possibilities to fully separate components of exynos_drm_drv. [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/103816 Regards Andrzej Anyway I am afraid exynosdrm seems to be still fragile to order of successful probes of their components. It can be easily observed on the system with two display pipelines with one of them probe deferring. For example universal with fimd/dpi + vidi: 1. fimd defers probe because panel is not yet probed. 2. vidi probes ok. 3. drmdev is initialized. 4. fimd probes ok, but it is too late!!! So you can reproduce the scenario on any target when one of the components defers and vidi is present (vidi never defers I suppose). Thanks for checking, Inki Dae Regards Andrzej + MODULE_AUTHOR(Jingoo Han jg1@samsung.com); MODULE_DESCRIPTION(Samsung SoC DP Driver); MODULE_LICENSE(GPL v2); diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index eab12f0..02d4772 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -484,12 +484,6 @@ static struct component_match *exynos_drm_match_add(struct device *dev) mutex_lock(drm_component_lock); - /* Do not retry to probe if there is no any kms driver regitered. */ - if (list_empty(drm_component_list)) { - mutex_unlock(drm_component_lock); - return ERR_PTR(-ENODEV); - } - list_for_each_entry(cdev, drm_component_list, list) { /* * Add components to master only in case that crtc and @@ -545,22 +539,6 @@ static const struct component_master_ops exynos_drm_ops = { .unbind = exynos_drm_unbind, }; -static struct platform_driver *const exynos_drm_kms_drivers[] = { -#ifdef CONFIG_DRM_EXYNOS_FIMD - fimd_driver, -#endif -#ifdef CONFIG_DRM_EXYNOS_DP - dp_driver, -#endif -#ifdef CONFIG_DRM_EXYNOS_DSI - dsi_driver, -#endif -#ifdef CONFIG_DRM_EXYNOS_HDMI - mixer_driver, - hdmi_driver, -#endif -}; - static struct platform_driver *const exynos_drm_non_kms_drivers[] = { #ifdef CONFIG_DRM_EXYNOS_G2D g2d_driver, @@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32); exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls); - for (i = 0; i ARRAY_SIZE(exynos_drm_kms_drivers); ++i) { - ret = platform_driver_register(exynos_drm_kms_drivers[i]); - if (ret 0) - goto err_unregister_kms_drivers; - } - match = exynos_drm_match_add(pdev-dev); - if (IS_ERR(match)) { - ret = PTR_ERR(match); - goto err_unregister_kms_drivers; - } + if (IS_ERR(match)) + return PTR_ERR(match); ret = component_master_add_with_match(pdev-dev, exynos_drm_ops, match); if (ret 0) - goto err_unregister_kms_drivers; + return ret; for (j = 0; j
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
On 20 November 2014 15:22, Vivek Gautam gautamvivek1...@gmail.com wrote: Hi Javier, On Thu, Nov 20, 2014 at 2:15 PM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Hello Vivek, On 11/20/2014 08:51 AM, Vivek Gautam wrote: I tested linux-next on Exynos5800 peach-pi board with linux-next and and the two patches $Subject and [0]. Below is my git hash: 4d9e6ee drm/exynos: Move platform drivers registration to module init 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36391a5 Add linux-next specific files for 20141119 9b1ced1 Merge branch 'akpm/master' 282497e mm: add strictlimit knob used exynos_defconfig Same here. With this display works for me. Without $Subject patch i get lookup in drm. I tested with today linux-next (next-20141120) and display is indeed working for me. So it seems that whatever caused the error in the phy-exynos-mipi-video driver reported by Paolo, got fixed recently. My working git hash is: 65a8d01 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy a9b43cb drm/exynos: Move platform drivers registration to module init 5b83d7a Add linux-next specific files for 20141120 1172916 mm: add strictlimit knob I did have to disable CONFIG_SND_SOC_SNOW though, otherwise the kernel did not boot due the issue reported previously by Kevin. Javier can you tell me your git hash. Was it on yesterday's linux-next ? In fact, my branch where I could reproduce the phy-exynos-mipi-video issue was not based on yesterday's next but next-20141117. The git hash is: 9fb5d7c arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy f740096 drm/exynos: Move platform drivers registration to module init efefb5c Add linux-next specific files for 20141117 8c944d7 mm: add strictlimit knob With 3.18-rc5 i could see display on Exynos5800 peach-pi with following git hash: b6dca11 drm/exynos: dp: Remove support for unused dptx-phy 7cc5c2d ARM: exynos_defconfig: Enable options for display panel support d0aca5e arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy fc14f9c Linux 3.18-rc5 e35c5a2 Merge tag 'armsoc-for-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc I don't need this drm lockup patch with 3.18-rc5 (with exynos_defconfig). Yes, that works because the commit that caused the Exynos DRM lockup was: 43c0767 (of/platform: Move platform devices under /sys/devices/platform) which landed in next-20141105. Reverting 43c0767 and only applying [0] should have the same effect. I am checking further with linux-samsung, coz i could see weird behavior as mentioned in [1] with linux-samsun/for-next merged with above git hash. Great, it should be good to know what caused: On linux-samsung tree the only patch that's missing apart from dptx-phy patches is the syscon patch from Pankaj Dubey: b784b98 mfd: syscon: Decouple syscon interface from platform devices This patch has landed in mfd/for-next and linux-next. Without this on kgene/for-next, any driver seeking PMU register via syscon API will fail to get regmap handles. Thanks, Pankaj Dubey So with below git hash, linux-samsung/for-next display works fine along with other devices that request PMU system controller : 7bd219e drm/exynos: dp: Remove support for unused dptx-phy e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 7099bde Revert Revert ARM: exynos_defconfig: Enable options for display panel support 713a994 mfd: syscon: Decouple syscon interface from platform devices 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support /* This is Kukjin's for-next today */ ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow fc14f9c Linux 3.18-rc5 exynos-mipi-video-phy 10040714.video-phy: can't request region for resource [mem 0x10040714-0x1004071f] The only reason i see this fails is since PMU is now requesting the entire memory region with base 0x1004. We should convert the mipi-phy pmu register handling too through syscon. even when I could not reproduce it anymore with today's linux-next. [0]: https://lkml.org/lkml/2014/10/30/394 [1]: http://www.spinics.net/lists/linux-samsung-soc/msg39032.html -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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
[PATCH 2/2] ARM: dts: Add max77693-haptic node for exynos4412-trats2
This patch adds max77693-haptic node to support for haptic motor driver. Signed-off-by: Jaewon Kim jaewon02@samsung.com --- arch/arm/boot/dts/exynos4412-trats2.dts |6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts index 72462e8..8ddebbc 100644 --- a/arch/arm/boot/dts/exynos4412-trats2.dts +++ b/arch/arm/boot/dts/exynos4412-trats2.dts @@ -543,6 +543,12 @@ regulator-max-microamp = 258; }; }; + + max77693_haptic { + compatible = maxim,max77693-haptic; + haptic-supply = ldo26_reg; + pwms = pwm 0 38022 0; + }; }; }; -- 1.7.9.5 -- 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 1/2] ARM: dts: add pwm node for exynos4412-trats2
This patch add PWM(Pulse Width Modulation) node and handle to use pwm property. Signed-off-by: Jaewon Kim jaewon02@samsung.com --- arch/arm/boot/dts/exynos4412-trats2.dts |7 +++ 1 file changed, 7 insertions(+) diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts b/arch/arm/boot/dts/exynos4412-trats2.dts index 8ee20bd..72462e8 100644 --- a/arch/arm/boot/dts/exynos4412-trats2.dts +++ b/arch/arm/boot/dts/exynos4412-trats2.dts @@ -636,6 +636,13 @@ }; }; + pwm: pwm@139D { + pinctrl-0 = pwm0_out; + pinctrl-names = default; + samsung,pwm-outputs = 0; + status = okay; + }; + dsi_0: dsi@11C8 { vddcore-supply = ldo8_reg; vddio-supply = ldo10_reg; -- 1.7.9.5 -- 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 PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Inki, On 11/20/2014 03:07 PM, Inki Dae wrote: Could you re-base this patch on top of exynos-drm-next? I tried to separate sub drivers into independent drivers but it seems that we need more times. So I will merge your patch. Sure, I'll rebase on top of exynos-drm-next and re-post so you can apply it. BTW, it would be great if exynos-drm-next is pulled in linux-next. That is what most people use to test integration issues so you can catch earlier any regression that may arise. You have to email Stephen Rothwell s...@canb.auug.org.au and point to your tree and branch and he will be able to add it to linux-next. Thanks, Inki Dae 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
Re: [PATCH 1/2] Input: add regulator haptic driver
Hi Jaewon, On 20 November 2014 19:01, Jaewon Kim jaewon02@samsung.com wrote: This patch adds support for haptic driver controlled by voltage of regulator. And this driver support for Force Feedback interface from input framework Signed-off-by: Jaewon Kim jaewon02@samsung.com Signed-off-by: Hyunhee Kim hyunhee@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/input/regulator-haptic.txt | 24 ++ drivers/input/misc/Kconfig | 11 + drivers/input/misc/Makefile|1 + drivers/input/misc/regulator-haptic.c | 241 4 files changed, 277 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/regulator-haptic.txt create mode 100644 drivers/input/misc/regulator-haptic.c diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt b/Documentation/devicetree/bindings/input/regulator-haptic.txt new file mode 100644 index 000..9f60e17 --- /dev/null +++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt @@ -0,0 +1,24 @@ +* Requlator Haptic Device Tree Bindings + +The regulator haptic driver controlled by voltage of regulator. +This driver implemented via Force Feedback interface. + +Required Properties: + - compatible : Should be regulator-haptic + - haptic-supply : Power supply for the haptic motor. + [*] refer Documentation/devicetree/bindings/regulator/regulator.txt + + - max-microvolt : The maximum voltage value supplied to haptic motor. + [The unit of the voltage is a micro] + + - min-microvolt : The minimum voltage value in which haptic motor reacts. + [The unit of the voltage is a micro] + +Example: + + regulator-haptic { + compatible = regulator-haptic; + haptic-supply = motor_regulator; + max-microvolt = 270; + min-microvolt = 110; + }; diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 23297ab..e5e556d 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -394,6 +394,17 @@ config INPUT_CM109 To compile this driver as a module, choose M here: the module will be called cm109. +config INPUT_REGULATOR_HAPTIC + tristate regulator haptics support + select INPUT_FF_MEMLESS + help + This option enables device driver support for the haptic controlled + by regulator. This driver supports ff-memless interface + from input framework. + + To compile this driver as a module, choose M here: the + module will be called regulator-haptic. + config INPUT_RETU_PWRBUTTON tristate Retu Power button Driver depends on MFD_RETU diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile index 19c7603..1f135af 100644 --- a/drivers/input/misc/Makefile +++ b/drivers/input/misc/Makefile @@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o obj-$(CONFIG_INPUT_POWERMATE) += powermate.o obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o +obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o diff --git a/drivers/input/misc/regulator-haptic.c b/drivers/input/misc/regulator-haptic.c new file mode 100644 index 000..1a83ecb --- /dev/null +++ b/drivers/input/misc/regulator-haptic.c @@ -0,0 +1,241 @@ +/* + * Regulator haptic driver + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * Author: Jaewon Kim jaewon02@samsung.com + * Author: Hyunhee Kim hyunhee@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/input.h +#include linux/slab.h +#include linux/regulator/consumer.h +#include linux/of.h + +#define MAX_MAGNITUDE_SHIFT16 + +struct regulator_haptic { + struct device *dev; + struct input_dev *input_dev; + struct regulator *regulator; + struct work_struct work; + + bool enabled; + bool suspend_state; + unsigned int max_volt; + unsigned int min_volt; + unsigned int intensity; + unsigned int magnitude; +}; + +static void regulator_haptic_enable(struct regulator_haptic *haptic) +{ + int error; + + if (haptic-enabled) + return; + + error = regulator_enable(haptic-regulator); + if (error) { + dev_err(haptic-dev, cannot enable
Re: [RFC PATCH v3 1/4] drm/exynos: make kms drivers to be independent drivers
On 2014년 11월 20일 23:23, Andrzej Hajda wrote: On 11/20/2014 02:56 PM, Inki Dae wrote: On 2014년 11월 20일 22:19, Andrzej Hajda wrote: On 11/20/2014 11:24 AM, Inki Dae wrote: This patch makes kms drivers to be independent drivers. For this, it removes all register codes to kms drivers from exynos_drm_drv module and adds module_init/exit for each kms driver so that each kms driver can be called independently. Changelog v3: - Use module_platform_driver macro instead module_init/exit. - Configure all kms drivers to be built in kernel image. Changelog v2: - none Signed-off-by: Inki Dae inki@samsung.com --- drivers/gpu/drm/exynos/exynos_dp_core.c |2 ++ drivers/gpu/drm/exynos/exynos_drm_drv.c | 43 +++--- drivers/gpu/drm/exynos/exynos_drm_drv.h |5 drivers/gpu/drm/exynos/exynos_drm_dsi.c |2 ++ drivers/gpu/drm/exynos/exynos_drm_fimd.c |2 ++ drivers/gpu/drm/exynos/exynos_hdmi.c |2 ++ drivers/gpu/drm/exynos/exynos_mixer.c|2 ++ 7 files changed, 13 insertions(+), 45 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index ed818b9..30ebf5d 100644 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c @@ -1408,6 +1408,8 @@ struct platform_driver dp_driver = { }, }; +module_platform_driver(dp_driver); If you try to build exynosdrm as module you will receive errors due to multiple definitions of init_module, ie module_init/module_*_driver macros can be used once per module. Ah, right. we had ever tried same way before but failed in same problem. I didn't realize that. Anyway, I will try to find out a better way. I'd really like to remove all register codes of sub drivers from exynos_drm_drv somehow. I have proposed once solution with sparse arrays, using linker scripts [1]. Something similar is used with clock controllers as I remember. I do not see other possibilities to fully separate components of exynos_drm_drv. [1]: http://permalink.gmane.org/gmane.comp.video.dri.devel/103816 I know this patch. I wasn't sure that the use of the private linker section is reasonable and overuse it. Actually, Mr. Park opposed this way. It might be a good idea if no problem for device drivers use the private linker section. Is there any device driver using the private linker section? Thanks, Inki Dae Regards Andrzej Anyway I am afraid exynosdrm seems to be still fragile to order of successful probes of their components. It can be easily observed on the system with two display pipelines with one of them probe deferring. For example universal with fimd/dpi + vidi: 1. fimd defers probe because panel is not yet probed. 2. vidi probes ok. 3. drmdev is initialized. 4. fimd probes ok, but it is too late!!! So you can reproduce the scenario on any target when one of the components defers and vidi is present (vidi never defers I suppose). Thanks for checking, Inki Dae Regards Andrzej + MODULE_AUTHOR(Jingoo Han jg1@samsung.com); MODULE_DESCRIPTION(Samsung SoC DP Driver); MODULE_LICENSE(GPL v2); diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index eab12f0..02d4772 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -484,12 +484,6 @@ static struct component_match *exynos_drm_match_add(struct device *dev) mutex_lock(drm_component_lock); - /* Do not retry to probe if there is no any kms driver regitered. */ - if (list_empty(drm_component_list)) { - mutex_unlock(drm_component_lock); - return ERR_PTR(-ENODEV); - } - list_for_each_entry(cdev, drm_component_list, list) { /* * Add components to master only in case that crtc and @@ -545,22 +539,6 @@ static const struct component_master_ops exynos_drm_ops = { .unbind = exynos_drm_unbind, }; -static struct platform_driver *const exynos_drm_kms_drivers[] = { -#ifdef CONFIG_DRM_EXYNOS_FIMD - fimd_driver, -#endif -#ifdef CONFIG_DRM_EXYNOS_DP - dp_driver, -#endif -#ifdef CONFIG_DRM_EXYNOS_DSI - dsi_driver, -#endif -#ifdef CONFIG_DRM_EXYNOS_HDMI - mixer_driver, - hdmi_driver, -#endif -}; - static struct platform_driver *const exynos_drm_non_kms_drivers[] = { #ifdef CONFIG_DRM_EXYNOS_G2D g2d_driver, @@ -587,22 +565,14 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32); exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls); - for (i = 0; i ARRAY_SIZE(exynos_drm_kms_drivers); ++i) { - ret = platform_driver_register(exynos_drm_kms_drivers[i]); - if (ret 0) - goto err_unregister_kms_drivers; - } - match = exynos_drm_match_add(pdev-dev); - if (IS_ERR(match)) { - ret = PTR_ERR(match); -
Re: [PATCH] PM / Domains: Power on the PM domain right after attach completes
On 11/20/2014 03:01 PM, Ulf Hansson wrote: On 20 November 2014 13:17, Grygorii Strashko grygorii.stras...@ti.com wrote: On 11/19/2014 10:54 AM, Ulf Hansson wrote: [...] Scenario 5), a platform driver with/without runtime PM callbacks. -probe() - do some initialization - may fetch handles to runtime PM resources - pm_runtime_enable() Well, and now how the driver knows if the device is on before accessing it? In this case the driver don't need to access the device during -probe(). That's postponed until sometime later. Note 1) Scenario 1) and 2), both relies on the approach to power on the PM domain by using pm_runtime_get_sync(). That approach didn't work when CONFIG_PM_RUNTIME was unset, but we recently decided to fixed that by the below patch, so that's good! [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled Note 2) Scenario 3) and 4) use the same principles for managing runtime PM. These scenarios needs a way to power on the generic PM domain prior probing the device. The call to pm_runtime_set_active(), prevents an already powered PM domain from power off until after probe, but that's not enough. Note 3) The $subject patch, tried to address the issues for scenario 3) and 4). It does so, but will affect scenario 5) which was working nicely before. In scenario 5), the $subject patch will cause the generic PM domain to potentially stay powered after -probe() even if the device is runtime PM suspended. Why would it? If the device is runtime-suspended, the domain will know that, because its callbacks will be used for that. At least, that's what I'd expect to happen, so is there a problem here? Genpd do knows about the device but it doesn’t get a notification to power off. There are no issues whatsoever for driver. This is a somewhat special case. Let's go through an example. 1. The PM domain is initially in powered off state. 2. The bus -probe() invokes dev_pm_domain_attach() and then the PM domain gets attached to the device. 3. $subject patch causes the PM domain to power on. 4. A driver -probe() sequence start, following the Scenario 5). 5. The device is initially in runtime PM suspended state and it will remain so during -probe(). 6. The pm_request_idle() invoked after really_probe() in driver core, won't trigger a runtime PM suspend callback to be invoked. In other words, genpd don't get a notification that it may power off. In this state, genpd will either power off from the late_initcall, genpd_poweroff_unused() (depending on when the driver was probed) or wait until some device's runtime PM suspend callback is invoked at any later point. if I understand things right (thanks to Russell), the Power domain may not be powered off not only in above case, but also in some cases when driver is unloaded. AMBA bus for example: static int amba_remove(struct device *dev) { pm_runtime_get_sync(dev); -- GPD=on, dev is active, usage_count = 1 ret = drv-remove(pcdev); --- GPD=on, should do balancing put() to compensate all get() made by driver, usage_count == 1 --- GPD=on, should do balancing get() to compensate put() in probe, usage_count == 2 pm_runtime_put_noidle(dev); -- GPD=on, dev is active, usage_count == 1 /* Undo the runtime PM settings in amba_probe() */ pm_runtime_disable(dev); -- GPD=on, dev is active, usage_count == 1 pm_runtime_set_suspended(dev); -- GPD=on, dev is suspended, usage_count == 1 pm_runtime_put_noidle(dev); -- GPD=on, dev is suspended, usage_count == 0 amba_put_disable_pclk(pcdev); dev_pm_domain_detach(dev, true); -- GPD=on, dev is suspended, usage_count == 0 For the generic OF-based PM domain look-up case: -dev_pm_domain_detach() -genpd_dev_pm_detach() - to remove the device from the PM domain. -genpd_queue_power_off_work() - to power off unused PM domains. That does the trick, right!? True. Thanks a lot for pointing me on right place. regards, -grygorii -- 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 1/2] Input: add regulator haptic driver
Hi On 11/20/2014 08:33 AM, Pankaj Dubey wrote: Hi Jaewon, On 20 November 2014 19:01, Jaewon Kim jaewon02@samsung.com wrote: This patch adds support for haptic driver controlled by voltage of regulator. And this driver support for Force Feedback interface from input framework Signed-off-by: Jaewon Kim jaewon02@samsung.com Signed-off-by: Hyunhee Kim hyunhee@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/input/regulator-haptic.txt | 24 ++ drivers/input/misc/Kconfig | 11 + drivers/input/misc/Makefile|1 + drivers/input/misc/regulator-haptic.c | 241 4 files changed, 277 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/regulator-haptic.txt create mode 100644 drivers/input/misc/regulator-haptic.c diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt b/Documentation/devicetree/bindings/input/regulator-haptic.txt new file mode 100644 index 000..9f60e17 --- /dev/null +++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt @@ -0,0 +1,24 @@ +* Requlator Haptic Device Tree Bindings + +The regulator haptic driver controlled by voltage of regulator. +This driver implemented via Force Feedback interface. + +Required Properties: + - compatible : Should be regulator-haptic + - haptic-supply : Power supply for the haptic motor. + [*] refer Documentation/devicetree/bindings/regulator/regulator.txt + + - max-microvolt : The maximum voltage value supplied to haptic motor. + [The unit of the voltage is a micro] + + - min-microvolt : The minimum voltage value in which haptic motor reacts. + [The unit of the voltage is a micro] + +Example: + + regulator-haptic { Should this be more about the function and not the driver name? Somehting like haptics { + compatible = regulator-haptic; + haptic-supply = motor_regulator; + max-microvolt = 270; + min-microvolt = 110; + }; diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 23297ab..e5e556d 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -394,6 +394,17 @@ config INPUT_CM109 To compile this driver as a module, choose M here: the module will be called cm109. +config INPUT_REGULATOR_HAPTIC + tristate regulator haptics support + select INPUT_FF_MEMLESS + help + This option enables device driver support for the haptic controlled + by regulator. This driver supports ff-memless interface + from input framework. + + To compile this driver as a module, choose M here: the + module will be called regulator-haptic. + config INPUT_RETU_PWRBUTTON tristate Retu Power button Driver depends on MFD_RETU diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile index 19c7603..1f135af 100644 --- a/drivers/input/misc/Makefile +++ b/drivers/input/misc/Makefile @@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o obj-$(CONFIG_INPUT_POWERMATE) += powermate.o obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o +obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o diff --git a/drivers/input/misc/regulator-haptic.c b/drivers/input/misc/regulator-haptic.c new file mode 100644 index 000..1a83ecb --- /dev/null +++ b/drivers/input/misc/regulator-haptic.c @@ -0,0 +1,241 @@ +/* + * Regulator haptic driver + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * Author: Jaewon Kim jaewon02@samsung.com + * Author: Hyunhee Kim hyunhee@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/input.h +#include linux/slab.h +#include linux/regulator/consumer.h +#include linux/of.h + +#define MAX_MAGNITUDE_SHIFT16 + +struct regulator_haptic { + struct device *dev; + struct input_dev *input_dev; + struct regulator *regulator; + struct work_struct work; + + bool enabled; + bool suspend_state; I don't understand what you are tracking here. You only set it and unset this value but never do any checking + unsigned int max_volt; + unsigned int min_volt; + unsigned int intensity; + unsigned int magnitude; +}; + +static void
[PATCH 4/4] ARM: EXYNOS: cpuidle: allow driver usage on Exynos3250 SoC
Register cpuidle platform device on Exynos3250 SoC allowing EXYNOS cpuidle driver usage on this SoC. Cc: Daniel Lezcano daniel.lezc...@linaro.org Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-exynos/exynos.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c index 847cd0a..6efdbbe 100644 --- a/arch/arm/mach-exynos/exynos.c +++ b/arch/arm/mach-exynos/exynos.c @@ -297,6 +297,7 @@ static void __init exynos_dt_machine_init(void) of_machine_is_compatible(samsung,exynos4212) || (of_machine_is_compatible(samsung,exynos4412) of_machine_is_compatible(samsung,trats2)) || + of_machine_is_compatible(samsung,exynos3250) || of_machine_is_compatible(samsung,exynos5250)) platform_device_register(exynos_cpuidle); -- 1.8.2.3 -- 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 3/4] ARM: EXYNOS: cpuidle: add AFTR mode support for Exynos3250
Cc: Daniel Lezcano daniel.lezc...@linaro.org Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-exynos/firmware.c | 8 +++- arch/arm/mach-exynos/pm.c | 12 +++- arch/arm/mach-exynos/regs-pmu.h | 1 + arch/arm/mach-exynos/smc.h | 9 + 4 files changed, 28 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/firmware.c b/arch/arm/mach-exynos/firmware.c index 766f57d..4ceea16 100644 --- a/arch/arm/mach-exynos/firmware.c +++ b/arch/arm/mach-exynos/firmware.c @@ -47,7 +47,13 @@ static int exynos_do_idle(unsigned long mode) __raw_writel(virt_to_phys(exynos_cpu_resume_ns), sysram_ns_base_addr + 0x24); __raw_writel(EXYNOS_AFTR_MAGIC, sysram_ns_base_addr + 0x20); - exynos_smc(SMC_CMD_CPU0AFTR, 0, 0, 0); + if (soc_is_exynos3250()) { + exynos_smc(SMC_CMD_SAVE, OP_TYPE_CORE, + SMC_POWERSTATE_IDLE, 0); + exynos_smc(SMC_CMD_SHUTDOWN, OP_TYPE_CLUSTER, + SMC_POWERSTATE_IDLE, 0); + } else + exynos_smc(SMC_CMD_CPU0AFTR, 0, 0, 0); break; case FW_DO_IDLE_SLEEP: exynos_smc(SMC_CMD_SLEEP, 0, 0, 0); diff --git a/arch/arm/mach-exynos/pm.c b/arch/arm/mach-exynos/pm.c index 86f3ecd8..2dec90f 100644 --- a/arch/arm/mach-exynos/pm.c +++ b/arch/arm/mach-exynos/pm.c @@ -130,6 +130,8 @@ int exynos_pm_central_resume(void) static void exynos_set_wakeupmask(long mask) { pmu_raw_writel(mask, S5P_WAKEUP_MASK); + if (soc_is_exynos3250()) + pmu_raw_writel(0x0, S5P_WAKEUP_MASK2); } static void exynos_cpu_set_boot_vector(long flags) @@ -143,7 +145,7 @@ static int exynos_aftr_finisher(unsigned long flags) { int ret; - exynos_set_wakeupmask(0xff3e); + exynos_set_wakeupmask(soc_is_exynos3250() ? 0x40003ffe : 0xff3e); /* Set value of power down register for aftr mode */ exynos_sys_powerdown_conf(SYS_AFTR); @@ -160,8 +162,13 @@ static int exynos_aftr_finisher(unsigned long flags) void exynos_enter_aftr(void) { + unsigned int cpuid = smp_processor_id(); + cpu_pm_enter(); + if (soc_is_exynos3250()) + exynos_set_boot_flag(cpuid, C2_STATE); + exynos_pm_central_suspend(); cpu_suspend(0, exynos_aftr_finisher); @@ -174,5 +181,8 @@ void exynos_enter_aftr(void) exynos_pm_central_resume(); + if (soc_is_exynos3250()) + exynos_clear_boot_flag(cpuid, C2_STATE); + cpu_pm_exit(); } diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h index 77defeb..b095cce 100644 --- a/arch/arm/mach-exynos/regs-pmu.h +++ b/arch/arm/mach-exynos/regs-pmu.h @@ -43,6 +43,7 @@ #define S5P_WAKEUP_STAT0x0600 #define S5P_EINT_WAKEUP_MASK 0x0604 #define S5P_WAKEUP_MASK0x0608 +#define S5P_WAKEUP_MASK2 0x0614 #define S5P_INFORM00x0800 #define S5P_INFORM10x0804 diff --git a/arch/arm/mach-exynos/smc.h b/arch/arm/mach-exynos/smc.h index f7b82f9..27a976d 100644 --- a/arch/arm/mach-exynos/smc.h +++ b/arch/arm/mach-exynos/smc.h @@ -17,6 +17,8 @@ #define SMC_CMD_SLEEP (-3) #define SMC_CMD_CPU1BOOT (-4) #define SMC_CMD_CPU0AFTR (-5) +#define SMC_CMD_SAVE (-6) +#define SMC_CMD_SHUTDOWN (-7) /* For CP15 Access */ #define SMC_CMD_C15RESUME (-11) /* For L2 Cache Access */ @@ -32,4 +34,11 @@ extern void exynos_smc(u32 cmd, u32 arg1, u32 arg2, u32 arg3); #endif /* __ASSEMBLY__ */ +/* op type for SMC_CMD_SAVE and SMC_CMD_SHUTDOWN */ +#define OP_TYPE_CORE0x0 +#define OP_TYPE_CLUSTER 0x1 + +/* Power State required for SMC_CMD_SAVE and SMC_CMD_SHUTDOWN */ +#define SMC_POWERSTATE_IDLE 0x1 + #endif -- 1.8.2.3 -- 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 1/4] ARM: EXYNOS: fix CPU1 hotplug for AFTR mode on Exynos3250
CPU1 hotplug may hang when AFTR is used. Fix it by: - setting AUTOWAKEUP_EN bit in ARM_COREx_CONFIGURATION register in exynos_cpu_power_up() - not clearing reserved bits of ARM_COREx_CONFIGURATION register in exynos_cpu_power_down() - waiting while an undocumented register 0x0908 becomes non-zero in exynos_core_restart() Cc: Daniel Lezcano daniel.lezc...@linaro.org Signed-off-by: Chanwoo Choi cw00.c...@samsung.com Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-exynos/platsmp.c | 19 +-- arch/arm/mach-exynos/regs-pmu.h | 1 + 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c index 7a1ebfe..9f9d7cd 100644 --- a/arch/arm/mach-exynos/platsmp.c +++ b/arch/arm/mach-exynos/platsmp.c @@ -126,6 +126,8 @@ static inline void platform_do_lowpower(unsigned int cpu, int *spurious) */ void exynos_cpu_power_down(int cpu) { + u32 core_conf; + if (cpu == 0 (of_machine_is_compatible(samsung,exynos5420) || of_machine_is_compatible(samsung,exynos5800))) { /* @@ -138,7 +140,10 @@ void exynos_cpu_power_down(int cpu) if (!(val S5P_CORE_LOCAL_PWR_EN)) return; } - pmu_raw_writel(0, EXYNOS_ARM_CORE_CONFIGURATION(cpu)); + + core_conf = pmu_raw_readl(EXYNOS_ARM_CORE_CONFIGURATION(cpu)); + core_conf = ~S5P_CORE_LOCAL_PWR_EN; + pmu_raw_writel(core_conf, EXYNOS_ARM_CORE_CONFIGURATION(cpu)); } /** @@ -149,7 +154,12 @@ void exynos_cpu_power_down(int cpu) */ void exynos_cpu_power_up(int cpu) { - pmu_raw_writel(S5P_CORE_LOCAL_PWR_EN, + u32 core_conf = S5P_CORE_LOCAL_PWR_EN; + + if (soc_is_exynos3250()) + core_conf |= S5P_CORE_AUTOWAKEUP_EN; + + pmu_raw_writel(core_conf, EXYNOS_ARM_CORE_CONFIGURATION(cpu)); } @@ -227,6 +237,11 @@ static void exynos_core_restart(u32 core_id) if (!of_machine_is_compatible(samsung,exynos3250)) return; + /* 0x0908 is an undocumented register */ + while (!pmu_raw_readl(0x0908)) + udelay(10); + udelay(10); + val = pmu_raw_readl(EXYNOS_ARM_CORE_STATUS(core_id)); val |= S5P_CORE_WAKEUP_FROM_LOCAL_CFG; pmu_raw_writel(val, EXYNOS_ARM_CORE_STATUS(core_id)); diff --git a/arch/arm/mach-exynos/regs-pmu.h b/arch/arm/mach-exynos/regs-pmu.h index b5f4406..77defeb 100644 --- a/arch/arm/mach-exynos/regs-pmu.h +++ b/arch/arm/mach-exynos/regs-pmu.h @@ -180,6 +180,7 @@ #define S5P_CORE_LOCAL_PWR_EN 0x3 #define S5P_CORE_WAKEUP_FROM_LOCAL_CFG (0x3 8) +#define S5P_CORE_AUTOWAKEUP_EN (1 31) /* Only for EXYNOS4210 */ #define S5P_CMU_CLKSTOP_LCD1_LOWPWR0x1154 -- 1.8.2.3 -- 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 2/4] ARM: EXYNOS: add code for setting/clearing boot flag
This code is needed for cpuidle (W-)AFTR mode support on Exynos3250. Cc: Daniel Lezcano daniel.lezc...@linaro.org Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- arch/arm/mach-exynos/common.h | 6 ++ arch/arm/mach-exynos/exynos.c | 25 + 2 files changed, 31 insertions(+) diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h index 431be1b..155f019 100644 --- a/arch/arm/mach-exynos/common.h +++ b/arch/arm/mach-exynos/common.h @@ -119,6 +119,12 @@ extern void __iomem *sysram_base_addr; extern void __iomem *pmu_base_addr; void exynos_sysram_init(void); +/* CPU BOOT mode flag */ +#define C2_STATE (1 3) + +void exynos_set_boot_flag(unsigned int cpu, unsigned int mode); +void exynos_clear_boot_flag(unsigned int cpu, unsigned int mode); + enum { FW_DO_IDLE_SLEEP, FW_DO_IDLE_AFTR, diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c index 8f638ad..847cd0a 100644 --- a/arch/arm/mach-exynos/exynos.c +++ b/arch/arm/mach-exynos/exynos.c @@ -148,6 +148,31 @@ static void __init exynos_init_late(void) exynos_pm_init(); } +#define REG_CPU_STATE_ADDR (sysram_ns_base_addr + 0x28) +#define BOOT_MODE_MASK 0x1f + +void exynos_set_boot_flag(unsigned int cpu, unsigned int mode) +{ + unsigned int tmp; + + tmp = __raw_readl(REG_CPU_STATE_ADDR + cpu * 4); + + if (mode BOOT_MODE_MASK) + tmp = ~BOOT_MODE_MASK; + + tmp |= mode; + __raw_writel(tmp, REG_CPU_STATE_ADDR + cpu * 4); +} + +void exynos_clear_boot_flag(unsigned int cpu, unsigned int mode) +{ + unsigned int tmp; + + tmp = __raw_readl(REG_CPU_STATE_ADDR + cpu * 4); + tmp = ~mode; + __raw_writel(tmp, REG_CPU_STATE_ADDR + cpu * 4); +} + static int __init exynos_fdt_map_chipid(unsigned long node, const char *uname, int depth, void *data) { -- 1.8.2.3 -- 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 0/4] ARM: EXYNOS: cpuidle: add AFTR mode support for Exynos3250
Hi, This patch series adds support for AFTR idle mode on boards with Exynos3250 SoC and allows EXYNOS cpuidle driver usage on these boards. It has been tested on Samsung Rinato board (Gear 2). Depends on: - for-next branch of linux-samsung.git kernel tree (or next-20141114 branch of linux-next kernel tree) - [PATCH v5] ARM: EXYNOS: add Exynos3250 PMU support (https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg39109.html) Best regards, -- Bartlomiej Zolnierkiewicz Samsung RD Institute Poland Samsung Electronics Bartlomiej Zolnierkiewicz (4): ARM: EXYNOS: fix CPU1 hotplug for AFTR mode on Exynos3250 ARM: EXYNOS: add code for setting/clearing boot flag ARM: EXYNOS: cpuidle: add AFTR mode support for Exynos3250 ARM: EXYNOS: cpuidle: allow driver usage on Exynos3250 SoC arch/arm/mach-exynos/common.h | 6 ++ arch/arm/mach-exynos/exynos.c | 26 ++ arch/arm/mach-exynos/firmware.c | 8 +++- arch/arm/mach-exynos/platsmp.c | 19 +-- arch/arm/mach-exynos/pm.c | 12 +++- arch/arm/mach-exynos/regs-pmu.h | 2 ++ arch/arm/mach-exynos/smc.h | 9 + 7 files changed, 78 insertions(+), 4 deletions(-) -- 1.8.2.3 -- 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 PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Inki, On 11/20/2014 04:06 PM, Inki Dae wrote: BTW, it would be great if exynos-drm-next is pulled in linux-next. That is what most people use to test integration issues so you can catch earlier any regression that may arise. You have to email Stephen Rothwell s...@canb.auug.org.au and point to your tree and branch and he will be able to add it to linux-next. Thanks for information. Actually, I received a similar email privately before. However, exynos-drm-next should go to drm-next first and than to mainline by Dave who is DRM subsystem maintainer. I think all vendor specific drm drivers would need to be checked by drm subsystem maintainer because these changes might be affect drm subsystem or other vendor specific drm drivers before go to mainline. This is orthogonal to the normal upstreaming path. linux-next is an integration tree that is created daily. So all the remote branches are merged and a git tag published. The branch does not get rebased and history is not preserved between two published linux-next tags. This is just to test the integration of different subsystems to be sure that a commit in one tree does not cause a regression in another one so issues can be spot earlier. For example in the case of $subject, a change in the OF caused a regression in the Exynos DRM driver. If needed, I will make a new branch, which is based on top of linux-next so other people can check their systems. You don't really need another branch, git will take care of merge everything in linux-next :) Thanks, Inki Dae 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
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
On Thu, Nov 20, 2014 at 03:22:23PM +0530, Vivek Gautam wrote: On linux-samsung tree the only patch that's missing apart from dptx-phy patches is the syscon patch from Pankaj Dubey: b784b98 mfd: syscon: Decouple syscon interface from platform devices So with below git hash, linux-samsung/for-next display works fine along with other devices that request PMU system controller : 7bd219e drm/exynos: dp: Remove support for unused dptx-phy e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 7099bde Revert Revert ARM: exynos_defconfig: Enable options for display panel support 713a994 mfd: syscon: Decouple syscon interface from platform devices 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support /* This is Kukjin's for-next today */ ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow fc14f9c Linux 3.18-rc5 are you using a clean exynos_defconfig? don't you need Javier's drm/exynos: Move platform drivers registration to module init patch too? kgene/for-next at: 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support plus: 5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36d908e drm/exynos: dp: Remove support for unused dptx-phy 624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices 68944e3 Revert Revert ARM: exynos_defconfig: Enable options for display panel support hangs with a black screen (albeit backlight seems to be on) on boot. I'm betting on Javier's patch at this point (i even tried disabling SND_SOC_SNOW but that didn't help). -- bye, p. -- 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] ARM: dts: Specify default clocks for Exynos4 camera devices
Specify the default mux and divider clocks in device tree to ensure the FIMC devices on Trats, Trats2, Universal_c210 and Odroid X2/U3 boards are clocked from recommended clock source and with maximum supported frequency. For Trats2 also the MIPI-CSIS and the camera sensor clocks are configured, the 'clock-frequency' property is deprecated in favour of 'assigned-clock-rates' property. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com --- arch/arm/boot/dts/exynos4210-trats.dts | 16 arch/arm/boot/dts/exynos4210-universal_c210.dts | 16 arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 16 arch/arm/boot/dts/exynos4412-trats2.dts | 32 --- 4 files changed, 77 insertions(+), 3 deletions(-) diff --git a/arch/arm/boot/dts/exynos4210-trats.dts b/arch/arm/boot/dts/exynos4210-trats.dts index f516da9..7208362 100644 --- a/arch/arm/boot/dts/exynos4210-trats.dts +++ b/arch/arm/boot/dts/exynos4210-trats.dts @@ -431,18 +431,34 @@ fimc_0: fimc@1180 { status = okay; + assigned-clocks = clock CLK_MOUT_FIMC0, + clock CLK_SCLK_FIMC0; + assigned-clock-parents = clock CLK_SCLK_MPLL; + assigned-clock-rates = 0, 16000; }; fimc_1: fimc@1181 { status = okay; + assigned-clocks = clock CLK_MOUT_FIMC1, + clock CLK_SCLK_FIMC1; + assigned-clock-parents = clock CLK_SCLK_MPLL; + assigned-clock-rates = 0, 16000; }; fimc_2: fimc@1182 { status = okay; + assigned-clocks = clock CLK_MOUT_FIMC2, + clock CLK_SCLK_FIMC2; + assigned-clock-parents = clock CLK_SCLK_MPLL; + assigned-clock-rates = 0, 16000; }; fimc_3: fimc@1183 { status = okay; + assigned-clocks = clock CLK_MOUT_FIMC3, + clock CLK_SCLK_FIMC3; + assigned-clock-parents = clock CLK_SCLK_MPLL; + assigned-clock-rates = 0, 16000; }; }; }; diff --git a/arch/arm/boot/dts/exynos4210-universal_c210.dts b/arch/arm/boot/dts/exynos4210-universal_c210.dts index d50eb3a..aaf0cae 100644 --- a/arch/arm/boot/dts/exynos4210-universal_c210.dts +++ b/arch/arm/boot/dts/exynos4210-universal_c210.dts @@ -473,18 +473,34 @@ fimc_0: fimc@1180 { status = okay; + assigned-clocks = clock CLK_MOUT_FIMC0, + clock CLK_SCLK_FIMC0; + assigned-clock-parents = clock CLK_SCLK_MPLL; + assigned-clock-rates = 0, 16000; }; fimc_1: fimc@1181 { status = okay; + assigned-clocks = clock CLK_MOUT_FIMC1, + clock CLK_SCLK_FIMC1; + assigned-clock-parents = clock CLK_SCLK_MPLL; + assigned-clock-rates = 0, 16000; }; fimc_2: fimc@1182 { status = okay; + assigned-clocks = clock CLK_MOUT_FIMC2, + clock CLK_SCLK_FIMC2; + assigned-clock-parents = clock CLK_SCLK_MPLL; + assigned-clock-rates = 0, 16000; }; fimc_3: fimc@1183 { status = okay; + assigned-clocks = clock CLK_MOUT_FIMC3, + clock CLK_SCLK_FIMC3; + assigned-clock-parents = clock CLK_SCLK_MPLL; + assigned-clock-rates = 0, 16000; }; }; }; diff --git a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi index c697ff0..adf1331 100644 --- a/arch/arm/boot/dts/exynos4412-odroid-common.dtsi +++ b/arch/arm/boot/dts/exynos4412-odroid-common.dtsi @@ -82,18 +82,34 @@ fimc_0: fimc@1180 { status = okay; + assigned-clocks = clock CLK_MOUT_FIMC0, + clock CLK_SCLK_FIMC0; + assigned-clock-parents = clock CLK_MOUT_MPLL_USER_T; + assigned-clock-rates = 0, 17600; }; fimc_1: fimc@1181 { status = okay; + assigned-clocks = clock CLK_MOUT_FIMC1, +
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hi Vivek, Vivek Gautam gautamvivek1...@gmail.com writes: [...] I tested linux-next on Exynos5800 peach-pi board with linux-next and and the two patches $Subject and [0]. Below is my git hash: 4d9e6ee drm/exynos: Move platform drivers registration to module init 4545ed4 POSTED: arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36391a5 Add linux-next specific files for 20141119 9b1ced1 Merge branch 'akpm/master' 282497e mm: add strictlimit knob With this display works for me. Without $Subject patch i get lookup in drm. The current linux-next (next-20141120) is still not fully booting for me. I do see the penguins come up on the display, but it doesn't finish booting. Full boot log below. I'm building using exynos_defconfig with CONFIG_SND_SOC_SNOW=n due to other errors previously reported. (Vivek, BTW, I'm curious how your peach-pi is booting with the audio support enabled.) Here's how I'm creating the tree, which appears to be the same as what you guys are doing, but just to be thorough: $ git reset --hard next/master HEAD is now at 5b83d7ad9106 Add linux-next specific files for 20141120 $ pwclient git-am 5197701 Applying patch #5197701 using 'git am' Description: [v2,2/2] arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy Applying: arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy $ pwclient git-am 5328881 Applying patch #5328881 using 'git am' Description: [RFC,1/1] drm/exynos: Move platform drivers registration to module init Applying: drm/exynos: Move platform drivers registration to module init $ git log --oneline -n5 b16800da58a3 drm/exynos: Move platform drivers registration to module init 87541edf8a17 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 5b83d7ad9106 Add linux-next specific files for 20141120 fd7e97b09f45 Merge branch 'akpm/master' 11729160b2d7 mm: add strictlimit knob Kevin [1] Connected to chromebook2 console [channel connected] (~$quit to exit) (user:khilman) is already connected # PYBOOT: console: connected. ~$hardreset Command(chromebook2 console) hardreset (user:khilman) Reboot chromebook2 Reboot: chromebook2 ; phidget 4 2 : ('off', 1, 'on') U-Boot 2013.04-gb98ed09 (Apr 30 2014 - 16:57:31) for Peach CPU:Exynos5422@1800MHz Board: Google Peach Pi, rev 13.6 I2C: ready DRAM: 3.5 GiB PMIC max77802-pmic initialized CPU:Exynos5422@1800MHz TPS65090 PMIC EC init MMC: EXYNOS DWMMC: 0, EXYNOS DWMMC: 1 SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB In:cros-ec-keyb Out: serial Err: lcd SF: Detected W25Q32DW with page size 4 KiB, total 32 MiB ELOG: Event(17) added with size 13 Net: No ethernet found. Hit any key to stop autoboot: 2 # PYBOOT: u-boot: taking control. 0 Exynos DP init done Peach # Peach setenv stdout serial # setenv stdout serialversion Peach # versionsetenv preboot usb start; sleep 1 U-Boot 2013.04-gb98ed09 (Apr 30 2014 - 16:57:31) for Peach armv7a-cros-linux-gnueabi-gcc.real (4.7.2_cos_gg_c8f69e0) 4.7.x-google 20130114 (prerelease) GNU ld (binutils-2.22_cos_gg_2) 2.22 Peach # setenv preboot usb start; sleep 1setenv bootargs console=tty1 console=ttySAC3,115200 debug earlyprintk rw root=/dev/mmcblk1p3 rootwait rootfstype=ext3 Peach # setenv bootargs console=tty1 console=ttySAC3,115200 debug earlyprintk rw root=/dev/mmcblk1p3 rootwait rootfstype=ext3if test -n ${initenv}; then run initenv; fi Peach # if test -n ${initenv}; then run initenv; fiif test -n ${preboot}; then run preboot; fi Peach # if test -n ${preboot}; then run preboot; fisetenv autoload no; setenv autoboot no (Re)start USB... USB0: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found USB1: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus 1 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 1 Ethernet Device(s) found Peach # dhcp dhcp Waiting for Ethernet connection... done. BOOTP broadcast 1 BOOTP broadcast 2 DHCP client bound to address 192.168.1.110 Peach # setenv serverip 192.168.1.2 setenv serverip 192.168.1.2 Peach # if test -n ${netargs}; then run netargs; fi if test -n ${netargs}; then run netargs; fi Peach # tftp 0x4100 192.168.1.2:tmp/chromebook2-3T8ptb/uImage-48m8WK tftp 0x4100 192.168.1.2:tmp/chromebook2-3T8ptb/uImage-48m8WK Using asx0 device TFTP from server 192.168.1.2; our IP address is 192.168.1.110 Filename 'tmp/chromebook2-3T8ptb/uImage-48m8WK'. Load address: 0x4100 Loading: *# # # ## 1.2 MiB/s done Bytes transferred = 3473930 (35020a hex) Peach # printenv bootargs printenv bootargs bootargs=console=tty1 console
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello Paolo, On 11/20/2014 04:57 PM, Paolo Pisati wrote: On Thu, Nov 20, 2014 at 03:22:23PM +0530, Vivek Gautam wrote: On linux-samsung tree the only patch that's missing apart from dptx-phy patches is the syscon patch from Pankaj Dubey: b784b98 mfd: syscon: Decouple syscon interface from platform devices So with below git hash, linux-samsung/for-next display works fine along with other devices that request PMU system controller : 7bd219e drm/exynos: dp: Remove support for unused dptx-phy e8f21fd arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 7099bde Revert Revert ARM: exynos_defconfig: Enable options for display panel support 713a994 mfd: syscon: Decouple syscon interface from platform devices 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support /* This is Kukjin's for-next today */ ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow fc14f9c Linux 3.18-rc5 are you using a clean exynos_defconfig? don't you need Javier's drm/exynos: Move platform drivers registration to module init patch too? Since Kukjin's for-next is based on Linux 3.18-rc5, the OF patch that causes the Exynos DRM deadlock is not there. That commit landed in next20141105. kgene/for-next at: 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support plus: 5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36d908e drm/exynos: dp: Remove support for unused dptx-phy 624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices 68944e3 Revert Revert ARM: exynos_defconfig: Enable options for display panel support hangs with a black screen (albeit backlight seems to be on) on boot. I'm betting on Javier's patch at this point (i even tried disabling SND_SOC_SNOW but that didn't help). I only tested with next20141120 but Vivek tested with Kukjin for-next AFAIU. What's your kernel command line and u-boot env vars? 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
Re: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
2014-11-21 0:26 GMT+09:00 Javier Martinez Canillas javier.marti...@collabora.co.uk: Hello Inki, On 11/20/2014 04:06 PM, Inki Dae wrote: BTW, it would be great if exynos-drm-next is pulled in linux-next. That is what most people use to test integration issues so you can catch earlier any regression that may arise. You have to email Stephen Rothwell s...@canb.auug.org.au and point to your tree and branch and he will be able to add it to linux-next. Thanks for information. Actually, I received a similar email privately before. However, exynos-drm-next should go to drm-next first and than to mainline by Dave who is DRM subsystem maintainer. I think all vendor specific drm drivers would need to be checked by drm subsystem maintainer because these changes might be affect drm subsystem or other vendor specific drm drivers before go to mainline. This is orthogonal to the normal upstreaming path. linux-next is an integration tree that is created daily. So all the remote branches are merged and a git tag published. The branch does not get rebased and history is not preserved between two published linux-next tags. This is just to test the integration of different subsystems to be sure that a commit in one tree does not cause a regression in another one so issues can be spot earlier. For example in the case of $subject, a change in the OF caused a regression in the Exynos DRM driver. If needed, I will make a new branch, which is based on top of linux-next so other people can check their systems. You don't really need another branch, git will take care of merge everything in linux-next :) Ah, sorry. There was my misunderstanding. drm-next already is merged to linux-next so I think we can do the integration test if exynos-drm-next is merged to drm-next earlier. Anyway, I will try to consider your opinion. Thanks, Inki Dae Thanks, Inki Dae 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: [RFC PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Hello, For completeness I'll comment what we talked with Kevin on IRC since probably this is the same issue that Paolo is facing. On 11/20/2014 05:41 PM, Kevin Hilman wrote: Peach # setenv preboot usb start; sleep 1setenv bootargs console=tty1 console=ttySAC3,115200 debug earlyprintk rw root=/dev/mmcblk1p3 rootwait rootfstype=ext3 My kernel command line is almost the same with the difference that I'm using clk_ignore_unused and I just checked that not passing that parameter, makes linux-next to hang showing the same output log that Kevin reported. Now, the question is why this does not happen with 3.18-rc+? My guess is that the clock been disabled by the common clock framework got added recently and it used to be unmanaged and left with the state set by the bootloader since the kernel didn't know about it. That's why clk_ignore_unused was not needed. Any ideas? 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
Re: [PATCH v5 1/2] clk: samsung: exynos5440: move restart code into clock driver
On 19/11/14 04:37, Pankaj Dubey wrote: +static int exynos5440_clk_restart_notify(struct notifier_block *this, + unsigned long code, void *unused) +{ + u32 val, status; + + status = readl_relaxed(reg_base + 0xbc); + val = readl_relaxed(reg_base + 0xcc); + val = (val 0x) | (status 0x); + writel_relaxed(val, reg_base + 0xcc); Can we have macro definitions for these 0xcc, 0xbc address offsets ? I must say I couldn't find them documented in any Exynos datasheet I've got though. I also wished this, but I could not find them documented. So I tried to keep logic of original code as it is, just changed location. I would also like to mention that I have not tested this on exynos5440 as I do not have one with me. I believe if it was working at its original place in exynos_restart it should work here also. Other patch (2/2) I have verified on Exynos3250 board and its working well. I think it's best to merge both patches in that series through the arm-soc tree, since applying them not in order may cause some breakage. Thus I'd let Kukjin take this patch set into his tree. For both patches: Acked-by: Sylwester Nawrocki s.nawro...@samsung.com -- Thanks, Sylwester -- 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 PATCH 1/1] drm/exynos: Move platform drivers registration to module init
Javier Martinez Canillas javier.marti...@collabora.co.uk writes: Hello, For completeness I'll comment what we talked with Kevin on IRC since probably this is the same issue that Paolo is facing. On 11/20/2014 05:41 PM, Kevin Hilman wrote: Peach # setenv preboot usb start; sleep 1setenv bootargs console=tty1 console=ttySAC3,115200 debug earlyprintk rw root=/dev/mmcblk1p3 rootwait rootfstype=ext3 My kernel command line is almost the same with the difference that I'm using clk_ignore_unused and I just checked that not passing that parameter, makes linux-next to hang showing the same output log that Kevin reported. Ah! Good find. I confirm that adding clk_ignore_unused is getting me booting again, but of course that is just masking a problem, so I hope someone can shed light on which clock isn't being correctly managed. Might I also suggest that folks have their default command-line to *not* use clk_ignore_unused, since it's primary job is to workaround clock bugs. Kevin -- 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 v3 1/2] usb: dwc2/gadget: add mutex to serialize init/deinit calls
On Fri, Oct 31, 2014 at 11:12:33AM +0100, Marek Szyprowski wrote: This patch adds mutex, which protects initialization and deinitialization procedures against suspend/resume methods. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com doesn't apply either: checking file drivers/usb/dwc2/core.h Hunk #1 FAILED at 187. 1 out of 1 hunk FAILED checking file drivers/usb/dwc2/gadget.c Hunk #2 succeeded at 2863 (offset -46 lines). Hunk #3 succeeded at 2889 (offset -46 lines). Hunk #4 succeeded at 2915 (offset -47 lines). Hunk #5 succeeded at 2934 (offset -47 lines). Hunk #6 succeeded at 2964 (offset -47 lines). Hunk #7 succeeded at 2976 (offset -47 lines). Hunk #8 FAILED at 3518. Hunk #9 succeeded at 3579 (offset -84 lines). Hunk #10 succeeded at 3603 with fuzz 1 (offset -84 lines). Hunk #11 succeeded at 3614 (offset -84 lines). Hunk #12 succeeded at 3632 with fuzz 1 (offset -84 lines). 1 out of 12 hunks FAILED please rebase on testing/next. Also, add Paul's Ack when doing so ;-) thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH v5] usb: dwc2/gadget: rework disconnect event handling
On Mon, Nov 17, 2014 at 09:59:42AM +0100, Marek Szyprowski wrote: This patch adds a call to s3c_hsotg_disconnect() from 'end session' interrupt (GOTGINT_SES_END_DET) to correctly notify gadget subsystem about unplugged usb cable. DISCONNINT interrupt cannot be used for this purpose, because it is asserted only in host mode. To avoid reporting disconnect event more than once, a disconnect call has been moved from USB_REQ_SET_ADDRESS handling function to SESSREQINT interrupt. This way driver ensures that disconnect event is reported either when usb cable is unplugged or every time the host starts a new session. To handle devices which has been synthesized without SRP support, connected state is set in ENUMDONE interrupt. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com doesn't apply, please rebase on my testing/next: checking file drivers/usb/dwc2/core.h Hunk #1 FAILED at 210. 1 out of 1 hunk FAILED checking file drivers/usb/dwc2/gadget.c Hunk #1 FAILED at 1029. Hunk #2 succeeded at 1108 (offset 1 line). Hunk #3 succeeded at 2031 (offset 1 line). Hunk #4 FAILED at 2293. 2 out of 4 hunks FAILED thanks -- balbi signature.asc Description: Digital signature
Re: [PATCH] PM / Domains: Power on the PM domain right after attach completes
On Thursday, November 20, 2014 11:13:01 AM Ulf Hansson wrote: On 20 November 2014 01:35, Rafael J. Wysocki r...@rjwysocki.net wrote: On Wednesday, November 19, 2014 09:54:00 AM Ulf Hansson wrote: [...] Scenario 5), a platform driver with/without runtime PM callbacks. -probe() - do some initialization - may fetch handles to runtime PM resources - pm_runtime_enable() Well, and now how the driver knows if the device is on before accessing it? In this case the driver don't need to access the device during -probe(). That's postponed until sometime later. If this is a platform driver, it rather does need to access the device, precisely because it doesn't know what power state the device is in otherwise. See below. Note 1) Scenario 1) and 2), both relies on the approach to power on the PM domain by using pm_runtime_get_sync(). That approach didn't work when CONFIG_PM_RUNTIME was unset, but we recently decided to fixed that by the below patch, so that's good! [PATCH] PM / domains: Kconfig: always enable PM_RUNTIME when genpd enabled Note 2) Scenario 3) and 4) use the same principles for managing runtime PM. These scenarios needs a way to power on the generic PM domain prior probing the device. The call to pm_runtime_set_active(), prevents an already powered PM domain from power off until after probe, but that's not enough. Note 3) The $subject patch, tried to address the issues for scenario 3) and 4). It does so, but will affect scenario 5) which was working nicely before. In scenario 5), the $subject patch will cause the generic PM domain to potentially stay powered after -probe() even if the device is runtime PM suspended. Why would it? If the device is runtime-suspended, the domain will know that, because its callbacks will be used for that. At least, that's what I'd expect to happen, so is there a problem here? Genpd do knows about the device but it doesn’t get a notification to power off. There are no issues whatsoever for driver. Except that the driver is arguably buggy. This is a somewhat special case. Let's go through an example. 1. The PM domain is initially in powered off state. 2. The bus -probe() invokes dev_pm_domain_attach() and then the PM domain gets attached to the device. 3. $subject patch causes the PM domain to power on. 4. A driver -probe() sequence start, following the Scenario 5). 5. The device is initially in runtime PM suspended state and it will remain so during -probe(). But is it physically suspended? The runtime PM status of the device after -probe is required to reflect its real state if runtime PM is enabled. If that's not the case, it is a bug. Agree. While I was searching for drivers that behave as in scenario 5), they tend to register some subsystem specific callbacks and don't access the device until some of those callbacks are invoked. At least that was my interpretation of their -probe() methods, but it's not always easy to tell how those callbacks are being used for each subsystem. Now, for platform drivers, the driver can't really assume anything in particular about the current power state of the device at -probe time, because different platforms including devices handled by that driver may behave differently. A good example would be two platforms A and B where the same device X is in a power domain such that A boots with the domain (physically) on, while B boots with the domain off. If the driver for X assumes anything about the initial power state of the device, it may not work on either A or B. I get your point and agree! 6. The pm_request_idle() invoked after really_probe() in driver core, won't trigger a runtime PM suspend callback to be invoked. In other words, genpd don't get a notification that it may power off. In this state, genpd will either power off from the late_initcall, genpd_poweroff_unused() (depending on when the driver was probed) or wait until some device's runtime PM suspend callback is invoked at any later point. Which sounds OK to me, so why is it a problem? The late_initcall doesn't work for modules. Also, suppose the PM domain only holds this inactive device that was probed as in scenario 5). Then, you could end up having the PM domain powered, even if it isn't needed. Anyway, I can live with this. It's likely the driver that behave as in scenario 5) that should be fixed as you stated. I see three options going forward. Option 1) Convert scenario 3) and 4) into using the pm_runtime_get_sync() approach. There are no theoretical obstacles to do this, but pure practical. There are a lot of drivers that needs to be converted and we also need to teach driver authors future wise to not use pm_runtime_set_active() in this manner. I'd say we need to do something like this
Re: [PATCH 1/2] drm/exynos: fix null pointer dereference issue
2014-11-13 Inki Dae inki@samsung.com: This patch fixes null pointer dereference issue incurred when ipp driver is enabled and Exynos drm driver is closed. Non kms driver should register its own sub driver to setup necessary resources, which is done by load(). So null pointer dereference occurs when ipp driver is enabled and Exynos drm driver is closed because ipp core device is registered after component_master_add_with_match call. This patch makes exynos_drm_device_subdrv_probe() to be called after all non kms drivers are registered. This patch is breaking exynos initialization, exynos_drm_device_subdrv_probe() needs the drvdata but it is still NULL at this point which make the whole exynos init fails. The drvdata is only set in exynos_drm_load() so we need call exynos_drm_device_subdrv_probe() after that. Do you have the crash output for this? What is the issue you are fixing? Usually you should add this kind of information to you commit message, it helps us understand what you are fixing, specially in cases when a regression is introduced, like this patch for example Gustavo -- 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 2/3] Revert drm/exynos: fix null pointer dereference issue
From: Gustavo Padovan gustavo.pado...@collabora.co.uk This reverts commit cea24824ab432f8acabb254d6805e9aa756de6af. Moving subdriver probe to exynos_drm_platform_probe() was making exynos_drm_device_subdrv_probe() fail because the platform data wasn't set yet. It only gets set in exynos_drm_load. We need to find a smarter way to fix this issue. Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index b94c9d1..91891cf 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -108,6 +108,11 @@ static int exynos_drm_load(struct drm_device *dev, unsigned long flags) if (ret) goto err_unbind_all; + /* Probe non kms sub drivers and virtual display driver. */ + ret = exynos_drm_device_subdrv_probe(dev); + if (ret) + goto err_cleanup_vblank; + /* * enable drm irq mode. * - with irq_enabled = true, we can use the vblank feature. @@ -133,6 +138,8 @@ static int exynos_drm_load(struct drm_device *dev, unsigned long flags) return 0; +err_cleanup_vblank: + drm_vblank_cleanup(dev); err_unbind_all: component_unbind_all(dev-dev, dev); err_mode_config_cleanup: @@ -146,6 +153,8 @@ err_free_private: static int exynos_drm_unload(struct drm_device *dev) { + exynos_drm_device_subdrv_remove(dev); + exynos_drm_fbdev_fini(dev); drm_kms_helper_poll_fini(dev); @@ -608,14 +617,8 @@ static int exynos_drm_platform_probe(struct platform_device *pdev) if (ret 0) goto err_unregister_non_kms_drivers; - /* Probe non kms sub drivers and virtual display driver. */ - ret = exynos_drm_device_subdrv_probe(platform_get_drvdata(pdev)); - if (ret) - goto err_unregister_resources; - return ret; -err_unregister_resources: #ifdef CONFIG_DRM_EXYNOS_IPP exynos_platform_device_ipp_unregister(); #endif @@ -637,8 +640,6 @@ static int exynos_drm_platform_remove(struct platform_device *pdev) { int i; - exynos_drm_device_subdrv_remove(platform_get_drvdata(pdev)); - #ifdef CONFIG_DRM_EXYNOS_IPP exynos_platform_device_ipp_unregister(); #endif -- 1.9.3 -- 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 1/3] drm/exynos: revert fixes for the infinite loop issue
From: Gustavo Padovan gustavo.pado...@collabora.co.uk This reverts commit 06a2f5c2c4e0cb4ff38ca3769ae1f81cc2d030cf and f7c2f36f4395f12d8ecb25c28ee88ec87b457089. These two patches were trying to fix an issue that was causing an infinite loop at the load of the exynos-drm but they were not tackling the source of the problem. A new patch that move the platform driver registration exynos_drm_init() follows this revert and fix the issue properly. Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 -- 1 file changed, 18 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index eab12f0..b94c9d1 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -484,12 +484,6 @@ static struct component_match *exynos_drm_match_add(struct device *dev) mutex_lock(drm_component_lock); - /* Do not retry to probe if there is no any kms driver regitered. */ - if (list_empty(drm_component_list)) { - mutex_unlock(drm_component_lock); - return ERR_PTR(-ENODEV); - } - list_for_each_entry(cdev, drm_component_list, list) { /* * Add components to master only in case that crtc and @@ -674,18 +668,6 @@ static int exynos_drm_init(void) { int ret; - /* -* Register device object only in case of Exynos SoC. -* -* Below codes resolves temporarily infinite loop issue incurred -* by Exynos drm driver when using multi-platform kernel. -* So these codes will be replaced with more generic way later. -*/ - if (!of_machine_is_compatible(samsung,exynos3) - !of_machine_is_compatible(samsung,exynos4) - !of_machine_is_compatible(samsung,exynos5)) - return -ENODEV; - exynos_drm_pdev = platform_device_register_simple(exynos-drm, -1, NULL, 0); if (IS_ERR(exynos_drm_pdev)) -- 1.9.3 -- 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 3/3] drm/exynos: move Exynos platform drivers registration to init
From: Gustavo Padovan gustavo.pado...@collabora.co.uk Registering the Exynos DRM subdevices platform drivers in the probe function is causing an infinite loop. Fix this by moving it to the exynos_drm_init() function to register the drivers on module init. Registering drivers in the probe functions causes a deadlock in the parent device lock. See Grant Likely explanation on the topic: I think the problem is that exynos_drm_init() is registering a normal (non-OF) platform device, so the parent will be /sys/devices/platform. It immediately gets bound against exynos_drm_platform_driver which calls the exynos drm_platform_probe() hook. The driver core obtains device_lock() on the device *and on the device parent*. Inside the probe hook, additional platform_drivers get registered. Each time one does, it tries to bind against every platform device in the system, which includes the ones created by OF. When it attempts to bind, it obtains device_lock() on the device *and on the device parent*. Before the change to move of-generated platform devices into /sys/devices/platform, the devices had different parents. Now both devices have /sys/devices/platform as the parent, so yes they are going to deadlock. The real problem is registering drivers from within a probe hook. That is completely wrong for the above deadlock reason. __driver_attach() will deadlock. Those registrations must be pulled out of .probe(). Registering devices in .probe() is okay because __device_attach() doesn't try to obtain device_lock() on the parent. INFO: task swapper/0:1 blocked for more than 120 seconds. Not tainted 3.18.0-rc3-next-20141105 #794 echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. swapper/0 D c052534c 0 1 0 0x [c052534c] (__schedule) from [c0525b34] (schedule_preempt_disabled+0x14/0x20) [c0525b34] (schedule_preempt_disabled) from [c0526d44] (mutex_lock_nested+0x1c4/0x464 [c0526d44] (mutex_lock_nested) from [c02be908] (__driver_attach+0x48/0x98) [c02be908] (__driver_attach) from [c02bcc00] (bus_for_each_dev+0x54/0x88) [c02bcc00] (bus_for_each_dev) from [c02bdce0] (bus_add_driver+0xe4/0x200) [c02bdce0] (bus_add_driver) from [c02bef94] (driver_register+0x78/0xf4) [c02bef94] (driver_register) from [c029e99c] (exynos_drm_platform_probe+0x34/0x234) [c029e99c] (exynos_drm_platform_probe) from [c02bfcf0] (platform_drv_probe+0x48/0xa4) [c02bfcf0] (platform_drv_probe) from [c02be680] (driver_probe_device+0x13c/0x37c) [c02be680] (driver_probe_device) from [c02be954] (__driver_attach+0x94/0x98) [c02be954] (__driver_attach) from [c02bcc00] (bus_for_each_dev+0x54/0x88) [c02bcc00] (bus_for_each_dev) from [c02bdce0] (bus_add_driver+0xe4/0x200) [c02bdce0] (bus_add_driver) from [c02bef94] (driver_register+0x78/0xf4) [c02bef94] (driver_register) from [c029e938] (exynos_drm_init+0x70/0xa0) [c029e938] (exynos_drm_init) from [c00089b0] (do_one_initcall+0xac/0x1f0) [c00089b0] (do_one_initcall) from [c074bd90] (kernel_init_freeable+0x10c/0x1d8) [c074bd90] (kernel_init_freeable) from [c051eabc] (kernel_init+0x8/0xec) [c051eabc] (kernel_init) from [c000f268] (ret_from_fork+0x14/0x2c) 3 locks held by swapper/0/1: #0: (dev-mutex){..}, at: [c02be908] __driver_attach+0x48/0x98 #1: (dev-mutex){..}, at: [c02be918] __driver_attach+0x58/0x98 #2: (dev-mutex){..}, at: [c02be908] __driver_attach+0x48/0x98 Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 124 +++- 1 file changed, 59 insertions(+), 65 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index 91891cf..cb3ed9b 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -548,6 +548,38 @@ static const struct component_master_ops exynos_drm_ops = { .unbind = exynos_drm_unbind, }; +static int exynos_drm_platform_probe(struct platform_device *pdev) +{ + struct component_match *match; + + pdev-dev.coherent_dma_mask = DMA_BIT_MASK(32); + exynos_drm_driver.num_ioctls = ARRAY_SIZE(exynos_ioctls); + + match = exynos_drm_match_add(pdev-dev); + if (IS_ERR(match)) { + return PTR_ERR(match); + } + + return component_master_add_with_match(pdev-dev, exynos_drm_ops, + match); +} + +static int exynos_drm_platform_remove(struct platform_device *pdev) +{ + component_master_del(pdev-dev, exynos_drm_ops); + return 0; +} + +static struct platform_driver exynos_drm_platform_driver = { + .probe = exynos_drm_platform_probe, + .remove = exynos_drm_platform_remove, + .driver = { + .owner = THIS_MODULE, + .name = exynos-drm, + .pm = exynos_drm_pm_ops, + },
[PATCH 0/3] drm/exynos: Fix exynos-drm initialization
From: Gustavo Padovan gustavo.pado...@collabora.co.uk These patches were tested both in drm-exynos-next and linux-next (with drm-exynos-next merged in) and it solves the infinite loop and parent device lock deadlock. It was tested with Ajay's DP patches applied. A tree based on drm-exynos-next can be found here: https://git.kernel.org/cgit/linux/kernel/git/padovan/drm-exynos.git/log/?h=dp-integ The first patch reverts the other tries to fix this problem. The second patch is a revert and fixes a regression with the subdriver probe function getting a NULL drvdata and thus failing drm_exynos_init() The third patch is a port to drm-exynos-next of Javier patches that moves the platform driver registration to init. Gustavo Padovan (3): drm/exynos: revert fixes for the infinite loop issue Revert drm/exynos: fix null pointer dereference issue drm/exynos: move Exynos platform drivers registration to init drivers/gpu/drm/exynos/exynos_drm_drv.c | 159 ++-- 1 file changed, 68 insertions(+), 91 deletions(-) -- 1.9.3 -- 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 PATCH 1/1] drm/exynos: Move platform drivers registration to module init
On Thu, Nov 20, 2014 at 10:22:54AM -0800, Kevin Hilman wrote: Javier Martinez Canillas javier.marti...@collabora.co.uk writes: Hello, For completeness I'll comment what we talked with Kevin on IRC since probably this is the same issue that Paolo is facing. On 11/20/2014 05:41 PM, Kevin Hilman wrote: Peach # setenv preboot usb start; sleep 1setenv bootargs console=tty1 console=ttySAC3,115200 debug earlyprintk rw root=/dev/mmcblk1p3 rootwait rootfstype=ext3 My kernel command line is almost the same with the difference that I'm using clk_ignore_unused and I just checked that not passing that parameter, makes linux-next to hang showing the same output log that Kevin reported. Ah! Good find. I confirm that adding clk_ignore_unused is getting me booting again, but of course that is just masking a problem, so I hope someone can shed light on which clock isn't being correctly managed. Might I also suggest that folks have their default command-line to *not* use clk_ignore_unused, since it's primary job is to workaround clock bugs. i'm testing kgene/for-next (not linux-next), with: flag@peachpi:~/linux$ cat /proc/cmdline console=tty1 console=ttySAC3,115200 debug earlyprintk rw rootwait root=/dev/mmcblk1p3 adding clk_ignore_unused didn't make any difference: it hangs on boot showing a black screen with backlight on. vanilla kgene/for-next as of today: 7552917 Revert ARM: exynos_defconfig: Enable options for display panel support ff0391a Merge branch 'v3.19-samsung-defconfig' into for-next 26c6283 Merge branch 'v3.18-samsung-fixes' into for-next cf864fd Merge branch 'v3.18-samsung-defconfig' into for-next 98b6380 ARM: exynos_defconfig: Enable max77802 rtc and clock drivers 839275c ARM: exynos_defconfig: Use 16 minors per MMC block device 0526f27 ARM: dts: Explicitly set dr_mode on exynos5250-snow fc14f9c Linux 3.18-rc5 ... plus 5e1e068 arm: dts: Exynos5: Use pmu_system_controller phandle for dp phy 36d908e drm/exynos: dp: Remove support for unused dptx-phy 624bff2 POSTED: mfd: syscon: Decouple syscon interface from syscon devices 68944e3 Revert Revert ARM: exynos_defconfig: Enable options for display panel support vanilla exynos_defconfig with SND_SOC_SNOW disabled. I should probably try linux-next at this point, but i wonder if people who reported kgene/for-next working were testing with a vanilla exynos_defconfig on a peach pi. -- bye, p. -- 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 3/3] drm/exynos: avoid leak if exynos_dpi_probe() fails
From: Gustavo Padovan gustavo.pado...@collabora.co.uk The component must be deleted if the probe fails. Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 0673a39..173d135 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -1202,8 +1202,10 @@ static int fimd_probe(struct platform_device *pdev) fimd_manager.ctx = ctx; ctx-display = exynos_dpi_probe(dev); - if (IS_ERR(ctx-display)) - return PTR_ERR(ctx-display); + if (IS_ERR(ctx-display)) { + ret = PTR_ERR(ctx-display); + goto err_del_component; + } pm_runtime_enable(pdev-dev); -- 1.9.3 -- 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 2/3] drm/exynos: avoid race condition when adding a drm component
From: Gustavo Padovan gustavo.pado...@collabora.co.uk exynos_drm_component_add() correctly checks if a component is present on drm_component_list however it release the lock right after the check and before we add the new component to the list. That just creates room to add the same component more than once to the list. The lock should be held for the whole journey while adding a new component. Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 16 +--- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c b/drivers/gpu/drm/exynos/exynos_drm_drv.c index cb3ed9b..230573d 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c @@ -402,10 +402,8 @@ int exynos_drm_component_add(struct device *dev, * added already just return. */ if (cdev-dev_type_flag == (EXYNOS_DEVICE_TYPE_CRTC | - EXYNOS_DEVICE_TYPE_CONNECTOR)) { - mutex_unlock(drm_component_lock); - return 0; - } + EXYNOS_DEVICE_TYPE_CONNECTOR)) + goto unlock; if (dev_type == EXYNOS_DEVICE_TYPE_CRTC) { cdev-crtc_dev = dev; @@ -417,14 +415,11 @@ int exynos_drm_component_add(struct device *dev, cdev-dev_type_flag |= dev_type; } - mutex_unlock(drm_component_lock); - return 0; + goto unlock; } } - mutex_unlock(drm_component_lock); - - cdev = kzalloc(sizeof(*cdev), GFP_KERNEL); + cdev = kzalloc(sizeof(*cdev), GFP_ATOMIC); if (!cdev) return -ENOMEM; @@ -436,10 +431,9 @@ int exynos_drm_component_add(struct device *dev, cdev-out_type = out_type; cdev-dev_type_flag = dev_type; - mutex_lock(drm_component_lock); list_add_tail(cdev-list, drm_component_list); +unlock: mutex_unlock(drm_component_lock); - return 0; } -- 1.9.3 -- 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 1/3] drm/exynos: free DP if probe fails to find a panel or bridge
From: Gustavo Padovan gustavo.pado...@collabora.co.uk DP was leaked everytime function returns EPROBE_DEFER, free it before returning. Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk --- drivers/gpu/drm/exynos/exynos_dp_core.c | 21 +++-- 1 file changed, 15 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c index 85762cf..6fd4a46 100644 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c @@ -1336,8 +1336,10 @@ static int exynos_dp_probe(struct platform_device *pdev) if (panel_node) { dp-panel = of_drm_find_panel(panel_node); of_node_put(panel_node); - if (!dp-panel) - return -EPROBE_DEFER; + if (!dp-panel) { + ret = -EPROBE_DEFER; + goto free_dp; + } } endpoint = of_graph_get_next_endpoint(dev-of_node, NULL); @@ -1346,10 +1348,14 @@ static int exynos_dp_probe(struct platform_device *pdev) if (bridge_node) { dp-bridge = of_drm_find_bridge(bridge_node); of_node_put(bridge_node); - if (!dp-bridge) - return -EPROBE_DEFER; - } else - return -EPROBE_DEFER; + if (!dp-bridge) { + ret = -EPROBE_DEFER; + goto free_dp; + } + } else { + ret = -EPROBE_DEFER; + goto free_dp; + } } exynos_dp_display.ctx = dp; @@ -1359,6 +1365,9 @@ static int exynos_dp_probe(struct platform_device *pdev) exynos_drm_component_del(pdev-dev, EXYNOS_DEVICE_TYPE_CONNECTOR); +free_dp: + devm_kfree(dev, dp); + return ret; } -- 1.9.3 -- 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 1/2] Input: add regulator haptic driver
Hi Pankaj, 2014년 11월 20일 23:33에 Pankaj Dubey 이(가) 쓴 글: Hi Jaewon, On 20 November 2014 19:01, Jaewon Kim jaewon02@samsung.com wrote: This patch adds support for haptic driver controlled by voltage of regulator. And this driver support for Force Feedback interface from input framework Signed-off-by: Jaewon Kim jaewon02@samsung.com Signed-off-by: Hyunhee Kim hyunhee@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/input/regulator-haptic.txt | 24 ++ drivers/input/misc/Kconfig | 11 + drivers/input/misc/Makefile|1 + drivers/input/misc/regulator-haptic.c | 241 4 files changed, 277 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/regulator-haptic.txt create mode 100644 drivers/input/misc/regulator-haptic.c diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt b/Documentation/devicetree/bindings/input/regulator-haptic.txt new file mode 100644 index 000..9f60e17 --- /dev/null +++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt @@ -0,0 +1,24 @@ +* Requlator Haptic Device Tree Bindings + +The regulator haptic driver controlled by voltage of regulator. +This driver implemented via Force Feedback interface. + +Required Properties: + - compatible : Should be regulator-haptic + - haptic-supply : Power supply for the haptic motor. + [*] refer Documentation/devicetree/bindings/regulator/regulator.txt + + - max-microvolt : The maximum voltage value supplied to haptic motor. + [The unit of the voltage is a micro] + + - min-microvolt : The minimum voltage value in which haptic motor reacts. + [The unit of the voltage is a micro] + +Example: + + regulator-haptic { + compatible = regulator-haptic; + haptic-supply = motor_regulator; + max-microvolt = 270; + min-microvolt = 110; + }; diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 23297ab..e5e556d 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -394,6 +394,17 @@ config INPUT_CM109 To compile this driver as a module, choose M here: the module will be called cm109. +config INPUT_REGULATOR_HAPTIC + tristate regulator haptics support + select INPUT_FF_MEMLESS + help + This option enables device driver support for the haptic controlled + by regulator. This driver supports ff-memless interface + from input framework. + + To compile this driver as a module, choose M here: the + module will be called regulator-haptic. + config INPUT_RETU_PWRBUTTON tristate Retu Power button Driver depends on MFD_RETU diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile index 19c7603..1f135af 100644 --- a/drivers/input/misc/Makefile +++ b/drivers/input/misc/Makefile @@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o obj-$(CONFIG_INPUT_POWERMATE) += powermate.o obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o +obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o diff --git a/drivers/input/misc/regulator-haptic.c b/drivers/input/misc/regulator-haptic.c new file mode 100644 index 000..1a83ecb --- /dev/null +++ b/drivers/input/misc/regulator-haptic.c @@ -0,0 +1,241 @@ +/* + * Regulator haptic driver + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * Author: Jaewon Kim jaewon02@samsung.com + * Author: Hyunhee Kim hyunhee@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/input.h +#include linux/slab.h +#include linux/regulator/consumer.h +#include linux/of.h + +#define MAX_MAGNITUDE_SHIFT16 + +struct regulator_haptic { + struct device *dev; + struct input_dev *input_dev; + struct regulator *regulator; + struct work_struct work; + + bool enabled; + bool suspend_state; + unsigned int max_volt; + unsigned int min_volt; + unsigned int intensity; + unsigned int magnitude; +}; + +static void regulator_haptic_enable(struct regulator_haptic *haptic) +{ + int error; + + if (haptic-enabled) + return; + + error = regulator_enable(haptic-regulator); + if (error) { + dev_err(haptic-dev, cannot enable regulator\n); + return; + } + +
Re: [PATCH 1/2] Input: add regulator haptic driver
Hi Dan, 2014년 11월 21일 00:09에 Dan Murphy 이(가) 쓴 글: Hi On 11/20/2014 08:33 AM, Pankaj Dubey wrote: Hi Jaewon, On 20 November 2014 19:01, Jaewon Kim jaewon02@samsung.com wrote: This patch adds support for haptic driver controlled by voltage of regulator. And this driver support for Force Feedback interface from input framework Signed-off-by: Jaewon Kim jaewon02@samsung.com Signed-off-by: Hyunhee Kim hyunhee@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com --- .../devicetree/bindings/input/regulator-haptic.txt | 24 ++ drivers/input/misc/Kconfig | 11 + drivers/input/misc/Makefile|1 + drivers/input/misc/regulator-haptic.c | 241 4 files changed, 277 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/regulator-haptic.txt create mode 100644 drivers/input/misc/regulator-haptic.c diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt b/Documentation/devicetree/bindings/input/regulator-haptic.txt new file mode 100644 index 000..9f60e17 --- /dev/null +++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt @@ -0,0 +1,24 @@ +* Requlator Haptic Device Tree Bindings + +The regulator haptic driver controlled by voltage of regulator. +This driver implemented via Force Feedback interface. + +Required Properties: + - compatible : Should be regulator-haptic + - haptic-supply : Power supply for the haptic motor. + [*] refer Documentation/devicetree/bindings/regulator/regulator.txt + + - max-microvolt : The maximum voltage value supplied to haptic motor. + [The unit of the voltage is a micro] + + - min-microvolt : The minimum voltage value in which haptic motor reacts. + [The unit of the voltage is a micro] + +Example: + + regulator-haptic { Should this be more about the function and not the driver name? Somehting like haptics { Yes, haptics is better than driver name. + compatible = regulator-haptic; + haptic-supply = motor_regulator; + max-microvolt = 270; + min-microvolt = 110; + }; diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig index 23297ab..e5e556d 100644 --- a/drivers/input/misc/Kconfig +++ b/drivers/input/misc/Kconfig @@ -394,6 +394,17 @@ config INPUT_CM109 To compile this driver as a module, choose M here: the module will be called cm109. +config INPUT_REGULATOR_HAPTIC + tristate regulator haptics support + select INPUT_FF_MEMLESS + help + This option enables device driver support for the haptic controlled + by regulator. This driver supports ff-memless interface + from input framework. + + To compile this driver as a module, choose M here: the + module will be called regulator-haptic. + config INPUT_RETU_PWRBUTTON tristate Retu Power button Driver depends on MFD_RETU diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile index 19c7603..1f135af 100644 --- a/drivers/input/misc/Makefile +++ b/drivers/input/misc/Makefile @@ -53,6 +53,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o obj-$(CONFIG_INPUT_POWERMATE) += powermate.o obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o +obj-$(CONFIG_INPUT_REGULATOR_HAPTIC) += regulator-haptic.o obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o diff --git a/drivers/input/misc/regulator-haptic.c b/drivers/input/misc/regulator-haptic.c new file mode 100644 index 000..1a83ecb --- /dev/null +++ b/drivers/input/misc/regulator-haptic.c @@ -0,0 +1,241 @@ +/* + * Regulator haptic driver + * + * Copyright (c) 2014 Samsung Electronics Co., Ltd. + * Author: Jaewon Kim jaewon02@samsung.com + * Author: Hyunhee Kim hyunhee@samsung.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/module.h +#include linux/platform_device.h +#include linux/input.h +#include linux/slab.h +#include linux/regulator/consumer.h +#include linux/of.h + +#define MAX_MAGNITUDE_SHIFT16 + +struct regulator_haptic { + struct device *dev; + struct input_dev *input_dev; + struct regulator *regulator; + struct work_struct work; + + bool enabled; + bool suspend_state; I don't understand what you are tracking here. You only set it and unset this value but never do any checking + unsigned int max_volt; + unsigned int min_volt; + unsigned int intensity; + unsigned int magnitude; +}; + +static void
Re: [PATCH 1/2] drm/exynos: fix null pointer dereference issue
On 2014년 11월 21일 08:12, Gustavo Padovan wrote: 2014-11-13 Inki Dae inki@samsung.com: This patch fixes null pointer dereference issue incurred when ipp driver is enabled and Exynos drm driver is closed. Non kms driver should register its own sub driver to setup necessary resources, which is done by load(). So null pointer dereference occurs when ipp driver is enabled and Exynos drm driver is closed because ipp core device is registered after component_master_add_with_match call. This patch makes exynos_drm_device_subdrv_probe() to be called after all non kms drivers are registered. This patch is breaking exynos initialization, exynos_drm_device_subdrv_probe() needs the drvdata but it is still NULL at this point which make the whole exynos init fails. The drvdata is only set in exynos_drm_load() so we need call exynos_drm_device_subdrv_probe() after that. There might be my missing point but with this patch, exynos_drm_device_subdrv_probe() will be called after exynos_drm_load() call because all kms drivers are probed before component_master_add_with_match call so exynos_drm_load() must be called by component_master_add_with_match function before exynos_drm_device_subdrv_probe call. So could you show me the error messages you faced with? There might be a corner case I missed. Do you have the crash output for this? What is the issue you are fixing? Ok, below is the error messages, # modetest [5.653291] [ cut here ] [5.656469] WARNING: CPU: 2 PID: 1404 at kernel/locking/mutex.c:511 __mutex_lock_slowpath+0x3d4/0x3d8() [5.665816] DEBUG_LOCKS_WARN_ON(l-magic != l) [5.670069] Modules linked in: [5.673286] CPU: 2 PID: 1404 Comm: modetest Not tainted 3.18.0-rc3-146775-gbcfef97 #1149 [5.681389] [c0014400] (unwind_backtrace) from [c0011570] (show_stack+0x10/0x14) [5.689090] [c0011570] (show_stack) from [c0474060] (dump_stack+0x84/0xc4) [5.696304] [c0474060] (dump_stack) from [c0021918] (warn_slowpath_common+0x6c/0x88) [5.704364] [c0021918] (warn_slowpath_common) from [c0021964] (warn_slowpath_fmt+0x30/0x40) [5.713047] [c0021964] (warn_slowpath_fmt) from [c0477a4c] (__mutex_lock_slowpath+0x3d4/0x3d8) [5.721984] [c0477a4c] (__mutex_lock_slowpath) from [c0477a5c] (mutex_lock+0xc/0x24) [5.730069] [c0477a5c] (mutex_lock) from [c028e6fc] (ipp_subdrv_close+0x4c/0x13c) [5.737881] [c028e6fc] (ipp_subdrv_close) from [c027a51c] (exynos_drm_subdrv_close+0x3c/0x4c) [5.746731] [c027a51c] (exynos_drm_subdrv_close) from [c025eadc] (drm_release+0x94/0x4c8) [5.755228] [c025eadc] (drm_release) from [c00cbdd4] (__fput+0x80/0x1c8) [5.762268] [c00cbdd4] (__fput) from [c0037840] (task_work_run+0xac/0xe4) [5.769382] [c0037840] (task_work_run) from [c00110f8] (do_work_pending+0x94/0xb4) [5.777275] [c00110f8] (do_work_pending) from [c000e6e0] (work_pending+0xc/0x20) [5.784994] ---[ end trace bb48a41ae89d1f25 ]--- [5.789598] Unable to handle kernel NULL pointer dereference at virtual address [5.797664] pgd = ee3b8000 [5.800354] [] *pgd=6e366831, *pte=, *ppte= [5.806610] Internal error: Oops: 817 [#1] PREEMPT SMP ARM [5.812074] Modules linked in: [5.815117] CPU: 2 PID: 1404 Comm: modetest Tainted: GW 3.18.0-rc3-146775-gbcfef97 #1149 [5.824314] task: eea90800 ti: ee33c000 task.ti: ee33c000 [5.829704] PC is at __mutex_lock_slowpath+0xf4/0x3d8 [5.834730] LR is at __mutex_lock_slowpath+0xdc/0x3d8 [5.839765] pc : [c047776c]lr : [c0477754]psr: 8093 [5.839765] sp : ee33de88 ip : ee33de98 fp : c06cb814 [5.851220] r10: ee0f5854 r9 : c0700784 r8 : eea90800 [5.856429] r7 : ee33c008 r6 : 6013 r5 : ee0f5844 r4 : ee0f5840 [5.862938] r3 : r2 : r1 : ee33de88 r0 : ee0f5840 [5.869451] Flags: Nzcv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [5.876654] Control: 10c5387d Table: 6e3b804a DAC: 0015 [5.882383] Process modetest (pid: 1404, stack limit = 0xee33c240) [5.888544] Stack: (0xee33de88 to 0xee33e000) [5.892888] de80: ee0f5854 ee33de88 0001d030 ee0f5840 [5.901048] dea0: c06b1d94 ee0f5810 c0705e4c ee0eeb00 ee0f5840 ee0f5810 c0477a5c [5.909207] dec0: eeb4a510 c028e6fc ee14a434 eeb4a510 c06b2fe4 ee14a400 ee33c000 eeb4a510 [5.917366] dee0: c06b1d94 ee0eeb00 ee14a400 ee14a434 0008 ee0eea08 c027a51c [5.925525] df00: c0705e4c ee0eeb00 ee0eea00 ee14a400 ee14a434 c025eadc ee0eea08 0001 [5.933684] df20: eebce000 0021 ee0eea00 ee3354e0 [5.941843] df40: ee32a250 ee711428 0008 ee0eea08 c00cbdd4 [5.950002] df60: eea90b4c c06ca604 eea90800 c000e824 ee33c000 c0037840 [5.958161] df80: ee33c018 c000e824 ee33dfb0 ee33c000 c000e824 c00110f8 0003 0001 [5.966320] dfa0: beff0a4c 0006
Re: [PATCH v5 2/2] ARM: EXYNOS: PMU: move restart code into pmu driver
Hi Pankaj, On Tue, Nov 18, 2014 at 4:17 PM, Pankaj Dubey pankaj.du...@samsung.com wrote: Let's register restart handler from PMU driver for restart functionality. So that we can remove restart hooks from machine specific file, and thus moving ahead when PMU moved to driver folder, this functionality can be reused for ARM64 based Exynos SoC's. Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com Acked-by: Guenter Roeck li...@roeck-us.net --- Tested on Exynos5800 peach-pi board with linux-samsung/for-next. Reboot works as expected mutiple times. Tested-by: Vivek Gautam gautam.vi...@samsung.com arch/arm/mach-exynos/common.h |1 - arch/arm/mach-exynos/exynos.c |6 -- arch/arm/mach-exynos/pmu.c| 23 +++ 3 files changed, 23 insertions(+), 7 deletions(-) diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h index 431be1b..865f878 100644 --- a/arch/arm/mach-exynos/common.h +++ b/arch/arm/mach-exynos/common.h @@ -12,7 +12,6 @@ #ifndef __ARCH_ARM_MACH_EXYNOS_COMMON_H #define __ARCH_ARM_MACH_EXYNOS_COMMON_H -#include linux/reboot.h #include linux/of.h #define EXYNOS3250_SOC_ID 0xE3472000 diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c index 8f995b7..c13d083 100644 --- a/arch/arm/mach-exynos/exynos.c +++ b/arch/arm/mach-exynos/exynos.c @@ -87,11 +87,6 @@ static struct map_desc exynos5_iodesc[] __initdata = { }, }; -static void exynos_restart(enum reboot_mode mode, const char *cmd) -{ - __raw_writel(0x1, pmu_base_addr + EXYNOS_SWRESET); -} - static struct platform_device exynos_cpuidle = { .name = exynos_cpuidle, #ifdef CONFIG_ARM_EXYNOS_CPUIDLE @@ -316,7 +311,6 @@ DT_MACHINE_START(EXYNOS_DT, SAMSUNG EXYNOS (Flattened Device Tree)) .init_machine = exynos_dt_machine_init, .init_late = exynos_init_late, .dt_compat = exynos_dt_compat, - .restart= exynos_restart, .reserve= exynos_reserve, .dt_fixup = exynos_dt_fixup, MACHINE_END diff --git a/arch/arm/mach-exynos/pmu.c b/arch/arm/mach-exynos/pmu.c index 6c8a76d..e4c3512 100644 --- a/arch/arm/mach-exynos/pmu.c +++ b/arch/arm/mach-exynos/pmu.c @@ -11,8 +11,11 @@ #include linux/io.h #include linux/of.h +#include linux/of_address.h #include linux/platform_device.h #include linux/delay.h +#include linux/notifier.h +#include linux/reboot.h #include exynos-pmu.h @@ -716,6 +719,13 @@ static void exynos5420_pmu_init(void) pr_info(EXYNOS5420 PMU initialized\n); } +static int pmu_restart_notify(struct notifier_block *this, + unsigned long code, void *unused) +{ + pmu_raw_writel(0x1, EXYNOS_SWRESET); + + return NOTIFY_DONE; +} static const struct exynos_pmu_data exynos4210_pmu_data = { .pmu_config = exynos4210_pmu_config, @@ -765,11 +775,20 @@ static const struct of_device_id exynos_pmu_of_device_ids[] = { { /*sentinel*/ }, }; +/* + * Exynos PMU restart notifier, handles restart functionality + */ +static struct notifier_block pmu_restart_handler = { + .notifier_call = pmu_restart_notify, + .priority = 128, +}; + static int exynos_pmu_probe(struct platform_device *pdev) { const struct of_device_id *match; struct device *dev = pdev-dev; struct resource *res; + int ret; res = platform_get_resource(pdev, IORESOURCE_MEM, 0); pmu_base_addr = devm_ioremap_resource(dev, res); @@ -794,6 +813,10 @@ static int exynos_pmu_probe(struct platform_device *pdev) platform_set_drvdata(pdev, pmu_context); + ret = register_restart_handler(pmu_restart_handler); + if (ret) + dev_warn(dev, can't register restart handler err=%d\n, ret); + dev_dbg(dev, Exynos PMU Driver probe done\n); return 0; } -- 1.7.9.5 -- 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 -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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 v3 2/5] drivers: soc: Add support for Exynos PMU driver
On Thu, Nov 20, 2014 at 3:33 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Thu, Nov 20, 2014 at 11:09:25AM +0530, Amit Daniel Kachhap wrote: diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 063113d..44d220d 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -6,3 +6,4 @@ obj-$(CONFIG_ARCH_QCOM) += qcom/ obj-$(CONFIG_ARCH_TEGRA) += tegra/ obj-$(CONFIG_SOC_TI) += ti/ obj-$(CONFIG_PLAT_VERSATILE) += versatile/ +obj-$(CONFIG_ARCH_EXYNOS)+= samsung/ Is ARCH_EXYNOS appropriate here, or is your new SOC_SAMSUNG better? yes, SOC_SAMSUNG is more appropriate. diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig new file mode 100644 index 000..a424ebc --- /dev/null +++ b/drivers/soc/samsung/Kconfig @@ -0,0 +1,20 @@ +# +# SAMSUNG SOC drivers +# +menuconfig SOC_SAMSUNG + bool Samsung SOC drivers support If you intend to select SOC_SAMSUNG, is there any point in making this a user-visible symbol? Agreed, only menu Samsung SOC drivers support will be fine. Regards, Amit -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 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] spi: s3c64xx: add support for exynos7 SPI controller
Hi Mark, CS can also be controlled automatically by setting AUTO_N_MANUAL to 1 in CS_CFG. When it is auto CS automatically toggles between packet to packet. NCS_TIME_COUNT in CS_CFG controls the inactive period. The driver by default uses manual mode. But on exynos7 the manual mode is removed. OK, but what's a packet here? Packet is either 1 byte or 4 bytes size depends on width of the SPI channel. I tested the driver with wm5110 codec. Did you try firmware downloads or something else that generates multiple transfers in a message? Normal register writes will use a single transfer so I'd expect them to just work. OK. I don't have provision to test on this board. I will try to test on older boards by disabling manual mode. I tested on exynos5420 peach-pit by enabling auto mode. I used dd command to read 1MB data from spi flash and I compared the result with manual mode. Both are same. I also tested this patch with Javier Martinez Canillas patches for enabling spidev nodes from http://www.spinics.net/lists/linux-samsung-soc/msg39057.html. I read 4MB flashdata from spi by enabling auto mode and compared the result. They look same. Thanks padma -- 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 1/2] i2c: s3c2410: Handle i2c sys_cfg register in i2c driver
On Thu, Oct 30, 2014 at 01:34:29PM +0530, Pankaj Dubey wrote: Let's handle i2c interrupt re-configuration in i2c driver. This will help us in removing some soc specific checks from machine files and will help in removing static iomapping of SYS register in exynos.c Since only Exynos5250, and Exynos5420 has i2c nodes in DT, added syscon based phandle to i2c device nodes of respective SoC DT files. Also handle saving and restoring of SYS_I2C_CFG register during suspend and resume of i2c driver. CC: Rob Herring robh...@kernel.org CC: Randy Dunlap rdun...@infradead.org CC: Wolfram Sang w...@the-dreams.de CC: Russell King li...@arm.linux.org.uk CC: devicet...@vger.kernel.org CC: linux-...@vger.kernel.org CC: linux-...@vger.kernel.org Signed-off-by: Pankaj Dubey pankaj.du...@samsung.com --- .../devicetree/bindings/i2c/i2c-s3c2410.txt|1 + arch/arm/boot/dts/exynos5250.dtsi |4 +++ arch/arm/boot/dts/exynos5420.dtsi |4 +++ I usually don't take DTS patches. They should go via arm-soc. Please say so if there are reasons I should take them. @@ -1084,6 +1092,23 @@ s3c24xx_i2c_parse_dt(struct device_node *np, struct s3c24xx_i2c *i2c) of_property_read_u32(np, samsung,i2c-slave-addr, pdata-slave_addr); of_property_read_u32(np, samsung,i2c-max-bus-freq, (u32 *)pdata-frequency); + /* + * Exynos5's legacy i2c controller and new high speed i2c + * controller have muxed interrupt sources. By default the + * interrupts for 4-channel HS-I2C controller are enabled. + * If node for first four channels of legacy i2c controller s/node/nodes/ + * are available then re-configure the interrupts via the + * system register. + */ + id = of_alias_get_id(np, i2c); + i2c-sysreg = syscon_regmap_lookup_by_phandle(np, + samsung,sysreg-phandle); + if (IS_ERR(i2c-sysreg)) { + /* As this is not compulsory do not return error */ + pr_info(i2c-%d skipping re-configuration of interrutps\n, id); I'd say drop this message. If you want to keep it, it should be dev_dbg. + return; + } + regmap_update_bits(i2c-sysreg, EXYNOS5_SYS_I2C_CFG, BIT(id), 0); } Rest looks good, thanks! signature.asc Description: Digital signature