[RESEND PATCH v2 1/3] ARM: EXYNOS: Handle of of_iomap() failure
From: Krzysztof Kozlowski k.kozlow...@samsung.com
Prevent possible NULL pointer dereference if of_iomap() fails. Handle
the error by skipping such power domain.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Changes since v1:
1. Add missing kfree() of domain name (allocated with kstrdup()).
---
arch/arm/mach-exynos/pm_domains.c | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index cbe56b35aea0..14622b5f4481 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -138,6 +138,14 @@ static __init int exynos4_pm_init_power_domain(void)
pd-pd.name = kstrdup(dev_name(dev), GFP_KERNEL);
pd-name = pd-pd.name;
pd-base = of_iomap(np, 0);
+ if (!pd-base) {
+ dev_warn(pdev-dev, Failed to map memory\n);
+ kfree(pd-pd.name);
+ kfree(pd);
+ of_node_put(np);
+ continue;
+ }
+
pd-pd.power_off = exynos_pd_power_off;
pd-pd.power_on = exynos_pd_power_on;
--
2.1.0
--
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: drm/exynos: getting the video processor to work
Hi Tobias, On 2015년 04월 22일 21:23, Tobias Jakobi wrote: Hello Inki and Joonyoung, On 2015-04-22 08:02, Inki Dae wrote: On 2015년 04월 22일 10:55, Joonyoung Shim wrote: Hi Tobias, On 04/21/2015 06:30 AM, Tobias Jakobi wrote: Hello, I've spend some time on figuring out how to use the VP on my Exynos4412. I noticed that currently it seems to be pretty broken (I've put a full crashlog with drm.debug=0xff at the end). As far as I can see, the problem stems from conflicting buffer counts in the driver. Let's start with vp_video_buffer(), there buf_num gets set to '2' when DRM_FORMAT_NV12 is encountered as pixelformat. Which results in the VP reading luma data from the plane's dma_addr[0] and chroma from dma_addr[1]. But dma_addr[1] is never correctly set. It should be set by exynos_check_plane(), but the loop only does one iteration since exynos_drm_fb_get_buf_cnt() returns 1. Which is due to special case handling in exynos_drm_format_num_buffers(). At least for the buffers that libdrm's modetest creates this case handling triggers and reduces buffer count to '1'. This is just pixel format issue and mixer driver is not completed about that. The exynos mixer can support two NV12 formats. To clarify it, NV12 and other NVXX formats have only two planes. That was also my impression. NV12 and NV21 are always bi-planar, with the only difference that NV21 has U/V order reversed (when comparing it to NV12). There is no uni-planar NV12/NV21. See also: https://wiki.videolan.org/YUV#NV12.2FNV21 Right. However, there is a case that we should consider for Exynos SoC. Exynos SoC has a Hardware video codec which is called MFC. This hardware can use a special function for improving decoding and encoding performance, which makes it possible for Y and CbCr data are placed in separated memory banks. So for this, a V4L2 guy of Samsung added a new format - NV12M - to v4l2 fourcc header. AFAIK, the pixels of NV12 format would consist into, yy yy uvuvuvuvu The memory region of each data - y or uv - is continuous each other. In this case, the base address of each gem buffer is same. On the other hand, the pixels of NV12M consist into, yy yy . uvuvuvuvu The memory region of each data - y or uv - isn't continuous each other. So Exynos driver identifies image format according to two cases above. In this case, the base address of each gem buffer is different. For more information, refer to exynos_drm_format_num_buffers function. First, NV12 format having just one buffer(Y plane and CbCr plane use a same buffer but differ their start index.) So it is called packed YUV format and drm_fourcc header defines these formats as follows, DRM_FORMAT_YUYV DRM_FORMAT_YVYU DRM_FORMAT_UYVY DRM_FORMAT_VYUY DRM_FORMAT_AYUV I'd like to know if any other formats except for NV12/NV21 are really supported by the video processor? Because I don't see any indication for First, above my comment was wrong. For this, I sent email again. Anyway, only NV12/NV21 + NV12/21 tiled are supported - this format contains macro blocks, which is specific to MFC (Hardware Video codec for Exynos SoC). However, we should consider NV12M format as I mentioned above. that. It's just NV12/NV21 and the tiled variants, which are there to make it easier to handle data from the MFC block. Second, NV12 format having split two buffers(one is for Y plane, other is for CbCr plane) All NVXX formats should be considered only for separated two buffers. Does is even make any difference for the VP if luma and chroma are in different buffers or in a single one, just with an offset between luma/chroma? I think not, because the VP just gets a dma_addr for both and then fetches data from that position. Current mixer driver considers only second NV12 format, we can know it from following comment in mixer driver. /* TODO: single buffer format NV12, NV21 */ So, it seems like wrong comment. Until now, it seems that we have been calling the packed YUV format as NVXX format and calling the NVXX format as NVXXM. And Exynos SoC have even NVXXMT whose format consists into many macro blocks and which has separated two buffers. I think getting just regular (un-tiled) NV12/NV21 working should come first, then we can think about how to handle the tiled formats (probably with the newly introduced fb modifiers). Already commented above. Thanks, Inki Dae I've patched the mixer so that it passes valid pointers for luma/chroma but I still get a crash (sysmmu) sooner or later. So there seems to be more issues than just this pixelformat/buffercount one. We would need to make Exynos drivers suitable to fourcc. Thanks, Inki Dae With best wishes, Tobias -- 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: drm/exynos: getting the video processor to work
Hello Inki, On 2015-04-22 16:26, Inki Dae wrote: Right. However, there is a case that we should consider for Exynos SoC. Exynos SoC has a Hardware video codec which is called MFC. This hardware can use a special function for improving decoding and encoding performance, which makes it possible for Y and CbCr data are placed in separated memory banks. So for this, a V4L2 guy of Samsung added a new format - NV12M - to v4l2 fourcc header. AFAIK, the pixels of NV12 format would consist into, yy yy uvuvuvuvu The memory region of each data - y or uv - is continuous each other. In this case, the base address of each gem buffer is same. On the other hand, the pixels of NV12M consist into, yy yy . uvuvuvuvu The memory region of each data - y or uv - isn't continuous each other. So Exynos driver identifies image format according to two cases above. In this case, the base address of each gem buffer is different. For more information, refer to exynos_drm_format_num_buffers function. I don't see how this is relevant here. The VP doesn't gain anything from the fact that it can pull data from different memory banks. It's just the MFC that benefits from that. Why does the VP need to know whether the data is NV12 or NV12M? When we get this data from userspace, then in the case of NV12 we always get two planes (yielding two handles, two pitches, two offsets). The VP then gets configured with two dma_addr, one for luma plane, one for chroma. If luma and chroma are contiguous in memory doesn't make any difference here. Correct me if I'm wrong, but I think this whole NV12/NV12M business is strictly related to the video decoding / v4l2 side. Anyway, only NV12/NV21 + NV12/21 tiled are supported - this format contains macro blocks, which is specific to MFC (Hardware Video codec for Exynos SoC). However, we should consider NV12M format as I mentioned above. Thanks for the confirmation, but as I said above, I don't see why we should consider NV12M for the DRM / presentation side. With best wishes, Tobias -- 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: drm/exynos: getting the video processor to work
On 2015년 04월 22일 10:55, Joonyoung Shim wrote: Hi Tobias, On 04/21/2015 06:30 AM, Tobias Jakobi wrote: Hello, I've spend some time on figuring out how to use the VP on my Exynos4412. I noticed that currently it seems to be pretty broken (I've put a full crashlog with drm.debug=0xff at the end). As far as I can see, the problem stems from conflicting buffer counts in the driver. Let's start with vp_video_buffer(), there buf_num gets set to '2' when DRM_FORMAT_NV12 is encountered as pixelformat. Which results in the VP reading luma data from the plane's dma_addr[0] and chroma from dma_addr[1]. But dma_addr[1] is never correctly set. It should be set by exynos_check_plane(), but the loop only does one iteration since exynos_drm_fb_get_buf_cnt() returns 1. Which is due to special case handling in exynos_drm_format_num_buffers(). At least for the buffers that libdrm's modetest creates this case handling triggers and reduces buffer count to '1'. This is just pixel format issue and mixer driver is not completed about that. The exynos mixer can support two NV12 formats. To clarify it, NV12 and other NVXX formats have only two planes. First, NV12 format having just one buffer(Y plane and CbCr plane use a same buffer but differ their start index.) So it is called packed YUV format and drm_fourcc header defines these formats as follows, DRM_FORMAT_YUYV DRM_FORMAT_YVYU DRM_FORMAT_UYVY DRM_FORMAT_VYUY DRM_FORMAT_AYUV Second, NV12 format having split two buffers(one is for Y plane, other is for CbCr plane) All NVXX formats should be considered only for separated two buffers. Current mixer driver considers only second NV12 format, we can know it from following comment in mixer driver. /* TODO: single buffer format NV12, NV21 */ So, it seems like wrong comment. Until now, it seems that we have been calling the packed YUV format as NVXX format and calling the NVXX format as NVXXM. And Exynos SoC have even NVXXMT whose format consists into many macro blocks and which has separated two buffers. We would need to make Exynos drivers suitable to fourcc. Thanks, Inki Dae -- 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/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform
On Tuesday, April 21, 2015 04:45:56 PM Kevin Hilman wrote: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com writes: On Monday, April 20, 2015 02:07:33 PM Kevin Hilman wrote: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com writes: Hi, This patch series removes the use of Exynos5250 specific support from exynos-cpufreq driver and enables the use of cpufreq-dt driver for this platform. The exynos-cpufreq driver itself is also removed as it is no longer used/needed after Exynos5250 support removal. This patch series has been tested on Exynos5250 based Arndale board. Depends on: - next-20150330 branch of linux-next kernel tree - [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210 platform [1] - [PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform [2] - [PATCH] cpufreq: exynos: remove dead -need_apll_change method [3] Any chance you could prepare a branch with all the dependencies for easy testing? All cpufreq changes with needed dependencies are now availble in https://github.com/bzolnier/linux.git repository and the branch is next-20150330-generic-cpufreq-exynos5420-5800-v2 Great, thanks. Also, The previous version from Thomas was v12, and this one is neither versioned nor has any reference to what may have changed since that Please note that Thomas' patchset was split on separate parts (this is part #3) and heavily modified so the previous versioning was dropped. The cover letter of part #1 ([PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4210 platform) contains detailed changelog on what has been changed since Thomas' original v12 patch series. Individual Thomas' patches which were modified by me also contain such information. Part #2 ([PATCH 0/6] cpufreq: use generic cpufreq drivers for Exynos4x12 platform) was entirely new code when compared to Thomas' v12 patchset so its cover letter doesn't contain such detailed changelog as part #1. The newly posted part #4 ([PATCH 0/8] cpufreq: add generic cpufreq driver support for Exynos5250/5800 platforms https://lkml.org/lkml/2015/4/21/314) also contains the detailed changelog. However for part #3 (this one, [PATCH 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform) such summary changelog got missed for some reason. Here it is: - split Exynos5250 support from the original patch - moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c - added CPU regulator supply property for Google Spring board - removed exynos-cpufreq driver entirely as it is no longer used/needed Great, thanks for clarifying. version. Also, on v12, I had several comments[1] and wonder if they've been addressed. All issues previously reported should have been fixed. If you still see some problems please let me know. [ I see now that exynos5420-arndale-octa.dts, exynos5420-peach-pit.dts, exynos5420-smdk5420.dts and exynos5800-peach-pi.dts should also have been updated to contain CPU cluster regulator supply properties or else if the default vdd_arm/vdd_kfc regulator state is set to too low value there may be problems with stability when switching to higher than default frequencies. I have posted v2 version of patch #2/8 of part #4 and pushed v2 combined branch on github. Sorry for the inconvenience. ] I've now tested your v2 branch with the bL switcher disabled, CPUidle enabled and CPUfreq enabled. With the default governor set to performance, it fails to boot. The last kernel messages on the console are: [ Small explanation for people not following the discussion from the start: This testing is relevant to part #4 of the rework: [PATCH 0/8] cpufreq: add generic cpufreq driver support for Exynos5250/5800 platforms (https://lkml.org/lkml/2015/4/21/314;), not this one which is part #3 and has no known issues. ] [...] [3.426021] cpu cpu0: bL_cpufreq_init: CPU 0 initialized [3.431189] cpu cpu4: bL_cpufreq_init: CPU 4 initialized However, with the default governor set to userspace it boots fine until my userspace (ubuntu) tries to enable the ondemand governor, and then it hangs. For it to boot, I have to disable the ondemand governor, and set the default governor to userspace. I've tried with ARM big.LITTLE cpuidle support enabled (I've just noticed that it is not turned on in exynos_defconfig) and my ODROID-XU3 board fails to boot. This happens even with cpufreq support disabled (hard lockup happens during mmc initialization which is done just after cpufreq initialization). Could you please check if disabling cpuidle support helps? As I reported earlier on Thomas' series, I suspect this is related to the fact that the higher OPPs aren't really functional without voltage scaling also supported. Part #4 contains voltage scaling support for arm_big_little[_dt] driver so this should not be a
[PATCH] ARM: exynos: Fix wake-up interrupts for Exynos3250
Commit 8b283c025443 (ARM: exynos4/5: convert pmu wakeup to
stacked domains) changed the Exynos PMU code to use stacked
domains. This has led to a number of interrupt numbers to be
fixed.
In the meantime, support for Exynos 3250 was added, missing
the required change to this platform. This amounts to revert
ace283a04a4a (ARM: EXYNOS: Fix wrong hwirq of RTC interrupt
for Exynos3250 SoC), as the initial patch was right, just a
bit early...
Cc: Chanwoo Choi cw00.c...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Kukjin Kim kg...@kernel.org
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/mach-exynos/suspend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index 3e6aea7..40dce36 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -87,8 +87,8 @@ static unsigned int exynos_pmu_spare3;
static u32 exynos_irqwake_intmask = 0x;
static const struct exynos_wkup_irq exynos3250_wkup_irq[] = {
- { 105, BIT(1) }, /* RTC alarm */
- { 106, BIT(2) }, /* RTC tick */
+ { 73, BIT(1) }, /* RTC alarm */
+ { 74, BIT(2) }, /* RTC tick */
{ /* sentinel */ },
};
--
2.1.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: drm/exynos: getting the video processor to work
Hi Tobias, On 04/22/2015 11:56 PM, Tobias Jakobi wrote: Hello Inki, On 2015-04-22 16:26, Inki Dae wrote: Right. However, there is a case that we should consider for Exynos SoC. Exynos SoC has a Hardware video codec which is called MFC. This hardware can use a special function for improving decoding and encoding performance, which makes it possible for Y and CbCr data are placed in separated memory banks. So for this, a V4L2 guy of Samsung added a new format - NV12M - to v4l2 fourcc header. AFAIK, the pixels of NV12 format would consist into, yy yy uvuvuvuvu The memory region of each data - y or uv - is continuous each other. In this case, the base address of each gem buffer is same. On the other hand, the pixels of NV12M consist into, yy yy . uvuvuvuvu The memory region of each data - y or uv - isn't continuous each other. So Exynos driver identifies image format according to two cases above. In this case, the base address of each gem buffer is different. For more information, refer to exynos_drm_format_num_buffers function. I don't see how this is relevant here. The VP doesn't gain anything from the fact that it can pull data from different memory banks. It's just the MFC that benefits from that. Why does the VP need to know whether the data is NV12 or NV12M? When we get this data from userspace, then in the case of NV12 we always get two planes (yielding two handles, two pitches, two offsets). The VP then gets configured with two dma_addr, one for luma plane, one for chroma. If luma and chroma are contiguous in memory doesn't make any difference here. I feel it is just each other different implementation issue, not right and wrong. If you are interested, could you please make a patch to support NV12 format(including NV12M)? Maybe will have to modify or remove exynos_drm_format_num_buffers function and delivery each buffer informations to mixer driver via struct exynos_drm_plane. I think it's not difficult to do. Thanks. Correct me if I'm wrong, but I think this whole NV12/NV12M business is strictly related to the video decoding / v4l2 side. Anyway, only NV12/NV21 + NV12/21 tiled are supported - this format contains macro blocks, which is specific to MFC (Hardware Video codec for Exynos SoC). However, we should consider NV12M format as I mentioned above. Thanks for the confirmation, but as I said above, I don't see why we should consider NV12M for the DRM / presentation side. With best wishes, Tobias -- 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] ARM: exynos: Fix wake-up interrupts for Exynos3250
2015-04-23 2:40 GMT+09:00 Marc Zyngier marc.zyng...@arm.com: Commit 8b283c025443 (ARM: exynos4/5: convert pmu wakeup to stacked domains) changed the Exynos PMU code to use stacked domains. This has led to a number of interrupt numbers to be fixed. In the meantime, support for Exynos 3250 was added, missing the required change to this platform. This amounts to revert ace283a04a4a (ARM: EXYNOS: Fix wrong hwirq of RTC interrupt for Exynos3250 SoC), as the initial patch was right, just a bit early... Cc: Chanwoo Choi cw00.c...@samsung.com Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: Kukjin Kim kg...@kernel.org Signed-off-by: Marc Zyngier marc.zyng...@arm.com --- arch/arm/mach-exynos/suspend.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com Thanks for fixing this! Best regards, Krzysztof -- 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] ARM: exynos: Fix wake-up interrupts for Exynos3250
Hi Marc,
On 04/23/2015 02:40 AM, Marc Zyngier wrote:
Commit 8b283c025443 (ARM: exynos4/5: convert pmu wakeup to
stacked domains) changed the Exynos PMU code to use stacked
domains. This has led to a number of interrupt numbers to be
fixed.
In the meantime, support for Exynos 3250 was added, missing
the required change to this platform. This amounts to revert
ace283a04a4a (ARM: EXYNOS: Fix wrong hwirq of RTC interrupt
for Exynos3250 SoC), as the initial patch was right, just a
bit early...
Cc: Chanwoo Choi cw00.c...@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Krzysztof Kozlowski k.kozlow...@samsung.com
Cc: Kukjin Kim kg...@kernel.org
Signed-off-by: Marc Zyngier marc.zyng...@arm.com
---
arch/arm/mach-exynos/suspend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-exynos/suspend.c b/arch/arm/mach-exynos/suspend.c
index 3e6aea7..40dce36 100644
--- a/arch/arm/mach-exynos/suspend.c
+++ b/arch/arm/mach-exynos/suspend.c
@@ -87,8 +87,8 @@ static unsigned int exynos_pmu_spare3;
static u32 exynos_irqwake_intmask = 0x;
static const struct exynos_wkup_irq exynos3250_wkup_irq[] = {
- { 105, BIT(1) }, /* RTC alarm */
- { 106, BIT(2) }, /* RTC tick */
+ { 73, BIT(1) }, /* RTC alarm */
+ { 74, BIT(2) }, /* RTC tick */
{ /* sentinel */ },
};
Reviewed-by: Chanwoo Choi cw00.c...@samsung.com
Thanks,
Chanwoo Choi
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 1/4] phy: phy-core: Make GENERIC_PHY an invisible option
Most of the phy providers use select to enable GENERIC_PHY. Since select is only recommended when the config is not visible, GENERIC_PHY is changed an invisible option. To maintain consistency, all phy providers are changed to select GENERIC_PHY and all non-phy drivers use depends on when the phy framework is explicity required. USB_MUSB_OMAP2PLUS has a cyclic dependency, so it is left as select. Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com --- drivers/ata/Kconfig | 1 - drivers/media/platform/exynos4-is/Kconfig | 2 +- drivers/phy/Kconfig | 4 ++-- drivers/usb/host/Kconfig | 4 ++-- drivers/video/fbdev/exynos/Kconfig| 2 +- 5 files changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 5f60155..6d2e881 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -301,7 +301,6 @@ config SATA_MV tristate Marvell SATA support depends on PCI || ARCH_DOVE || ARCH_MV78XX0 || \ ARCH_MVEBU || ARCH_ORION5X || COMPILE_TEST - select GENERIC_PHY help This option enables support for the Marvell Serial ATA family. Currently supports 88SX[56]0[48][01] PCI(-X) chips, diff --git a/drivers/media/platform/exynos4-is/Kconfig b/drivers/media/platform/exynos4-is/Kconfig index b7b2e47..b6f3eaa 100644 --- a/drivers/media/platform/exynos4-is/Kconfig +++ b/drivers/media/platform/exynos4-is/Kconfig @@ -31,7 +31,7 @@ config VIDEO_S5P_FIMC config VIDEO_S5P_MIPI_CSIS tristate S5P/EXYNOS MIPI-CSI2 receiver (MIPI-CSIS) driver depends on REGULATOR - select GENERIC_PHY + depends on GENERIC_PHY help This is a V4L2 driver for Samsung S5P and EXYNOS4 SoC MIPI-CSI2 receiver (MIPI-CSIS) devices. diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 2962de2..edecdb1 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -5,7 +5,7 @@ menu PHY Subsystem config GENERIC_PHY - bool PHY Core + bool help Generic PHY support. @@ -72,7 +72,7 @@ config PHY_MIPHY365X config PHY_RCAR_GEN2 tristate Renesas R-Car generation 2 USB PHY driver depends on ARCH_SHMOBILE - depends on GENERIC_PHY + select GENERIC_PHY help Support for USB PHY found on Renesas R-Car generation 2 SoCs. diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig index 5ad60e4..e2197e2 100644 --- a/drivers/usb/host/Kconfig +++ b/drivers/usb/host/Kconfig @@ -182,7 +182,7 @@ config USB_EHCI_HCD_SPEAR config USB_EHCI_HCD_STI tristate Support for ST STiHxxx on-chip EHCI USB controller depends on ARCH_STI OF - select GENERIC_PHY + depends on GENERIC_PHY select USB_EHCI_HCD_PLATFORM help Enable support for the on-chip EHCI controller found on @@ -409,7 +409,7 @@ config USB_OHCI_HCD_SPEAR config USB_OHCI_HCD_STI tristate Support for ST STiHxxx on-chip OHCI USB controller depends on ARCH_STI OF - select GENERIC_PHY + depends on GENERIC_PHY select USB_OHCI_HCD_PLATFORM help Enable support for the on-chip OHCI controller found on diff --git a/drivers/video/fbdev/exynos/Kconfig b/drivers/video/fbdev/exynos/Kconfig index 1f16b46..6c53894 100644 --- a/drivers/video/fbdev/exynos/Kconfig +++ b/drivers/video/fbdev/exynos/Kconfig @@ -16,7 +16,7 @@ if EXYNOS_VIDEO config EXYNOS_MIPI_DSI bool EXYNOS MIPI DSI driver support. - select GENERIC_PHY + depends on GENERIC_PHY help This enables support for MIPI-DSI device. -- 2.3.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
[PATCHv3 3/4] usb: ehci-platform: Use devm_of_phy_get_by_index
Getting phys by index instead of phy names so that we do
not have to create a naming scheme when multiple phys
are present
Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com
Reviewed-by: Ray Jui r...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
---
drivers/usb/host/ehci-platform.c | 69 ++--
1 file changed, 24 insertions(+), 45 deletions(-)
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index d8a75a5..145bf19 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -88,15 +88,13 @@ static int ehci_platform_power_on(struct platform_device
*dev)
}
for (phy_num = 0; phy_num priv-num_phys; phy_num++) {
- if (priv-phys[phy_num]) {
- ret = phy_init(priv-phys[phy_num]);
- if (ret)
- goto err_exit_phy;
- ret = phy_power_on(priv-phys[phy_num]);
- if (ret) {
- phy_exit(priv-phys[phy_num]);
- goto err_exit_phy;
- }
+ ret = phy_init(priv-phys[phy_num]);
+ if (ret)
+ goto err_exit_phy;
+ ret = phy_power_on(priv-phys[phy_num]);
+ if (ret) {
+ phy_exit(priv-phys[phy_num]);
+ goto err_exit_phy;
}
}
@@ -104,10 +102,8 @@ static int ehci_platform_power_on(struct platform_device
*dev)
err_exit_phy:
while (--phy_num = 0) {
- if (priv-phys[phy_num]) {
- phy_power_off(priv-phys[phy_num]);
- phy_exit(priv-phys[phy_num]);
- }
+ phy_power_off(priv-phys[phy_num]);
+ phy_exit(priv-phys[phy_num]);
}
err_disable_clks:
while (--clk = 0)
@@ -123,10 +119,8 @@ static void ehci_platform_power_off(struct platform_device
*dev)
int clk, phy_num;
for (phy_num = 0; phy_num priv-num_phys; phy_num++) {
- if (priv-phys[phy_num]) {
- phy_power_off(priv-phys[phy_num]);
- phy_exit(priv-phys[phy_num]);
- }
+ phy_power_off(priv-phys[phy_num]);
+ phy_exit(priv-phys[phy_num]);
}
for (clk = EHCI_MAX_CLKS - 1; clk = 0; clk--)
@@ -154,7 +148,6 @@ static int ehci_platform_probe(struct platform_device *dev)
struct usb_ehci_pdata *pdata = dev_get_platdata(dev-dev);
struct ehci_platform_priv *priv;
struct ehci_hcd *ehci;
- const char *phy_name;
int err, irq, phy_num, clk = 0;
if (usb_disabled())
@@ -204,36 +197,22 @@ static int ehci_platform_probe(struct platform_device
*dev)
priv-num_phys = of_count_phandle_with_args(dev-dev.of_node,
phys, #phy-cells);
- priv-num_phys = priv-num_phys 0 ? priv-num_phys : 1;
- priv-phys = devm_kcalloc(dev-dev, priv-num_phys,
- sizeof(struct phy *), GFP_KERNEL);
- if (!priv-phys)
- return -ENOMEM;
+ if (priv-num_phys 0) {
+ priv-phys = devm_kcalloc(dev-dev, priv-num_phys,
+ sizeof(struct phy *), GFP_KERNEL);
+ if (!priv-phys)
+ return -ENOMEM;
+ } else
+ priv-num_phys = 0;
for (phy_num = 0; phy_num priv-num_phys; phy_num++) {
- err = of_property_read_string_index(
- dev-dev.of_node,
- phy-names, phy_num,
- phy_name);
-
- if (err 0) {
- if (priv-num_phys 1) {
- dev_err(dev-dev, phy-names
not provided);
- goto err_put_hcd;
- } else
- phy_name = usb;
- }
-
- priv-phys[phy_num] = devm_phy_get(dev-dev,
- phy_name);
- if (IS_ERR(priv-phys[phy_num])) {
- err = PTR_ERR(priv-phys[phy_num]);
- if ((priv-num_phys 1) ||
- (err == -EPROBE_DEFER))
- goto err_put_hcd;
- priv-phys[phy_num] = NULL;
- }
+
[PATCHv3 4/4] usb: ohci-platform: Use devm_of_phy_get_by_index
Getting phys by index instead of phy names so that we do
not have to create a naming scheme when multiple phys are present
Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com
Reviewed-by: Ray Jui r...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
---
drivers/usb/host/ohci-platform.c | 69 ++--
1 file changed, 24 insertions(+), 45 deletions(-)
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index 185ceee..c2669f18 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -57,15 +57,13 @@ static int ohci_platform_power_on(struct platform_device
*dev)
}
for (phy_num = 0; phy_num priv-num_phys; phy_num++) {
- if (priv-phys[phy_num]) {
- ret = phy_init(priv-phys[phy_num]);
- if (ret)
- goto err_exit_phy;
- ret = phy_power_on(priv-phys[phy_num]);
- if (ret) {
- phy_exit(priv-phys[phy_num]);
- goto err_exit_phy;
- }
+ ret = phy_init(priv-phys[phy_num]);
+ if (ret)
+ goto err_exit_phy;
+ ret = phy_power_on(priv-phys[phy_num]);
+ if (ret) {
+ phy_exit(priv-phys[phy_num]);
+ goto err_exit_phy;
}
}
@@ -73,10 +71,8 @@ static int ohci_platform_power_on(struct platform_device
*dev)
err_exit_phy:
while (--phy_num = 0) {
- if (priv-phys[phy_num]) {
- phy_power_off(priv-phys[phy_num]);
- phy_exit(priv-phys[phy_num]);
- }
+ phy_power_off(priv-phys[phy_num]);
+ phy_exit(priv-phys[phy_num]);
}
err_disable_clks:
while (--clk = 0)
@@ -92,10 +88,8 @@ static void ohci_platform_power_off(struct platform_device
*dev)
int clk, phy_num;
for (phy_num = 0; phy_num priv-num_phys; phy_num++) {
- if (priv-phys[phy_num]) {
- phy_power_off(priv-phys[phy_num]);
- phy_exit(priv-phys[phy_num]);
- }
+ phy_power_off(priv-phys[phy_num]);
+ phy_exit(priv-phys[phy_num]);
}
for (clk = OHCI_MAX_CLKS - 1; clk = 0; clk--)
@@ -123,7 +117,6 @@ static int ohci_platform_probe(struct platform_device *dev)
struct usb_ohci_pdata *pdata = dev_get_platdata(dev-dev);
struct ohci_platform_priv *priv;
struct ohci_hcd *ohci;
- const char *phy_name;
int err, irq, phy_num, clk = 0;
if (usb_disabled())
@@ -174,36 +167,22 @@ static int ohci_platform_probe(struct platform_device
*dev)
priv-num_phys = of_count_phandle_with_args(dev-dev.of_node,
phys, #phy-cells);
- priv-num_phys = priv-num_phys 0 ? priv-num_phys : 1;
- priv-phys = devm_kcalloc(dev-dev, priv-num_phys,
- sizeof(struct phy *), GFP_KERNEL);
- if (!priv-phys)
- return -ENOMEM;
+ if (priv-num_phys 0) {
+ priv-phys = devm_kcalloc(dev-dev, priv-num_phys,
+ sizeof(struct phy *), GFP_KERNEL);
+ if (!priv-phys)
+ return -ENOMEM;
+ } else
+ priv-num_phys = 0;
for (phy_num = 0; phy_num priv-num_phys; phy_num++) {
- err = of_property_read_string_index(
- dev-dev.of_node,
- phy-names, phy_num,
- phy_name);
-
- if (err 0) {
- if (priv-num_phys 1) {
- dev_err(dev-dev, phy-names
not provided);
- goto err_put_hcd;
- } else
- phy_name = usb;
- }
-
- priv-phys[phy_num] = devm_phy_get(dev-dev,
- phy_name);
- if (IS_ERR(priv-phys[phy_num])) {
- err = PTR_ERR(priv-phys[phy_num]);
- if ((priv-num_phys 1) ||
- (err == -EPROBE_DEFER))
- goto err_put_hcd;
- priv-phys[phy_num] = NULL;
- }
+
[PATCHv3 2/4] phy: core: Add devm_of_phy_get_by_index to phy-core
Some generic drivers, such as ehci, may use multiple phys and for such
drivers referencing phy(s) by name(s) does not make sense. Instead of
inventing new naming schemes and using custom code to iterate through them,
such drivers are better of using nameless phy bindings and using this newly
introduced API to iterate through them.
Signed-off-by: Arun Ramamurthy arun.ramamur...@broadcom.com
Reviewed-by: Ray Jui r...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
---
Documentation/phy.txt | 7 ++-
drivers/phy/phy-core.c | 32
include/linux/phy/phy.h | 8
3 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
index 371361c..b388c5a 100644
--- a/Documentation/phy.txt
+++ b/Documentation/phy.txt
@@ -76,6 +76,8 @@ struct phy *phy_get(struct device *dev, const char *string);
struct phy *phy_optional_get(struct device *dev, const char *string);
struct phy *devm_phy_get(struct device *dev, const char *string);
struct phy *devm_phy_optional_get(struct device *dev, const char *string);
+struct phy *devm_of_phy_get_by_index(struct device *dev, struct device_node
*np,
+int index);
phy_get, phy_optional_get, devm_phy_get and devm_phy_optional_get can
be used to get the PHY. In the case of dt boot, the string arguments
@@ -86,7 +88,10 @@ successful PHY get. On driver detach, release function is
invoked on
the the devres data and devres data is freed. phy_optional_get and
devm_phy_optional_get should be used when the phy is optional. These
two functions will never return -ENODEV, but instead returns NULL when
-the phy cannot be found.
+the phy cannot be found.Some generic drivers, such as ehci, may use multiple
+phys and for such drivers referencing phy(s) by name(s) does not make sense. In
+this case, devm_of_phy_get_by_index can be used to get a phy reference based on
+the index.
It should be noted that NULL is a valid phy reference. All phy
consumer calls on the NULL phy become NOPs. That is the release calls,
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 3791838..964a84d 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -623,6 +623,38 @@ struct phy *devm_of_phy_get(struct device *dev, struct
device_node *np,
EXPORT_SYMBOL_GPL(devm_of_phy_get);
/**
+ * devm_of_phy_get_by_index() - lookup and obtain a reference to a phy by
index.
+ * @dev: device that requests this phy
+ * @np: node containing the phy
+ * @index: index of the phy
+ *
+ * Gets the phy using _of_phy_get(), and associates a device with it using
+ * devres. On driver detach, release function is invoked on the devres data,
+ * then, devres data is freed.
+ *
+ */
+struct phy *devm_of_phy_get_by_index(struct device *dev, struct device_node
*np,
+int index)
+{
+ struct phy **ptr, *phy;
+
+ ptr = devres_alloc(devm_phy_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ phy = _of_phy_get(np, index);
+ if (!IS_ERR(phy)) {
+ *ptr = phy;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return phy;
+}
+EXPORT_SYMBOL_GPL(devm_of_phy_get_by_index);
+
+/**
* phy_create() - create a new phy
* @dev: device that is creating the new phy
* @node: device node of the phy
diff --git a/include/linux/phy/phy.h b/include/linux/phy/phy.h
index a0197fa..978d5af 100644
--- a/include/linux/phy/phy.h
+++ b/include/linux/phy/phy.h
@@ -133,6 +133,8 @@ struct phy *devm_phy_get(struct device *dev, const char
*string);
struct phy *devm_phy_optional_get(struct device *dev, const char *string);
struct phy *devm_of_phy_get(struct device *dev, struct device_node *np,
const char *con_id);
+struct phy *devm_of_phy_get_by_index(struct device *dev, struct device_node
*np,
+int index);
void phy_put(struct phy *phy);
void devm_phy_put(struct device *dev, struct phy *phy);
struct phy *of_phy_get(struct device_node *np, const char *con_id);
@@ -261,6 +263,12 @@ static inline struct phy *devm_of_phy_get(struct device
*dev,
return ERR_PTR(-ENOSYS);
}
+struct phy *devm_of_phy_get_by_index(struct device *dev, struct device_node
*np,
+int index);
+{
+ return ERR_PTR(-ENOSYS);
+}
+
static inline void phy_put(struct phy *phy)
{
}
--
2.3.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: [PATCH 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform
Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com writes:
[...]
However, with the default governor set to userspace it boots fine until
my userspace (ubuntu) tries to enable the ondemand governor, and then it
hangs.
For it to boot, I have to disable the ondemand governor, and set the
default governor to userspace.
I've tried with ARM big.LITTLE cpuidle support enabled (I've just noticed
that it is not turned on in exynos_defconfig) and my ODROID-XU3 board
fails to boot. This happens even with cpufreq support disabled (hard
lockup happens during mmc initialization which is done just after cpufreq
initialization).
Right, the XU3 has broken secure firmware such that MCPM cannot properly
control CCI, so CPUidle will hang when trying to hit low power states,
so you have to disable CCI by adding something like this to the end of
your XU3 .dts file:
cci {
status = disabled;
};
Could you please check if disabling cpuidle support helps?
For now, I've disabled CPUidle so we have a similar setup, but it
doesn't change anything on exynos5800-peach-pi
As I reported earlier on Thomas' series, I suspect this is related to
the fact that the higher OPPs aren't really functional without voltage
scaling also supported.
Part #4 contains voltage scaling support for arm_big_little[_dt] driver
so this should not be a problem any longer.
You may try next-20150330-generic-cpufreq-exynos5420-5800-v2-debug
branch from my github (with cpufreq debugging printks enabled) to check
whether the voltage scaling is indeed done on your board.
I'm also seeing the wait_until_divider_stable errors when switching
between the available A7 OPPs. I'd reported this one earlier as well,
along with the script to reproduce it.
I've tried your script and it works fine for me (I only needed to change
cpu4 to cpu0 as on ODROID-XU3 CPUs 0,5,6,7 are A7 and 1,2,3,4 are A15).
Then it seems something isn't quite right for exynos5800-peach-pi.
Below is the script[1] I'm using on exynos which also checks the voltage
by quering the regulator fwk (and optionally checking the INA2xx sensors
on odroid-xu3 if that support is enabled)
On your debug branch, it just gives -1 for all the voltages, so the
regulator voltage never changes:
# ./dvfs
CPU regulator: cpu0, vdd_arm, /sys/class/regulator/regulator.18
[ 45.691483] arm_big_little: bL_cpufreq_set_rate: cpu: 0, old cluster: 0, new
cluster: 0, freq: 20
[ 45.699581] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 0, cluster: 0,
400 MHz, -1 mV -- 200 MHz, -1 mV
current freq: 20
current voltage: 1262500
[ 46.969821] arm_big_little: bL_cpufreq_set_rate: cpu: 0, old cluster: 0, new
cluster: 0, freq: 30
[ 46.978272] arm_big_little: bL_cpufreq_set_rate_cluster: cpu 0, cluster: 0,
200 MHz, -1 mV -- 300 MHz, -1 mV
current freq: 30
current voltage: 1262500
I added a bit more debug to the cpufreq driver[1] and found that the
regulator_get_optional is failing:
[3.407295] cpu cpu0: Unable to get regulator cpu-cluster.0
[3.458282] cpu cpu4: Unable to get regulator cpu-cluster.1
Kevin
[1]
#!/bin/sh
if [ ! -d /sys/devices/system/cpu/cpu0/cpufreq ]; then
echo CPUfreq not enabled in kernel.
exit 1
fi
# NOTE: odroid-xu3: CPU0 = A7.0, CPU1 = A15.0
cpu=cpu0
reg_name=vdd_arm
hwmon=hwmon0
#cpu=cpu4
#reg_name=vdd_kfc
#hwmon=hwmon3
cpu_reg=$(dirname `find /sys/class/regulator/regulator.*/ -name name -exec grep
-l $reg_name {} \;`)
echo CPU regulator: $cpu, $reg_name, $cpu_reg
# Cycle through frequencies (and check voltage)
cd /sys/devices/system/cpu/$cpu/cpufreq
echo userspace scaling_governor
for freq in `cat scaling_available_frequencies`; do
echo ${freq} scaling_setspeed
sleep 0.2
echo -n current freq:
cat scaling_cur_freq
echo -n current voltage:
cat ${cpu_reg}/microvolts
# odroid-xu3 INA231 monitors
if [ ! -z $hwmon ]; then
if [ -e /sys/class/hwmon/$hwmon/in1_input ]; then
echo -n current voltage (ina2xx):
cat /sys/class/hwmon/$hwmon/in1_input
fi
fi
sleep 1
done
[2]
diff --git a/drivers/cpufreq/arm_big_little.c
b/drivers/cpufreq/arm_big_little.c
index 024f185b2154..4108f909cc9c 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -16,6 +16,7 @@
* of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
+#define DEBUG
#define pr_fmt(fmt) KBUILD_MODNAME : fmt
@@ -446,6 +447,8 @@ static int _get_cluster_clk_and_freq_table(struct
device *cpu_dev)
ret = regulator_set_voltage_time(reg[cluster], min_uV,
max_uV);
if (ret 0)
transition_latencies[cluster] = ret * 1000;
+ } else {
+ dev_warn(cpu_dev, Unable to get regulator %s, name);
}
ret = dev_pm_opp_init_cpufreq_table(cpu_dev,
freq_table[cluster]);
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
[PATCHv3 0/4] add devm_of_phy_get_by_index and update platform drivers
This patch set adds a new API to get phy by index when multiple phys are present. This patch is based on discussion with Arnd Bergmann about dt bindings for multiple phys. History: v1: - Removed null pointers on Dmitry's suggestion - Improved documentation in commit messages - Exported new phy api v2: - EHCI and OHCI platform Kconfigs select Generic Phy to fix build errors in certain configs. v3: - Made GENERIC_PHY an invisible option so that other configs can select it - Added stubs for devm_of_phy_get_by_index - Reformated code Arun Ramamurthy (4): phy: phy-core: Make GENERIC_PHY an invisible option phy: core: Add devm_of_phy_get_by_index to phy-core usb: ehci-platform: Use devm_of_phy_get_by_index usb: ohci-platform: Use devm_of_phy_get_by_index Documentation/phy.txt | 7 +++- drivers/ata/Kconfig | 1 - drivers/media/platform/exynos4-is/Kconfig | 2 +- drivers/phy/Kconfig | 4 +- drivers/phy/phy-core.c| 32 ++ drivers/usb/host/Kconfig | 4 +- drivers/usb/host/ehci-platform.c | 69 +++ drivers/usb/host/ohci-platform.c | 69 +++ drivers/video/fbdev/exynos/Kconfig| 2 +- include/linux/phy/phy.h | 8 10 files changed, 100 insertions(+), 98 deletions(-) -- 2.3.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
[RESEND PATCH v2 3/3] ARM: EXYNOS: Add missing of_node_put() when parsing power domains
From: Krzysztof Kozlowski k.kozlow...@samsung.com
Add missing of_node_put() to:
1. Error return path if allocating memory for exynos_pm_domain failed.
2. Second iteration over power domains if a child domain was not present
or was incomplete.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reported-by: Karol Wrona k.wr...@samsung.com
---
Changes since v1:
1. New patch.
---
arch/arm/mach-exynos/pm_domains.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index 61c32ccc9f7a..1a90c5da2fd7 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -138,6 +138,7 @@ static __init int exynos4_pm_init_power_domain(void)
if (!pd) {
pr_err(%s: failed to allocate memory for domain\n,
__func__);
+ of_node_put(np);
return -ENOMEM;
}
@@ -209,15 +210,15 @@ no_clk:
args.args_count = 0;
child_domain = of_genpd_get_from_provider(args);
if (!child_domain)
- continue;
+ goto next_pd;
if (of_parse_phandle_with_args(np, power-domains,
#power-domain-cells, 0, args) != 0)
- continue;
+ goto next_pd;
parent_domain = of_genpd_get_from_provider(args);
if (!parent_domain)
- continue;
+ goto next_pd;
if (pm_genpd_add_subdomain(parent_domain, child_domain))
pr_warn(%s failed to add subdomain: %s\n,
@@ -225,6 +226,7 @@ no_clk:
else
pr_info(%s has as child subdomain: %s.\n,
parent_domain-name, child_domain-name);
+next_pd:
of_node_put(np);
}
--
2.1.0
--
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
[RESEND PATCH v2 2/3] ARM: EXYNOS: Handle of_find_device_by_node and kstrdup failures
From: Krzysztof Kozlowski k.kozlow...@samsung.com
Prevent possible NULL pointer dereference of pointer returned by
of_find_device_by_node(). Handle this by skipping such power domain.
Additionally fail the init on kstrdup() failure. Such case is actually
not fatal because the name for power domain allocated by kstrdup() is
used only in printk. Still as a precaution handle this as an error
condition.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
Changes since v1:
None.
---
arch/arm/mach-exynos/pm_domains.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index 14622b5f4481..61c32ccc9f7a 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -126,6 +126,12 @@ static __init int exynos4_pm_init_power_domain(void)
struct device *dev;
pdev = of_find_device_by_node(np);
+ if (!pdev) {
+ pr_err(%s: failed to find device for node %s\n,
+ __func__, np-name);
+ of_node_put(np);
+ continue;
+ }
dev = pdev-dev;
pd = kzalloc(sizeof(*pd), GFP_KERNEL);
@@ -136,6 +142,12 @@ static __init int exynos4_pm_init_power_domain(void)
}
pd-pd.name = kstrdup(dev_name(dev), GFP_KERNEL);
+ if (!pd-pd.name) {
+ kfree(pd);
+ of_node_put(np);
+ return -ENOMEM;
+ }
+
pd-name = pd-pd.name;
pd-base = of_iomap(np, 0);
if (!pd-base) {
--
2.1.0
--
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/8] cpufreq: arm_big_little: add cluster regulator support
Hi Bartlomiej,
Add cluster regulator support as a preparation to adding
generic arm_big_little_dt cpufreq_dt driver support for
ODROID-XU3 board. This allows arm_big_little[_dt] driver
to set not only the frequency but also the voltage (which
is obtained from operating point's voltage value) for CPU
clusters.
Cc: Kukjin Kim kgene@samsung.com
Cc: Doug Anderson diand...@chromium.org
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Andreas Faerber afaer...@suse.de
Cc: Sachin Kamat sachin.ka...@linaro.org
Cc: Thomas Abraham thomas...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
.../bindings/cpufreq/arm_big_little_dt.txt |4 +
drivers/cpufreq/arm_big_little.c | 153
+--- 2 files changed, 139 insertions(+), 18
deletions(-)
diff --git
a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt
index 0715695..8ca4a12 100644 ---
a/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt +++
b/Documentation/devicetree/bindings/cpufreq/arm_big_little_dt.txt @@
-18,6 +18,10 @@ Required properties: Optional properties:
- clock-latency: Specify the possible maximum transition latency for
clock, in unit of nanoseconds.
+- cpu-cluster.0-supply: Provides the regulator node supplying
voltage to CPU
+ cluster 0.
+- cpu-cluster.1-supply: Provides the regulator node supplying
voltage to CPU
+ cluster 1.
Examples:
diff --git a/drivers/cpufreq/arm_big_little.c
b/drivers/cpufreq/arm_big_little.c index e1a6ba6..edb461b 100644
--- a/drivers/cpufreq/arm_big_little.c
+++ b/drivers/cpufreq/arm_big_little.c
@@ -31,6 +31,7 @@
#include linux/slab.h
#include linux/topology.h
#include linux/types.h
+#include linux/regulator/consumer.h
#include asm/bL_switcher.h
#include arm_big_little.h
@@ -54,6 +55,9 @@ static bool bL_switching_enabled;
static struct cpufreq_arm_bL_ops *arm_bL_ops;
static struct clk *clk[MAX_CLUSTERS];
+static struct regulator *reg[MAX_CLUSTERS];
+static struct device *cpu_devs[MAX_CLUSTERS];
+static int transition_latencies[MAX_CLUSTERS];
static struct cpufreq_frequency_table *freq_table[MAX_CLUSTERS + 1];
static atomic_t cluster_usage[MAX_CLUSTERS + 1];
@@ -122,7 +126,76 @@ static unsigned int bL_cpufreq_get_rate(unsigned
int cpu) }
}
-static unsigned int
+static int
+bL_cpufreq_set_rate_cluster(u32 cpu, u32 cluster, u32 new_rate)
+{
+ unsigned long volt = 0, volt_old = 0;
+ long freq_Hz;
+ u32 old_rate;
+ int ret;
+
+ freq_Hz = new_rate * 1000;
+ old_rate = clk_get_rate(clk[cluster]) / 1000;
+
+ if (!IS_ERR(reg[cluster])) {
+ struct dev_pm_opp *opp;
+ unsigned long opp_freq;
+
+ rcu_read_lock();
+ opp = dev_pm_opp_find_freq_ceil(cpu_devs[cluster],
freq_Hz);
+ if (IS_ERR(opp)) {
+ rcu_read_unlock();
+ pr_err(%s: cpu %d, cluster: %d, failed to
find OPP for %ld\n,
+ __func__, cpu, cluster, freq_Hz);
+ return PTR_ERR(opp);
+ }
+ volt = dev_pm_opp_get_voltage(opp);
+ opp_freq = dev_pm_opp_get_freq(opp);
+ rcu_read_unlock();
+ volt_old = regulator_get_voltage(reg[cluster]);
+ pr_debug(%s: cpu %d, cluster: %d, Found OPP: %ld
kHz, %ld uV\n,
+ __func__, cpu, cluster, opp_freq / 1000,
volt);
+ }
+
+ pr_debug(%s: cpu %d, cluster: %d, %u MHz, %ld mV -- %u
MHz, %ld mV\n,
+ __func__, cpu, cluster,
+ old_rate / 1000, (volt_old 0) ? volt_old / 1000 :
-1,
+ new_rate / 1000, volt ? volt / 1000 : -1);
+
+ /* scaling up? scale voltage before frequency */
+ if (!IS_ERR(reg[cluster]) new_rate old_rate) {
+ ret = regulator_set_voltage_tol(reg[cluster], volt,
0);
+ if (ret) {
+ pr_err(%s: cpu: %d, cluster: %d, failed to
scale voltage up: %d\n,
+ __func__, cpu, cluster, ret);
+ return ret;
+ }
+ }
+
+ ret = clk_set_rate(clk[cluster], new_rate * 1000);
+ if (WARN_ON(ret)) {
+ pr_err(%s: clk_set_rate failed: %d, cluster: %d\n,
+ __func__, cluster, ret);
+ if (!IS_ERR(reg[cluster]) volt_old 0)
+ regulator_set_voltage_tol(reg[cluster],
volt_old, 0);
+ return ret;
+ }
+
+ /* scaling down? scale voltage after frequency */
+ if (!IS_ERR(reg[cluster]) new_rate old_rate) {
+ ret = regulator_set_voltage_tol(reg[cluster], volt,
0);
+ if (ret) {
+ pr_err(%s: cpu: %d, cluster: %d, failed to
scale voltage down: %d\n,
+
Re: [PATCH 2/8] ARM: dts: add cluster regulator supply properties for exynos5422-odroidxu3
Hi Bartlomiej,
Add cluster regulator supply properties as a preparation to
adding generic arm_big_little_dt cpufreq driver support for
ODROID-XU3 board.
Cc: Kukjin Kim kgene@samsung.com
Cc: Doug Anderson diand...@chromium.org
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Andreas Faerber afaer...@suse.de
Cc: Sachin Kamat sachin.ka...@linaro.org
Cc: Thomas Abraham thomas...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
arch/arm/boot/dts/exynos5422-odroidxu3.dts |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts index edc25cf..e876016
100644 --- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -355,6 +355,14 @@
dr_mode = otg;
};
+cpu0 {
+ cpu-cluster.0-supply = buck2_reg;
+};
+
+cpu4 {
+ cpu-cluster.1-supply = buck6_reg;
+};
+
i2c_0 {
status = okay;
Reviewed-by: Lukasz Majewski l.majew...@samsung.com
--
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 5/8] ARM: Exynos: use generic cpufreq driver for Exynos5420
Hi Bartlomiej,
From: Thomas Abraham thomas...@samsung.com
The new CPU clock type allows the use of generic arm_big_little_dt
cpufreq driver for Exynos5420.
Changes by Bartlomiej:
- split Exynos5420 support from the original patch
- disable cpufreq if big.LITTLE switcher support is enabled
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Signed-off-by: Thomas Abraham thomas...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
arch/arm/mach-exynos/exynos.c |7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-exynos/exynos.c
b/arch/arm/mach-exynos/exynos.c index 4b03a32..11ac7fb 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -207,6 +207,13 @@ struct cpufreq_dt_platform_data cpufreq_dt_pd = {
static const struct of_device_id exynos_cpufreq_matches[] = {
{ .compatible = samsung,exynos4210, .data = cpufreq-dt },
{ .compatible = samsung,exynos5250, .data = cpufreq-dt },
+/*
+ * FIXME: When big.LITTLE switcher is enabled system lockups during
+ * ondemand governor stress testing (observed on ODROID-XU3 board).
+ */
+#ifndef CONFIG_BL_SWITCHER
+ { .compatible = samsung,exynos5420, .data =
arm-bL-cpufreq-dt }, +#endif
{ /* sentinel */ }
};
Reviewed-by: Lukasz Majewski l.majew...@samsung.com
--
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 6/8] clk: samsung: exynos5800: fix cpu clock configuration data
Hi Bartlomiej,
Fix cpu clock configuration data for Exynos5800 (it uses
higher PCLK_DBG divider values than Exynos5420 and supports
additional frequencies).
Based on Hardkernel's kernel for ODROID-XU3 board.
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Thomas Abraham thomas...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c | 36
+++--- 1 file changed, 33 insertions(+),
3 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c index 9398a2d..462aaee 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -1274,10 +1274,34 @@ static const struct exynos_cpuclk_cfg_data
exynos5420_eglclk_d[] __initconst = { { 0 },
};
+static const struct exynos_cpuclk_cfg_data exynos5800_eglclk_d[]
__initconst = {
+ { 200, E5420_EGL_DIV0(3, 7, 7, 4), },
+ { 190, E5420_EGL_DIV0(3, 7, 7, 4), },
+ { 180, E5420_EGL_DIV0(3, 7, 7, 4), },
+ { 170, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 160, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 150, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 140, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 130, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 120, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 110, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 100, E5420_EGL_DIV0(3, 7, 6, 2), },
+ { 90, E5420_EGL_DIV0(3, 7, 6, 2), },
+ { 80, E5420_EGL_DIV0(3, 7, 5, 2), },
+ { 70, E5420_EGL_DIV0(3, 7, 5, 2), },
+ { 60, E5420_EGL_DIV0(3, 7, 4, 2), },
+ { 50, E5420_EGL_DIV0(3, 7, 3, 2), },
+ { 40, E5420_EGL_DIV0(3, 7, 3, 2), },
+ { 30, E5420_EGL_DIV0(3, 7, 3, 2), },
+ { 20, E5420_EGL_DIV0(3, 7, 3, 2), },
+ { 0 },
+};
+
#define E5420_KFC_DIV(kpll, pclk,
aclk) \ kpll) 24) |
((pclk) 20) | ((aclk) 4)))
static const struct exynos_cpuclk_cfg_data exynos5420_kfcclk_d[]
__initconst = {
+ { 140, E5420_KFC_DIV(3, 5, 3), }, /* for Exynos5800 */
{ 130, E5420_KFC_DIV(3, 5, 2), },
{ 120, E5420_KFC_DIV(3, 5, 2), },
{ 110, E5420_KFC_DIV(3, 5, 2), },
@@ -1357,9 +1381,15 @@ static void __init exynos5x_clk_init(struct
device_node *np, ARRAY_SIZE(exynos5800_gate_clks));
}
- exynos_register_cpu_clock(ctx, CLK_ARM_CLK, armclk,
- mout_cpu_p[0], mout_cpu_p[1], 0x200,
- exynos5420_eglclk_d,
ARRAY_SIZE(exynos5420_eglclk_d), 0);
+ if (soc == EXYNOS5420) {
+ exynos_register_cpu_clock(ctx, CLK_ARM_CLK, armclk,
+ mout_cpu_p[0], mout_cpu_p[1], 0x200,
+ exynos5420_eglclk_d,
ARRAY_SIZE(exynos5420_eglclk_d), 0);
+ } else {
+ exynos_register_cpu_clock(ctx, CLK_ARM_CLK, armclk,
+ mout_cpu_p[0], mout_cpu_p[1], 0x200,
+ exynos5800_eglclk_d,
ARRAY_SIZE(exynos5800_eglclk_d), 0);
+ }
exynos_register_cpu_clock(ctx, CLK_KFC_CLK, kfcclk,
mout_kfc_p[0], mout_kfc_p[1], 0x28200,
exynos5420_kfcclk_d,
ARRAY_SIZE(exynos5420_kfcclk_d), 0);
Reviewed-by: Lukasz Majewski l.majew...@samsung.com
--
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 4/8] ARM: dts: Exynos5420: add CPU OPP and regulator supply property
Hi Bartlomiej,
From: Thomas Abraham thomas...@samsung.com
For Exynos5420 platforms, add CPU operating points and CPU
regulator supply properties for migrating from Exynos specific
cpufreq driver to using generic cpufreq driver.
Changes by Bartlomiej:
- split Exynos5420 support from the original patch
Cc: Kukjin Kim kgene@samsung.com
Cc: Doug Anderson diand...@chromium.org
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Cc: Andreas Faerber afaer...@suse.de
Cc: Sachin Kamat sachin.ka...@linaro.org
Signed-off-by: Thomas Abraham thomas...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
arch/arm/boot/dts/exynos5420.dtsi | 38
+ 1 file changed, 38 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi index f67b23f..85b9cfc 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -59,8 +59,26 @@
device_type = cpu;
compatible = arm,cortex-a15;
reg = 0x0;
+ clocks = clock CLK_ARM_CLK;
+ clock-names = cpu-cluster.0;
clock-frequency = 18;
cci-control-port = cci_control1;
+ clock-latency = 14;
+
+ operating-points =
+ 180 125
+ 170 1212500
+ 160 1175000
+ 150 1137500
+ 140 1112500
+ 130 1062500
+ 120 1037500
+ 110 1012500
+ 100 987500
+ 90 962500
+ 80 937500
+ 70 912500
+ ;
};
cpu1: cpu@1 {
@@ -69,6 +87,7 @@
reg = 0x1;
clock-frequency = 18;
cci-control-port = cci_control1;
+ clock-latency = 14;
};
cpu2: cpu@2 {
@@ -77,6 +96,7 @@
reg = 0x2;
clock-frequency = 18;
cci-control-port = cci_control1;
+ clock-latency = 14;
};
cpu3: cpu@3 {
@@ -85,14 +105,29 @@
reg = 0x3;
clock-frequency = 18;
cci-control-port = cci_control1;
+ clock-latency = 14;
};
cpu4: cpu@100 {
device_type = cpu;
compatible = arm,cortex-a7;
reg = 0x100;
+ clocks = clock CLK_KFC_CLK;
+ clock-names = cpu-cluster.1;
clock-frequency = 10;
cci-control-port = cci_control0;
+ clock-latency = 14;
+
+ operating-points =
+ 130 1275000
+ 120 1212500
+ 110 1162500
+ 100 1112500
+ 90 1062500
+ 80 1025000
+ 70 975000
+ 60 937500
+ ;
};
cpu5: cpu@101 {
@@ -101,6 +136,7 @@
reg = 0x101;
clock-frequency = 10;
cci-control-port = cci_control0;
+ clock-latency = 14;
};
cpu6: cpu@102 {
@@ -109,6 +145,7 @@
reg = 0x102;
clock-frequency = 10;
cci-control-port = cci_control0;
+ clock-latency = 14;
};
cpu7: cpu@103 {
@@ -117,6 +154,7 @@
reg = 0x103;
clock-frequency = 10;
cci-control-port = cci_control0;
+ clock-latency = 14;
};
};
Reviewed-by: Lukasz Majewski l.majew...@samsung.com
--
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: drm/exynos: getting the video processor to work
On 2015년 04월 22일 15:02, Inki Dae wrote: On 2015년 04월 22일 10:55, Joonyoung Shim wrote: Hi Tobias, On 04/21/2015 06:30 AM, Tobias Jakobi wrote: Hello, I've spend some time on figuring out how to use the VP on my Exynos4412. I noticed that currently it seems to be pretty broken (I've put a full crashlog with drm.debug=0xff at the end). As far as I can see, the problem stems from conflicting buffer counts in the driver. Let's start with vp_video_buffer(), there buf_num gets set to '2' when DRM_FORMAT_NV12 is encountered as pixelformat. Which results in the VP reading luma data from the plane's dma_addr[0] and chroma from dma_addr[1]. But dma_addr[1] is never correctly set. It should be set by exynos_check_plane(), but the loop only does one iteration since exynos_drm_fb_get_buf_cnt() returns 1. Which is due to special case handling in exynos_drm_format_num_buffers(). At least for the buffers that libdrm's modetest creates this case handling triggers and reduces buffer count to '1'. This is just pixel format issue and mixer driver is not completed about that. The exynos mixer can support two NV12 formats. To clarify it, NV12 and other NVXX formats have only two planes. First, NV12 format having just one buffer(Y plane and CbCr plane use a same buffer but differ their start index.) So it is called packed YUV format and drm_fourcc header defines these formats as follows, DRM_FORMAT_YUYV DRM_FORMAT_YVYU DRM_FORMAT_UYVY DRM_FORMAT_VYUY DRM_FORMAT_AYUV Sorry, there was my mistake. Packed YUV format means Y/Cb/Cr values are packed with one pixel. Second, NV12 format having split two buffers(one is for Y plane, other is for CbCr plane) All NVXX formats should be considered only for separated two buffers. So in case of Exynos, we identify that image data is NVXX format or NVXXM according to that whether having separated buffers or not. For this, we had already have a discussion before. I really forgot it. Current mixer driver considers only second NV12 format, we can know it from following comment in mixer driver. /* TODO: single buffer format NV12, NV21 */ So, it seems like wrong comment. Until now, it seems that we have been calling the packed YUV format as NVXX format and calling the NVXX format as NVXXM. And Exynos SoC have even NVXXMT whose format consists into many macro blocks and which has separated two buffers. So Joonyoung is right. we should consider two cases. One is the case of using one buffer and other is the case of using two buffers case. Thanks, Inki Dae We would need to make Exynos drivers suitable to fourcc. Thanks, Inki Dae -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] i2c: Mark adapter devices with pm_runtime_no_callbacks
On Thu, Apr 16, 2015 at 01:05:19PM +0100, Charles Keepax wrote: Commit 523c5b89640e (i2c: Remove support for legacy PM) removed the PM ops from the bus type, which causes the pm operations on the s3c2410 adapter device to fail (-ENOSUPP in rpm_callback). The adapter device doesn't get bound to a driver and as such can't have its own pm_runtime callbacks. Previously this was fine as the bus callbacks would have been used, but now this can cause devices which use PM runtime and are attached over I2C to fail to resume. This commit fixes this issue by marking all adapter devices with pm_runtime_no_callbacks, since they can't have any. Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com Applied to for-current, thanks! Will push out somewhat later today. Lars-Peter, if you'd like to donate some ack/review tag until then, this would be much appreciated. signature.asc Description: Digital signature
Re: [PATCH 3/8] clk: samsung: exynos5420: add cpu clock configuration data and instantiate cpu clock
Hi Bartlomiej,
From: Thomas Abraham thomas...@samsung.com
With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type. Add the CPU clock
configuration data and instantiate the CPU clock type for Exynos5420.
Changes by Bartlomiej:
- split Exynos5420 support from the original patches
- moved E5420_[EGL,KFC]_DIV0() macros to clk-exynos5420.c
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Mike Turquette mturque...@linaro.org
Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk
Signed-off-by: Thomas Abraham thomas...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
---
drivers/clk/samsung/clk-exynos5420.c | 58
++--
include/dt-bindings/clock/exynos5420.h |2 ++ 2 files changed, 58
insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c index 07d666c..9398a2d 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -19,6 +19,7 @@
#include linux/syscore_ops.h
#include clk.h
+#include clk-cpu.h
#define APLL_LOCK0x0
#define APLL_CON00x100
@@ -616,9 +617,11 @@ static struct samsung_mux_clock
exynos5x_mux_clks[] __initdata = { MUX(0, mout_mspll_kfc,
mout_mspll_cpu_p, SRC_TOP7, 8, 2), MUX(0, mout_mspll_cpu,
mout_mspll_cpu_p, SRC_TOP7, 12, 2),
- MUX(0, mout_apll, mout_apll_p, SRC_CPU, 0, 1),
+ MUX_F(0, mout_apll, mout_apll_p, SRC_CPU, 0, 1,
+ CLK_SET_RATE_PARENT, 0),
MUX(0, mout_cpu, mout_cpu_p, SRC_CPU, 16, 1),
- MUX(0, mout_kpll, mout_kpll_p, SRC_KFC, 0, 1),
+ MUX_F(0, mout_kpll, mout_kpll_p, SRC_KFC, 0, 1,
+ CLK_SET_RATE_PARENT, 0),
MUX(0, mout_kfc, mout_kfc_p, SRC_KFC, 16, 1),
MUX(0, mout_aclk200, mout_group1_p, SRC_TOP0, 8, 2),
@@ -1246,6 +1249,50 @@ static struct samsung_pll_clock
exynos5x_plls[nr_plls] __initdata = { KPLL_CON0, NULL),
};
+#define E5420_EGL_DIV0(apll, pclk_dbg, atb,
cpud) \
+ apll) 24) | ((pclk_dbg) 20) | ((atb)
16) | \
+ ((cpud) 4)))
+
+static const struct exynos_cpuclk_cfg_data exynos5420_eglclk_d[]
__initconst = {
+ { 180, E5420_EGL_DIV0(3, 7, 7, 4), },
+ { 170, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 160, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 150, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 140, E5420_EGL_DIV0(3, 7, 7, 3), },
+ { 130, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 120, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 110, E5420_EGL_DIV0(3, 7, 7, 2), },
+ { 100, E5420_EGL_DIV0(3, 6, 6, 2), },
+ { 90, E5420_EGL_DIV0(3, 6, 6, 2), },
+ { 80, E5420_EGL_DIV0(3, 5, 5, 2), },
+ { 70, E5420_EGL_DIV0(3, 5, 5, 2), },
+ { 60, E5420_EGL_DIV0(3, 4, 4, 2), },
+ { 50, E5420_EGL_DIV0(3, 3, 3, 2), },
+ { 40, E5420_EGL_DIV0(3, 3, 3, 2), },
+ { 30, E5420_EGL_DIV0(3, 3, 3, 2), },
+ { 20, E5420_EGL_DIV0(3, 3, 3, 2), },
+ { 0 },
+};
+
+#define E5420_KFC_DIV(kpll, pclk,
aclk) \
+ kpll) 24) | ((pclk) 20) | ((aclk) 4)))
+
+static const struct exynos_cpuclk_cfg_data exynos5420_kfcclk_d[]
__initconst = {
+ { 130, E5420_KFC_DIV(3, 5, 2), },
+ { 120, E5420_KFC_DIV(3, 5, 2), },
+ { 110, E5420_KFC_DIV(3, 5, 2), },
+ { 100, E5420_KFC_DIV(3, 5, 2), },
+ { 90, E5420_KFC_DIV(3, 5, 2), },
+ { 80, E5420_KFC_DIV(3, 5, 2), },
+ { 70, E5420_KFC_DIV(3, 4, 2), },
+ { 60, E5420_KFC_DIV(3, 4, 2), },
+ { 50, E5420_KFC_DIV(3, 4, 2), },
+ { 40, E5420_KFC_DIV(3, 3, 2), },
+ { 30, E5420_KFC_DIV(3, 3, 2), },
+ { 20, E5420_KFC_DIV(3, 3, 2), },
+ { 0 },
+};
+
static const struct of_device_id ext_clk_match[] __initconst = {
{ .compatible = samsung,exynos5420-oscclk, .data = (void
*)0, }, { },
@@ -1310,6 +1357,13 @@ static void __init exynos5x_clk_init(struct
device_node *np, ARRAY_SIZE(exynos5800_gate_clks));
}
+ exynos_register_cpu_clock(ctx, CLK_ARM_CLK, armclk,
+ mout_cpu_p[0], mout_cpu_p[1], 0x200,
+ exynos5420_eglclk_d,
ARRAY_SIZE(exynos5420_eglclk_d), 0);
+ exynos_register_cpu_clock(ctx, CLK_KFC_CLK, kfcclk,
+ mout_kfc_p[0], mout_kfc_p[1], 0x28200,
+ exynos5420_kfcclk_d,
ARRAY_SIZE(exynos5420_kfcclk_d), 0); +
exynos5420_clk_sleep_init();
samsung_clk_of_add_provider(np, ctx);
diff --git a/include/dt-bindings/clock/exynos5420.h
b/include/dt-bindings/clock/exynos5420.h index 99da0d1..dde9664 100644
--- a/include/dt-bindings/clock/exynos5420.h
+++ b/include/dt-bindings/clock/exynos5420.h
@@ -25,6 +25,8 @@
#define CLK_FOUT_MPLL10
#define CLK_FOUT_BPLL11
#define
Re: [PATCH v2] i2c: Mark adapter devices with pm_runtime_no_callbacks
On Thu, Apr 16, 2015 at 02:28:02PM +0200, Beata Michalska wrote: On 04/16/2015 02:05 PM, Charles Keepax wrote: Commit 523c5b89640e (i2c: Remove support for legacy PM) removed the PM ops from the bus type, which causes the pm operations on the s3c2410 adapter device to fail (-ENOSUPP in rpm_callback). The adapter device doesn't get bound to a driver and as such can't have its own pm_runtime callbacks. Previously this was fine as the bus callbacks would have been used, but now this can cause devices which use PM runtime and are attached over I2C to fail to resume. This commit fixes this issue by marking all adapter devices with pm_runtime_no_callbacks, since they can't have any. Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com Thereis at least one more casewhen an I2C device fails to resume due to bus callbacks being dropped(like fimc-is-i2c driver for exynos4-is, the same scenario), so I'm glad to see it's being handled in on place -it saves the trouble. Thanks for the confirmation! If you could also add a formal 'Acked-by' next time, this would help me because patchwork collects them for me automatically. signature.asc Description: Digital signature
Re: [PATCH 1/2] thermal: exynos: Reorder exynos_map_dt_data() function
Hi Joonyoung,
Hi Lukasz,
On 04/17/2015 09:39 PM, Lukasz Majewski wrote:
Hi Joonyoung,
Hi Lukasz,
On 04/15/2015 08:05 PM, Lukasz Majewski wrote:
Hi Joonyoung,
Hi Lukasz,
On 01/30/2015 05:14 PM, Lukasz Majewski wrote:
Hi Eduardo, Abhilash,
On Thu, Jan 22, 2015 at 06:02:07PM +0530, Abhilash Kesavan
wrote:
Hi Lukasz,
On Thu, Jan 22, 2015 at 2:31 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
Hi Abhilash,
Hi Lukasz,
On Mon, Jan 19, 2015 at 5:14 PM, Lukasz Majewski
l.majew...@samsung.com wrote:
The exynos_map_dt_data() function must be called before
thermal_zone_of_sensor_register(), and hence provide
tmu_read() function, before it is needed.
This change is driven by adding support for enabling
thermal_zoneX when it is properly initialized.
One can read the mode of operation
at /sys/class/thermal/thermal_zone0/mode Such functionality
was missing in the of-thermal.c code.
Reported-by: Abhilash Kesavan a.kesa...@samsung.com
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index
9d2d685..5d946ab 100644 ---
a/drivers/thermal/samsung/exynos_tmu.c +++
b/drivers/thermal/samsung/exynos_tmu.c @@ -975,15 +975,16
@@ static int exynos_tmu_probe(struct platform_device
*pdev) platform_set_drvdata(pdev, data);
mutex_init(data-lock);
+ ret = exynos_map_dt_data(pdev);
+ if (ret)
+ goto err_sensor;
It's enough to just return ret.
One more, i think to need to take out regulator enable codes from
exynos_map_dt_data. If not, can't restore about regulator when
error occurs.
+
data-tzd =
thermal_zone_of_sensor_register(pdev-dev, 0, data,
exynos_sensor_ops); if (IS_ERR(data-tzd)) {
pr_err(thermal: tz: %p ERROR\n,
data-tzd); return PTR_ERR(data-tzd);
}
- ret = exynos_map_dt_data(pdev);
- if (ret)
- goto err_sensor;
pdata = data-pdata;
I have been testing this along with your v5 patch set and am
seeing incorrect temperature being reported at boot-up on
exynos7.
Does it show a maximal temperature value (0x1FF)?
I did not print the current temperature register, but I
remember the message showing ~105C. Will give you the
register value when I test with more debug prints tomorrow.
It looks
like exynos_tmu_read gets called from
thermal_zone_of_device_update during boot-up, now that we
have it populated early. However, as the tmu initialization
function has not been called yet it returns a wrong value.
Does that sound correct ?
No, this is a mistake. However, I'm wondering why on
Exynos4/5 this error didn't show up...
I have been lowering the software trip point temperature in
the exynos7 dts file (to 55C) for testing purposes. Hence,
when the temperature is read incorrectly as ~105C the board
trips at boot-up
this is a very
unusual value - I had problems with
reading 0xFF values with
similar symptom (but
this was caused by lack of vtmu).
itself. Maybe for exynos4/5 the incorrect value read during
boot-up is in the non-tripping range and once the tmu is
initialized later it continues to function properly
thereafter ?
The reordering is needed to be able to call set_mode callback
at of-thermal.c to set the mode.
If this change causes problems, then another solution
(probably not so neat) must be found.
Please let me know if you need any further details.
Abhilash, could you provide more details (like relevant output
from dmesg) and point me a list of patches which shall I apply
to test this issue on Exynos4/5?
What is the status of this patch? Is it still required?
It is strange, since on Exynos4/5 this works and some problems
show up when run on Exynos7.
I'm also wondering the status of this patch.
This patch has been dropped.
I get below errors when boots odroidxu3 board without this patch.
Could you share the exact SHA1 and branch which you use in your
setup?
I tested with of odroidxu3 patchset for pwm-fan control of Anand
Moon on 20150414 -next.
http://www.spinics.net/lists/arm-kernel/msg412031.html
For a reference please check following branch at github (this is
the code which should be merged to v4.1-rc1)
g...@github.com:lmajewski/linux-samsung-thermal.git
branch: next [1]
This branch includes exynos7 support done by Chanwoo.
I got following errors from branch [1] without patchset of Anand
Moon,
[4.576442] thermal thermal_zone0: failed to read out thermal
zone 0 [4.581685] 1006.tmu supply vtmu
Re: drm/exynos: getting the video processor to work
Hello Inki and Joonyoung, On 2015-04-22 08:02, Inki Dae wrote: On 2015년 04월 22일 10:55, Joonyoung Shim wrote: Hi Tobias, On 04/21/2015 06:30 AM, Tobias Jakobi wrote: Hello, I've spend some time on figuring out how to use the VP on my Exynos4412. I noticed that currently it seems to be pretty broken (I've put a full crashlog with drm.debug=0xff at the end). As far as I can see, the problem stems from conflicting buffer counts in the driver. Let's start with vp_video_buffer(), there buf_num gets set to '2' when DRM_FORMAT_NV12 is encountered as pixelformat. Which results in the VP reading luma data from the plane's dma_addr[0] and chroma from dma_addr[1]. But dma_addr[1] is never correctly set. It should be set by exynos_check_plane(), but the loop only does one iteration since exynos_drm_fb_get_buf_cnt() returns 1. Which is due to special case handling in exynos_drm_format_num_buffers(). At least for the buffers that libdrm's modetest creates this case handling triggers and reduces buffer count to '1'. This is just pixel format issue and mixer driver is not completed about that. The exynos mixer can support two NV12 formats. To clarify it, NV12 and other NVXX formats have only two planes. That was also my impression. NV12 and NV21 are always bi-planar, with the only difference that NV21 has U/V order reversed (when comparing it to NV12). There is no uni-planar NV12/NV21. See also: https://wiki.videolan.org/YUV#NV12.2FNV21 First, NV12 format having just one buffer(Y plane and CbCr plane use a same buffer but differ their start index.) So it is called packed YUV format and drm_fourcc header defines these formats as follows, DRM_FORMAT_YUYV DRM_FORMAT_YVYU DRM_FORMAT_UYVY DRM_FORMAT_VYUY DRM_FORMAT_AYUV I'd like to know if any other formats except for NV12/NV21 are really supported by the video processor? Because I don't see any indication for that. It's just NV12/NV21 and the tiled variants, which are there to make it easier to handle data from the MFC block. Second, NV12 format having split two buffers(one is for Y plane, other is for CbCr plane) All NVXX formats should be considered only for separated two buffers. Does is even make any difference for the VP if luma and chroma are in different buffers or in a single one, just with an offset between luma/chroma? I think not, because the VP just gets a dma_addr for both and then fetches data from that position. Current mixer driver considers only second NV12 format, we can know it from following comment in mixer driver. /* TODO: single buffer format NV12, NV21 */ So, it seems like wrong comment. Until now, it seems that we have been calling the packed YUV format as NVXX format and calling the NVXX format as NVXXM. And Exynos SoC have even NVXXMT whose format consists into many macro blocks and which has separated two buffers. I think getting just regular (un-tiled) NV12/NV21 working should come first, then we can think about how to handle the tiled formats (probably with the newly introduced fb modifiers). I've patched the mixer so that it passes valid pointers for luma/chroma but I still get a crash (sysmmu) sooner or later. So there seems to be more issues than just this pixelformat/buffercount one. We would need to make Exynos drivers suitable to fourcc. Thanks, Inki Dae With best wishes, Tobias -- 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
