Re: [PATCH 00/21] On-demand device registration
Hi Tomeu, On 05/28/2015 07:33 AM, Rob Herring wrote: On Mon, May 25, 2015 at 9:53 AM, Tomeu Vizoso tomeu.viz...@collabora.com wrote: I have a problem with the panel on my Tegra Chromebook taking longer than expected to be ready during boot (Stéphane Marchesin reported what is basically the same issue in [0]), and have looked into ordered probing as a better way of solving this than moving nodes around in the DT or playing with initcall levels. While reading the thread [1] that Alexander Holler started with his series to make probing order deterministic, it occurred to me that it should be possible to achieve the same by registering devices as they are referenced by other devices. I like the concept and novel approach. This basically reuses the information that is already implicit in the probe() implementations, saving us from refactoring existing drivers or adding information to DTBs. Something I'm not completely happy with is that I have had to move the call to of_platform_populate after all platform drivers have been registered. Otherwise I don't see how I could register drivers on demand as we don't have yet each driver's compatible strings. Yeah, this is the opposite of what we'd really like. Ideally, we would have a solution that works for modules too. However, we're no worse off. We pretty much build-in dependencies to avoid module ordering problems. Perhaps we need to make the probing on-demand rather than simply on device-driver match occurring. For machs that don't move of_platform_populate() to a later point, these patches shouldn't cause any problems but it's not guaranteed that we'll avoid all the deferred probes as some drivers may not be registered yet. Ideally, of_platform_populate is not explicitly called by each platform. So I think we need to make this work for the default case. I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these patches were enough to eliminate all the deferred probes. With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s. That's certainly compelling. I've found your idea about moving device registration later during System boot very interesting so I've decided to try it on dra7-evem (TI) :). It's good to know time during Kernel boot when we can assume that all drivers are ready for probing, so there are more ways to control probing order. Pls, Note here that TI OMAP2+ mach is not pure DT mach - it's combination of DT and not DT devices/drivers. Ok. So What was done... LKML Linux 4.1-rc3 (a simple case) 1) use your patches 3/4 as reference (only these two patches :) 2) move of_platform_populate later at device_initcall_sync time Boot time reduction ~0.4 sec TI Android Kernel 3.14 (NOT a simple case) 1) use your patches 3/4 as reference (only these two patches :) 2) move of_platform_populate later at device_initcall_sync time 3) make it to boot (not sure I've fixed all issues, but those which break the System boot): - split non-DT and DT devices registration in platform code; - keep non-DT devices registration from .init_machine() [arch_initcall] - move DT-devices registration at device_initcall_sync time - fix drivers which use platform_driver_probe(). Note. Now there are at about ~190 occurrences of this macro in Kernel. - re-order few devices in DT (4 devices) - fix one driver which uses of_find_device_by_node() wrongly Note. This API is used some times with assumption that requested dev has been probed already. Boot time reduction ~0.3 sec. Probing of some devices are still deferred. TI Android Kernel 3.14 + of_platform_device_ensure 1) backport of_platform_device_ensure() (also need patches of: Introduce device tree node flag helpers and of: Keep track of populated platform devices) 2) back-port all your patches which uses of_platform_device_ensure() 3) make it to boot: - drop patch dma: of: Probe DMA controllers on demand - fix deadlock in regulator core: regulator_dev_lookup() called from regulator_register() in K3.14 4) get rid of deferred probes - add of_platform_device_ensure() calls in: - drivers/video/fbdev/omap2/dss/output.c - drivers/extcon/extcon-class.c Boot time reduction: NONE !? So few comments from above: - registering devices later during the System boot may improve boot time. But resolving of all deferred probes may NOT improve boot time ;) Have you seen smth like this? - usage of of_platform_device_ensure() will require continuous fixing of Kernel :( - late_initcall is not (as for me not safe) a good time to register devices. A lot of platforms/subsystems/frameworks perform their final initialization or clean-up steps, with assumption that System mostly ready to work. For example, CPUIdle/CPUFreq are allowed and other PM staff. CPUIdle and driver's probing are not friends. What would be nice to have for now in my opinion: - some useful place to move device population
[PATCH v2] drm/exynos: add error messages if clks failed to get enabled
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Check error and call DRM_ERROR if clk_prepare_enable() fails.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 28 +++
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 --
drivers/gpu/drm/exynos/exynos_mixer.c | 31 +-
3 files changed, 62 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index d659ba2..d9798e2 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -606,6 +606,7 @@ static void decon_init(struct decon_context *ctx)
static void decon_enable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc-ctx;
+ int ret;
if (!ctx-suspended)
return;
@@ -614,10 +615,29 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
pm_runtime_get_sync(ctx-dev);
- clk_prepare_enable(ctx-pclk);
- clk_prepare_enable(ctx-aclk);
- clk_prepare_enable(ctx-eclk);
- clk_prepare_enable(ctx-vclk);
+ ret = clk_prepare_enable(ctx-pclk);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the pclk [%d]\n, ret);
+ return;
+ }
+
+ ret = clk_prepare_enable(ctx-aclk);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the aclk [%d]\n, ret);
+ return;
+ }
+
+ ret = clk_prepare_enable(ctx-eclk);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the eclk [%d]\n, ret);
+ return;
+ }
+
+ ret = clk_prepare_enable(ctx-vclk);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the vclk [%d]\n, ret);
+ return;
+ }
decon_init(ctx);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9661853..7c8ba61 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -808,6 +808,7 @@ static void fimd_apply(struct fimd_context *ctx)
static void fimd_enable(struct exynos_drm_crtc *crtc)
{
struct fimd_context *ctx = crtc-ctx;
+ int ret;
if (!ctx-suspended)
return;
@@ -816,8 +817,17 @@ static void fimd_enable(struct exynos_drm_crtc *crtc)
pm_runtime_get_sync(ctx-dev);
- clk_prepare_enable(ctx-bus_clk);
- clk_prepare_enable(ctx-lcd_clk);
+ ret = clk_prepare_enable(ctx-bus_clk);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the bus clk [%d]\n, ret);
+ return;
+ }
+
+ ret = clk_prepare_enable(ctx-lcd_clk);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the lcd clk [%d]\n, ret);
+ return;
+ }
/* if vblank was enabled status, enable it again. */
if (test_and_clear_bit(0, ctx-irq_flags))
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 6bab717..1b77fc7 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1031,6 +1031,7 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
{
struct mixer_context *ctx = crtc-ctx;
struct mixer_resources *res = ctx-mixer_res;
+ int ret;
mutex_lock(ctx-mixer_mutex);
if (ctx-powered) {
@@ -1042,12 +1043,32 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
pm_runtime_get_sync(ctx-dev);
- clk_prepare_enable(res-mixer);
- clk_prepare_enable(res-hdmi);
+ ret = clk_prepare_enable(res-mixer);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the mixer clk [%d]\n, ret);
+ return;
+ }
+ ret = clk_prepare_enable(res-hdmi);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the hdmi clk [%d]\n, ret);
+ return;
+ }
if (ctx-vp_enabled) {
- clk_prepare_enable(res-vp);
- if (ctx-has_sclk)
- clk_prepare_enable(res-sclk_mixer);
+ ret = clk_prepare_enable(res-vp);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the vp clk [%d]\n,
+ ret);
+ return;
+ }
+ if (ctx-has_sclk) {
+ ret = clk_prepare_enable(res-sclk_mixer);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the \
+ sclk_mixer clk [%d]\n,
+ ret);
+ return;
+ }
+ }
}
mutex_lock(ctx-mixer_mutex);
--
2.1.0
--
[PATCH] drivers/cpufreq: include module.h for modular exynos-cpufreq.c code
This file is built off of a tristate Kconfig option (ARM_EXYNOS_CPUFREQ) and also contains modular function calls so it should explicitly include module.h to avoid compile breakage during pending header shuffles. Cc: Rafael J. Wysocki r...@rjwysocki.net Cc: Viresh Kumar viresh.ku...@linaro.org Cc: Kukjin Kim kg...@kernel.org Cc: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: linux...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- [ patch will be appended to the implicit include fixup series, see: https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortma...@windriver.com for the original series posting.] drivers/cpufreq/exynos-cpufreq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c index 82d2fbb20f7e..4c157302365f 100644 --- a/drivers/cpufreq/exynos-cpufreq.c +++ b/drivers/cpufreq/exynos-cpufreq.c @@ -10,6 +10,7 @@ */ #include linux/kernel.h +#include linux/module.h #include linux/err.h #include linux/clk.h #include linux/io.h -- 2.2.1 -- 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 00/21] On-demand device registration
On Mon, May 25, 2015 at 10:53 AM, Tomeu Vizoso tomeu.viz...@collabora.com wrote: Hello, I have a problem with the panel on my Tegra Chromebook taking longer than expected to be ready during boot (Stéphane Marchesin reported what is basically the same issue in [0]), and have looked into ordered probing as a better way of solving this than moving nodes around in the DT or playing with initcall levels. While reading the thread [1] that Alexander Holler started with his series to make probing order deterministic, it occurred to me that it should be possible to achieve the same by registering devices as they are referenced by other devices. This basically reuses the information that is already implicit in the probe() implementations, saving us from refactoring existing drivers or adding information to DTBs. Something I'm not completely happy with is that I have had to move the call to of_platform_populate after all platform drivers have been registered. Otherwise I don't see how I could register drivers on demand as we don't have yet each driver's compatible strings. For machs that don't move of_platform_populate() to a later point, these patches shouldn't cause any problems but it's not guaranteed that we'll avoid all the deferred probes as some drivers may not be registered yet. I have tested this on boards with Tegra, iMX.6 and Exynos SoCs, and these patches were enough to eliminate all the deferred probes. With this series I get the kernel to output to the panel in 0.5s, instead of 2.8s. So, complete drive-by comment (and I won't claim to be a DT expert, etc, etc, so take this with a few grains of salt), but why not push the problem to the DT compiler (or a pre-process step that could be run on existing DT blobs), which generates an optional DT node that is the recommended probe order? That seems like it avoids adding complexity into the early boot code (which seems like a good thing).. As a bonus, a bootarg (or something like that) which runs through the recommended probe order in reverse (to continue our current state of ensuring that EPROBE_DEFER error paths are well tested) At any rate, for a device like a drm driver that has multiple sub-components, and depends on various other clk/gpio/regulator/etc drivers, the current EPROBE_DEFER situation is pretty comical, so any solution that improves on things is very much welcome :-) BR, -R Regards, Tomeu [0] http://lists.freedesktop.org/archives/dri-devel/2014-August/066527.html [1] https://lkml.org/lkml/2014/5/12/452 Tomeu Vizoso (21): regulator: core: Reduce critical area in _regulator_get ARM: tegra: Add gpio-ranges property ARM: tegra: Register drivers before devices ARM: EXYNOS: Register drivers before devices ARM i.MX6q: Register drivers before devices of/platform: Add of_platform_device_ensure() of/platform: Ensure device registration on lookup gpio: Probe GPIO drivers on demand gpio: Probe pinctrl devices on demand regulator: core: Probe regulators on demand drm: Probe panels on demand drm/tegra: Probe dpaux devices on demand i2c: core: Probe i2c master devices on demand pwm: Probe PWM chip devices on demand backlight: Probe backlight devices on demand usb: phy: Probe phy devices on demand clk: Probe clk providers on demand pinctrl: Probe pinctrl devices on demand phy: core: Probe phy providers on demand dma: of: Probe DMA controllers on demand power-supply: Probe power supplies on demand arch/arm/boot/dts/tegra124.dtsi | 1 + arch/arm/mach-exynos/exynos.c | 4 +-- arch/arm/mach-imx/mach-imx6q.c | 12 - arch/arm/mach-tegra/tegra.c | 21 ++- drivers/clk/clk.c | 3 +++ drivers/dma/of-dma.c| 3 +++ drivers/gpio/gpiolib-of.c | 5 drivers/gpu/drm/drm_panel.c | 3 +++ drivers/gpu/drm/tegra/dpaux.c | 3 +++ drivers/i2c/i2c-core.c | 3 +++ drivers/of/platform.c | 53 + drivers/phy/phy-core.c | 3 +++ drivers/pinctrl/devicetree.c| 2 ++ drivers/power/power_supply_core.c | 3 +++ drivers/pwm/core.c | 3 +++ drivers/regulator/core.c| 45 +++ drivers/usb/phy/phy.c | 3 +++ drivers/video/backlight/backlight.c | 3 +++ include/linux/of_platform.h | 2 ++ 19 files changed, 130 insertions(+), 45 deletions(-) -- 2.4.1 ___ 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 0/6] Exynos SYSMMU (IOMMU) dts and arch updates
On 06/01/15 20:34, Krzysztof Kozlowski wrote: W dniu 01.06.2015 o 19:10, Marek Szyprowski pisze: Hello, Main changes for Exynos SYSMMU (IOMMU) driver has been finally scheduled for merging - see https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/commit/?h=next In meantime there have been quite a lot of changes related to Exynos DTS files queued for merging and my patches don't apply anymore. To ease merge process I've decided to rebased all Exynos SYSMMU dts changes onto latest exynos next tree from: https://github.com/krzk/linux dt-for-next While rebasing I've fixes a few spotted issues: some nodes still used old 'samsung,power-domain' properties (now replaced with 'power-domains') and added properties to jpeg codec merged recently. Thanks for rebasing this stuff. Same here ;-) I picked whole patchset with Javier's tested-by. I'll send it to Kukjin later or directly to arm-soc (depending what will happen with last pull request). Kukjin, you mentioned that you will do something with this patchset the previous weekend. Since then nothing happened so I am not sure what are your plans... Can you share them? Do you want to pick it by yourself, do you have any comments or maybe you need something from our side? (I checked the patches and they look fine) Done, thanks. - Kukjin -- 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/6] cpufreq: use generic cpufreq drivers forExynos4210platform
On 05/14/15 22:07, Kukjin Kim wrote: On 05/14/15 14:10, Viresh Kumar wrote: On 14-05-15, 13:07, Kukjin Kim wrote: On 05/13/15 23:08, Bartlomiej Zolnierkiewicz wrote: Hi, Hi Bart, On Friday, April 03, 2015 06:43:43 PM Bartlomiej Zolnierkiewicz wrote: Hi, This patch series removes the use of Exynos4210 specific support from cpufreq-exynos driver and enables the use of cpufreq-dt driver for this platform. Gentle Ping. Mike/Kukjin/Viresh could you please review/ack relevant patches (patches #1-3 are for clock subsystem, patches #4-5 for Exynos mach/dts and patch #6 is for cpufreq subsystem)? Sorry I thought I already Acked an older version of this set and so didn't went for it again. Done now. Yes, I totally agreed with this patches for arch side changes and this approach when Thomas posted. Also what is your preferred way to upstream them (patches are not independent so it would be best to merge them through one tree, otherwise synchronization of git pulls between different subsystem trees will be needed)? I can provide topic branch for arch side changes even it is small. I think once Viresh and Mike make each topic branch based on -rc or the smallest changes from each subsystem then I could handle this series or Viresh or Mike need to handle this series with merging each topic branches in subsystem. I'm fine either way. Viresh and Mike, how do you think about that? For cpufreq subsystem changes, you can take them in your tree. Hi Viresh, OK, I will take the cpufreq changes with your ack. Thanks for your confirmation. Hi Mike and Sylwester, How can we handle this series well without any problems? hmm... Still I need to get clock guys' ack or any comments on this series... - Kukjin I'm still hoping that this patchset will make it into v4.2 as there are no known issues with it (except minor coding nit for patch #5)... Sure, why not :-) -- 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: [GIT PULL] clk/samsung updates for 4.2
Quoting Sylwester Nawrocki (2015-06-03 09:09:39) The following changes since commit 20db7092e478c33a2bf5254063c51f5db6443959: Merge branch 'clk-next-hi6220' into clk-next (2015-05-27 22:06:42 -0700) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git tags/clk-samsung-for-4.2 Sylwester, Pulled towards 4.2. Thanks for the pull request. One small thing: clk-next isn't considered stable. I had some stuff in there (Stephen's amba assigned-clock-rates patch) which I had to pull out (no ACK from maintainer) and it crept back in because this PR was based on top of it. No big deal because I caught it when it happened (this time). In the future I am always happy to take PRs based on -rc1 (or any -rc that is already present in clk-next). Of course if you have a dependency on stuff already merged in clk-next then just let me know. Regards, Mike for you to fetch changes up to e5c6fc4f271a27d5b236b5f4929bf0f2dab80a7d: clk: exynos5433: Add CLK_IGNORE_UNUSED flag to clocks for SMC (2015-06-02 14:52:12 +0200) Updates of the exynos5433 clock definitions for proper support of SMC, DVFS of GPU and CPU big.LITTLE cores and a fix for system suspend adding one of the clock controller's registers to save/restore list. Chanwoo Choi (1): clk: exynos5433: Add CLK_SET_RATE_PARENT to support DVFS for big.LITTLE core Hyungwon Hwang (1): clk: exynos5433: Add DIV_CPIF to the list of stored registers on suspend Jonghwa Lee (1): clk: exynos5433: Add CLK_IGNORE_UNUSED flag to clocks for SMC Joonyoung Shim (1): clk: exynos5433: Add clock flag to support the DVFS of GPU drivers/clk/samsung/clk-exynos5433.c | 81 +- 1 file changed, 40 insertions(+), 41 deletions(-) -- 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: [PATCH 10/11] spi: add more debug prints in s3c64xx
On Wednesday, June 03, 2015 at 11:26:42 PM, Michal Suchanek wrote: The SPI NOR transfers mysteriously fail so add more debug prints about SPI transactions. Signed-off-by: Michal Suchanek hramr...@gmail.com dev_dbg() and friends would certainly be nicer here. Best regards, Marek Vasut -- 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 04/11] mtd: ofpart: do not fail probe when no partitions exist
On Wednesday, June 03, 2015 at 11:26:40 PM, Michal Suchanek wrote: On Exynos it is necessary to set SPI controller parameters that apply to a SPI slave in a DT subnode of the slave device. The ofpart code returns an error when there are subnodes of the SPI flash but no partitions are found. Change this condition to a warning so that flash without partitions can be accessed on Exynos. I have to admit the rationale for this patch is not very clear to me, sorry. Can you please explain this a bit more ? Best regards, Marek Vasut -- 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 00/11] Enable access to SPI NOR flash on Samsung Snow board
On Wednesday, June 03, 2015 at 11:26:39 PM, Michal Suchanek wrote: Hello, Hi, this patch series makes it possible to access the SPI NOR flash in the Samsung XE303 'Snow' Chromebook. Unfortunately not all issues are resolved. To work around an issue with the pl330 dma engine I respun the patch for limiting transfer size in m25p80 driver. Looks like fixing a bug at the wrong place to me ... As the flash does not contain any sane filesystem and is only likely to be accessed with mtd_debug or similar tool the limit of the dma engine is easily reached. Filesystems using shorter data transfers are less likely to be affected. Sounds like the DMA engine driver should be fixed. Best regards, Marek Vasut -- 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 08/11] MTD: m25p80: Add option to limit SPI transfer size.
On Wednesday, June 03, 2015 at 11:26:41 PM, Michal Suchanek wrote: On sunxi the SPI controller currently does not have DMA support and fails any transfer larger than 63 bytes. On Exynos the pl330 DMA controller fails any transfer larger than 64kb when using slower speed like 40MHz and any transfer larger than 128bytes when running at 133MHz. This smells more like some corruption of the data on the bus or something even more obscure. The best thing is that in both cases the controller can just lock up and never finish potentially leaving the hardware in unusable state. So it is required that the m25p80 driver actively prevents doing transfers that are too large for the current driver state on a particular piece of hardware. Signed-off-by: Michal Suchanek hramr...@gmail.com -- Update commit message and documentation text. --- .../devicetree/bindings/mtd/jedec,spi-nor.txt | 6 ++ drivers/mtd/devices/m25p80.c | 24 -- 2 files changed, 28 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt index 2bee681..4e63ae8 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt @@ -19,6 +19,12 @@ Optional properties: all chips and support for it can not be detected at runtime. Refer to your chips' datasheet to check if this is supported by your chip. +- linux,max_tx_len : With some SPI controller drivers possible transfer size is + limited. This may be hardware or driver bug. + Transfer data in chunks no larger than this value. + Using this option may severely degrade performance and + possibly flash memory life when max_tx_len is smaller than + flash page size (typically 256 bytes) Will we need similar patch for all other SPI slave drivers, like SPI NAND ? Best regards, Marek Vasut -- 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 6/8] mfd: cros_ec: Support multiple EC in a system
Hello Lee,
Thanks a lot for your feedback.
On 06/03/2015 10:53 AM, Lee Jones wrote:
On Tue, 02 Jun 2015, Javier Martinez Canillas wrote:
From: Gwendal Grignou gwen...@chromium.org
Chromebooks can have more than one Embedded Controller so the
cros_ec device id has to be incremented for each EC registered.
Add code to handle multiple EC. First ec found is cros-ec0,
second cros-ec1 and so on.
Add a new structure to represent multiple EC as different char
devices (e.g: /dev/cros_ec, /dev/cros_pd). It connects to
cros_ec_device and allows sysfs inferface for cros_pd.
Also reduce number of allocated objects, make chromeos sysfs
class object a static and add refcounting to prevent object
deletion while command is in progress.
Signed-off-by: Gwendal Grignou gwen...@chromium.org
Reviewed-by: Dmitry Torokhov d...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v3:
- Add defines for the EC and PD index constants.
- Remove cros_ec_dev_register() and declare the mfd_cells as static structs.
Suggested by Lee Jones.
- Add a new line before the return statement in cros_ec_dev_register().
Suggested by Lee Jones.
Changes since v2: None
Changes since v1:
- Squash patch that adds support to represent EC's as different
char devices (e.g: /dev/cros_ec, /dev/cros_pd):
https://chromium-review.googlesource.com/#/c/217297/
Suggested by Gwendal Grignou
- Use cros_ec instead of cros-ec in the subject line to be consistent.
Suggested by Gwendal Grignou
---
drivers/input/keyboard/cros_ec_keyb.c | 2 +-
drivers/mfd/cros_ec.c | 59 +++--
drivers/mfd/cros_ec_i2c.c | 1 -
drivers/mfd/cros_ec_spi.c | 1 -
drivers/platform/chrome/cros_ec_dev.c | 128
-
drivers/platform/chrome/cros_ec_dev.h | 7 --
drivers/platform/chrome/cros_ec_lightbar.c | 75 +
drivers/platform/chrome/cros_ec_lpc.c | 1 -
drivers/platform/chrome/cros_ec_sysfs.c| 48 +--
include/linux/mfd/cros_ec.h| 44 --
10 files changed, 240 insertions(+), 126 deletions(-)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 974154a74505..b01966dc7eb3 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -275,7 +275,7 @@ static int cros_ec_keyb_probe(struct platform_device
*pdev)
ckdev-dev = dev;
dev_set_drvdata(pdev-dev, ckdev);
-idev-name = ec-ec_name;
+idev-name = CROS_EC_DEV_NAME;
idev-phys = ec-phys_name;
__set_bit(EV_REP, idev-evbit);
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 08d82bfc5268..4fbb4ce8f81e 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -24,11 +24,29 @@
#include linux/mfd/core.h
#include linux/mfd/cros_ec.h
-static const struct mfd_cell cros_devs[] = {
-{
-.name = cros-ec-ctl,
-.id = PLATFORM_DEVID_AUTO,
-},
+#define CROS_EC_DEV_EC_INDEX 0
+#define CROS_EC_DEV_PD_INDEX 1
+
+struct cros_ec_platform ec_p = {
+.cmd_offset = EC_CMD_PASSTHRU_OFFSET(CROS_EC_DEV_EC_INDEX),
+};
+
+struct cros_ec_platform pd_p = {
+.cmd_offset = EC_CMD_PASSTHRU_OFFSET(CROS_EC_DEV_PD_INDEX),
+};
+
+struct mfd_cell ec_cell = {
+.name = cros-ec-ctl,
+.id = PLATFORM_DEVID_AUTO,
+.platform_data = ec_p,
+.pdata_size = sizeof(ec_p),
+};
+
+struct mfd_cell ec_pd_cell = {
+.name = cros-ec-ctl,
+.id = PLATFORM_DEVID_AUTO,
+.platform_data = pd_p,
+.pdata_size = sizeof(pd_p),
};
int cros_ec_register(struct cros_ec_device *ec_dev)
@@ -52,14 +70,39 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
cros_ec_query_all(ec_dev);
-err = mfd_add_devices(dev, 0, cros_devs,
- ARRAY_SIZE(cros_devs),
+if (IS_ENABLED(CONFIG_OF) dev-of_node)
+ec_p.ec_name = of_get_property(dev-of_node, devname,
+ NULL);
Has this binding already been accepted? We don't normally allow
device nameproperties in DT.
Sigh, I now noticed that I missed the DT binding change when originally
forward porting the patches from the downstream ChromiumOS tree. I'm so
sorry about that.
ChromiumOS tree has in Documentation/devicetree/bindings/mfd/cros-ec.txt:
Optional properties (All):
- devname: name of the EC. Can be based on its function: for instance,
for Sensor Hub, 'cros_sh', for Power Delivery MCU 'cros_pd'.
If not present, 'cros_ec' can be assumed.
When you say that normally device names are not allowed in DT, do you mean
that devname is a too generic property name? (which I totally agree) or
that DT bindings shouldn't have a property to change a device's name for
something more descriptive?
Because for
Re: [PATCH v4 6/8] mfd: cros_ec: Support multiple EC in a system
On Wed, 03 Jun 2015, Javier Martinez Canillas wrote:
Hello Lee,
Thanks a lot for your feedback.
On 06/03/2015 10:53 AM, Lee Jones wrote:
On Tue, 02 Jun 2015, Javier Martinez Canillas wrote:
From: Gwendal Grignou gwen...@chromium.org
Chromebooks can have more than one Embedded Controller so the
cros_ec device id has to be incremented for each EC registered.
Add code to handle multiple EC. First ec found is cros-ec0,
second cros-ec1 and so on.
Add a new structure to represent multiple EC as different char
devices (e.g: /dev/cros_ec, /dev/cros_pd). It connects to
cros_ec_device and allows sysfs inferface for cros_pd.
Also reduce number of allocated objects, make chromeos sysfs
class object a static and add refcounting to prevent object
deletion while command is in progress.
Signed-off-by: Gwendal Grignou gwen...@chromium.org
Reviewed-by: Dmitry Torokhov d...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v3:
- Add defines for the EC and PD index constants.
- Remove cros_ec_dev_register() and declare the mfd_cells as static
structs.
Suggested by Lee Jones.
- Add a new line before the return statement in cros_ec_dev_register().
Suggested by Lee Jones.
Changes since v2: None
Changes since v1:
- Squash patch that adds support to represent EC's as different
char devices (e.g: /dev/cros_ec, /dev/cros_pd):
https://chromium-review.googlesource.com/#/c/217297/
Suggested by Gwendal Grignou
- Use cros_ec instead of cros-ec in the subject line to be consistent.
Suggested by Gwendal Grignou
---
drivers/input/keyboard/cros_ec_keyb.c | 2 +-
drivers/mfd/cros_ec.c | 59 +++--
drivers/mfd/cros_ec_i2c.c | 1 -
drivers/mfd/cros_ec_spi.c | 1 -
drivers/platform/chrome/cros_ec_dev.c | 128
-
drivers/platform/chrome/cros_ec_dev.h | 7 --
drivers/platform/chrome/cros_ec_lightbar.c | 75 +
drivers/platform/chrome/cros_ec_lpc.c | 1 -
drivers/platform/chrome/cros_ec_sysfs.c| 48 +--
include/linux/mfd/cros_ec.h| 44 --
10 files changed, 240 insertions(+), 126 deletions(-)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 974154a74505..b01966dc7eb3 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -275,7 +275,7 @@ static int cros_ec_keyb_probe(struct platform_device
*pdev)
ckdev-dev = dev;
dev_set_drvdata(pdev-dev, ckdev);
- idev-name = ec-ec_name;
+ idev-name = CROS_EC_DEV_NAME;
idev-phys = ec-phys_name;
__set_bit(EV_REP, idev-evbit);
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 08d82bfc5268..4fbb4ce8f81e 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -24,11 +24,29 @@
#include linux/mfd/core.h
#include linux/mfd/cros_ec.h
-static const struct mfd_cell cros_devs[] = {
- {
- .name = cros-ec-ctl,
- .id = PLATFORM_DEVID_AUTO,
- },
+#define CROS_EC_DEV_EC_INDEX 0
+#define CROS_EC_DEV_PD_INDEX 1
+
+struct cros_ec_platform ec_p = {
+ .cmd_offset = EC_CMD_PASSTHRU_OFFSET(CROS_EC_DEV_EC_INDEX),
+};
+
+struct cros_ec_platform pd_p = {
+ .cmd_offset = EC_CMD_PASSTHRU_OFFSET(CROS_EC_DEV_PD_INDEX),
+};
+
+struct mfd_cell ec_cell = {
+ .name = cros-ec-ctl,
+ .id = PLATFORM_DEVID_AUTO,
+ .platform_data = ec_p,
+ .pdata_size = sizeof(ec_p),
+};
+
+struct mfd_cell ec_pd_cell = {
+ .name = cros-ec-ctl,
+ .id = PLATFORM_DEVID_AUTO,
+ .platform_data = pd_p,
+ .pdata_size = sizeof(pd_p),
};
int cros_ec_register(struct cros_ec_device *ec_dev)
@@ -52,14 +70,39 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
cros_ec_query_all(ec_dev);
- err = mfd_add_devices(dev, 0, cros_devs,
-ARRAY_SIZE(cros_devs),
+ if (IS_ENABLED(CONFIG_OF) dev-of_node)
+ ec_p.ec_name = of_get_property(dev-of_node, devname,
+ NULL);
Has this binding already been accepted? We don't normally allow
device nameproperties in DT.
Sigh, I now noticed that I missed the DT binding change when originally
forward porting the patches from the downstream ChromiumOS tree. I'm so
sorry about that.
ChromiumOS tree has in Documentation/devicetree/bindings/mfd/cros-ec.txt:
Optional properties (All):
- devname: name of the EC. Can be based on its function: for instance,
for Sensor Hub, 'cros_sh', for Power Delivery MCU 'cros_pd'.
If not present, 'cros_ec' can be assumed.
When you say that normally device names are not allowed in DT, do you mean
that devname is a too generic property name?
Re: [PATCH v4 6/8] mfd: cros_ec: Support multiple EC in a system
Hello Lee, On 06/03/2015 01:27 PM, Lee Jones wrote: On Wed, 03 Jun 2015, Javier Martinez Canillas wrote: [snip] - err = mfd_add_devices(dev, 0, cros_devs, - ARRAY_SIZE(cros_devs), + if (IS_ENABLED(CONFIG_OF) dev-of_node) + ec_p.ec_name = of_get_property(dev-of_node, devname, +NULL); Has this binding already been accepted? We don't normally allow device nameproperties in DT. Sigh, I now noticed that I missed the DT binding change when originally forward porting the patches from the downstream ChromiumOS tree. I'm so sorry about that. ChromiumOS tree has in Documentation/devicetree/bindings/mfd/cros-ec.txt: Optional properties (All): - devname: name of the EC. Can be based on its function: for instance, for Sensor Hub, 'cros_sh', for Power Delivery MCU 'cros_pd'. If not present, 'cros_ec' can be assumed. When you say that normally device names are not allowed in DT, do you mean that devname is a too generic property name? (which I totally agree) or that DT bindings shouldn't have a property to change a device's name for something more descriptive? Because for example, the regulator bindings has a regulator-name property. If you agree I can change the property to google,cros-ec-name which should be more precise. I mean, no names of devices are allowed in Device Tree: `git grep name -- arch/arm/boot/dts/ | grep dev` Ok, but do you agree on having a google,cros-ec-name (with no dev on it) property to define the resource name just like regulators have regulator-name that changes what is shown in /sys/kernel/debug/regulator/$name? Otherwise all the EC's will be named cros_ec or regardless of their function and this is shown in both /dev/$name and /sys/class/chromeos/$name. 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 2/9] mm: Provide new get_vaddr_frames() helper
On Tue 02-06-15 15:29:12, Andrew Morton wrote: On Tue, 2 Jun 2015 17:23:00 +0200 Jan Kara j...@suse.cz wrote: That's a lump of new code which many kernels won't be needing. Can we put all this in a new .c file and select it within drivers/media Kconfig? So the attached patch should do what you had in mind. OK? lgtm. drivers/gpu/drm/exynos/Kconfig | 1 + drivers/media/platform/omap/Kconfig | 1 + drivers/media/v4l2-core/Kconfig | 1 + mm/Kconfig | 3 + mm/Makefile | 1 + mm/frame-vec.c | 233 But frame_vector.c would be a more pleasing name. For `struct frame_vector'. OK, makes sense. Updated patch attached. Honza -- Jan Kara j...@suse.cz SUSE Labs, CR From a129ecf637e75421d823d54eab885cd36e54c6ec Mon Sep 17 00:00:00 2001 From: Jan Kara j...@suse.cz Date: Tue, 2 Jun 2015 16:40:32 +0200 Subject: [PATCH] mm: Move get_vaddr_frames() behind a config option get_vaddr_frames() is used by relatively rare drivers so hide it and the related functions behind a config option that is selected only by drivers that need the infrastructure. Suggested-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Jan Kara j...@suse.cz --- drivers/gpu/drm/exynos/Kconfig | 1 + drivers/media/platform/omap/Kconfig | 1 + drivers/media/v4l2-core/Kconfig | 1 + mm/Kconfig | 3 + mm/Makefile | 1 + mm/frame_vector.c | 233 mm/gup.c| 225 -- 7 files changed, 240 insertions(+), 225 deletions(-) create mode 100644 mm/frame_vector.c diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index 0a6780367d28..fc678289cf79 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -71,6 +71,7 @@ config DRM_EXYNOS_VIDI config DRM_EXYNOS_G2D bool Exynos DRM G2D depends on DRM_EXYNOS !VIDEO_SAMSUNG_S5P_G2D + select FRAME_VECTOR help Choose this option if you want to use Exynos G2D for DRM. diff --git a/drivers/media/platform/omap/Kconfig b/drivers/media/platform/omap/Kconfig index dc2aaab54aef..217d613b0fe7 100644 --- a/drivers/media/platform/omap/Kconfig +++ b/drivers/media/platform/omap/Kconfig @@ -10,6 +10,7 @@ config VIDEO_OMAP2_VOUT select OMAP2_DSS if HAS_IOMEM ARCH_OMAP2PLUS select OMAP2_VRFB if ARCH_OMAP2 || ARCH_OMAP3 select VIDEO_OMAP2_VOUT_VRFB if VIDEO_OMAP2_VOUT OMAP2_VRFB + select FRAME_VECTOR default n ---help--- V4L2 Display driver support for OMAP2/3 based boards. diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig index ba7e21a73023..0cb22add650b 100644 --- a/drivers/media/v4l2-core/Kconfig +++ b/drivers/media/v4l2-core/Kconfig @@ -73,6 +73,7 @@ config VIDEOBUF2_CORE config VIDEOBUF2_MEMOPS tristate + select FRAME_VECTOR config VIDEOBUF2_DMA_CONTIG tristate diff --git a/mm/Kconfig b/mm/Kconfig index 390214da4546..2ca52e9986f0 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -635,3 +635,6 @@ config MAX_STACK_SIZE_MB changed to a smaller value in which case that is used. A sane initial value is 80 MB. + +config FRAME_VECTOR + bool diff --git a/mm/Makefile b/mm/Makefile index 98c4eaeabdcb..be5d5c866305 100644 --- a/mm/Makefile +++ b/mm/Makefile @@ -78,3 +78,4 @@ obj-$(CONFIG_CMA) += cma.o obj-$(CONFIG_MEMORY_BALLOON) += balloon_compaction.o obj-$(CONFIG_PAGE_EXTENSION) += page_ext.o obj-$(CONFIG_CMA_DEBUGFS) += cma_debug.o +obj-$(CONFIG_FRAME_VECTOR) += frame_vector.o diff --git a/mm/frame_vector.c b/mm/frame_vector.c new file mode 100644 index ..5d85bcd150ae --- /dev/null +++ b/mm/frame_vector.c @@ -0,0 +1,233 @@ +#include linux/kernel.h +#include linux/errno.h +#include linux/err.h +#include linux/mm.h +#include linux/slab.h +#include linux/pagemap.h +#include linux/sched.h + +/* + * get_vaddr_frames() - map virtual addresses to pfns + * @start: starting user address + * @nr_frames: number of pages / pfns from start to map + * @write: whether pages will be written to by the caller + * @force: whether to force write access even if user mapping is + * readonly. See description of the same argument of + get_user_pages(). + * @vec: structure which receives pages / pfns of the addresses mapped. + * It should have space for at least nr_frames entries. + * + * This function maps virtual addresses from @start and fills @vec structure + * with page frame numbers or page pointers to corresponding pages (choice + * depends on the type of the vma underlying the virtual address). If @start + * belongs to a normal vma, the function grabs reference to each of the pages + * to pin them in memory. If @start belongs to VM_IO | VM_PFNMAP vma, we don't + * touch page structures and the caller
Re: [PATCH v4 0/8] mfd: cros_ec: Add multi EC and proto v3 support
Hello Heiko, On 06/02/2015 11:15 PM, Heiko Stübner wrote: Am Dienstag, 2. Juni 2015, 10:11:03 schrieb Javier Martinez Canillas: Hello, Newer Chromebooks have more than one Embedded Controller (EC) in the system. These additional ECs are connected through I2C with a host EC which is the one that is connected to the Application Processor (AP) through different transports (I2C, SPI or LPC). So on these platforms, sub-processors are chained to each other: AP -- Host EC -- Power Delivery (PD) EC The AP sends commands to the additional EC through the host EC using a set of passthru commands and the host redirects to the correct EC. This is a v4 of a series that adds support for multiple EC in a system and also for the protocol version 3 that is used on newer ECs. Most patches were taken from the downstream ChromiumOS v3.14 tree with fixes squashed, split to minimise the cross subsystem churn and changes for mainline inclusion but were not modified functionality wise. This version addresses a lot of issues pointed out by Lee Jones on the v3 posted before [0]. The patches are based on top of [PATCH 0/2] mfd: cros_ec: Small cleanups [1] that were posted before and was already picked by Lee Jones. Testing was done on some Chromebooks that have a single EC and support protocol v2 such as the Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi to be sure that no regressions were introduced for these machines. I just gave this a try on veyron and everything still works as expected. All patches except [PATCH v4 6/8] mfd: cros_ec: Support multiple EC in a system already have Tested-by tags, so this patch now is also Tested-by: Heiko Stuebner he...@sntech.de Thanks a lot for testing the series again. Now let's wait for Olof to review/ack/provide feedback on patches #1-#6 that touches drivers/platform/chrome, so Lee can merge through his tree. Heiko 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
[PATCH stable-4.0] ARM: EXYNOS: Fix failed second suspend on Exynos4
commit 6f024978e74bda616b27183adee029b65eb27032 upstream.
On Exynos4412 boards (Trats2, Odroid U3) after enabling L2 cache in
56b60b8bce4a (ARM: 8265/1: dts: exynos4: Add nodes for L2 cache
controller) the second suspend to RAM failed. First suspend worked fine
but the next one hang just after powering down of secondary CPUs (system
consumed energy as it would be running but was not responsive).
The issue was caused by enabling delayed reset assertion for CPU0 just
after issuing power down of cores. This was introduced for Exynos4 in
13cfa6c4f7fa (ARM: EXYNOS: Fix CPU idle clock down after CPU off).
The whole behavior is not well documented but after checking with vendor
code this should be done like this (on Exynos4):
1. Enable delayed reset assertion when system is running (for all CPUs).
2. Disable delayed reset assertion before suspending the system.
This can be done after powering off secondary CPUs.
3. Re-enable the delayed reset assertion when system is resumed.
Fixes: 13cfa6c4f7fa (ARM: EXYNOS: Fix CPU idle clock down after CPU off)
Cc: sta...@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Tested-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Tested-by: Chanwoo Choi cw00.c...@samsung.com
Signed-off-by: Kukjin Kim kg...@kernel.org
---
arch/arm/mach-exynos/common.h | 2 ++
arch/arm/mach-exynos/exynos.c | 27 +++
arch/arm/mach-exynos/platsmp.c | 39 ++-
arch/arm/mach-exynos/suspend.c | 3 +++
4 files changed, 34 insertions(+), 37 deletions(-)
diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index f70eca7ee705..0ef8d4b47102 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -153,6 +153,8 @@ extern void exynos_enter_aftr(void);
extern struct cpuidle_exynos_data cpuidle_coupled_exynos_data;
+extern void exynos_set_delayed_reset_assertion(bool enable);
+
extern void s5p_init_cpu(void __iomem *cpuid_addr);
extern unsigned int samsung_rev(void);
extern void __iomem *cpu_boot_reg_base(void);
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 9e9dfdfad9d7..1081ff1f03c6 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -166,6 +166,33 @@ static void __init exynos_init_io(void)
exynos_map_io();
}
+/*
+ * Set or clear the USE_DELAYED_RESET_ASSERTION option. Used by smp code
+ * and suspend.
+ *
+ * This is necessary only on Exynos4 SoCs. When system is running
+ * USE_DELAYED_RESET_ASSERTION should be set so the ARM CLK clock down
+ * feature could properly detect global idle state when secondary CPU is
+ * powered down.
+ *
+ * However this should not be set when such system is going into suspend.
+ */
+void exynos_set_delayed_reset_assertion(bool enable)
+{
+ if (soc_is_exynos4()) {
+ unsigned int tmp, core_id;
+
+ for (core_id = 0; core_id num_possible_cpus(); core_id++) {
+ tmp = pmu_raw_readl(EXYNOS_ARM_CORE_OPTION(core_id));
+ if (enable)
+ tmp |= S5P_USE_DELAYED_RESET_ASSERTION;
+ else
+ tmp = ~(S5P_USE_DELAYED_RESET_ASSERTION);
+ pmu_raw_writel(tmp, EXYNOS_ARM_CORE_OPTION(core_id));
+ }
+ }
+}
+
static const struct of_device_id exynos_dt_pmu_match[] = {
{ .compatible = samsung,exynos3250-pmu },
{ .compatible = samsung,exynos4210-pmu },
diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c
index d2e9f12d12f1..d45e8cd23925 100644
--- a/arch/arm/mach-exynos/platsmp.c
+++ b/arch/arm/mach-exynos/platsmp.c
@@ -34,30 +34,6 @@
extern void exynos4_secondary_startup(void);
-/*
- * Set or clear the USE_DELAYED_RESET_ASSERTION option, set on Exynos4 SoCs
- * during hot-(un)plugging CPUx.
- *
- * The feature can be cleared safely during first boot of secondary CPU.
- *
- * Exynos4 SoCs require setting USE_DELAYED_RESET_ASSERTION during powering
- * down a CPU so the CPU idle clock down feature could properly detect global
- * idle state when CPUx is off.
- */
-static void exynos_set_delayed_reset_assertion(u32 core_id, bool enable)
-{
- if (soc_is_exynos4()) {
- unsigned int tmp;
-
- tmp = pmu_raw_readl(EXYNOS_ARM_CORE_OPTION(core_id));
- if (enable)
- tmp |= S5P_USE_DELAYED_RESET_ASSERTION;
- else
- tmp = ~(S5P_USE_DELAYED_RESET_ASSERTION);
- pmu_raw_writel(tmp, EXYNOS_ARM_CORE_OPTION(core_id));
- }
-}
-
#ifdef CONFIG_HOTPLUG_CPU
static inline void cpu_leave_lowpower(u32 core_id)
{
@@ -73,8 +49,6 @@ static inline void cpu_leave_lowpower(u32 core_id)
: =r (v)
: Ir (CR_C), Ir (0x40)
: cc);
-
-exynos_set_delayed_reset_assertion(core_id, false);
}
static inline void
[PATCH v2 1/3] drm/exynos: fimd: ensure proper hw state in fimd_clear_channel()
One should not do any assumptions on the stare of the fimd hardware
during driver initialization, so to properly reset fimd before enabling
IOMMU, one should ensure that all power domains and clocks are really
enabled. This patch adds pm_runtime and clocks management in the
fimd_clear_channel() function to ensure that any access to fimd
registers will be performed with clocks and power domains enabled.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 22 ++
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 96618534358e..3ec9d4299a86 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -242,12 +242,21 @@ static void fimd_enable_shadow_channel_path(struct
fimd_context *ctx,
writel(val, ctx-regs + SHADOWCON);
}
+static int fimd_enable_vblank(struct exynos_drm_crtc *crtc);
+static void fimd_disable_vblank(struct exynos_drm_crtc *crtc);
+
static void fimd_clear_channel(struct fimd_context *ctx)
{
unsigned int win, ch_enabled = 0;
DRM_DEBUG_KMS(%s\n, __FILE__);
+ /* Hardware is in unknown state, so ensure it gets enabled properly */
+ pm_runtime_get_sync(ctx-dev);
+
+ clk_prepare_enable(ctx-bus_clk);
+ clk_prepare_enable(ctx-lcd_clk);
+
/* Check if any channel is enabled. */
for (win = 0; win WINDOWS_NR; win++) {
u32 val = readl(ctx-regs + WINCON(win));
@@ -265,12 +274,17 @@ static void fimd_clear_channel(struct fimd_context *ctx)
/* Wait for vsync, as disable channel takes effect at next vsync */
if (ch_enabled) {
- unsigned int state = ctx-suspended;
-
- ctx-suspended = 0;
+ ctx-suspended = false;
+ fimd_enable_vblank(ctx-crtc);
fimd_wait_for_vblank(ctx-crtc);
- ctx-suspended = state;
+ fimd_disable_vblank(ctx-crtc);
+ ctx-suspended = true;
}
+
+ clk_disable_unprepare(ctx-lcd_clk);
+ clk_disable_unprepare(ctx-bus_clk);
+
+ pm_runtime_put(ctx-dev);
}
static int fimd_iommu_attach_devices(struct fimd_context *ctx,
--
1.9.2
--
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 v2 2/3] drm/exynos: iommu: detach from default dma-mapping domain on init
This patch adds code, which detach sub-device nodes from default iommu
domain if such has been configured. This lets Exynos DRM driver to properly
attach sub-devices to its own, common for all sub-devices domain.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
index b32b291f88ff..323601a52a25 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
@@ -100,6 +100,9 @@ int drm_iommu_attach_device(struct drm_device *drm_dev,
dma_set_max_seg_size(subdrv_dev, 0xu);
+ if (subdrv_dev-archdata.mapping)
+ arm_iommu_detach_device(subdrv_dev);
+
ret = arm_iommu_attach_device(subdrv_dev, dev-archdata.mapping);
if (ret 0) {
DRM_DEBUG_KMS(failed iommu attach.\n);
--
1.9.2
--
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 v2 0/3] Exynos SYSMMU (IOMMU) updates for Exynos DRM
Hello, Main changes for Exynos SYSMMU (IOMMU) driver has been finally scheduled for merging - see https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/commit/?h=next To let Exynos IOMMU driver work correctly, some fixes are also needed in Exynos DRM driver. v2 of this patchset has been rebased onto latest exynos-drm-next branch with atomic mode setting patches applied. Best regards Marek Szyprowski Samsung RD Institute Poland Marek Szyprowski (3): drm/exynos: fimd: ensure proper hw state in fimd_clear_channel() drm/exynos: iommu: detach from default dma-mapping domain on init drm/exynos: iommu: improve a check for non-iommu dma_ops drivers/gpu/drm/exynos/exynos_drm_fimd.c | 22 ++ drivers/gpu/drm/exynos/exynos_drm_iommu.c | 7 +-- 2 files changed, 23 insertions(+), 6 deletions(-) -- 1.9.2 -- 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 v2 3/3] drm/exynos: iommu: improve a check for non-iommu dma_ops
DRM Exynos driver is relying on dma-mapping internal structures when used with IOMMU enabled. This patch partially hides dma-mapping internal things by using proper get_dma_ops/set_dma_ops calls. Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_iommu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c b/drivers/gpu/drm/exynos/exynos_drm_iommu.c index 323601a52a25..34596da7be33 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c @@ -117,8 +117,8 @@ int drm_iommu_attach_device(struct drm_device *drm_dev, * If iommu attach succeeded, the sub driver would have dma_ops * for iommu and also all sub drivers have same dma_ops. */ - if (!dev-archdata.dma_ops) - dev-archdata.dma_ops = subdrv_dev-archdata.dma_ops; + if (get_dma_ops(dev) == get_dma_ops(NULL)) + set_dma_ops(dev, get_dma_ops(subdrv_dev)); return 0; } -- 1.9.2 -- 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: [GIT PULL] ARM: EXYNOS: DTS improvements for 4.2, 3rd
On 02.06.2015 12:40, Kukjin Kim wrote: Krzysztof Kozlowski wrote: Dear Kukjin, Quite big set of changes, mostly refactor. You can find them also on the lists with my reviewed-by. Thanks for your gentle reminder and gathering. I'm sorting them out and it should be fine tonight in my tree... If any differences with yours, I'll let you know and please check them tomorrow morning so that it could be sent out to arm-soc tomorrow for 4.2. Hi, Everything from pull request was merged, thanks. However I cannot find the Marek's Exynos IOMMU patches in your tree. You replied that you will also take care of them. They are waiting on the lists for quite long time. Marek recently rebased them on top of my DTS-label-rework, so you can pull them directly: 1. From mailing list: http://www.spinics.net/lists/linux-samsung-soc/msg45022.html They only miss Javier's tested-by: Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk 2. From my dt-for-next branch: https://github.com/krzk/linux/commits/dt-for-next The IOMMU part of Marek's patchset was applied by Joerg so it would be great if the Exynos-stuff also could be merged for 4.2. 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 v10 17/17] drm/exynos: split exynos_crtc-dpms in enable() and disable()
Hi,
On 2015년 06월 02일 00:04, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
To follow more closely the new atomic API we split the dpms()
helper into the enable() and disable() helper to get exactly the
same semantics.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 87
++
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 8 +--
drivers/gpu/drm/exynos/exynos_drm_drv.h| 6 ++-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 69 +---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 53 +++---
drivers/gpu/drm/exynos/exynos_mixer.c | 26 +++--
6 files changed, 62 insertions(+), 187 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index f29e4be..d659ba2 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -603,75 +603,39 @@ static void decon_init(struct decon_context *ctx)
writel(VIDCON1_VCLK_HOLD, ctx-regs + VIDCON1(0));
}
-static int decon_poweron(struct decon_context *ctx)
+static void decon_enable(struct exynos_drm_crtc *crtc)
{
- int ret;
+ struct decon_context *ctx = crtc-ctx;
if (!ctx-suspended)
- return 0;
+ return;
ctx-suspended = false;
pm_runtime_get_sync(ctx-dev);
- ret = clk_prepare_enable(ctx-pclk);
- if (ret 0) {
- DRM_ERROR(Failed to prepare_enable the pclk [%d]\n, ret);
- goto pclk_err;
- }
-
- ret = clk_prepare_enable(ctx-aclk);
- if (ret 0) {
- DRM_ERROR(Failed to prepare_enable the aclk [%d]\n, ret);
- goto aclk_err;
- }
-
- ret = clk_prepare_enable(ctx-eclk);
- if (ret 0) {
- DRM_ERROR(Failed to prepare_enable the eclk [%d]\n, ret);
- goto eclk_err;
- }
-
- ret = clk_prepare_enable(ctx-vclk);
- if (ret 0) {
- DRM_ERROR(Failed to prepare_enable the vclk [%d]\n, ret);
- goto vclk_err;
- }
+ clk_prepare_enable(ctx-pclk);
+ clk_prepare_enable(ctx-aclk);
+ clk_prepare_enable(ctx-eclk);
+ clk_prepare_enable(ctx-vclk);
Merged this patch series to exynos-drm-next. However, this patch
especially above codes is required for more clean-up. Even though
decon_enable function never return error number, I think its internal
codes should be considered for some exception cases to check where an
error occurred at. So could you post the clean-up patch?
Thanks,
Inki Dae
decon_init(ctx);
/* if vblank was enabled status, enable it again. */
- if (test_and_clear_bit(0, ctx-irq_flags)) {
- ret = decon_enable_vblank(ctx-crtc);
- if (ret) {
- DRM_ERROR(Failed to re-enable vblank [%d]\n, ret);
- goto err;
- }
- }
+ if (test_and_clear_bit(0, ctx-irq_flags))
+ decon_enable_vblank(ctx-crtc);
decon_window_resume(ctx);
decon_apply(ctx);
-
- return 0;
-
-err:
- clk_disable_unprepare(ctx-vclk);
-vclk_err:
- clk_disable_unprepare(ctx-eclk);
-eclk_err:
- clk_disable_unprepare(ctx-aclk);
-aclk_err:
- clk_disable_unprepare(ctx-pclk);
-pclk_err:
- ctx-suspended = true;
- return ret;
}
-static int decon_poweroff(struct decon_context *ctx)
+static void decon_disable(struct exynos_drm_crtc *crtc)
{
+ struct decon_context *ctx = crtc-ctx;
+
if (ctx-suspended)
- return 0;
+ return;
/*
* We need to make sure that all windows are disabled before we
@@ -688,30 +652,11 @@ static int decon_poweroff(struct decon_context *ctx)
pm_runtime_put_sync(ctx-dev);
ctx-suspended = true;
- return 0;
-}
-
-static void decon_dpms(struct exynos_drm_crtc *crtc, int mode)
-{
- DRM_DEBUG_KMS(%s, %d\n, __FILE__, mode);
-
- switch (mode) {
- case DRM_MODE_DPMS_ON:
- decon_poweron(crtc-ctx);
- break;
- case DRM_MODE_DPMS_STANDBY:
- case DRM_MODE_DPMS_SUSPEND:
- case DRM_MODE_DPMS_OFF:
- decon_poweroff(crtc-ctx);
- break;
- default:
- DRM_DEBUG_KMS(unspecified mode %d\n, mode);
- break;
- }
}
static const struct exynos_drm_crtc_ops decon_crtc_ops = {
- .dpms = decon_dpms,
+ .enable = decon_enable,
+ .disable = decon_disable,
.mode_fixup = decon_mode_fixup,
.commit = decon_commit,
.enable_vblank = decon_enable_vblank,
@@ -796,7 +741,7 @@ static void decon_unbind(struct device *dev, struct
device *master,
{
struct decon_context *ctx = dev_get_drvdata(dev);
- decon_dpms(ctx-crtc, DRM_MODE_DPMS_OFF);
+
Re: [PATCH v5 7/9] mfd: cros_ec: Support multiple EC in a system
Hello Lee,
On 06/03/2015 03:49 PM, Lee Jones wrote:
[...]
int cros_ec_register(struct cros_ec_device *ec_dev)
@@ -52,14 +68,39 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
cros_ec_query_all(ec_dev);
-err = mfd_add_devices(dev, 0, cros_devs,
- ARRAY_SIZE(cros_devs),
+if (IS_ENABLED(CONFIG_OF) dev-of_node)
+ec_p.ec_name = of_get_property(dev-of_node,
+ google,cros-ec-name, NULL);
NACK
You either need to obtain this another way, or have a chat with the DT
Maintainers and explain why this platform is special enough to break
the normal conventions.
HINT: I different compatible string is normally more amenable, but
this will also require a DT ACK for me to take it through.
Ok, I'll just remove the property then. After all the driver only supports
two types of controllers currently, the normal host EC and the Power Delivery
(PD) one. And there isn't a DTS even in the downstream ChromiumOS tree that
is setting a different EC name right now.
I guess the idea of the binding was to make it future proof from when the
driver supports more types of controllers but I'll let Gwendal to comment on
this since he is the author of these patches.
+if (!ec_p.ec_name)
+ec_p.ec_name = CROS_EC_DEV_NAME;
+
+err = mfd_add_devices(ec_dev-dev, PLATFORM_DEVID_AUTO, ec_cell, 1,
NULL, ec_dev-irq, NULL);
if (err) {
-dev_err(dev, failed to add mfd devices\n);
+dev_err(dev, failed to add ec\n);
Might be nice to expand 'ec' so your users have half a chance in
deciphering what just went wrong.
I will, thanks a lot for your feedback.
[...]
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
[PATCH 5/9] drm/exynos: pass struct exynos_drm_plane in update/enable
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
We already have the plane pointer in before calling .update_plane() or
disable_plane() so pass it directly to those calls avoiding a new
conversion from zpos to struct exynos_drm_plane.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 26 +-
drivers/gpu/drm/exynos/exynos_drm_drv.h| 6 --
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24
drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 ++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 22 +-
drivers/gpu/drm/exynos/exynos_mixer.c | 28 +++-
6 files changed, 43 insertions(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index f2b2139..acbb712 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -392,24 +392,20 @@ static void decon_shadow_protect_win(struct decon_context
*ctx,
writel(val, ctx-regs + SHADOWCON);
}
-static void decon_update_plane(struct exynos_drm_crtc *crtc, unsigned int win)
+static void decon_update_plane(struct exynos_drm_crtc *crtc,
+ struct exynos_drm_plane *plane)
{
struct decon_context *ctx = crtc-ctx;
struct drm_display_mode *mode = crtc-base.state-adjusted_mode;
- struct exynos_drm_plane *plane;
int padding;
unsigned long val, alpha;
unsigned int last_x;
unsigned int last_y;
+ unsigned int win = plane-zpos;
if (ctx-suspended)
return;
- if (win 0 || win = WINDOWS_NR)
- return;
-
- plane = ctx-planes[win];
-
/* If suspended, enable this on resume */
if (ctx-suspended) {
plane-resume = true;
@@ -510,17 +506,13 @@ static void decon_update_plane(struct exynos_drm_crtc
*crtc, unsigned int win)
plane-enabled = true;
}
-static void decon_disable_plane(struct exynos_drm_crtc *crtc, unsigned int win)
+static void decon_disable_plane(struct exynos_drm_crtc *crtc,
+ struct exynos_drm_plane *plane)
{
struct decon_context *ctx = crtc-ctx;
- struct exynos_drm_plane *plane;
+ unsigned int win = plane-zpos;
u32 val;
- if (win 0 || win = WINDOWS_NR)
- return;
-
- plane = ctx-planes[win];
-
if (ctx-suspended) {
/* do not resume this window*/
plane-resume = false;
@@ -554,7 +546,7 @@ static void decon_window_suspend(struct decon_context *ctx)
plane = ctx-planes[i];
plane-resume = plane-enabled;
if (plane-enabled)
- decon_disable_plane(ctx-crtc, i);
+ decon_disable_plane(ctx-crtc, plane);
}
}
@@ -578,9 +570,9 @@ static void decon_apply(struct decon_context *ctx)
for (i = 0; i WINDOWS_NR; i++) {
plane = ctx-planes[i];
if (plane-enabled)
- decon_update_plane(ctx-crtc, i);
+ decon_update_plane(ctx-crtc, plane);
else
- decon_disable_plane(ctx-crtc, i);
+ decon_disable_plane(ctx-crtc, plane);
}
decon_commit(ctx-crtc);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 1858dae..0d19aaf 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -185,8 +185,10 @@ struct exynos_drm_crtc_ops {
int (*enable_vblank)(struct exynos_drm_crtc *crtc);
void (*disable_vblank)(struct exynos_drm_crtc *crtc);
void (*wait_for_vblank)(struct exynos_drm_crtc *crtc);
- void (*update_plane)(struct exynos_drm_crtc *crtc, unsigned int zpos);
- void (*disable_plane)(struct exynos_drm_crtc *crtc, unsigned int zpos);
+ void (*update_plane)(struct exynos_drm_crtc *crtc,
+struct exynos_drm_plane *plane);
+ void (*disable_plane)(struct exynos_drm_crtc *crtc,
+ struct exynos_drm_plane *plane);
void (*te_handler)(struct exynos_drm_crtc *crtc);
void (*clock_enable)(struct exynos_drm_crtc *crtc, bool enable);
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9c8522b..5a3f9f2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -618,22 +618,18 @@ static void fimd_shadow_protect_win(struct fimd_context
*ctx,
writel(val, ctx-regs + reg);
}
-static void fimd_update_plane(struct exynos_drm_crtc *crtc, unsigned int win)
+static void fimd_update_plane(struct exynos_drm_crtc *crtc,
+ struct exynos_drm_plane
[PATCH 3/9] drm/exynos: rename win_commit/disable to atomic-like names
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Rename win_commit() helper to update_plane() and win_disable() to
disable_plane().
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 14 +++---
drivers/gpu/drm/exynos/exynos_drm_drv.h| 4 ++--
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 +++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 10 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 12 ++--
drivers/gpu/drm/exynos/exynos_mixer.c | 12 ++--
6 files changed, 33 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index ffd7c3b..f2b2139 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -392,7 +392,7 @@ static void decon_shadow_protect_win(struct decon_context
*ctx,
writel(val, ctx-regs + SHADOWCON);
}
-static void decon_win_commit(struct exynos_drm_crtc *crtc, unsigned int win)
+static void decon_update_plane(struct exynos_drm_crtc *crtc, unsigned int win)
{
struct decon_context *ctx = crtc-ctx;
struct drm_display_mode *mode = crtc-base.state-adjusted_mode;
@@ -510,7 +510,7 @@ static void decon_win_commit(struct exynos_drm_crtc *crtc,
unsigned int win)
plane-enabled = true;
}
-static void decon_win_disable(struct exynos_drm_crtc *crtc, unsigned int win)
+static void decon_disable_plane(struct exynos_drm_crtc *crtc, unsigned int win)
{
struct decon_context *ctx = crtc-ctx;
struct exynos_drm_plane *plane;
@@ -554,7 +554,7 @@ static void decon_window_suspend(struct decon_context *ctx)
plane = ctx-planes[i];
plane-resume = plane-enabled;
if (plane-enabled)
- decon_win_disable(ctx-crtc, i);
+ decon_disable_plane(ctx-crtc, i);
}
}
@@ -578,9 +578,9 @@ static void decon_apply(struct decon_context *ctx)
for (i = 0; i WINDOWS_NR; i++) {
plane = ctx-planes[i];
if (plane-enabled)
- decon_win_commit(ctx-crtc, i);
+ decon_update_plane(ctx-crtc, i);
else
- decon_win_disable(ctx-crtc, i);
+ decon_disable_plane(ctx-crtc, i);
}
decon_commit(ctx-crtc);
@@ -683,8 +683,8 @@ static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable_vblank = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
.wait_for_vblank = decon_wait_for_vblank,
- .win_commit = decon_win_commit,
- .win_disable = decon_win_disable,
+ .update_plane = decon_update_plane,
+ .disable_plane = decon_disable_plane,
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 552ca4a..1858dae 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -185,8 +185,8 @@ struct exynos_drm_crtc_ops {
int (*enable_vblank)(struct exynos_drm_crtc *crtc);
void (*disable_vblank)(struct exynos_drm_crtc *crtc);
void (*wait_for_vblank)(struct exynos_drm_crtc *crtc);
- void (*win_commit)(struct exynos_drm_crtc *crtc, unsigned int zpos);
- void (*win_disable)(struct exynos_drm_crtc *crtc, unsigned int zpos);
+ void (*update_plane)(struct exynos_drm_crtc *crtc, unsigned int zpos);
+ void (*disable_plane)(struct exynos_drm_crtc *crtc, unsigned int zpos);
void (*te_handler)(struct exynos_drm_crtc *crtc);
void (*clock_enable)(struct exynos_drm_crtc *crtc, bool enable);
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 7c8ba61..2b0080d 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -618,7 +618,7 @@ static void fimd_shadow_protect_win(struct fimd_context
*ctx,
writel(val, ctx-regs + reg);
}
-static void fimd_win_commit(struct exynos_drm_crtc *crtc, unsigned int win)
+static void fimd_update_plane(struct exynos_drm_crtc *crtc, unsigned int win)
{
struct fimd_context *ctx = crtc-ctx;
struct exynos_drm_plane *plane;
@@ -734,7 +734,7 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc,
unsigned int win)
atomic_set(ctx-win_updated, 1);
}
-static void fimd_win_disable(struct exynos_drm_crtc *crtc, unsigned int win)
+static void fimd_disable_plane(struct exynos_drm_crtc *crtc, unsigned int win)
{
struct fimd_context *ctx = crtc-ctx;
struct exynos_drm_plane *plane;
@@ -773,7 +773,7 @@ static void fimd_window_suspend(struct fimd_context *ctx)
plane = ctx-planes[i];
plane-resume = plane-enabled;
if (plane-enabled)
- fimd_win_disable(ctx-crtc, i);
[PATCH 2/9] drm/exynos: add atomic asynchronous commit
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
The atomic modesetting interfaces supports async commits that should be
implemented by the drivers. If drm core requests an async commit
exynos_atomic_commit() will schedule a work task to run the update later.
It also waits to an update to finishes to schedule a new one.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 6
drivers/gpu/drm/exynos/exynos_drm_drv.h | 6
drivers/gpu/drm/exynos/exynos_drm_fb.c | 51 ++---
3 files changed, 52 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 08b9a8c..8ccff36 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -60,6 +60,9 @@ static int exynos_drm_load(struct drm_device *dev, unsigned
long flags)
if (!private)
return -ENOMEM;
+ INIT_WORK(private-work, exynos_drm_atomic_work);
+ private-dev = dev;
+
dev_set_drvdata(dev-dev, dev);
dev-dev_private = (void *)private;
@@ -140,6 +143,8 @@ err_free_private:
static int exynos_drm_unload(struct drm_device *dev)
{
+ struct exynos_drm_private *private = dev-dev_private;
+
exynos_drm_device_subdrv_remove(dev);
exynos_drm_fbdev_fini(dev);
@@ -150,6 +155,7 @@ static int exynos_drm_unload(struct drm_device *dev)
drm_mode_config_cleanup(dev);
drm_release_iommu_mapping(dev);
+ flush_work(private-work);
kfree(dev-dev_private);
dev-dev_private = NULL;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 1c66f65..552ca4a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -255,6 +255,10 @@ struct exynos_drm_private {
unsigned long da_space_size;
unsigned int pipe;
+
+ struct drm_device *dev;
+ struct work_struct work;
+ struct drm_atomic_state *state;
};
/*
@@ -324,6 +328,8 @@ static inline int exynos_drm_probe_vidi(void) { return 0; }
static inline void exynos_drm_remove_vidi(void) {}
#endif
+void exynos_drm_atomic_work(struct work_struct *work);
+
/* 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);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 789db6f..28626db 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -267,20 +267,18 @@ static void exynos_drm_output_poll_changed(struct
drm_device *dev)
exynos_drm_fbdev_init(dev);
}
-static int exynos_atomic_commit(struct drm_device *dev,
- struct drm_atomic_state *state,
- bool async)
+static void exynos_atomic_commit_schedule(struct drm_device *dev,
+ struct drm_atomic_state *state)
{
- int ret;
-
- ret = drm_atomic_helper_prepare_planes(dev, state);
- if (ret)
- return ret;
-
- /* This is the point of no return */
+ struct exynos_drm_private *private = dev-dev_private;
- drm_atomic_helper_swap_state(dev, state);
+ private-state = state;
+ schedule_work(private-work);
+}
+static void exynos_atomic_commit_complete(struct drm_device *dev,
+ struct drm_atomic_state *state)
+{
drm_atomic_helper_commit_modeset_disables(dev, state);
drm_atomic_helper_commit_modeset_enables(dev, state);
@@ -300,6 +298,37 @@ static int exynos_atomic_commit(struct drm_device *dev,
drm_atomic_helper_cleanup_planes(dev, state);
drm_atomic_state_free(state);
+}
+
+void exynos_drm_atomic_work(struct work_struct *work)
+{
+ struct exynos_drm_private *private = container_of(work,
+ struct exynos_drm_private, work);
+
+ exynos_atomic_commit_complete(private-dev, private-state);
+}
+
+static int exynos_atomic_commit(struct drm_device *dev,
+ struct drm_atomic_state *state,
+ bool async)
+{
+ struct exynos_drm_private *private = dev-dev_private;
+ int ret;
+
+ ret = drm_atomic_helper_prepare_planes(dev, state);
+ if (ret)
+ return ret;
+
+ /* This is the point of no return */
+
+ drm_atomic_helper_swap_state(dev, state);
+
+ flush_work(private-work);
+
+ if (async)
+ exynos_atomic_commit_schedule(dev, state);
+ else
+ exynos_atomic_commit_complete(dev, state);
return 0;
}
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the
[PATCH 8/9] drm/exynos: remove unused fields from struct exynos_drm_plane
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Now after the mode to use drm_plane_state directly struct drm_plane_state
has many unused fields, along with others that weren't used before the
plane state change. Thus remove them all.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 0d19aaf..b83d487 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -53,21 +53,12 @@ enum exynos_drm_output_type {
* - the unit is screen coordinates.
* @src_width: width of a partial image to be displayed from framebuffer.
* @src_height: height of a partial image to be displayed from framebuffer.
- * @fb_width: width of a framebuffer.
- * @fb_height: height of a framebuffer.
* @crtc_x: offset x on hardware screen.
* @crtc_y: offset y on hardware screen.
* @crtc_width: window width to be displayed (hardware screen).
* @crtc_height: window height to be displayed (hardware screen).
- * @mode_width: width of screen mode.
- * @mode_height: height of screen mode.
* @h_ratio: horizontal scaling ratio, 16.16 fixed point
* @v_ratio: vertical scaling ratio, 16.16 fixed point
- * @refresh: refresh rate.
- * @scan_flag: interlace or progressive way.
- * (it could be DRM_MODE_FLAG_*)
- * @bpp: pixel size.(in bit)
- * @pixel_format: fourcc pixel format of this overlay
* @dma_addr: array of bus(accessed by dma) address to the memory region
* allocated for a overlay.
* @zpos: order of overlay layer(z position).
@@ -84,21 +75,12 @@ struct exynos_drm_plane {
unsigned int src_y;
unsigned int src_width;
unsigned int src_height;
- unsigned int fb_width;
- unsigned int fb_height;
unsigned int crtc_x;
unsigned int crtc_y;
unsigned int crtc_width;
unsigned int crtc_height;
- unsigned int mode_width;
- unsigned int mode_height;
unsigned int h_ratio;
unsigned int v_ratio;
- unsigned int refresh;
- unsigned int scan_flag;
- unsigned int bpp;
- unsigned int pitch;
- uint32_t pixel_format;
dma_addr_t dma_addr[MAX_FB_BUFFER];
unsigned int zpos;
--
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
[PATCH 9/9] drm/exynos: unify exynos_drm_plane names with drm core
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Rename crtc_{widht,height} to crtc_{w,h} and src_{width,height} to
src_{w,h} to make it similar to the atomic state names.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 14 +++---
drivers/gpu/drm/exynos/exynos_drm_drv.h| 16
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 +++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 ++-
drivers/gpu/drm/exynos/exynos_mixer.c | 22 +++---
5 files changed, 39 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 7a99237..4e63a9c 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -442,25 +442,25 @@ static void decon_update_plane(struct exynos_drm_crtc
*crtc,
DRM_DEBUG_KMS(start addr = 0x%lx\n,
(unsigned long)val);
DRM_DEBUG_KMS(ovl_width = %d, ovl_height = %d\n,
- plane-crtc_width, plane-crtc_height);
+ plane-crtc_w, plane-crtc_h);
/*
* OSD position.
* In case the window layout goes of LCD layout, DECON fails.
*/
- if ((plane-crtc_x + plane-crtc_width) mode-hdisplay)
- plane-crtc_x = mode-hdisplay - plane-crtc_width;
- if ((plane-crtc_y + plane-crtc_height) mode-vdisplay)
- plane-crtc_y = mode-vdisplay - plane-crtc_height;
+ if ((plane-crtc_x + plane-crtc_w) mode-hdisplay)
+ plane-crtc_x = mode-hdisplay - plane-crtc_w;
+ if ((plane-crtc_y + plane-crtc_h) mode-vdisplay)
+ plane-crtc_y = mode-vdisplay - plane-crtc_h;
val = VIDOSDxA_TOPLEFT_X(plane-crtc_x) |
VIDOSDxA_TOPLEFT_Y(plane-crtc_y);
writel(val, ctx-regs + VIDOSD_A(win));
- last_x = plane-crtc_x + plane-crtc_width;
+ last_x = plane-crtc_x + plane-crtc_w;
if (last_x)
last_x--;
- last_y = plane-crtc_y + plane-crtc_height;
+ last_y = plane-crtc_y + plane-crtc_h;
if (last_y)
last_y--;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b83d487..7c6196e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -51,12 +51,12 @@ enum exynos_drm_output_type {
* - the unit is screen coordinates.
* @src_y: offset y on a framebuffer to be displayed.
* - the unit is screen coordinates.
- * @src_width: width of a partial image to be displayed from framebuffer.
- * @src_height: height of a partial image to be displayed from framebuffer.
+ * @src_w: width of a partial image to be displayed from framebuffer.
+ * @src_h: height of a partial image to be displayed from framebuffer.
* @crtc_x: offset x on hardware screen.
* @crtc_y: offset y on hardware screen.
- * @crtc_width: window width to be displayed (hardware screen).
- * @crtc_height: window height to be displayed (hardware screen).
+ * @crtc_w: window width to be displayed (hardware screen).
+ * @crtc_h: window height to be displayed (hardware screen).
* @h_ratio: horizontal scaling ratio, 16.16 fixed point
* @v_ratio: vertical scaling ratio, 16.16 fixed point
* @dma_addr: array of bus(accessed by dma) address to the memory region
@@ -73,12 +73,12 @@ struct exynos_drm_plane {
struct drm_plane base;
unsigned int src_x;
unsigned int src_y;
- unsigned int src_width;
- unsigned int src_height;
+ unsigned int src_w;
+ unsigned int src_h;
unsigned int crtc_x;
unsigned int crtc_y;
- unsigned int crtc_width;
- unsigned int crtc_height;
+ unsigned int crtc_w;
+ unsigned int crtc_h;
unsigned int h_ratio;
unsigned int v_ratio;
dma_addr_t dma_addr[MAX_FB_BUFFER];
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 2ece83b..920727b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -659,18 +659,18 @@ static void fimd_update_plane(struct exynos_drm_crtc
*crtc,
writel(val, ctx-regs + VIDWx_BUF_START(win, 0));
/* buffer end address */
- size = pitch * plane-crtc_height;
+ size = pitch * plane-crtc_h;
val = (unsigned long)(dma_addr + size);
writel(val, ctx-regs + VIDWx_BUF_END(win, 0));
DRM_DEBUG_KMS(start addr = 0x%lx, end addr = 0x%lx, size = 0x%lx\n,
(unsigned long)dma_addr, val, size);
DRM_DEBUG_KMS(ovl_width = %d, ovl_height = %d\n,
- plane-crtc_width, plane-crtc_height);
+ plane-crtc_w, plane-crtc_h);
/* buffer size */
- buf_offsize = pitch - (plane-crtc_width * bpp);
-
[PATCH 6/9] drm/exynos: remove duplicated check for suspend
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
The same check is place twice in fimd/decon_update_plane(), remove
one of them.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 3 ---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ---
2 files changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index acbb712..b773a48 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -403,9 +403,6 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
unsigned int last_y;
unsigned int win = plane-zpos;
- if (ctx-suspended)
- return;
-
/* If suspended, enable this on resume */
if (ctx-suspended) {
plane-resume = true;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 5a3f9f2..f586002 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -627,9 +627,6 @@ static void fimd_update_plane(struct exynos_drm_crtc *crtc,
unsigned int last_x, last_y, buf_offsize, line_size;
unsigned int win = plane-zpos;
- if (ctx-suspended)
- return;
-
/* If suspended, enable this on resume */
if (ctx-suspended) {
plane-resume = true;
--
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
[PATCH 4/9] drm/exynos: don't disable planes already disabled
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
on resume (or enable()) do not call disable_plane() on planes that
are already disabled.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 2b0080d..9c8522b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -786,23 +786,10 @@ static void fimd_window_resume(struct fimd_context *ctx)
plane = ctx-planes[i];
plane-enabled = plane-resume;
plane-resume = false;
- }
-}
-static void fimd_apply(struct fimd_context *ctx)
-{
- struct exynos_drm_plane *plane;
- int i;
-
- for (i = 0; i WINDOWS_NR; i++) {
- plane = ctx-planes[i];
if (plane-enabled)
fimd_update_plane(ctx-crtc, i);
- else
- fimd_disable_plane(ctx-crtc, i);
}
-
- fimd_commit(ctx-crtc);
}
static void fimd_enable(struct exynos_drm_crtc *crtc)
@@ -835,7 +822,7 @@ static void fimd_enable(struct exynos_drm_crtc *crtc)
fimd_window_resume(ctx);
- fimd_apply(ctx);
+ fimd_commit(ctx-crtc);
}
static void fimd_disable(struct exynos_drm_crtc *crtc)
--
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
[PATCH 7/9] drm/exynos: use drm atomic state directly
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
For some fields the use struct exynos_drm_plane filled with data from the
plane state just creates a source of duplicated information and overhead.
Here we change the crtc drivers to access the plane state directly
simplifying the code by not relying on a exynos internal struct.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 23 ++-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 29 +++--
drivers/gpu/drm/exynos/exynos_drm_plane.c | 12 --
drivers/gpu/drm/exynos/exynos_mixer.c | 65 --
4 files changed, 63 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index b773a48..7a99237 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -281,16 +281,16 @@ static void decon_disable_vblank(struct exynos_drm_crtc
*crtc)
}
}
-static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win)
+static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
+struct drm_framebuffer *fb)
{
- struct exynos_drm_plane *plane = ctx-planes[win];
unsigned long val;
int padding;
val = readl(ctx-regs + WINCON(win));
val = ~WINCONx_BPPMODE_MASK;
- switch (plane-pixel_format) {
+ switch (fb-pixel_format) {
case DRM_FORMAT_RGB565:
val |= WINCONx_BPPMODE_16BPP_565;
val |= WINCONx_BURSTLEN_16WORD;
@@ -339,7 +339,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx,
unsigned int win)
break;
}
- DRM_DEBUG_KMS(bpp = %d\n, plane-bpp);
+ DRM_DEBUG_KMS(bpp = %d\n, fb-bits_per_pixel);
/*
* In case of exynos, setting dma-burst to 16Word causes permanent
@@ -349,8 +349,8 @@ static void decon_win_set_pixfmt(struct decon_context *ctx,
unsigned int win)
* movement causes unstable DMA which results into iommu crash/tear.
*/
- padding = (plane-pitch / (plane-bpp 3)) - plane-fb_width;
- if (plane-fb_width + padding MIN_FB_WIDTH_FOR_16WORD_BURST) {
+ padding = (fb-pitches[0] / (fb-bits_per_pixel 3)) - fb-width;
+ if (fb-width + padding MIN_FB_WIDTH_FOR_16WORD_BURST) {
val = ~WINCONx_BURSTLEN_MASK;
val |= WINCONx_BURSTLEN_8WORD;
}
@@ -397,11 +397,14 @@ static void decon_update_plane(struct exynos_drm_crtc
*crtc,
{
struct decon_context *ctx = crtc-ctx;
struct drm_display_mode *mode = crtc-base.state-adjusted_mode;
+ struct drm_plane_state *state = plane-base.state;
int padding;
unsigned long val, alpha;
unsigned int last_x;
unsigned int last_y;
unsigned int win = plane-zpos;
+ unsigned int bpp = state-fb-bits_per_pixel 3;
+ unsigned int pitch = state-fb-pitches[0];
/* If suspended, enable this on resume */
if (ctx-suspended) {
@@ -426,11 +429,11 @@ static void decon_update_plane(struct exynos_drm_crtc
*crtc,
val = (unsigned long)plane-dma_addr[0];
writel(val, ctx-regs + VIDW_BUF_START(win));
- padding = (plane-pitch / (plane-bpp 3)) - plane-fb_width;
+ padding = (pitch / bpp) - state-fb-width;
/* buffer size */
- writel(plane-fb_width + padding, ctx-regs + VIDW_WHOLE_X(win));
- writel(plane-fb_height, ctx-regs + VIDW_WHOLE_Y(win));
+ writel(state-fb-width + padding, ctx-regs + VIDW_WHOLE_X(win));
+ writel(state-fb-height, ctx-regs + VIDW_WHOLE_Y(win));
/* offset from the start of the buffer to read */
writel(plane-src_x, ctx-regs + VIDW_OFFSET_X(win));
@@ -481,7 +484,7 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
writel(alpha, ctx-regs + VIDOSD_D(win));
- decon_win_set_pixfmt(ctx, win);
+ decon_win_set_pixfmt(ctx, win, state-fb);
/* hardware window 0 doesn't support color key. */
if (win != 0)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index f586002..2ece83b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -490,9 +490,9 @@ static void fimd_disable_vblank(struct exynos_drm_crtc
*crtc)
}
}
-static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned int win)
+static void fimd_win_set_pixfmt(struct fimd_context *ctx, unsigned int win,
+ struct drm_framebuffer *fb)
{
- struct exynos_drm_plane *plane = ctx-planes[win];
unsigned long val;
val = WINCONx_ENWIN;
@@ -502,11 +502,11 @@ static void fimd_win_set_pixfmt(struct fimd_context *ctx,
unsigned int win)
* So the request format is ARGB then change it to
[PATCH 1/9] drm/exynos: add error messages if clks failed to get enabled
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Check error and call DRM_ERROR if clk_prepare_enable() fails.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 29
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 --
drivers/gpu/drm/exynos/exynos_mixer.c | 31 +-
3 files changed, 63 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index d659ba2..ffd7c3b 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -606,6 +606,7 @@ static void decon_init(struct decon_context *ctx)
static void decon_enable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc-ctx;
+ int ret;
if (!ctx-suspended)
return;
@@ -614,10 +615,30 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
pm_runtime_get_sync(ctx-dev);
- clk_prepare_enable(ctx-pclk);
- clk_prepare_enable(ctx-aclk);
- clk_prepare_enable(ctx-eclk);
- clk_prepare_enable(ctx-vclk);
+ ret = clk_prepare_enable(ctx-pclk);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the pclk [%d]\n, ret);
+ return;
+ goto pclk_err;
+ }
+
+ ret = clk_prepare_enable(ctx-aclk);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the aclk [%d]\n, ret);
+ return;
+ }
+
+ ret = clk_prepare_enable(ctx-eclk);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the eclk [%d]\n, ret);
+ return;
+ }
+
+ ret = clk_prepare_enable(ctx-vclk);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the vclk [%d]\n, ret);
+ return;
+ }
decon_init(ctx);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 9661853..7c8ba61 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -808,6 +808,7 @@ static void fimd_apply(struct fimd_context *ctx)
static void fimd_enable(struct exynos_drm_crtc *crtc)
{
struct fimd_context *ctx = crtc-ctx;
+ int ret;
if (!ctx-suspended)
return;
@@ -816,8 +817,17 @@ static void fimd_enable(struct exynos_drm_crtc *crtc)
pm_runtime_get_sync(ctx-dev);
- clk_prepare_enable(ctx-bus_clk);
- clk_prepare_enable(ctx-lcd_clk);
+ ret = clk_prepare_enable(ctx-bus_clk);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the bus clk [%d]\n, ret);
+ return;
+ }
+
+ ret = clk_prepare_enable(ctx-lcd_clk);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the lcd clk [%d]\n, ret);
+ return;
+ }
/* if vblank was enabled status, enable it again. */
if (test_and_clear_bit(0, ctx-irq_flags))
diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 6bab717..1b77fc7 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1031,6 +1031,7 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
{
struct mixer_context *ctx = crtc-ctx;
struct mixer_resources *res = ctx-mixer_res;
+ int ret;
mutex_lock(ctx-mixer_mutex);
if (ctx-powered) {
@@ -1042,12 +1043,32 @@ static void mixer_enable(struct exynos_drm_crtc *crtc)
pm_runtime_get_sync(ctx-dev);
- clk_prepare_enable(res-mixer);
- clk_prepare_enable(res-hdmi);
+ ret = clk_prepare_enable(res-mixer);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the mixer clk [%d]\n, ret);
+ return;
+ }
+ ret = clk_prepare_enable(res-hdmi);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the hdmi clk [%d]\n, ret);
+ return;
+ }
if (ctx-vp_enabled) {
- clk_prepare_enable(res-vp);
- if (ctx-has_sclk)
- clk_prepare_enable(res-sclk_mixer);
+ ret = clk_prepare_enable(res-vp);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the vp clk [%d]\n,
+ ret);
+ return;
+ }
+ if (ctx-has_sclk) {
+ ret = clk_prepare_enable(res-sclk_mixer);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the \
+ sclk_mixer clk [%d]\n,
+ ret);
+ return;
+ }
+ }
}
[PATCH v5 2/9] mfd: cros_ec: rev cros_ec_commands.h
From: Stephen Barber smbar...@chromium.org
Update cros_ec_commands.h to the latest version in the EC
firmware sources and add power domain and passthru commands.
Also, update lightbar to use new command names.
Signed-off-by: Stephen Barber smbar...@chromium.org
Reviewed-by: Randall Spangler rspang...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Heiko Stuebner he...@sntech.de
Reviewed-by: Gwendal Grignou gwen...@chromium.org
Tested-by: Gwendal Grignou gwen...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes since v4: None
Changes since v3: None
Changes since v2: None
Changes since v1:
- Added Gwendal Grignou and Heiko Stuebner Tested-by tags
- Added Gwendal Grignou Reviewed-by tag
- Added Lee Jones Acked-by tag
---
drivers/platform/chrome/cros_ec_lightbar.c | 14 +-
include/linux/mfd/cros_ec_commands.h | 277 ++---
2 files changed, 262 insertions(+), 29 deletions(-)
diff --git a/drivers/platform/chrome/cros_ec_lightbar.c
b/drivers/platform/chrome/cros_ec_lightbar.c
index 560e5d41b7ae..6e1986a2dce1 100644
--- a/drivers/platform/chrome/cros_ec_lightbar.c
+++ b/drivers/platform/chrome/cros_ec_lightbar.c
@@ -197,8 +197,8 @@ static ssize_t brightness_store(struct device *dev,
return -ENOMEM;
param = (struct ec_params_lightbar *)msg-data;
- param-cmd = LIGHTBAR_CMD_BRIGHTNESS;
- param-brightness.num = val;
+ param-cmd = LIGHTBAR_CMD_SET_BRIGHTNESS;
+ param-set_brightness.num = val;
ret = lb_throttle();
if (ret)
goto exit;
@@ -253,11 +253,11 @@ static ssize_t led_rgb_store(struct device *dev, struct
device_attribute *attr,
if (i == 4) {
param = (struct ec_params_lightbar *)msg-data;
- param-cmd = LIGHTBAR_CMD_RGB;
- param-rgb.led = val[0];
- param-rgb.red = val[1];
- param-rgb.green = val[2];
- param-rgb.blue = val[3];
+ param-cmd = LIGHTBAR_CMD_SET_RGB;
+ param-set_rgb.led = val[0];
+ param-set_rgb.red = val[1];
+ param-set_rgb.green = val[2];
+ param-set_rgb.blue = val[3];
/*
* Throttle only the first of every four transactions,
* so that the user can update all four LEDs at once.
diff --git a/include/linux/mfd/cros_ec_commands.h
b/include/linux/mfd/cros_ec_commands.h
index a49cd41feea7..13b630c10d4c 100644
--- a/include/linux/mfd/cros_ec_commands.h
+++ b/include/linux/mfd/cros_ec_commands.h
@@ -515,7 +515,7 @@ struct ec_host_response {
/*
* Notes on commands:
*
- * Each command is an 8-byte command value. Commands which take params or
+ * Each command is an 16-bit command value. Commands which take params or
* return response data specify structs for that data. If no struct is
* specified, the command does not input or output data, respectively.
* Parameter/response length is implicit in the structs. Some underlying
@@ -966,7 +966,7 @@ struct rgb_s {
/* List of tweakable parameters. NOTE: It's __packed so it can be sent in a
* host command, but the alignment is the same regardless. Keep it that way.
*/
-struct lightbar_params {
+struct lightbar_params_v0 {
/* Timing */
int32_t google_ramp_up;
int32_t google_ramp_down;
@@ -1000,32 +1000,81 @@ struct lightbar_params {
struct rgb_s color[8]; /* 0-3 are Google colors */
} __packed;
+struct lightbar_params_v1 {
+ /* Timing */
+ int32_t google_ramp_up;
+ int32_t google_ramp_down;
+ int32_t s3s0_ramp_up;
+ int32_t s0_tick_delay[2]; /* AC=0/1 */
+ int32_t s0a_tick_delay[2]; /* AC=0/1 */
+ int32_t s0s3_ramp_down;
+ int32_t s3_sleep_for;
+ int32_t s3_ramp_up;
+ int32_t s3_ramp_down;
+ int32_t tap_tick_delay;
+ int32_t tap_display_time;
+
+ /* Tap-for-battery params */
+ uint8_t tap_pct_red;
+ uint8_t tap_pct_green;
+ uint8_t tap_seg_min_on;
+ uint8_t tap_seg_max_on;
+ uint8_t tap_seg_osc;
+ uint8_t tap_idx[3];
+
+ /* Oscillation */
+ uint8_t osc_min[2]; /* AC=0/1 */
+ uint8_t osc_max[2]; /* AC=0/1 */
+ uint8_t w_ofs[2]; /* AC=0/1 */
+
+ /* Brightness limits based on the backlight and AC. */
+ uint8_t bright_bl_off_fixed[2]; /* AC=0/1 */
+ uint8_t bright_bl_on_min[2];/* AC=0/1 */
+ uint8_t bright_bl_on_max[2];/* AC=0/1 */
+
+ /* Battery level thresholds */
+ uint8_t battery_threshold[LB_BATTERY_LEVELS - 1];
+
+ /* Map [AC][battery_level] to color index */
+ uint8_t
[PATCH v5 5/9] mfd: cros_ec: add bus-specific proto v3 code
From: Stephen Barber smbar...@chromium.org
Add proto v3 support to the SPI, I2C, and LPC.
Signed-off-by: Stephen Barber smbar...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Heiko Stuebner he...@sntech.de
Reviewed-by: Gwendal Grignou gwen...@chromium.org
Tested-by: Gwendal Grignou gwen...@chromium.org
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes since v4: None
Changes since v3:
- Added acked-by tag from Lee Jones.
Changes since v2: None
Changes since v1:
- Added Gwendal Grignou Reviewed-by and Tested-by tags
---
drivers/mfd/cros_ec_i2c.c | 166 ++-
drivers/mfd/cros_ec_spi.c | 382 +-
drivers/platform/chrome/cros_ec_lpc.c | 73 ++-
include/linux/mfd/cros_ec.h | 6 +
4 files changed, 569 insertions(+), 58 deletions(-)
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index b400bfa2772a..22e8a4ae1711 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -13,6 +13,7 @@
* GNU General Public License for more details.
*/
+#include linux/delay.h
#include linux/kernel.h
#include linux/module.h
#include linux/i2c.h
@@ -22,6 +23,32 @@
#include linux/platform_device.h
#include linux/slab.h
+/**
+ * Request format for protocol v3
+ * byte 0 0xda (EC_COMMAND_PROTOCOL_3)
+ * byte 1-8struct ec_host_request
+ * byte 10-response data
+ */
+struct ec_host_request_i2c {
+ /* Always 0xda to backward compatible with v2 struct */
+ uint8_t command_protocol;
+ struct ec_host_request ec_request;
+} __packed;
+
+
+/*
+ * Response format for protocol v3
+ * byte 0 result code
+ * byte 1 packet_length
+ * byte 2-9struct ec_host_response
+ * byte 10-response data
+ */
+struct ec_host_response_i2c {
+ uint8_t result;
+ uint8_t packet_length;
+ struct ec_host_response ec_response;
+} __packed;
+
static inline struct cros_ec_device *to_ec_dev(struct device *dev)
{
struct i2c_client *client = to_i2c_client(dev);
@@ -29,6 +56,134 @@ static inline struct cros_ec_device *to_ec_dev(struct
device *dev)
return i2c_get_clientdata(client);
}
+static int cros_ec_pkt_xfer_i2c(struct cros_ec_device *ec_dev,
+ struct cros_ec_command *msg)
+{
+ struct i2c_client *client = ec_dev-priv;
+ int ret = -ENOMEM;
+ int i;
+ int packet_len;
+ u8 *out_buf = NULL;
+ u8 *in_buf = NULL;
+ u8 sum;
+ struct i2c_msg i2c_msg[2];
+ struct ec_host_response *ec_response;
+ struct ec_host_request_i2c *ec_request_i2c;
+ struct ec_host_response_i2c *ec_response_i2c;
+ int request_header_size = sizeof(struct ec_host_request_i2c);
+ int response_header_size = sizeof(struct ec_host_response_i2c);
+
+ i2c_msg[0].addr = client-addr;
+ i2c_msg[0].flags = 0;
+ i2c_msg[1].addr = client-addr;
+ i2c_msg[1].flags = I2C_M_RD;
+
+ packet_len = msg-insize + response_header_size;
+ BUG_ON(packet_len ec_dev-din_size);
+ in_buf = ec_dev-din;
+ i2c_msg[1].len = packet_len;
+ i2c_msg[1].buf = (char *) in_buf;
+
+ packet_len = msg-outsize + request_header_size;
+ BUG_ON(packet_len ec_dev-dout_size);
+ out_buf = ec_dev-dout;
+ i2c_msg[0].len = packet_len;
+ i2c_msg[0].buf = (char *) out_buf;
+
+ /* create request data */
+ ec_request_i2c = (struct ec_host_request_i2c *) out_buf;
+ ec_request_i2c-command_protocol = EC_COMMAND_PROTOCOL_3;
+
+ ec_dev-dout++;
+ ret = cros_ec_prepare_tx(ec_dev, msg);
+ ec_dev-dout--;
+
+ /* send command to EC and read answer */
+ ret = i2c_transfer(client-adapter, i2c_msg, 2);
+ if (ret 0) {
+ dev_dbg(ec_dev-dev, i2c transfer failed: %d\n, ret);
+ goto done;
+ } else if (ret != 2) {
+ dev_err(ec_dev-dev, failed to get response: %d\n, ret);
+ ret = -EIO;
+ goto done;
+ }
+
+ ec_response_i2c = (struct ec_host_response_i2c *) in_buf;
+ msg-result = ec_response_i2c-result;
+ ec_response = ec_response_i2c-ec_response;
+
+ switch (msg-result) {
+ case EC_RES_SUCCESS:
+ break;
+ case EC_RES_IN_PROGRESS:
+ ret = -EAGAIN;
+ dev_dbg(ec_dev-dev, command 0x%02x in progress\n,
+ msg-command);
+ goto done;
+
+ default:
+ dev_dbg(ec_dev-dev, command 0x%02x returned %d\n,
+ msg-command, msg-result);
+ /*
+* When we send v3 request to v2 ec, ec won't recognize the
+* 0xda (EC_COMMAND_PROTOCOL_3) and will return with status
+* EC_RES_INVALID_COMMAND with zero data length.
+*
+* In case of invalid command for v3 protocol the
[PATCH v5 1/9] mfd: cros_ec: Use a zero-length array for command data
Commit 1b84f2a4cd4a (mfd: cros_ec: Use fixed size arrays to transfer
data with the EC) modified the struct cros_ec_command fields to not
use pointers for the input and output buffers and use fixed length
arrays instead.
This change was made because the cros_ec ioctl API uses that struct
cros_ec_command to allow user-space to send commands to the EC and
to get data from the EC. So using pointers made the API not 64-bit
safe. Unfortunately this approach was not flexible enough for all
the use-cases since there may be a need to send larger commands
on newer versions of the EC command protocol.
So to avoid to choose a constant length that it may be too big for
most commands and thus wasting memory and CPU cycles on copy from
and to user-space or having a size that is too small for some big
commands, use a zero-length array that is both 64-bit safe and
flexible. The same buffer is used for both output and input data
so the maximum of these values should be used to allocate it.
Suggested-by: Gwendal Grignou gwen...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Heiko Stuebner he...@sntech.de
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes since v4: None
Changes since v3:
- Added acked-by tag from Lee Jones.
Changes since v2:
- Set the version field in the cros_ec_command. Reported by Heiko Stuebner.
- Use kmalloc/kfree instead of pre-allocating using variables in the stack.
Suggested by Lee Jones.
Changes since v1:
- Add Heiko Stuebner Tested-by tag
- Removed a new blank line at EOF warning. Reported by Heiko Stuebner
- Use kmalloc instead of kzalloc when the message is later initialized
Suggested by Gwendal Grignou
- Pre-allocate struct cros_ec_command instead of dynamically allocate it
whenever is possible. Suggested by Gwendal Grignou
- Pre-allocate buffers for the usual cases and only allocate dynamically
in the heap for bigger sizes. Suggested by Gwendal Grignou
- Don't access the cros_ec_command received from user-space before doing
a copy_from_user. Suggested by Gwendal Grignou
- Only copy from user-space outsize bytes and copy_to_user insize bytes
Suggested by Gwendal Grignou
- ec_device_ioctl_xcmd() must return the numbers of bytes read and not 0
on success. Suggested by Gwendal Grignou
- Rename alloc_cmd_msg to alloc_lightbar_cmd_msg. Suggested by Gwendal Grignou
---
drivers/i2c/busses/i2c-cros-ec-tunnel.c| 45 ++---
drivers/input/keyboard/cros_ec_keyb.c | 29 --
drivers/mfd/cros_ec.c | 28 --
drivers/mfd/cros_ec_i2c.c | 4 +-
drivers/mfd/cros_ec_spi.c | 2 +-
drivers/platform/chrome/cros_ec_dev.c | 65 +++-
drivers/platform/chrome/cros_ec_lightbar.c | 152 +++-
drivers/platform/chrome/cros_ec_lpc.c | 8 +-
drivers/platform/chrome/cros_ec_sysfs.c| 154 ++---
include/linux/mfd/cros_ec.h| 6 +-
10 files changed, 318 insertions(+), 175 deletions(-)
diff --git a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
index fa8dedd8c3a2..a0d95ff682ae 100644
--- a/drivers/i2c/busses/i2c-cros-ec-tunnel.c
+++ b/drivers/i2c/busses/i2c-cros-ec-tunnel.c
@@ -182,8 +182,9 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg i2c_msgs[],
const u16 bus_num = bus-remote_bus;
int request_len;
int response_len;
+ int alloc_size;
int result;
- struct cros_ec_command msg = { };
+ struct cros_ec_command *msg;
request_len = ec_i2c_count_message(i2c_msgs, num);
if (request_len 0) {
@@ -198,25 +199,39 @@ static int ec_i2c_xfer(struct i2c_adapter *adap, struct
i2c_msg i2c_msgs[],
return response_len;
}
- result = ec_i2c_construct_message(msg.outdata, i2c_msgs, num, bus_num);
- if (result)
- return result;
+ alloc_size = max(request_len, response_len);
+ msg = kmalloc(sizeof(*msg) + alloc_size, GFP_KERNEL);
+ if (!msg)
+ return -ENOMEM;
- msg.version = 0;
- msg.command = EC_CMD_I2C_PASSTHRU;
- msg.outsize = request_len;
- msg.insize = response_len;
+ result = ec_i2c_construct_message(msg-data, i2c_msgs, num, bus_num);
+ if (result) {
+ dev_err(dev, Error constructing EC i2c message %d\n, result);
+ goto exit;
+ }
- result = cros_ec_cmd_xfer(bus-ec, msg);
- if (result 0)
- return result;
+ msg-version = 0;
+ msg-command = EC_CMD_I2C_PASSTHRU;
+ msg-outsize = request_len;
+ msg-insize = response_len;
- result = ec_i2c_parse_response(msg.indata, i2c_msgs, num);
- if (result 0)
- return result;
+ result = cros_ec_cmd_xfer(bus-ec, msg);
+ if (result 0) {
+ dev_err(dev, Error transferring EC i2c
[PATCH v5 4/9] mfd: cros_ec: add proto v3 skeleton
From: Stephen Barber smbar...@chromium.org
Add support in cros_ec.c to handle EC host command protocol v3.
For v3+, probe for maximum shared protocol version and max
request, response, and passthrough sizes. For now, this will
always fall back to v2, since there is no bus-specific code
for handling proto v3 packets.
Signed-off-by: Stephen Barber smbar...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Reviewed-by: Gwendal Grignou gwen...@chromium.org
Tested-by: Gwendal Grignou gwen...@chromium.org
Tested-by: Heiko Stuebner he...@sntech.de
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes since v4: None
Changes since v3:
- Added tested-by from Heiko Stuebner.
- Added acked-by tag from Lee Jones.
Changes since v2:
- Add the helpers to the drivers/platform/chrome/cros_ec_proto.c driver
instead of drivers/mfd/cros_ec.c. Suggested by Lee Jones.
- Rename the proto probe functions for proto_query since probe has a
special meaning in Linux so is confusing.
Changes since v1:
- Squash change https://chromium-review.googlesource.com/#/c/262870/ in
the patch. Suggested by Gwendal Grignou
- Add Reviewed-by and Tested-by tags from Gwendal Grignou
---
drivers/mfd/cros_ec.c | 23 ++-
drivers/mfd/cros_ec_i2c.c | 4 +
drivers/mfd/cros_ec_spi.c | 7 +-
drivers/platform/chrome/cros_ec_lpc.c | 4 +
drivers/platform/chrome/cros_ec_proto.c | 339
include/linux/mfd/cros_ec.h | 28 ++-
6 files changed, 355 insertions(+), 50 deletions(-)
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index d857f6a2b57b..08d82bfc5268 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -36,19 +36,22 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
struct device *dev = ec_dev-dev;
int err = 0;
- if (ec_dev-din_size) {
- ec_dev-din = devm_kzalloc(dev, ec_dev-din_size, GFP_KERNEL);
- if (!ec_dev-din)
- return -ENOMEM;
- }
- if (ec_dev-dout_size) {
- ec_dev-dout = devm_kzalloc(dev, ec_dev-dout_size, GFP_KERNEL);
- if (!ec_dev-dout)
- return -ENOMEM;
- }
+ ec_dev-max_request = sizeof(struct ec_params_hello);
+ ec_dev-max_response = sizeof(struct ec_response_get_protocol_info);
+ ec_dev-max_passthru = 0;
+
+ ec_dev-din = devm_kzalloc(dev, ec_dev-din_size, GFP_KERNEL);
+ if (!ec_dev-din)
+ return -ENOMEM;
+
+ ec_dev-dout = devm_kzalloc(dev, ec_dev-dout_size, GFP_KERNEL);
+ if (!ec_dev-dout)
+ return -ENOMEM;
mutex_init(ec_dev-lock);
+ cros_ec_query_all(ec_dev);
+
err = mfd_add_devices(dev, 0, cros_devs,
ARRAY_SIZE(cros_devs),
NULL, ec_dev-irq, NULL);
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/mfd/cros_ec_i2c.c
index fbf7819f5de5..b400bfa2772a 100644
--- a/drivers/mfd/cros_ec_i2c.c
+++ b/drivers/mfd/cros_ec_i2c.c
@@ -143,8 +143,12 @@ static int cros_ec_i2c_probe(struct i2c_client *client,
ec_dev-priv = client;
ec_dev-irq = client-irq;
ec_dev-cmd_xfer = cros_ec_cmd_xfer_i2c;
+ ec_dev-pkt_xfer = NULL;
ec_dev-ec_name = client-name;
ec_dev-phys_name = client-adapter-name;
+ ec_dev-din_size = sizeof(struct ec_host_response) +
+ sizeof(struct ec_response_get_protocol_info);
+ ec_dev-dout_size = sizeof(struct ec_host_request);
err = cros_ec_register(ec_dev);
if (err) {
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index 573730fec947..04da2f288ef8 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -361,10 +361,13 @@ static int cros_ec_spi_probe(struct spi_device *spi)
ec_dev-priv = ec_spi;
ec_dev-irq = spi-irq;
ec_dev-cmd_xfer = cros_ec_cmd_xfer_spi;
+ ec_dev-pkt_xfer = NULL;
ec_dev-ec_name = ec_spi-spi-modalias;
ec_dev-phys_name = dev_name(ec_spi-spi-dev);
- ec_dev-din_size = EC_MSG_BYTES + EC_MSG_PREAMBLE_COUNT;
- ec_dev-dout_size = EC_MSG_BYTES;
+ ec_dev-din_size = EC_MSG_PREAMBLE_COUNT +
+ sizeof(struct ec_host_response) +
+ sizeof(struct ec_response_get_protocol_info);
+ ec_dev-dout_size = sizeof(struct ec_host_request);
err = cros_ec_register(ec_dev);
if (err) {
diff --git a/drivers/platform/chrome/cros_ec_lpc.c
b/drivers/platform/chrome/cros_ec_lpc.c
index 214ae7fef984..06c5790b2c28 100644
--- a/drivers/platform/chrome/cros_ec_lpc.c
+++ b/drivers/platform/chrome/cros_ec_lpc.c
@@ -205,7 +205,11 @@ static int cros_ec_lpc_probe(struct platform_device *pdev)
ec_dev-ec_name = pdev-name;
ec_dev-phys_name = dev_name(dev);
ec_dev-cmd_xfer = cros_ec_cmd_xfer_lpc;
+
[PATCH v5 3/9] mfd: cros_ec: Move protocol helpers out of the MFD driver
The MFD driver should only have the logic to instantiate its child devices
and setup any shared resources that will be used by the subdevices drivers.
The cros_ec MFD is more complex than expected since it also has helpers to
communicate with the EC. So the driver will only get more bigger as other
protocols are supported in the future. So move the communication protocol
helpers to its own driver as drivers/platform/chrome/cros_ec_proto.c.
Suggested-by: Lee Jones lee.jo...@linaro.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Heiko Stuebner he...@sntech.de
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes since v4: None
Changes since v3:
- Added tested-by tag from Heiko Stuebner.
- Added acked-by tag from Lee Jones.
Changes since v2: None, new patch.
---
drivers/i2c/busses/Kconfig | 2 +-
drivers/input/keyboard/Kconfig | 2 +-
drivers/mfd/Kconfig | 6 +-
drivers/mfd/cros_ec.c | 96 --
drivers/platform/chrome/Kconfig | 9 ++-
drivers/platform/chrome/Makefile| 1 +
drivers/platform/chrome/cros_ec_proto.c | 115
7 files changed, 129 insertions(+), 102 deletions(-)
create mode 100644 drivers/platform/chrome/cros_ec_proto.c
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 2255af23b9c7..5f1c1c4f5d87 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -1103,7 +1103,7 @@ config I2C_SIBYTE
config I2C_CROS_EC_TUNNEL
tristate ChromeOS EC tunnel I2C bus
- depends on MFD_CROS_EC
+ depends on CROS_EC_PROTO
help
If you say yes here you get an I2C bus that will tunnel i2c commands
through to the other side of the ChromeOS EC to the i2c bus
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 106fbac7f8c5..e8eb60c6d83e 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -677,7 +677,7 @@ config KEYBOARD_W90P910
config KEYBOARD_CROS_EC
tristate ChromeOS EC keyboard
select INPUT_MATRIXKMAP
- depends on MFD_CROS_EC
+ depends on CROS_EC_PROTO
help
Say Y here to enable the matrix keyboard used by ChromeOS devices
and implemented on the ChromeOS EC. You must enable one bus option
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d5ad04dad081..cf3b86d441f7 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -94,6 +94,8 @@ config MFD_AXP20X
config MFD_CROS_EC
tristate ChromeOS Embedded Controller
select MFD_CORE
+ select CHROME_PLATFORMS
+ select CROS_EC_PROTO
help
If you say Y here you get support for the ChromeOS Embedded
Controller (EC) providing keyboard, battery and power services.
@@ -102,7 +104,7 @@ config MFD_CROS_EC
config MFD_CROS_EC_I2C
tristate ChromeOS Embedded Controller (I2C)
- depends on MFD_CROS_EC I2C
+ depends on MFD_CROS_EC CROS_EC_PROTO I2C
help
If you say Y here, you get support for talking to the ChromeOS
@@ -112,7 +114,7 @@ config MFD_CROS_EC_I2C
config MFD_CROS_EC_SPI
tristate ChromeOS Embedded Controller (SPI)
- depends on MFD_CROS_EC SPI OF
+ depends on MFD_CROS_EC CROS_EC_PROTO SPI OF
---help---
If you say Y here, you get support for talking to the ChromeOS EC
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 4a0f6dfcd376..d857f6a2b57b 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -23,102 +23,6 @@
#include linux/module.h
#include linux/mfd/core.h
#include linux/mfd/cros_ec.h
-#include linux/mfd/cros_ec_commands.h
-#include linux/delay.h
-
-#define EC_COMMAND_RETRIES 50
-
-int cros_ec_prepare_tx(struct cros_ec_device *ec_dev,
- struct cros_ec_command *msg)
-{
- uint8_t *out;
- int csum, i;
-
- BUG_ON(msg-outsize EC_PROTO2_MAX_PARAM_SIZE);
- out = ec_dev-dout;
- out[0] = EC_CMD_VERSION0 + msg-version;
- out[1] = msg-command;
- out[2] = msg-outsize;
- csum = out[0] + out[1] + out[2];
- for (i = 0; i msg-outsize; i++)
- csum += out[EC_MSG_TX_HEADER_BYTES + i] = msg-data[i];
- out[EC_MSG_TX_HEADER_BYTES + msg-outsize] = (uint8_t)(csum 0xff);
-
- return EC_MSG_TX_PROTO_BYTES + msg-outsize;
-}
-EXPORT_SYMBOL(cros_ec_prepare_tx);
-
-int cros_ec_check_result(struct cros_ec_device *ec_dev,
-struct cros_ec_command *msg)
-{
- switch (msg-result) {
- case EC_RES_SUCCESS:
- return 0;
- case EC_RES_IN_PROGRESS:
- dev_dbg(ec_dev-dev, command 0x%02x in progress\n,
- msg-command);
- return -EAGAIN;
- default:
- dev_dbg(ec_dev-dev, command 0x%02x returned %d\n,
-
Re: [PATCH v5 7/9] mfd: cros_ec: Support multiple EC in a system
On Wed, 03 Jun 2015, Javier Martinez Canillas wrote:
From: Gwendal Grignou gwen...@chromium.org
Chromebooks can have more than one Embedded Controller so the
cros_ec device id has to be incremented for each EC registered.
Add a new structure to represent multiple EC as different char
devices (e.g: /dev/cros_ec, /dev/cros_pd). It connects to
cros_ec_device and allows sysfs inferface for cros_pd.
Also reduce number of allocated objects, make chromeos sysfs
class object a static and add refcounting to prevent object
deletion while command is in progress.
Signed-off-by: Gwendal Grignou gwen...@chromium.org
Reviewed-by: Dmitry Torokhov d...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Heiko Stuebner he...@sntech.de
---
Changes since v4:
- Use cros-ec-name DT property instead of devname. Suggested by Lee Jones.
- Pass PLATFORM_DEVID_AUTO directly to mfd_add_devices().
Suggested by Lee Jones.
- Add Heiko Stuebner tested-by tag.
- Fix get_version by passing the cmd_offset to EC_CMD_GET_VERSION.
Changes since v3:
- Add defines for the EC and PD index constants.
- Remove cros_ec_dev_register() and declare the mfd_cells as static structs.
Suggested by Lee Jones.
Changes since v2: None
Changes since v1:
- Squash patch that adds support to represent EC's as different
char devices (e.g: /dev/cros_ec, /dev/cros_pd):
https://chromium-review.googlesource.com/#/c/217297/
Suggested by Gwendal Grignou
- Use cros_ec instead of cros-ec in the subject line to be consistent.
Suggested by Gwendal Grignou
---
drivers/input/keyboard/cros_ec_keyb.c | 2 +-
drivers/mfd/cros_ec.c | 57 +++--
drivers/mfd/cros_ec_i2c.c | 1 -
drivers/mfd/cros_ec_spi.c | 1 -
drivers/platform/chrome/cros_ec_dev.c | 130
-
drivers/platform/chrome/cros_ec_dev.h | 7 --
drivers/platform/chrome/cros_ec_lightbar.c | 75 +
drivers/platform/chrome/cros_ec_lpc.c | 1 -
drivers/platform/chrome/cros_ec_sysfs.c| 48 +--
include/linux/mfd/cros_ec.h| 44 --
10 files changed, 239 insertions(+), 127 deletions(-)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 974154a74505..b01966dc7eb3 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -275,7 +275,7 @@ static int cros_ec_keyb_probe(struct platform_device
*pdev)
ckdev-dev = dev;
dev_set_drvdata(pdev-dev, ckdev);
- idev-name = ec-ec_name;
+ idev-name = CROS_EC_DEV_NAME;
idev-phys = ec-phys_name;
__set_bit(EV_REP, idev-evbit);
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 08d82bfc5268..6935f385992e 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -24,11 +24,27 @@
#include linux/mfd/core.h
#include linux/mfd/cros_ec.h
-static const struct mfd_cell cros_devs[] = {
- {
- .name = cros-ec-ctl,
- .id = PLATFORM_DEVID_AUTO,
- },
+#define CROS_EC_DEV_EC_INDEX 0
+#define CROS_EC_DEV_PD_INDEX 1
+
+struct cros_ec_platform ec_p = {
+ .cmd_offset = EC_CMD_PASSTHRU_OFFSET(CROS_EC_DEV_EC_INDEX),
+};
+
+struct cros_ec_platform pd_p = {
+ .cmd_offset = EC_CMD_PASSTHRU_OFFSET(CROS_EC_DEV_PD_INDEX),
+};
+
+struct mfd_cell ec_cell = {
+ .name = cros-ec-ctl,
+ .platform_data = ec_p,
+ .pdata_size = sizeof(ec_p),
+};
+
+struct mfd_cell ec_pd_cell = {
+ .name = cros-ec-ctl,
+ .platform_data = pd_p,
+ .pdata_size = sizeof(pd_p),
};
int cros_ec_register(struct cros_ec_device *ec_dev)
@@ -52,14 +68,39 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
cros_ec_query_all(ec_dev);
- err = mfd_add_devices(dev, 0, cros_devs,
- ARRAY_SIZE(cros_devs),
+ if (IS_ENABLED(CONFIG_OF) dev-of_node)
+ ec_p.ec_name = of_get_property(dev-of_node,
+google,cros-ec-name, NULL);
NACK
You either need to obtain this another way, or have a chat with the DT
Maintainers and explain why this platform is special enough to break
the normal conventions.
HINT: I different compatible string is normally more amenable, but
this will also require a DT ACK for me to take it through.
+ if (!ec_p.ec_name)
+ ec_p.ec_name = CROS_EC_DEV_NAME;
+
+ err = mfd_add_devices(ec_dev-dev, PLATFORM_DEVID_AUTO, ec_cell, 1,
NULL, ec_dev-irq, NULL);
if (err) {
- dev_err(dev, failed to add mfd devices\n);
+ dev_err(dev, failed to add ec\n);
Might be nice to expand 'ec' so your users have half a chance in
deciphering what just went wrong.
[...]
--
Lee Jones
Linaro STMicroelectronics Landing
[PATCH v5 7/9] mfd: cros_ec: Support multiple EC in a system
From: Gwendal Grignou gwen...@chromium.org
Chromebooks can have more than one Embedded Controller so the
cros_ec device id has to be incremented for each EC registered.
Add a new structure to represent multiple EC as different char
devices (e.g: /dev/cros_ec, /dev/cros_pd). It connects to
cros_ec_device and allows sysfs inferface for cros_pd.
Also reduce number of allocated objects, make chromeos sysfs
class object a static and add refcounting to prevent object
deletion while command is in progress.
Signed-off-by: Gwendal Grignou gwen...@chromium.org
Reviewed-by: Dmitry Torokhov d...@chromium.org
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Heiko Stuebner he...@sntech.de
---
Changes since v4:
- Use cros-ec-name DT property instead of devname. Suggested by Lee Jones.
- Pass PLATFORM_DEVID_AUTO directly to mfd_add_devices().
Suggested by Lee Jones.
- Add Heiko Stuebner tested-by tag.
- Fix get_version by passing the cmd_offset to EC_CMD_GET_VERSION.
Changes since v3:
- Add defines for the EC and PD index constants.
- Remove cros_ec_dev_register() and declare the mfd_cells as static structs.
Suggested by Lee Jones.
Changes since v2: None
Changes since v1:
- Squash patch that adds support to represent EC's as different
char devices (e.g: /dev/cros_ec, /dev/cros_pd):
https://chromium-review.googlesource.com/#/c/217297/
Suggested by Gwendal Grignou
- Use cros_ec instead of cros-ec in the subject line to be consistent.
Suggested by Gwendal Grignou
---
drivers/input/keyboard/cros_ec_keyb.c | 2 +-
drivers/mfd/cros_ec.c | 57 +++--
drivers/mfd/cros_ec_i2c.c | 1 -
drivers/mfd/cros_ec_spi.c | 1 -
drivers/platform/chrome/cros_ec_dev.c | 130 -
drivers/platform/chrome/cros_ec_dev.h | 7 --
drivers/platform/chrome/cros_ec_lightbar.c | 75 +
drivers/platform/chrome/cros_ec_lpc.c | 1 -
drivers/platform/chrome/cros_ec_sysfs.c| 48 +--
include/linux/mfd/cros_ec.h| 44 --
10 files changed, 239 insertions(+), 127 deletions(-)
diff --git a/drivers/input/keyboard/cros_ec_keyb.c
b/drivers/input/keyboard/cros_ec_keyb.c
index 974154a74505..b01966dc7eb3 100644
--- a/drivers/input/keyboard/cros_ec_keyb.c
+++ b/drivers/input/keyboard/cros_ec_keyb.c
@@ -275,7 +275,7 @@ static int cros_ec_keyb_probe(struct platform_device *pdev)
ckdev-dev = dev;
dev_set_drvdata(pdev-dev, ckdev);
- idev-name = ec-ec_name;
+ idev-name = CROS_EC_DEV_NAME;
idev-phys = ec-phys_name;
__set_bit(EV_REP, idev-evbit);
diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 08d82bfc5268..6935f385992e 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -24,11 +24,27 @@
#include linux/mfd/core.h
#include linux/mfd/cros_ec.h
-static const struct mfd_cell cros_devs[] = {
- {
- .name = cros-ec-ctl,
- .id = PLATFORM_DEVID_AUTO,
- },
+#define CROS_EC_DEV_EC_INDEX 0
+#define CROS_EC_DEV_PD_INDEX 1
+
+struct cros_ec_platform ec_p = {
+ .cmd_offset = EC_CMD_PASSTHRU_OFFSET(CROS_EC_DEV_EC_INDEX),
+};
+
+struct cros_ec_platform pd_p = {
+ .cmd_offset = EC_CMD_PASSTHRU_OFFSET(CROS_EC_DEV_PD_INDEX),
+};
+
+struct mfd_cell ec_cell = {
+ .name = cros-ec-ctl,
+ .platform_data = ec_p,
+ .pdata_size = sizeof(ec_p),
+};
+
+struct mfd_cell ec_pd_cell = {
+ .name = cros-ec-ctl,
+ .platform_data = pd_p,
+ .pdata_size = sizeof(pd_p),
};
int cros_ec_register(struct cros_ec_device *ec_dev)
@@ -52,14 +68,39 @@ int cros_ec_register(struct cros_ec_device *ec_dev)
cros_ec_query_all(ec_dev);
- err = mfd_add_devices(dev, 0, cros_devs,
- ARRAY_SIZE(cros_devs),
+ if (IS_ENABLED(CONFIG_OF) dev-of_node)
+ ec_p.ec_name = of_get_property(dev-of_node,
+ google,cros-ec-name, NULL);
+
+ if (!ec_p.ec_name)
+ ec_p.ec_name = CROS_EC_DEV_NAME;
+
+ err = mfd_add_devices(ec_dev-dev, PLATFORM_DEVID_AUTO, ec_cell, 1,
NULL, ec_dev-irq, NULL);
if (err) {
- dev_err(dev, failed to add mfd devices\n);
+ dev_err(dev, failed to add ec\n);
return err;
}
+ if (ec_dev-max_passthru) {
+ /*
+* Register a PD device as well on top of this device.
+* We make the following assumptions:
+* - behind an EC, we have a pd
+* - only one device added.
+* - the EC is responsive at init time (it is not true for a
+* sensor hub.
+*/
+ pd_p.ec_name = CROS_EC_DEV_PD_NAME;
+
+ err = mfd_add_devices(ec_dev-dev, PLATFORM_DEVID_AUTO,
+
[PATCH v5 9/9] mfd: cros_ec: spi: Add delay for asserting CS
From: Alexandru M Stan ams...@chromium.org
Some ECs need a little time for waking up before they can accept
SPI data at a high speed. This is configurable via a DT property
google,cros-ec-spi-pre-delay.
Use this DT property to cause a delay before the beginning of a
SPI transaction to make sure that the EC has already woken up.
Signed-off-by: Alexandru M Stan ams...@chromium.org
Reviewed-by: Doug Anderson diand...@chromium.org
Signed-off-by: Chris Zhong z...@rock-chips.com
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Heiko Stuebner he...@sntech.de
Acked-by: Lee Jones lee.jo...@linaro.org
---
Changes since v4: None.
Changes since v3:
- New patch, split DT binding and driver implementation as suggested
by Lee Jones.
- Add tested-by tag from Heiko Stuebner.
- Add acked-by tag from Lee Jones.
---
drivers/mfd/cros_ec_spi.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
index faba03e2f1ef..16f228dc243f 100644
--- a/drivers/mfd/cros_ec_spi.c
+++ b/drivers/mfd/cros_ec_spi.c
@@ -71,12 +71,15 @@
* @spi: SPI device we are connected to
* @last_transfer_ns: time that we last finished a transfer, or 0 if there
* if no record
+ * @start_of_msg_delay: used to set the delay_usecs on the spi_transfer that
+ * is sent when we want to turn on CS at the start of a transaction.
* @end_of_msg_delay: used to set the delay_usecs on the spi_transfer that
* is sent when we want to turn off CS at the end of a transaction.
*/
struct cros_ec_spi {
struct spi_device *spi;
s64 last_transfer_ns;
+ unsigned int start_of_msg_delay;
unsigned int end_of_msg_delay;
};
@@ -366,7 +369,7 @@ static int cros_ec_pkt_xfer_spi(struct cros_ec_device
*ec_dev,
struct ec_host_request *request;
struct ec_host_response *response;
struct cros_ec_spi *ec_spi = ec_dev-priv;
- struct spi_transfer trans;
+ struct spi_transfer trans, trans_delay;
struct spi_message msg;
int i, len;
u8 *ptr;
@@ -393,13 +396,23 @@ static int cros_ec_pkt_xfer_spi(struct cros_ec_device
*ec_dev,
goto exit;
}
+ /*
+* Leave a gap between CS assertion and clocking of data to allow the
+* EC time to wakeup.
+*/
+ spi_message_init(msg);
+ if (ec_spi-start_of_msg_delay) {
+ memset(trans_delay, 0, sizeof(trans_delay));
+ trans_delay.delay_usecs = ec_spi-start_of_msg_delay;
+ spi_message_add_tail(trans_delay, msg);
+ }
+
/* Transmit phase - send our message */
memset(trans, 0, sizeof(trans));
trans.tx_buf = ec_dev-dout;
trans.rx_buf = rx_buf;
trans.len = len;
trans.cs_change = 1;
- spi_message_init(msg);
spi_message_add_tail(trans, msg);
ret = spi_sync(ec_spi-spi, msg);
@@ -602,6 +615,10 @@ static void cros_ec_spi_dt_probe(struct cros_ec_spi
*ec_spi, struct device *dev)
u32 val;
int ret;
+ ret = of_property_read_u32(np, google,cros-ec-spi-pre-delay, val);
+ if (!ret)
+ ec_spi-start_of_msg_delay = val;
+
ret = of_property_read_u32(np, google,cros-ec-spi-msg-delay, val);
if (!ret)
ec_spi-end_of_msg_delay = val;
--
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
[PATCH v5 0/9] mfd: cros_ec: Add multi EC and proto v3 support
Hello, Newer Chromebooks have more than one Embedded Controller (EC) in the system. These additional ECs are connected through I2C with a host EC which is the one that is connected to the Application Processor (AP) through different transports (I2C, SPI or LPC). So on these platforms, sub-processors are chained to each other: AP -- Host EC -- Power Delivery (PD) EC The AP sends commands to the additional EC through the host EC using a set of passthru commands and the host redirects to the correct EC. This is a v5 of a series that adds support for multiple EC in a system and also for the protocol version 3 that is used on newer ECs. Most patches were taken from the downstream ChromiumOS v3.14 tree with fixes squashed, split to minimise the cross subsystem churn and changes for mainline inclusion but were not modified functionality wise. This version addresses a lot of issues pointed out by Lee Jones on the v4 posted before [0]. The patches are based on top of [PATCH 0/2] mfd: cros_ec: Small cleanups [1] that were posted before and was already picked by Lee Jones. Testing was done on some Chromebooks that have a single EC and support protocol v2 such as the Exynos5250 Snow, Exynos5420 Peach Pit and Exynos5800 Peach Pi to be sure that no regressions were introduced for these machines. The series were tested using a modified ectool [2] that supports the new cros_ec IOCTL API. They were also tested on a x86 Pixel Chromebook 2 (Samus) that uses the new protocol v3 and has 2 EC (cros_ec and cros_pd). But for testing on Samus, also the posted [PATCH 0/3] platform/chrome: Changes for cros_ec_lpc and cros_ec_dev series [3] are needed. The series is composed of the following patches: Alexandru M Stan (2): mfd: cros_ec: spi: Add a DT property to delay asserting the CS mfd: cros_ec: spi: Add delay for asserting CS Gwendal Grignou (2): mfd: cros_ec: Add DT property to define ChromeOS EC name mfd: cros_ec: Support multiple EC in a system Javier Martinez Canillas (2): mfd: cros_ec: Use a zero-length array for command data mfd: cros_ec: Move protocol helpers out of the MFD driver Stephen Barber (3): mfd: cros_ec: rev cros_ec_commands.h mfd: cros_ec: add proto v3 skeleton mfd: cros_ec: add bus-specific proto v3 code Documentation/devicetree/bindings/mfd/cros-ec.txt | 9 + drivers/i2c/busses/Kconfig| 2 +- drivers/i2c/busses/i2c-cros-ec-tunnel.c | 45 ++- drivers/input/keyboard/Kconfig| 2 +- drivers/input/keyboard/cros_ec_keyb.c | 31 +- drivers/mfd/Kconfig | 6 +- drivers/mfd/cros_ec.c | 156 +++-- drivers/mfd/cros_ec_i2c.c | 169 - drivers/mfd/cros_ec_spi.c | 407 +++--- drivers/platform/chrome/Kconfig | 9 +- drivers/platform/chrome/Makefile | 1 + drivers/platform/chrome/cros_ec_dev.c | 189 ++ drivers/platform/chrome/cros_ec_dev.h | 7 - drivers/platform/chrome/cros_ec_lightbar.c| 217 +++- drivers/platform/chrome/cros_ec_lpc.c | 84 - drivers/platform/chrome/cros_ec_proto.c | 382 drivers/platform/chrome/cros_ec_sysfs.c | 178 ++ include/linux/mfd/cros_ec.h | 84 - include/linux/mfd/cros_ec_commands.h | 277 +-- 19 files changed, 1806 insertions(+), 449 deletions(-) create mode 100644 drivers/platform/chrome/cros_ec_proto.c Patch #1 modifies the struct cros_ec_command to use a zero-length array for the buffer used for EC input and output data. Patch #2 synchronises the cros_ec_commands.h with a newer version of the file in the EC firmware repository. Patch #3 moves the EC communication protocol helper functions out of the MFD driver. Patch #4 adds the EC host command protocol v3 support to the cros_ec driver and patch #5 adds the bus specific proto v3 support for I2C, SPI and LPC. Patch #6 adds a DT property to specify the ChromeOS EC name according to its function. Patch #7 adds support to make multiple EC have a different device id and also exposing a per EC character device interface. Patch #8 adds a DT property to the cros_ec DT binding to specify a delay before receiving SPI transfers to make sure that the EC has already waked up and patch #9 implements it in the cros_ec_spi driver. Since the changes are quite intrusive and affects all ChromeOS EC related drivers, the patches should be merged through the MFD subsystem tree with the ack of the drivers/platform/chrome maintainer. Best regards, Javier [0]: https://lkml.org/lkml/2015/6/2/111 [1]: https://lkml.org/lkml/2015/5/20/235 [2]: http://cgit.collabora.com/git/user/javier/ec.git/log/?h=mainline-ioctl-zero-length [3]: https://lkml.org/lkml/2015/5/20/184 -- To unsubscribe from this list: send the line
Re: [PATCH] drm/exynos: add a dependency on FB_S3C to DECON driver
Hi Inki, 2015-06-03 Inki Dae inki@samsung.com: This patch makes one of Linux framebuffer and DRM CRTC drivers to be enabled. Display controllers, FIMD and DECON, can be controlled by Linux framebuffer or DRM CRTC drivers so only one of them should be enabled. Signed-off-by: Inki Dae inki@samsung.com --- drivers/gpu/drm/exynos/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Gustavo Padovan gustavo.pado...@collabora.co.uk 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
Re: [PATCH] drm/exynos: vidi: remove unused varables
Hi Inki, 2015-06-03 Inki Dae inki@samsung.com: This patch removes unnsed varables in vidi_disable function. Signed-off-by: Inki Dae inki@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_vidi.c |2 -- 1 file changed, 2 deletions(-) Reviewed-by: Gustavo Padovan gustavo.pado...@collabora.co.uk 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 v5 8/9] mfd: cros_ec: spi: Add a DT property to delay asserting the CS
From: Alexandru M Stan ams...@chromium.org Some ECs need a little time for waking up before they can accept SPI data at a high speed. Add a google,cros-ec-spi-pre-delay property to the DT binding to configure this. If this property isn't set, then no delay will be added. However, if set it will cause a delay equal to the value passed to it to be inserted at the beginning of a transaction. Signed-off-by: Alexandru M Stan ams...@chromium.org Reviewed-by: Doug Anderson diand...@chromium.org Signed-off-by: Chris Zhong z...@rock-chips.com Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Tested-by: Heiko Stuebner he...@sntech.de Acked-by: Lee Jones lee.jo...@linaro.org --- Changes since v4: None. Changes since v3: - Split DT binding and driver change as suggested by Lee Jones. - Add tested-by tag from Heiko Stuebner - Add acked-by tag from Lee Jones. Changes since v2: None Changes since v1: None, new patch --- Documentation/devicetree/bindings/mfd/cros-ec.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt b/Documentation/devicetree/bindings/mfd/cros-ec.txt index dcf404d16067..e03a61c54954 100644 --- a/Documentation/devicetree/bindings/mfd/cros-ec.txt +++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt @@ -18,6 +18,10 @@ Required properties (SPI): - reg: SPI chip select Optional properties (SPI): +- google,cros-ec-spi-pre-delay: Some implementations of the EC need a little + time to wake up from sleep before they can receive SPI transfers at a high + clock rate. This property specifies the delay, in usecs, between the + assertion of the CS to the start of the first clock pulse. - google,cros-ec-spi-msg-delay: Some implementations of the EC require some additional processing time in order to accept new transactions. If the delay between transactions is not long enough the EC may not be able to respond -- 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: [PATCH v10 17/17] drm/exynos: split exynos_crtc-dpms in enable() and disable()
Hi Inki,
2015-06-03 Inki Dae inki@samsung.com:
Hi,
On 2015년 06월 02일 00:04, Gustavo Padovan wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
To follow more closely the new atomic API we split the dpms()
helper into the enable() and disable() helper to get exactly the
same semantics.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 87
++
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 8 +--
drivers/gpu/drm/exynos/exynos_drm_drv.h| 6 ++-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 69 +---
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 53 +++---
drivers/gpu/drm/exynos/exynos_mixer.c | 26 +++--
6 files changed, 62 insertions(+), 187 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index f29e4be..d659ba2 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -603,75 +603,39 @@ static void decon_init(struct decon_context *ctx)
writel(VIDCON1_VCLK_HOLD, ctx-regs + VIDCON1(0));
}
-static int decon_poweron(struct decon_context *ctx)
+static void decon_enable(struct exynos_drm_crtc *crtc)
{
- int ret;
+ struct decon_context *ctx = crtc-ctx;
if (!ctx-suspended)
- return 0;
+ return;
ctx-suspended = false;
pm_runtime_get_sync(ctx-dev);
- ret = clk_prepare_enable(ctx-pclk);
- if (ret 0) {
- DRM_ERROR(Failed to prepare_enable the pclk [%d]\n, ret);
- goto pclk_err;
- }
-
- ret = clk_prepare_enable(ctx-aclk);
- if (ret 0) {
- DRM_ERROR(Failed to prepare_enable the aclk [%d]\n, ret);
- goto aclk_err;
- }
-
- ret = clk_prepare_enable(ctx-eclk);
- if (ret 0) {
- DRM_ERROR(Failed to prepare_enable the eclk [%d]\n, ret);
- goto eclk_err;
- }
-
- ret = clk_prepare_enable(ctx-vclk);
- if (ret 0) {
- DRM_ERROR(Failed to prepare_enable the vclk [%d]\n, ret);
- goto vclk_err;
- }
+ clk_prepare_enable(ctx-pclk);
+ clk_prepare_enable(ctx-aclk);
+ clk_prepare_enable(ctx-eclk);
+ clk_prepare_enable(ctx-vclk);
Merged this patch series to exynos-drm-next. However, this patch
especially above codes is required for more clean-up. Even though
decon_enable function never return error number, I think its internal
codes should be considered for some exception cases to check where an
error occurred at. So could you post the clean-up patch?
Thanks for merging the patches! I will send follow-up patches shortly to
add checks and errors messages back.
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 v5 6/9] mfd: cros_ec: Add DT property to define ChromeOS EC name
From: Gwendal Grignou gwen...@chromium.org Chromebooks can have more than one Embedded Controller with different functinality. For example there may be a EC that handles Power Delivery (PD) or another one that is a Sensor Hub (SH). So there should be a way to specify the function so that is reflected in the character device name and the sysfs entries. Add a google,cros-ec-name DT property to the ChromeOS EC binding document to change the EC name based on its function. Signed-off-by: Gwendal Grignou gwen...@chromium.org Reviewed-by: Doug Anderson diand...@chromium.org Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v4: None, new patch --- Documentation/devicetree/bindings/mfd/cros-ec.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt b/Documentation/devicetree/bindings/mfd/cros-ec.txt index 8009c3d87f33..dcf404d16067 100644 --- a/Documentation/devicetree/bindings/mfd/cros-ec.txt +++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt @@ -30,6 +30,11 @@ Required properties (LPC): - compatible: google,cros-ec-lpc - reg: List of (IO address, size) pairs defining the interface uses +Optional properties (All): +- google,cros-ec-name: name of the EC. Can be based on its function: for + instance, for Sensor Hub, 'cros_sh', for Power Delivery MCU 'cros_pd'. + If is not present, a default name will be set (i.e: 'cros_ec'). + Example for I2C: -- 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
[GIT PULL] clk/samsung updates for 4.2
The following changes since commit 20db7092e478c33a2bf5254063c51f5db6443959: Merge branch 'clk-next-hi6220' into clk-next (2015-05-27 22:06:42 -0700) are available in the git repository at: git://linuxtv.org/snawrocki/samsung.git tags/clk-samsung-for-4.2 for you to fetch changes up to e5c6fc4f271a27d5b236b5f4929bf0f2dab80a7d: clk: exynos5433: Add CLK_IGNORE_UNUSED flag to clocks for SMC (2015-06-02 14:52:12 +0200) Updates of the exynos5433 clock definitions for proper support of SMC, DVFS of GPU and CPU big.LITTLE cores and a fix for system suspend adding one of the clock controller's registers to save/restore list. Chanwoo Choi (1): clk: exynos5433: Add CLK_SET_RATE_PARENT to support DVFS for big.LITTLE core Hyungwon Hwang (1): clk: exynos5433: Add DIV_CPIF to the list of stored registers on suspend Jonghwa Lee (1): clk: exynos5433: Add CLK_IGNORE_UNUSED flag to clocks for SMC Joonyoung Shim (1): clk: exynos5433: Add clock flag to support the DVFS of GPU drivers/clk/samsung/clk-exynos5433.c | 81 +- 1 file changed, 40 insertions(+), 41 deletions(-) -- 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: [PATCH 1/9] drm/exynos: add error messages if clks failed to get enabled
Hi Gustavo,
On Wed, Jun 3, 2015 at 5:30 PM, Gustavo Padovan gust...@padovan.org wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Check error and call DRM_ERROR if clk_prepare_enable() fails.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 29
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 --
drivers/gpu/drm/exynos/exynos_mixer.c | 31
+-
3 files changed, 63 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index d659ba2..ffd7c3b 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -606,6 +606,7 @@ static void decon_init(struct decon_context *ctx)
static void decon_enable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc-ctx;
+ int ret;
if (!ctx-suspended)
return;
@@ -614,10 +615,30 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
pm_runtime_get_sync(ctx-dev);
- clk_prepare_enable(ctx-pclk);
- clk_prepare_enable(ctx-aclk);
- clk_prepare_enable(ctx-eclk);
- clk_prepare_enable(ctx-vclk);
+ ret = clk_prepare_enable(ctx-pclk);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the pclk [%d]\n, ret);
+ return;
+ goto pclk_err;
This goto after return probably got here by mistake. Debug/rebase leftover?
..snip..
By the way, are you using some branch to prepare this patch?
Could you please check if you're able to apple it?
In current master branch that i see similar DRM_ERROR() messages are
already in place in similar functions. For example, in master branch i
see decon_poweron() instead of decon_enable() and fimd_poweron()
instead of fimd_enable() in your patch. Is there any chance that it's
slightly outdated?
Best regards,
Alexey Klimov
--
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/9] drm/exynos: add error messages if clks failed to get enabled
On Wed, Jun 3, 2015 at 7:59 PM, Alexey Klimov klimov.li...@gmail.com wrote:
Hi Gustavo,
On Wed, Jun 3, 2015 at 5:30 PM, Gustavo Padovan gust...@padovan.org wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Check error and call DRM_ERROR if clk_prepare_enable() fails.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 29
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 --
drivers/gpu/drm/exynos/exynos_mixer.c | 31
+-
3 files changed, 63 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index d659ba2..ffd7c3b 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -606,6 +606,7 @@ static void decon_init(struct decon_context *ctx)
static void decon_enable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc-ctx;
+ int ret;
if (!ctx-suspended)
return;
@@ -614,10 +615,30 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
pm_runtime_get_sync(ctx-dev);
- clk_prepare_enable(ctx-pclk);
- clk_prepare_enable(ctx-aclk);
- clk_prepare_enable(ctx-eclk);
- clk_prepare_enable(ctx-vclk);
+ ret = clk_prepare_enable(ctx-pclk);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the pclk [%d]\n, ret);
+ return;
+ goto pclk_err;
This goto after return probably got here by mistake. Debug/rebase leftover?
..snip..
By the way, are you using some branch to prepare this patch?
Could you please check if you're able to apple it?
In current master branch that i see similar DRM_ERROR() messages are
already in place in similar functions. For example, in master branch i
see decon_poweron() instead of decon_enable() and fimd_poweron()
instead of fimd_enable() in your patch. Is there any chance that it's
slightly outdated?
Ah, now i see. It depends on [PATCH v10 17/17] drm/exynos: split
exynos_crtc-dpms in enable() and disable() and partially reverts it
and restores messages back.
--
Best regards,
Alexey Klimov
--
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
[RFT v2 06/48] pinctrl: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc
Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we
already have a pointer to corresponding irq_desc.
Signed-off-by: Jiang Liu jiang@linux.intel.com
Acked-by: Linus Walleij linus.wall...@linaro.org
---
drivers/pinctrl/intel/pinctrl-cherryview.c|2 +-
drivers/pinctrl/intel/pinctrl-intel.c |2 +-
drivers/pinctrl/mediatek/pinctrl-mtk-common.c |4 ++--
drivers/pinctrl/nomadik/pinctrl-nomadik.c | 12 +---
drivers/pinctrl/pinctrl-amd.c |2 +-
drivers/pinctrl/pinctrl-at91.c|2 +-
drivers/pinctrl/pinctrl-coh901.c |4 ++--
drivers/pinctrl/pinctrl-rockchip.c|4 ++--
drivers/pinctrl/pinctrl-single.c |2 +-
drivers/pinctrl/pinctrl-st.c |6 +++---
drivers/pinctrl/qcom/pinctrl-msm.c|2 +-
drivers/pinctrl/samsung/pinctrl-exynos.c |8
drivers/pinctrl/samsung/pinctrl-s3c24xx.c | 18 +-
drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 22 ++
drivers/pinctrl/sirf/pinctrl-sirf.c |2 +-
drivers/pinctrl/sunxi/pinctrl-sunxi.c |4 ++--
16 files changed, 46 insertions(+), 50 deletions(-)
diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c
b/drivers/pinctrl/intel/pinctrl-cherryview.c
index 82f691c4..878e798bcb56 100644
--- a/drivers/pinctrl/intel/pinctrl-cherryview.c
+++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
@@ -1368,7 +1368,7 @@ static void chv_gpio_irq_handler(unsigned irq, struct
irq_desc *desc)
{
struct gpio_chip *gc = irq_desc_get_handler_data(desc);
struct chv_pinctrl *pctrl = gpiochip_to_pinctrl(gc);
- struct irq_chip *chip = irq_get_chip(irq);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
unsigned long pending;
u32 intr_line;
diff --git a/drivers/pinctrl/intel/pinctrl-intel.c
b/drivers/pinctrl/intel/pinctrl-intel.c
index 00768e53deec..a40681097402 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -840,7 +840,7 @@ static void intel_gpio_irq_handler(unsigned irq, struct
irq_desc *desc)
{
struct gpio_chip *gc = irq_desc_get_handler_data(desc);
struct intel_pinctrl *pctrl = gpiochip_to_pinctrl(gc);
- struct irq_chip *chip = irq_get_chip(irq);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
int i;
chained_irq_enter(chip, desc);
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index 474812e2b0cb..fd05ca6125b0 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -1018,8 +1018,8 @@ mtk_eint_debounce_process(struct mtk_pinctrl *pctl, int
index)
static void mtk_eint_irq_handler(unsigned irq, struct irq_desc *desc)
{
- struct irq_chip *chip = irq_get_chip(irq);
- struct mtk_pinctrl *pctl = irq_get_handler_data(irq);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct mtk_pinctrl *pctl = irq_desc_get_handler_data(desc);
unsigned int status, eint_num;
int offset, index, virq;
const struct mtk_eint_offsets *eint_offsets =
diff --git a/drivers/pinctrl/nomadik/pinctrl-nomadik.c
b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
index a6a22054c0ba..902f53b855bf 100644
--- a/drivers/pinctrl/nomadik/pinctrl-nomadik.c
+++ b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
@@ -854,10 +854,9 @@ static struct irq_chip nmk_gpio_irq_chip = {
.flags = IRQCHIP_MASK_ON_SUSPEND,
};
-static void __nmk_gpio_irq_handler(unsigned int irq, struct irq_desc *desc,
- u32 status)
+static void __nmk_gpio_irq_handler(struct irq_desc *desc, u32 status)
{
- struct irq_chip *host_chip = irq_get_chip(irq);
+ struct irq_chip *host_chip = irq_desc_get_chip(desc);
struct gpio_chip *chip = irq_desc_get_handler_data(desc);
chained_irq_enter(host_chip, desc);
@@ -882,17 +881,16 @@ static void nmk_gpio_irq_handler(unsigned int irq, struct
irq_desc *desc)
status = readl(nmk_chip-addr + NMK_GPIO_IS);
clk_disable(nmk_chip-clk);
- __nmk_gpio_irq_handler(irq, desc, status);
+ __nmk_gpio_irq_handler(desc, status);
}
-static void nmk_gpio_latent_irq_handler(unsigned int irq,
- struct irq_desc *desc)
+static void nmk_gpio_latent_irq_handler(unsigned int irq, struct irq_desc
*desc)
{
struct gpio_chip *chip = irq_desc_get_handler_data(desc);
struct nmk_gpio_chip *nmk_chip = container_of(chip, struct
nmk_gpio_chip, chip);
u32 status = nmk_chip-get_latent_status(nmk_chip-bank);
- __nmk_gpio_irq_handler(irq, desc, status);
+ __nmk_gpio_irq_handler(desc, status);
}
/* I/O Functions */
diff --git a/drivers/pinctrl/pinctrl-amd.c b/drivers/pinctrl/pinctrl-amd.c
index
[RFT v2 10/48] irqchip: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc
Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we
already have a pointer to corresponding irq_desc.
Signed-off-by: Jiang Liu jiang@linux.intel.com
---
drivers/irqchip/exynos-combiner.c |4 ++--
drivers/irqchip/irq-armada-370-xp.c |2 +-
drivers/irqchip/irq-dw-apb-ictl.c |4 ++--
drivers/irqchip/irq-gic.c |4 ++--
drivers/irqchip/irq-orion.c |2 +-
drivers/irqchip/irq-sunxi-nmi.c |2 +-
drivers/irqchip/spear-shirq.c |2 +-
7 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/irqchip/exynos-combiner.c
b/drivers/irqchip/exynos-combiner.c
index 5945223b73fa..039ceb46fcc0 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -62,8 +62,8 @@ static void combiner_unmask_irq(struct irq_data *data)
static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc
*desc)
{
- struct combiner_chip_data *chip_data = irq_get_handler_data(irq);
- struct irq_chip *chip = irq_get_chip(irq);
+ struct combiner_chip_data *chip_data = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
unsigned int cascade_irq, combiner_irq;
unsigned long status;
diff --git a/drivers/irqchip/irq-armada-370-xp.c
b/drivers/irqchip/irq-armada-370-xp.c
index daccc8bdbb42..40b5fe99a1d5 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -451,7 +451,7 @@ static void armada_370_xp_handle_msi_irq(struct pt_regs *r,
bool b) {}
static void armada_370_xp_mpic_handle_cascade_irq(unsigned int irq,
struct irq_desc *desc)
{
- struct irq_chip *chip = irq_get_chip(irq);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
unsigned long irqmap, irqn, irqsrc, cpuid;
unsigned int cascade_irq;
diff --git a/drivers/irqchip/irq-dw-apb-ictl.c
b/drivers/irqchip/irq-dw-apb-ictl.c
index 53bb7326a60a..cddcd3b75f00 100644
--- a/drivers/irqchip/irq-dw-apb-ictl.c
+++ b/drivers/irqchip/irq-dw-apb-ictl.c
@@ -28,8 +28,8 @@
static void dw_apb_ictl_handler(unsigned int irq, struct irq_desc *desc)
{
- struct irq_chip *chip = irq_get_chip(irq);
- struct irq_chip_generic *gc = irq_get_handler_data(irq);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct irq_chip_generic *gc = irq_desc_get_handler_data(desc);
struct irq_domain *d = gc-private;
u32 stat;
int n;
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 01999d74bd3a..6c8a5a7fb4a0 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -288,8 +288,8 @@ static void __exception_irq_entry gic_handle_irq(struct
pt_regs *regs)
static void gic_handle_cascade_irq(unsigned int irq, struct irq_desc *desc)
{
- struct gic_chip_data *chip_data = irq_get_handler_data(irq);
- struct irq_chip *chip = irq_get_chip(irq);
+ struct gic_chip_data *chip_data = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
unsigned int cascade_irq, gic_irq;
unsigned long status;
diff --git a/drivers/irqchip/irq-orion.c b/drivers/irqchip/irq-orion.c
index ad0c0f6f1d65..58e034db0e7c 100644
--- a/drivers/irqchip/irq-orion.c
+++ b/drivers/irqchip/irq-orion.c
@@ -109,7 +109,7 @@ IRQCHIP_DECLARE(orion_intc, marvell,orion-intc,
orion_irq_init);
static void orion_bridge_irq_handler(unsigned int irq, struct irq_desc *desc)
{
- struct irq_domain *d = irq_get_handler_data(irq);
+ struct irq_domain *d = irq_desc_get_handler_data(desc);
struct irq_chip_generic *gc = irq_get_domain_generic_chip(d, 0);
u32 stat = readl_relaxed(gc-reg_base + ORION_BRIDGE_IRQ_CAUSE)
diff --git a/drivers/irqchip/irq-sunxi-nmi.c b/drivers/irqchip/irq-sunxi-nmi.c
index 4a9ce5b50c5b..2eaa9d9df241 100644
--- a/drivers/irqchip/irq-sunxi-nmi.c
+++ b/drivers/irqchip/irq-sunxi-nmi.c
@@ -61,7 +61,7 @@ static inline u32 sunxi_sc_nmi_read(struct irq_chip_generic
*gc, u32 off)
static void sunxi_sc_nmi_handle_irq(unsigned int irq, struct irq_desc *desc)
{
struct irq_domain *domain = irq_desc_get_handler_data(desc);
- struct irq_chip *chip = irq_get_chip(irq);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
unsigned int virq = irq_find_mapping(domain, 0);
chained_irq_enter(chip, desc);
diff --git a/drivers/irqchip/spear-shirq.c b/drivers/irqchip/spear-shirq.c
index 9c145a7cb056..fb68ee9c0424 100644
--- a/drivers/irqchip/spear-shirq.c
+++ b/drivers/irqchip/spear-shirq.c
@@ -185,7 +185,7 @@ static struct spear_shirq *spear320_shirq_blocks[] = {
static void shirq_handler(unsigned irq, struct irq_desc *desc)
{
- struct spear_shirq *shirq = irq_get_handler_data(irq);
+ struct spear_shirq *shirq = irq_desc_get_handler_data(desc);
u32 pend;
pend = readl(shirq-base +
Re: [PATCH 04/11] mtd: ofpart: do not fail probe when no partitions exist
On 4 June 2015 at 00:58, Marek Vasut ma...@denx.de wrote:
On Wednesday, June 03, 2015 at 11:26:40 PM, Michal Suchanek wrote:
On Exynos it is necessary to set SPI controller parameters that apply to
a SPI slave in a DT subnode of the slave device. The ofpart code returns
an error when there are subnodes of the SPI flash but no partitions are
found. Change this condition to a warning so that flash without
partitions can be accessed on Exynos.
I have to admit the rationale for this patch is not very clear to me, sorry.
Can you please explain this a bit more ?
This is how the DT entry for SPI slave looks with s3c64xx:
flash: m25p80@0 {
#address-cells = 1;
#size-cells = 1;
compatible = jedec,spi-nor;
reg = 0;
spi-max-frequency = 4000;
linux,max_tx_len = 65536;
m25p,fast-read;
controller-data {
samsung,spi-feedback-delay = 0;
};
};
this is example of flash partitions:
flash@0 {
#address-cells = 1;
#size-cells = 1;
partition@0 {
label = u-boot;
reg = 0x000 0x10;
read-only;
};
uimage@10 {
reg = 0x010 0x20;
};
};
The parser ignores any flash without subnodes and returns 0 (no
partititon). When there is a subnode it assumes the flash is
partitioned and tries to parse the subnodes as partitions. When there
are subnodes and none parses as partition an error is returned. As
shown above it is valid to have subnodes on unpartitioned flash.
When an error is returned from a partition parser the mtdpart code
passes on this error to the flash probe function and the proble of the
flash fails.
Thanks
Michal
--
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 08/11] MTD: m25p80: Add option to limit SPI transfer size.
On 4 June 2015 at 01:03, Marek Vasut ma...@denx.de wrote: On Wednesday, June 03, 2015 at 11:26:41 PM, Michal Suchanek wrote: On sunxi the SPI controller currently does not have DMA support and fails any transfer larger than 63 bytes. On Exynos the pl330 DMA controller fails any transfer larger than 64kb when using slower speed like 40MHz and any transfer larger than 128bytes when running at 133MHz. This smells more like some corruption of the data on the bus or something even more obscure. If the data was corrupted you would get corrupted data and not transfer failure. AFAIK there is no checksum or anything. I actually do get corrupted data when I use wrong feedback delay setting. The best thing is that in both cases the controller can just lock up and never finish potentially leaving the hardware in unusable state. So it is required that the m25p80 driver actively prevents doing transfers that are too large for the current driver state on a particular piece of hardware. Signed-off-by: Michal Suchanek hramr...@gmail.com -- Update commit message and documentation text. --- .../devicetree/bindings/mtd/jedec,spi-nor.txt | 6 ++ drivers/mtd/devices/m25p80.c | 24 -- 2 files changed, 28 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt index 2bee681..4e63ae8 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt @@ -19,6 +19,12 @@ Optional properties: all chips and support for it can not be detected at runtime. Refer to your chips' datasheet to check if this is supported by your chip. +- linux,max_tx_len : With some SPI controller drivers possible transfer size is + limited. This may be hardware or driver bug. + Transfer data in chunks no larger than this value. + Using this option may severely degrade performance and + possibly flash memory life when max_tx_len is smaller than + flash page size (typically 256 bytes) Will we need similar patch for all other SPI slave drivers, like SPI NAND ? Probably. Some SPI slave drivers already do have similar option. In general it cannot be expected that you can reliably transfer arbitrarily large data over SPI it seems. However, if the nand driver transfers data a page at a time it should be fine. Thanks Michal -- 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: [RFT v2 10/48] irqchip: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc
On 04.06.2015 13:13, Jiang Liu wrote: Use irq_desc_get_xxx() to avoid redundant lookup of irq_desc while we already have a pointer to corresponding irq_desc. Signed-off-by: Jiang Liu jiang@linux.intel.com --- drivers/irqchip/exynos-combiner.c |4 ++-- For exynos: Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com 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 0/6] Exynos SYSMMU (IOMMU) dts and arch updates
On 04.06.2015 08:11, Kukjin Kim wrote: On 06/01/15 20:34, Krzysztof Kozlowski wrote: W dniu 01.06.2015 o 19:10, Marek Szyprowski pisze: Hello, Main changes for Exynos SYSMMU (IOMMU) driver has been finally scheduled for merging - see https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/commit/?h=next In meantime there have been quite a lot of changes related to Exynos DTS files queued for merging and my patches don't apply anymore. To ease merge process I've decided to rebased all Exynos SYSMMU dts changes onto latest exynos next tree from: https://github.com/krzk/linux dt-for-next While rebasing I've fixes a few spotted issues: some nodes still used old 'samsung,power-domain' properties (now replaced with 'power-domains') and added properties to jpeg codec merged recently. Thanks for rebasing this stuff. Same here ;-) I picked whole patchset with Javier's tested-by. I'll send it to Kukjin later or directly to arm-soc (depending what will happen with last pull request). Kukjin, you mentioned that you will do something with this patchset the previous weekend. Since then nothing happened so I am not sure what are your plans... Can you share them? Do you want to pick it by yourself, do you have any comments or maybe you need something from our side? (I checked the patches and they look fine) Done, thanks. Thank you, I tested the for-next branch on some of my boards and everything looked fine. 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
[RFT v2 46/48] genirq, irqchip: Kill the first parameter 'irq' of irq_flow_handler_t
Now most IRQ flow handlers make no use of the first parameter 'irq'.
And for those who do make use of 'irq', we could easily get the irq
number through irq_desc-irq_data-irq. So kill the first parameter
'irq' of irq_flow_handler_t.
To ease review, I have split the changes into several parts, though
they should be merge as one to support bisecting.
Signed-off-by: Jiang Liu jiang@linux.intel.com
Acked-by: Ralf Baechle r...@linux-mips.org
---
drivers/irqchip/exynos-combiner.c|4 ++--
drivers/irqchip/irq-armada-370-xp.c |3 +--
drivers/irqchip/irq-bcm7038-l1.c |2 +-
drivers/irqchip/irq-bcm7120-l2.c |2 +-
drivers/irqchip/irq-brcmstb-l2.c |4 ++--
drivers/irqchip/irq-dw-apb-ictl.c|2 +-
drivers/irqchip/irq-gic.c|2 +-
drivers/irqchip/irq-imgpdc.c |4 ++--
drivers/irqchip/irq-keystone.c |2 +-
drivers/irqchip/irq-metag-ext.c |3 +--
drivers/irqchip/irq-metag.c |3 +--
drivers/irqchip/irq-mips-gic.c |2 +-
drivers/irqchip/irq-mmp.c|2 +-
drivers/irqchip/irq-orion.c |2 +-
drivers/irqchip/irq-s3c24xx.c|2 +-
drivers/irqchip/irq-sunxi-nmi.c |2 +-
drivers/irqchip/irq-tb10x.c |2 +-
drivers/irqchip/irq-versatile-fpga.c |4 ++--
drivers/irqchip/irq-vic.c|2 +-
drivers/irqchip/spear-shirq.c|2 +-
20 files changed, 24 insertions(+), 27 deletions(-)
diff --git a/drivers/irqchip/exynos-combiner.c
b/drivers/irqchip/exynos-combiner.c
index 039ceb46fcc0..2bf152307bac 100644
--- a/drivers/irqchip/exynos-combiner.c
+++ b/drivers/irqchip/exynos-combiner.c
@@ -60,7 +60,7 @@ static void combiner_unmask_irq(struct irq_data *data)
__raw_writel(mask, combiner_base(data) + COMBINER_ENABLE_SET);
}
-static void combiner_handle_cascade_irq(unsigned int irq, struct irq_desc
*desc)
+static void combiner_handle_cascade_irq(struct irq_desc *desc)
{
struct combiner_chip_data *chip_data = irq_desc_get_handler_data(desc);
struct irq_chip *chip = irq_desc_get_chip(desc);
@@ -81,7 +81,7 @@ static void combiner_handle_cascade_irq(unsigned int irq,
struct irq_desc *desc)
cascade_irq = irq_find_mapping(combiner_irq_domain, combiner_irq);
if (unlikely(!cascade_irq))
- handle_bad_irq(irq, desc);
+ handle_bad_irq(desc);
else
generic_handle_irq(cascade_irq);
diff --git a/drivers/irqchip/irq-armada-370-xp.c
b/drivers/irqchip/irq-armada-370-xp.c
index 40b5fe99a1d5..fa26eb1b4f17 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -448,8 +448,7 @@ static void armada_370_xp_handle_msi_irq(struct pt_regs
*regs, bool is_chained)
static void armada_370_xp_handle_msi_irq(struct pt_regs *r, bool b) {}
#endif
-static void armada_370_xp_mpic_handle_cascade_irq(unsigned int irq,
- struct irq_desc *desc)
+static void armada_370_xp_mpic_handle_cascade_irq(struct irq_desc *desc)
{
struct irq_chip *chip = irq_desc_get_chip(desc);
unsigned long irqmap, irqn, irqsrc, cpuid;
diff --git a/drivers/irqchip/irq-bcm7038-l1.c b/drivers/irqchip/irq-bcm7038-l1.c
index d3b8c8be15f6..9ad6540bd57e 100644
--- a/drivers/irqchip/irq-bcm7038-l1.c
+++ b/drivers/irqchip/irq-bcm7038-l1.c
@@ -116,7 +116,7 @@ static inline void l1_writel(u32 val, void __iomem *reg)
writel(val, reg);
}
-static void bcm7038_l1_irq_handle(unsigned int irq, struct irq_desc *desc)
+static void bcm7038_l1_irq_handle(struct irq_desc *desc)
{
struct bcm7038_l1_chip *intc = irq_desc_get_handler_data(desc);
struct bcm7038_l1_cpu *cpu;
diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index 3ba5cc780fcb..4ee0d839009e 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -52,7 +52,7 @@ struct bcm7120_l2_intc_data {
const __be32 *map_mask_prop;
};
-static void bcm7120_l2_intc_irq_handle(unsigned int irq, struct irq_desc *desc)
+static void bcm7120_l2_intc_irq_handle(struct irq_desc *desc)
{
struct bcm7120_l2_intc_data *b = irq_desc_get_handler_data(desc);
struct irq_chip *chip = irq_desc_get_chip(desc);
diff --git a/drivers/irqchip/irq-brcmstb-l2.c b/drivers/irqchip/irq-brcmstb-l2.c
index 994c01fdb4b5..ab3d0c52ea5a 100644
--- a/drivers/irqchip/irq-brcmstb-l2.c
+++ b/drivers/irqchip/irq-brcmstb-l2.c
@@ -51,7 +51,7 @@ struct brcmstb_l2_intc_data {
u32 saved_mask; /* for suspend/resume */
};
-static void brcmstb_l2_intc_irq_handle(unsigned int __irq, struct irq_desc
*desc)
+static void brcmstb_l2_intc_irq_handle(struct irq_desc *desc)
{
struct brcmstb_l2_intc_data *b = irq_desc_get_handler_data(desc);
struct irq_chip_generic *gc = irq_get_domain_generic_chip(b-domain, 0);
@@ -65,7 +65,7 @@ static void brcmstb_l2_intc_irq_handle(unsigned int
[RFT v2 44/48] genirq, pinctrl: Kill the first parameter 'irq' of irq_flow_handler_t
Now most IRQ flow handlers make no use of the first parameter 'irq'.
And for those who do make use of 'irq', we could easily get the irq
number through irq_desc-irq_data-irq. So kill the first parameter
'irq' of irq_flow_handler_t.
To ease review, I have split the changes into several parts, though
they should be merge as one to support bisecting.
Signed-off-by: Jiang Liu jiang@linux.intel.com
---
drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c |2 +-
drivers/pinctrl/intel/pinctrl-baytrail.c |2 +-
drivers/pinctrl/intel/pinctrl-cherryview.c|2 +-
drivers/pinctrl/intel/pinctrl-intel.c |2 +-
drivers/pinctrl/mediatek/pinctrl-mtk-common.c |2 +-
drivers/pinctrl/nomadik/pinctrl-nomadik.c |4 ++--
drivers/pinctrl/pinctrl-adi2.c|3 +--
drivers/pinctrl/pinctrl-amd.c |4 ++--
drivers/pinctrl/pinctrl-at91.c|2 +-
drivers/pinctrl/pinctrl-coh901.c |2 +-
drivers/pinctrl/pinctrl-rockchip.c|2 +-
drivers/pinctrl/pinctrl-single.c |2 +-
drivers/pinctrl/pinctrl-st.c |4 ++--
drivers/pinctrl/qcom/pinctrl-msm.c|4 ++--
drivers/pinctrl/samsung/pinctrl-exynos.c |4 ++--
drivers/pinctrl/samsung/pinctrl-s3c24xx.c |8
drivers/pinctrl/samsung/pinctrl-s3c64xx.c | 10 +-
drivers/pinctrl/sirf/pinctrl-sirf.c |4 ++--
drivers/pinctrl/spear/pinctrl-plgpio.c|2 +-
drivers/pinctrl/sunxi/pinctrl-sunxi.c |2 +-
20 files changed, 33 insertions(+), 34 deletions(-)
diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
index 4ad5c1a996e3..df940687524f 100644
--- a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
+++ b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
@@ -143,7 +143,7 @@ static inline bool cygnus_get_bit(struct cygnus_gpio *chip,
unsigned int reg,
return !!(readl(chip-base + offset) BIT(shift));
}
-static void cygnus_gpio_irq_handler(unsigned int irq, struct irq_desc *desc)
+static void cygnus_gpio_irq_handler(struct irq_desc *desc)
{
struct gpio_chip *gc = irq_desc_get_handler_data(desc);
struct cygnus_gpio *chip = to_cygnus_gpio(gc);
diff --git a/drivers/pinctrl/intel/pinctrl-baytrail.c
b/drivers/pinctrl/intel/pinctrl-baytrail.c
index 2062c224e32f..94870cedb0ad 100644
--- a/drivers/pinctrl/intel/pinctrl-baytrail.c
+++ b/drivers/pinctrl/intel/pinctrl-baytrail.c
@@ -421,7 +421,7 @@ static void byt_gpio_dbg_show(struct seq_file *s, struct
gpio_chip *chip)
spin_unlock_irqrestore(vg-lock, flags);
}
-static void byt_gpio_irq_handler(unsigned irq, struct irq_desc *desc)
+static void byt_gpio_irq_handler(struct irq_desc *desc)
{
struct irq_data *data = irq_desc_get_irq_data(desc);
struct byt_gpio *vg = to_byt_gpio(irq_desc_get_handler_data(desc));
diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c
b/drivers/pinctrl/intel/pinctrl-cherryview.c
index 878e798bcb56..cfdc5f1c9cd6 100644
--- a/drivers/pinctrl/intel/pinctrl-cherryview.c
+++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
@@ -1364,7 +1364,7 @@ static struct irq_chip chv_gpio_irqchip = {
.flags = IRQCHIP_SKIP_SET_WAKE,
};
-static void chv_gpio_irq_handler(unsigned irq, struct irq_desc *desc)
+static void chv_gpio_irq_handler(struct irq_desc *desc)
{
struct gpio_chip *gc = irq_desc_get_handler_data(desc);
struct chv_pinctrl *pctrl = gpiochip_to_pinctrl(gc);
diff --git a/drivers/pinctrl/intel/pinctrl-intel.c
b/drivers/pinctrl/intel/pinctrl-intel.c
index a40681097402..a64ca4bd69cd 100644
--- a/drivers/pinctrl/intel/pinctrl-intel.c
+++ b/drivers/pinctrl/intel/pinctrl-intel.c
@@ -836,7 +836,7 @@ static void intel_gpio_community_irq_handler(struct
gpio_chip *gc,
}
}
-static void intel_gpio_irq_handler(unsigned irq, struct irq_desc *desc)
+static void intel_gpio_irq_handler(struct irq_desc *desc)
{
struct gpio_chip *gc = irq_desc_get_handler_data(desc);
struct intel_pinctrl *pctrl = gpiochip_to_pinctrl(gc);
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index fd05ca6125b0..9ec45d4875db 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -1016,7 +1016,7 @@ mtk_eint_debounce_process(struct mtk_pinctrl *pctl, int
index)
}
}
-static void mtk_eint_irq_handler(unsigned irq, struct irq_desc *desc)
+static void mtk_eint_irq_handler(struct irq_desc *desc)
{
struct irq_chip *chip = irq_desc_get_chip(desc);
struct mtk_pinctrl *pctl = irq_desc_get_handler_data(desc);
diff --git a/drivers/pinctrl/nomadik/pinctrl-nomadik.c
b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
index 902f53b855bf..cd70a30f8d8e 100644
--- a/drivers/pinctrl/nomadik/pinctrl-nomadik.c
+++ b/drivers/pinctrl/nomadik/pinctrl-nomadik.c
@@ -871,7 +871,7 @@ static
Re: [PATCH] ARM: multi_v7_defconfig: enable usb3503
riku.voi...@linaro.org writes: From: Riku Voipio riku.voi...@linaro.org CONFIG_USB_HSIC_USB3503 is needed by exynos5250-arndale for the on-board asix network controller. Enable it so networking works with multi_v7_defconfig out of box like it does with exynos_defconfig. USB3503 is also referenced from exynos4412-odroidu3.dts and exynos5250-spring.dts so this patch should improve multi_v7_defconfig on those platforms as well. Signed-off-by: Riku Voipio riku.voi...@linaro.org Tyler pointed me to this in order to get arndale networking on mainline, but looks like this might need to be revisited for current mainline. I tested this and it doesn't work because as of commit 7de7c6717f2c (ARM: multi_v7_defconfig: Enable Exynos USB PHY) the PHY that this depends on is built as a module in multi_v7_config, so having this driver built-in doesn't help. Even after the PHY driver is loaded, this driver will not detect the hardware. So instead, I think this driver should be built as a module as well. Testing that, I can get networking by doing loading both the phy and this driver after boot: # modprobe phy-exynos-usb2 # modprobe usb3503 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] drivers/cpufreq: include module.h for modular exynos-cpufreq.c code
On 03-06-15, 17:18, Paul Gortmaker wrote: This file is built off of a tristate Kconfig option (ARM_EXYNOS_CPUFREQ) and also contains modular function calls so it should explicitly include module.h to avoid compile breakage during pending header shuffles. Cc: Rafael J. Wysocki r...@rjwysocki.net Cc: Viresh Kumar viresh.ku...@linaro.org Cc: Kukjin Kim kg...@kernel.org Cc: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: linux...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-soc@vger.kernel.org Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- [ patch will be appended to the implicit include fixup series, see: https://lkml.kernel.org/r/1430444867-22342-1-git-send-email-paul.gortma...@windriver.com for the original series posting.] drivers/cpufreq/exynos-cpufreq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c index 82d2fbb20f7e..4c157302365f 100644 --- a/drivers/cpufreq/exynos-cpufreq.c +++ b/drivers/cpufreq/exynos-cpufreq.c @@ -10,6 +10,7 @@ */ #include linux/kernel.h +#include linux/module.h #include linux/err.h #include linux/clk.h #include linux/io.h Acked-by: Viresh Kumar viresh.ku...@linaro.org -- viresh -- 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
[RFT v2 36/48] genirq, arm: Kill the first parameter 'irq' of irq_flow_handler_t
Now most IRQ flow handlers make no use of the first parameter 'irq'.
And for those who do make use of 'irq', we could easily get the irq
number through irq_desc-irq_data-irq. So kill the first parameter
'irq' of irq_flow_handler_t.
To ease review, I have split the changes into several parts, though
they should be merge as one to support bisecting.
Signed-off-by: Jiang Liu jiang@linux.intel.com
Signed-off-by: Hans Ulli Kroll ulli.kr...@googlemail.com
---
arch/arm/common/it8152.c |2 +-
arch/arm/common/locomo.c |2 +-
arch/arm/common/sa.c |4 ++--
arch/arm/include/asm/hardware/it8152.h |2 +-
arch/arm/include/asm/mach/irq.h|4 ++--
arch/arm/mach-dove/irq.c |4 ++--
arch/arm/mach-footbridge/isa-irq.c |4 ++--
arch/arm/mach-gemini/gpio.c|2 +-
arch/arm/mach-imx/3ds_debugboard.c |2 +-
arch/arm/mach-imx/mach-mx31ads.c |2 +-
arch/arm/mach-iop13xx/msi.c|2 +-
arch/arm/mach-lpc32xx/irq.c|4 ++--
arch/arm/mach-netx/generic.c |2 +-
arch/arm/mach-omap1/fpga.c |2 +-
arch/arm/mach-omap2/prm_common.c |2 +-
arch/arm/mach-pxa/balloon3.c |2 +-
arch/arm/mach-pxa/cm-x2xx-pci.c|4 ++--
arch/arm/mach-pxa/lpd270.c |2 +-
arch/arm/mach-pxa/pcm990-baseboard.c |2 +-
arch/arm/mach-pxa/viper.c |2 +-
arch/arm/mach-pxa/zeus.c |2 +-
arch/arm/mach-rpc/ecard.c |2 +-
arch/arm/mach-s3c24xx/bast-irq.c |3 +--
arch/arm/mach-s3c64xx/common.c |8
arch/arm/mach-sa1100/neponset.c|2 +-
arch/arm/plat-orion/gpio.c |2 +-
26 files changed, 35 insertions(+), 36 deletions(-)
diff --git a/arch/arm/common/it8152.c b/arch/arm/common/it8152.c
index 5114b68e99d5..aaa206181f92 100644
--- a/arch/arm/common/it8152.c
+++ b/arch/arm/common/it8152.c
@@ -95,7 +95,7 @@ void it8152_init_irq(void)
}
}
-void it8152_irq_demux(unsigned int irq, struct irq_desc *desc)
+void it8152_irq_demux(struct irq_desc *desc)
{
int bits_pd, bits_lp, bits_ld;
int i;
diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index d4a62ff39576..43e18e8b0277 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -138,7 +138,7 @@ static struct locomo_dev_info locomo_devices[] = {
},
};
-static void locomo_handler(unsigned int irq, struct irq_desc *desc)
+static void locomo_handler(struct irq_desc *desc)
{
struct locomo *lchip = irq_desc_get_chip_data(desc);
int req, i;
diff --git a/arch/arm/common/sa.c b/arch/arm/common/sa.c
index 0d0844fa54c2..762dfe7081f0 100644
--- a/arch/arm/common/sa.c
+++ b/arch/arm/common/sa.c
@@ -197,7 +197,7 @@ static struct sa_dev_info sa_devices[] = {
* will call us again if there are more interrupts to process.
*/
static void
-sa_irq_handler(unsigned int irq, struct irq_desc *desc)
+sa_irq_handler(struct irq_desc *desc)
{
unsigned int stat0, stat1, i;
struct sa *sachip = irq_desc_get_handler_data(desc);
@@ -213,7 +213,7 @@ sa_irq_handler(unsigned int irq, struct irq_desc *desc)
sa_writel(stat1, mapbase + SA_INTSTATCLR1);
if (stat0 == 0 stat1 == 0) {
- do_bad_IRQ(irq, desc);
+ do_bad_IRQ(desc);
return;
}
diff --git a/arch/arm/include/asm/hardware/it8152.h
b/arch/arm/include/asm/hardware/it8152.h
index d36a73d7c0e8..076777ff3daa 100644
--- a/arch/arm/include/asm/hardware/it8152.h
+++ b/arch/arm/include/asm/hardware/it8152.h
@@ -106,7 +106,7 @@ extern void __iomem *it8152_base_address;
struct pci_dev;
struct pci_sys_data;
-extern void it8152_irq_demux(unsigned int irq, struct irq_desc *desc);
+extern void it8152_irq_demux(struct irq_desc *desc);
extern void it8152_init_irq(void);
extern int it8152_pci_map_irq(const struct pci_dev *dev, u8 slot, u8 pin);
extern int it8152_pci_setup(int nr, struct pci_sys_data *sys);
diff --git a/arch/arm/include/asm/mach/irq.h b/arch/arm/include/asm/mach/irq.h
index 2092ee1e1300..4703e00283db 100644
--- a/arch/arm/include/asm/mach/irq.h
+++ b/arch/arm/include/asm/mach/irq.h
@@ -23,10 +23,10 @@ extern int show_fiq_list(struct seq_file *, int);
/*
* This is for easy migration, but should be changed in the source
*/
-#define do_bad_IRQ(irq,desc) \
+#define do_bad_IRQ(desc) \
do { \
raw_spin_lock(desc-lock); \
- handle_bad_irq(irq, desc); \
+ handle_bad_irq(desc); \
raw_spin_unlock(desc-lock); \
} while(0)
diff --git a/arch/arm/mach-dove/irq.c b/arch/arm/mach-dove/irq.c
index 6d0f0b12f95a..30140cbdb249 100644
---
Re: [RFT v2 36/48] genirq, arm: Kill the first parameter 'irq' of irq_flow_handler_t
On 04.06.2015 13:13, Jiang Liu wrote: Now most IRQ flow handlers make no use of the first parameter 'irq'. And for those who do make use of 'irq', we could easily get the irq number through irq_desc-irq_data-irq. So kill the first parameter 'irq' of irq_flow_handler_t. To ease review, I have split the changes into several parts, though they should be merge as one to support bisecting. Signed-off-by: Jiang Liu jiang@linux.intel.com Signed-off-by: Hans Ulli Kroll ulli.kr...@googlemail.com --- arch/arm/common/it8152.c |2 +- arch/arm/common/locomo.c |2 +- arch/arm/common/sa.c |4 ++-- arch/arm/include/asm/hardware/it8152.h |2 +- arch/arm/include/asm/mach/irq.h|4 ++-- arch/arm/mach-dove/irq.c |4 ++-- arch/arm/mach-footbridge/isa-irq.c |4 ++-- arch/arm/mach-gemini/gpio.c|2 +- arch/arm/mach-imx/3ds_debugboard.c |2 +- arch/arm/mach-imx/mach-mx31ads.c |2 +- arch/arm/mach-iop13xx/msi.c|2 +- arch/arm/mach-lpc32xx/irq.c|4 ++-- arch/arm/mach-netx/generic.c |2 +- arch/arm/mach-omap1/fpga.c |2 +- arch/arm/mach-omap2/prm_common.c |2 +- arch/arm/mach-pxa/balloon3.c |2 +- arch/arm/mach-pxa/cm-x2xx-pci.c|4 ++-- arch/arm/mach-pxa/lpd270.c |2 +- arch/arm/mach-pxa/pcm990-baseboard.c |2 +- arch/arm/mach-pxa/viper.c |2 +- arch/arm/mach-pxa/zeus.c |2 +- arch/arm/mach-rpc/ecard.c |2 +- arch/arm/mach-s3c24xx/bast-irq.c |3 +-- arch/arm/mach-s3c64xx/common.c |8 For s3c24xx/s3c64xx: Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com 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: [RFT v2 46/48] genirq, irqchip: Kill the first parameter 'irq' of irq_flow_handler_t
On 04.06.2015 13:13, Jiang Liu wrote: Now most IRQ flow handlers make no use of the first parameter 'irq'. And for those who do make use of 'irq', we could easily get the irq number through irq_desc-irq_data-irq. So kill the first parameter 'irq' of irq_flow_handler_t. To ease review, I have split the changes into several parts, though they should be merge as one to support bisecting. Signed-off-by: Jiang Liu jiang@linux.intel.com Acked-by: Ralf Baechle r...@linux-mips.org --- drivers/irqchip/exynos-combiner.c|4 ++-- For exynos: Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com 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 11/11] dt: Exynos: add Snow SPI NOR node.
On 04.06.2015 06:26, Michal Suchanek wrote:
The Snow has onboard SPI NOR flash which contains the bootloader.
Add DT node for this flash chip. The flash is rated 133MHz but the pl330
controller can transfer only up to 128 bytes at this speed so use more
conservative settings. Even at 40MHz pl330 can transfer at most 64k with
the current driver.
Signed-off-by: Michal Suchanek hramr...@gmail.com
---
arch/arm/boot/dts/exynos5250-snow.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index 1fa72cf..38e4cda 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -691,6 +691,18 @@
num-cs = 1;
cs-gpios = gpa2 5 0;
status = okay;
+ flash: m25p80@0 {
The indentation looks odd. This should be at the same level as status.
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = jedec,spi-nor;
+ reg = 0;
+ spi-max-frequency = 4000;
So actually you wanted 133 MHz but as a workaround for DMA issue you use
40 MHz, right? Could you add here a small TODO note in comment about it?
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 09/11] dma: pl330: fix wording in mcbufsz message
On 04.06.2015 06:26, Michal Suchanek wrote: The kernel is not trying to increase mcbufsz. It suggests you should try doing so. Also print the calculated required size of mcbufsz. Signed-off-by: Michal Suchanek hramr...@gmail.com Looks good: Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com 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 01/11] ARM: dt: Add SPI CS on Samsung Snow board.
On 04.06.2015 06:26, Michal Suchanek wrote: Although there is only one choice of chipselect it is necessary to specify it. The driver cannot claim the gpio otherwise. Signed-off-by: Michal Suchanek hramr...@gmail.com --- arch/arm/boot/dts/exynos5250-snow.dts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) Acked-by: Krzysztof Kozlowski k.kozlow...@samsung.com 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 00/11] Enable access to SPI NOR flash on Samsung Snow board
On 4 June 2015 at 00:53, Marek Vasut ma...@denx.de wrote: On Wednesday, June 03, 2015 at 11:26:39 PM, Michal Suchanek wrote: Hello, Hi, this patch series makes it possible to access the SPI NOR flash in the Samsung XE303 'Snow' Chromebook. Unfortunately not all issues are resolved. To work around an issue with the pl330 dma engine I respun the patch for limiting transfer size in m25p80 driver. Looks like fixing a bug at the wrong place to me ... As the flash does not contain any sane filesystem and is only likely to be accessed with mtd_debug or similar tool the limit of the dma engine is easily reached. Filesystems using shorter data transfers are less likely to be affected. Sounds like the DMA engine driver should be fixed. I looked at the pl330 datasheet and don't see anything obviusly wrong with the pl330 driver in Linux. Ideally it would be fixed but I have no idea what's wrong with it. Thanks Michal -- 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/9] drm/exynos: add error messages if clks failed to get enabled
2015-06-03 Alexey Klimov klimov.li...@gmail.com:
Hi Gustavo,
On Wed, Jun 3, 2015 at 5:30 PM, Gustavo Padovan gust...@padovan.org wrote:
From: Gustavo Padovan gustavo.pado...@collabora.co.uk
Check error and call DRM_ERROR if clk_prepare_enable() fails.
Signed-off-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 29
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 --
drivers/gpu/drm/exynos/exynos_mixer.c | 31
+-
3 files changed, 63 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index d659ba2..ffd7c3b 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -606,6 +606,7 @@ static void decon_init(struct decon_context *ctx)
static void decon_enable(struct exynos_drm_crtc *crtc)
{
struct decon_context *ctx = crtc-ctx;
+ int ret;
if (!ctx-suspended)
return;
@@ -614,10 +615,30 @@ static void decon_enable(struct exynos_drm_crtc *crtc)
pm_runtime_get_sync(ctx-dev);
- clk_prepare_enable(ctx-pclk);
- clk_prepare_enable(ctx-aclk);
- clk_prepare_enable(ctx-eclk);
- clk_prepare_enable(ctx-vclk);
+ ret = clk_prepare_enable(ctx-pclk);
+ if (ret 0) {
+ DRM_ERROR(Failed to prepare_enable the pclk [%d]\n, ret);
+ return;
+ goto pclk_err;
This goto after return probably got here by mistake. Debug/rebase leftover?
Yes. Thanks for pointing it out. I'll send an updated patch fixing this.
..snip..
By the way, are you using some branch to prepare this patch?
Could you please check if you're able to apple it?
In current master branch that i see similar DRM_ERROR() messages are
already in place in similar functions. For example, in master branch i
see decon_poweron() instead of decon_enable() and fimd_poweron()
instead of fimd_enable() in your patch. Is there any chance that it's
slightly outdated?
This is based on tree of today, with the atomic modesetting patches
applied.
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
