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 > 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
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 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
[PATCH] drm/exynos: add a dependency on FB_S3C to DECON driver
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 --- drivers/gpu/drm/exynos/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index 0a67803..8203283 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -26,7 +26,7 @@ config DRM_EXYNOS_FIMD config DRM_EXYNOS7_DECON bool "Exynos DRM DECON" - depends on DRM_EXYNOS + depends on DRM_EXYNOS && !FB_S3C select FB_MODE_HELPERS help Choose this option if you want to use Exynos DECON for DRM. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drm/exynos: vidi: remove unused varables
This patch removes unnsed varables in vidi_disable function.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_vidi.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index abe4ee0..16dc68c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -179,8 +179,6 @@ static void vidi_enable(struct exynos_drm_crtc *crtc)
static void vidi_disable(struct exynos_drm_crtc *crtc)
{
struct vidi_context *ctx = crtc->ctx;
- struct exynos_drm_plane *plane;
- int i;
mutex_lock(&ctx->lock);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] drm/exynos: fimd: ensure proper hw state in fimd_clear_channel()
Hi Marek,
I have merged atomic patch series. Can you re-base your patch series on
top of exynos-drm-next?
Thanks,
Inki Dae
On 2015년 06월 01일 20:15, Marek Szyprowski wrote:
> 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 calls to power on/off 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
> Tested-by: Javier Martinez Canillas
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 26 +-
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index a0edab833148..d10ad3920e78 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 void fimd_clear_channel(struct fimd_context *ctx)
> +static int fimd_poweron(struct fimd_context *ctx);
> +static int fimd_poweroff(struct fimd_context *ctx);
> +
> +static int fimd_clear_channel(struct fimd_context *ctx)
> {
> unsigned int win, ch_enabled = 0;
> + int ret;
>
> DRM_DEBUG_KMS("%s\n", __FILE__);
>
> + /* Hardware is in unknown state, so ensure it get enabled properly */
> + ret = fimd_poweron(ctx);
> + if (ret)
> + return ret;
> +
> /* Check if any channel is enabled. */
> for (win = 0; win < WINDOWS_NR; win++) {
> u32 val = readl(ctx->regs + WINCON(win));
> @@ -258,19 +267,15 @@ static void fimd_clear_channel(struct fimd_context *ctx)
> if (ctx->driver_data->has_shadowcon)
> fimd_enable_shadow_channel_path(ctx, win,
> false);
> -
> ch_enabled = 1;
> }
> }
>
> /* Wait for vsync, as disable channel takes effect at next vsync */
> - if (ch_enabled) {
> - unsigned int state = ctx->suspended;
> -
> - ctx->suspended = 0;
> + if (ch_enabled)
> fimd_wait_for_vblank(ctx->crtc);
> - ctx->suspended = state;
> - }
> +
> + return fimd_poweroff(ctx);
> }
>
> static int fimd_iommu_attach_devices(struct fimd_context *ctx,
> @@ -285,7 +290,10 @@ static int fimd_iommu_attach_devices(struct fimd_context
> *ctx,
>* If any channel is already active, iommu will throw
>* a PAGE FAULT when enabled. So clear any channel if enabled.
>*/
> - fimd_clear_channel(ctx);
> + ret = fimd_clear_channel(ctx);
> + if (ret)
> + return ret;
> +
> ret = drm_iommu_attach_device(ctx->drm_dev, ctx->dev);
> if (ret) {
> DRM_ERROR("drm_iommu_attach failed.\n");
>
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 17/17] drm/exynos: split exynos_crtc->dpms in enable() and disable()
On 2015년 06월 02일 23:19, Javier Martinez Canillas wrote: > Hello Gustavo, > > On Tue, Jun 2, 2015 at 4:06 PM, Gustavo Padovan wrote: >> Hi Inki, >> >> 2015-06-02 Inki Dae : >> >>> Hi, >>> >>> On 2015년 06월 02일 00:04, Gustavo Padovan wrote: From: Gustavo Padovan 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. >>> >>> Below is the result from checkpatch.pl. Please fix all errors and check >>> your patch with checkpatch.pl before posting it. >>> >>> Thanks, >>> Inki Dae >>> >>> total: 62 errors, 0 warnings, 410 lines checked >> >> I think you did something wrong when checking, for me it looks like >> this: >> >> 0016-drm-exynos-split-exynos_crtc-dpms-in-enable-and-disa.patch has no >> obvious style problems and is ready for submission. >> WARNING: Do not use whitespace before Signed-off-by: >> #12: >> Signed-off-by: Gustavo Padovan >> >> total: 0 errors, 1 warnings, 594 lines checked >> > > I also don't get any checkpatch.pl error or warnings when testing your patch: > > $ pwclient get 6523251 > Saved patch to > v10-17-17-drm-exynos-split-exynos_crtc--dpms-in-enable-and-disable.patch.0 > > $ ./scripts/checkpatch.pl > v10-17-17-drm-exynos-split-exynos_crtc--dpms-in-enable-and-disable.patch > total: 0 errors, 0 warnings, 410 lines checked > > v10-17-17-drm-exynos-split-exynos_crtc--dpms-in-enable-and-disable.patch > has no obvious style problems and is ready for submission. Yes, there was something wrong. While coping this patch series to my PC, it seems that the text format of this patch file was mutated. Thanks for checking, Inki Dae > >> Gustavo > > Best regards, > Javier > -- > To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" > in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: multi_v7_defconfig: Enable display on Trats2board
On 05/24/15 05:27, Arnd Bergmann wrote: > On Saturday 23 May 2015 11:18:58 Kukjin Kim wrote: >> On 05/22/15 18:11, Javier Martinez Canillas wrote: >>> Hello Krzysztof, >>> >>> On 05/22/2015 02:48 AM, Krzysztof Kozlowski wrote: Enable the Exynos DSI and S6E8AA0 panel for full X11 display on Trats2. Signed-off-by: Krzysztof Kozlowski --- arch/arm/configs/multi_v7_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 0848337a2a01..e9785020aab1 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -413,10 +413,12 @@ CONFIG_DRM=y CONFIG_DRM_PTN3460=m CONFIG_DRM_PS8622=m CONFIG_DRM_EXYNOS=m +CONFIG_DRM_EXYNOS_DSI=y CONFIG_DRM_EXYNOS_FIMD=y CONFIG_DRM_EXYNOS_HDMI=y CONFIG_DRM_RCAR_DU=m CONFIG_DRM_TEGRA=y +CONFIG_DRM_PANEL_S6E8AA0=m CONFIG_DRM_PANEL_SIMPLE=y CONFIG_FB_ARMCLCD=y CONFIG_FB_WM8505=y >>> >>> Reviewed-by: Javier Martinez Canillas >>> >> Looks good to me and this would be handled by arm-soc guys directly >> >> Acked-by: Kukjin Kim >> > > I'd actually prefer if you could put this into the same branch as your > other defconfig changes. We'll handle any conflicts when merging that in. > OK, 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: exynos4412: Audio dies after one day on kernel 4.0
On 03.06.2015 04:51, gabr...@unseen.is wrote:
> On 05/31/2015 08:47 AM, Krzysztof Kozlowski wrote:
>> 2015-05-31 2:32 GMT+09:00 :
>>>
>>> Hello,
>>>
>>> I've been successfully using a self compiled linux kernel until version
>>> 3.19 together with Debian Stretch.
>>>
>>> After upgrading the kernel to version 4.0 I see strange messages in the
>>> logs i.e.
>>>
>>> May 27 22:44:01 pulseaudio[1027]: [alsa-sink-383.i2s-HiFi HiFi-0]
>>> alsa-sink.c: ALSA woke us up to write new data to the device, but there
>>> was actually nothing to write!
>>> May 27 22:44:01 pulseaudio[1027]: [alsa-sink-383.i2s-HiFi HiFi-0]
>>> alsa-sink.c: Most likely this is a bug in the ALSA driver
>>> 'snd_soc_simple_card'. Please report this issue to the ALSA developers.
>>> May 27 22:44:01 pulseaudio[1027]: [alsa-sink-383.i2s-HiFi HiFi-0]
>>> alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent
>>> snd_pcm_avail() returned 0 or another value < min_avail.
>>>
>>>
>>> I can easily play sound in perfect quality for approx the first 24h.
>>> After that time the sound becomes distorted and is choppy/crackling.
>>> After rebooting then the sound is optimal again.
>>>
>>>
>>> I have tried to use kernel 4.0 with almost exactly the same
>>> configuration than for 3.19 to no avail.
>>>
>>> Then somebody on
>>> http://forum.odroid.com/viewtopic.php?f=82&t=13281&p=91186 gave me the
>>> hint that the followin patch might solve the issue:
>>>
>>> https://github.com/prahal/linux/commit/5e60cfc9fa5101a346e29ef5f944fbbad300c72d
>>>
>>>
>>> The patch did help something. I can now still play music after 2 days
>>> but what happens is that each time I turn on music I get a choppy sound
>>> for some time. That means the sound comes clear but every 2 seconds the
>>> sound pauses for a fraction of a second. Which is somewhat comparable to
>>> the issue earlier but without the heavy crackling - and that this goes
>>> away after a couple of minutes.
>>>
>>>
>>> But furthermore the sound has now simple cracklings. One in two second
>>> approx. and they do not disappear.
>>>
>>>
>>> Does anybody have an idea what could be the matter here?
>>>
>>> Thanks in advance.
>>
>> +Cc Robert, dmaengine list.
>>
>> Bisecting would be helpful. You could also try reverting following commits:
>> 88987d2c75
>> aee4d1fac8
>>
>> Other possible test case would be disabling runtime PM for pl330 DMA driver:
>>
>> for i in /sys/bus/amba/drivers/dma-pl330/*.[amp]dma/power ; do
>> echo "on" > ${i}/control
>> done
>>
>
> Thanks a lot Krzysztof,
>
> I have reverted 88987d2c75 and aee4d1fac8 from 4.0.4 and I have still
> audio working after 1 and 1/2 day. Unluckily the alsa error message
> occured still once but they don't seem to be the issue here.
+CC Marek,
Robert, Marek, do you have any idea for the cause?
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 v4 5/5] ARM: dts: Add LEDs to exynos5410-odroidxu
On 02.06.2015 22:38, Andreas Färber wrote: > Am 02.06.2015 um 22:02 schrieb Krzysztof Kozlowski: >> W dniu 16.03.2015 o 07:00, Andreas Färber pisze: >>> Signed-off-by: Hakjoo Kim >>> Signed-off-by: Andreas Färber >>> --- >>> v2 -> v3: Unchanged >>> >>> v1 -> v2: >>> * Filled in Sob from Hakjoo Kim >>> >>> arch/arm/boot/dts/exynos5410-odroidxu.dts | 25 + >>> 1 file changed, 25 insertions(+) >> >> What is the rationale behind doing this in separate patch, not as part >> of 2/5? You can just add new board DTS with all of its features at once, >> but maybe I am missing something? > > This patch depends on the pinctrl driver, 2/5 on nothing. > > By keeping it a separate patch it was intended to go in more quickly > (clear fail there ;)) and it's easier to review the actual changes - > squashing is always easier than picking apart. OK, I'm fine with it. The patch looks good: Reviewed-by: Krzysztof Kozlowski Can you resend everything with the change in chosen/console? 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 2/9] mm: Provide new get_vaddr_frames() helper
On Tue, 2 Jun 2015 17:23:00 +0200 Jan Kara 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'. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/8] mfd: cros_ec: Add multi EC and proto v3 support
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 Heiko -- 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: exynos4412: Audio dies after one day on kernel 4.0
On 05/31/2015 08:47 AM, Krzysztof Kozlowski wrote:
> 2015-05-31 2:32 GMT+09:00 :
>>
>> Hello,
>>
>> I've been successfully using a self compiled linux kernel until version
>> 3.19 together with Debian Stretch.
>>
>> After upgrading the kernel to version 4.0 I see strange messages in the
>> logs i.e.
>>
>> May 27 22:44:01 pulseaudio[1027]: [alsa-sink-383.i2s-HiFi HiFi-0]
>> alsa-sink.c: ALSA woke us up to write new data to the device, but there
>> was actually nothing to write!
>> May 27 22:44:01 pulseaudio[1027]: [alsa-sink-383.i2s-HiFi HiFi-0]
>> alsa-sink.c: Most likely this is a bug in the ALSA driver
>> 'snd_soc_simple_card'. Please report this issue to the ALSA developers.
>> May 27 22:44:01 pulseaudio[1027]: [alsa-sink-383.i2s-HiFi HiFi-0]
>> alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent
>> snd_pcm_avail() returned 0 or another value < min_avail.
>>
>>
>> I can easily play sound in perfect quality for approx the first 24h.
>> After that time the sound becomes distorted and is choppy/crackling.
>> After rebooting then the sound is optimal again.
>>
>>
>> I have tried to use kernel 4.0 with almost exactly the same
>> configuration than for 3.19 to no avail.
>>
>> Then somebody on
>> http://forum.odroid.com/viewtopic.php?f=82&t=13281&p=91186 gave me the
>> hint that the followin patch might solve the issue:
>>
>> https://github.com/prahal/linux/commit/5e60cfc9fa5101a346e29ef5f944fbbad300c72d
>>
>>
>> The patch did help something. I can now still play music after 2 days
>> but what happens is that each time I turn on music I get a choppy sound
>> for some time. That means the sound comes clear but every 2 seconds the
>> sound pauses for a fraction of a second. Which is somewhat comparable to
>> the issue earlier but without the heavy crackling - and that this goes
>> away after a couple of minutes.
>>
>>
>> But furthermore the sound has now simple cracklings. One in two second
>> approx. and they do not disappear.
>>
>>
>> Does anybody have an idea what could be the matter here?
>>
>> Thanks in advance.
>
> +Cc Robert, dmaengine list.
>
> Bisecting would be helpful. You could also try reverting following commits:
> 88987d2c75
> aee4d1fac8
>
> Other possible test case would be disabling runtime PM for pl330 DMA driver:
>
> for i in /sys/bus/amba/drivers/dma-pl330/*.[amp]dma/power ; do
> echo "on" > ${i}/control
> done
>
Thanks a lot Krzysztof,
I have reverted 88987d2c75 and aee4d1fac8 from 4.0.4 and I have still
audio working after 1 and 1/2 day. Unluckily the alsa error message
occured still once but they don't seem to be the issue here.
Do you need to have tested out something else?
Best regards,
Gabriel
--
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 05/98] exynos_drm.h: use __u64 from linux/types.h
On Sat, May 30, 2015 at 05:46:56PM +0100, Russell King - ARM Linux wrote: > Note that drm/drm.h is all that should need to be included - drm/drm.h > takes care of including linux/types.h when building on Linux platforms. > (note: if your compiler doesn't set __linux__ then you're probably not > using the proper compiler...) Thanks, I'll fix this by including only drm/drm.h in exynos_drm.h, nouveau_drm.h, radeon_drm.h and via_drm.h patches. I'm using standard gcc from Debian for the x86 compilation. -Mikko -- 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 Thu 28-05-15 16:24:02, Andrew Morton wrote: > On Wed, 13 May 2015 15:08:08 +0200 Jan Kara wrote: > > > Provide new function get_vaddr_frames(). This function maps virtual > > addresses from given start and fills given array with page frame numbers of > > the corresponding pages. If given 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. Caller > > must make sure pfns aren't reused for anything else while he is using > > them. > > > > This function is created for various drivers to simplify handling of > > their buffers. > > > > Acked-by: Mel Gorman > > Acked-by: Vlastimil Babka > > Signed-off-by: Jan Kara > > --- > > include/linux/mm.h | 44 +++ > > mm/gup.c | 226 > > + > > 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? Honza -- Jan Kara SUSE Labs, CR >From d18fc7863fc62d8ad0c1747b789a0dcf032ccf42 Mon Sep 17 00:00:00 2001 From: Jan Kara 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 Signed-off-by: Jan Kara --- 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 mm/gup.c| 225 -- 7 files changed, 240 insertions(+), 225 deletions(-) create mode 100644 mm/frame-vec.c diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig index 0a6780367d28..b2fac87137c7 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_VEC 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..7cceca7b184d 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_VEC 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..957e5a18b0ff 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_VEC config VIDEOBUF2_DMA_CONTIG tristate diff --git a/mm/Kconfig b/mm/Kconfig index 390214da4546..d039615e8f82 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_VEC + bool diff --git a/mm/Makefile b/mm/Makefile index 98c4eaeabdcb..d38305462e17 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_VEC) += frame-vec.o diff --git a/mm/frame-vec.c b/mm/frame-vec.c new file mode 100644 index ..5d85bcd150ae --- /dev/null +++ b/mm/frame-vec.c @@ -0,0 +1,233 @@ +#include +#include +#include +#include +#include +#include +#include + +/* + * 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 functi
Re: [PATCH v10 17/17] drm/exynos: split exynos_crtc->dpms in enable() and disable()
Hello Gustavo, On Tue, Jun 2, 2015 at 4:06 PM, Gustavo Padovan wrote: > Hi Inki, > > 2015-06-02 Inki Dae : > >> Hi, >> >> On 2015년 06월 02일 00:04, Gustavo Padovan wrote: >> > From: Gustavo Padovan >> > >> > 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. >> >> Below is the result from checkpatch.pl. Please fix all errors and check >> your patch with checkpatch.pl before posting it. >> >> Thanks, >> Inki Dae >> >> total: 62 errors, 0 warnings, 410 lines checked > > I think you did something wrong when checking, for me it looks like > this: > > 0016-drm-exynos-split-exynos_crtc-dpms-in-enable-and-disa.patch has no > obvious style problems and is ready for submission. > WARNING: Do not use whitespace before Signed-off-by: > #12: > Signed-off-by: Gustavo Padovan > > total: 0 errors, 1 warnings, 594 lines checked > I also don't get any checkpatch.pl error or warnings when testing your patch: $ pwclient get 6523251 Saved patch to v10-17-17-drm-exynos-split-exynos_crtc--dpms-in-enable-and-disable.patch.0 $ ./scripts/checkpatch.pl v10-17-17-drm-exynos-split-exynos_crtc--dpms-in-enable-and-disable.patch total: 0 errors, 0 warnings, 410 lines checked v10-17-17-drm-exynos-split-exynos_crtc--dpms-in-enable-and-disable.patch has no obvious style problems and is ready for submission. > Gustavo 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 v10 02/17] drm/exynos: use adjusted_mode of crtc_state instead of mode
Hi Inki, 2015-06-02 Inki Dae : > On 2015년 06월 02일 09:03, Joonyoung Shim wrote: > > On 06/02/2015 12:09 AM, Tobias Jakobi wrote: > >> Hello, > >> > >> as pointed out in [1] before, this gives me an kernel oops during boot. > >> > >> With best wishes, > >> Tobias > >> > >> [1] http://www.spinics.net/lists/linux-samsung-soc/msg44736.html > >> > > > > Yeah, this patch should go after switched by drm_helper_crtc_mode_set, > > e.g. after the patch "drm/exynos: atomic phase 1: add .mode_set_nofb() > > callback". Then crtc->base.state cannot be NULL. > > > > Gustavo, sorry for that, i meant rebase based on the patch "drm/exynos: > > atomic phase 1: add .mode_set_nofb() callback" > > > > Inki, i think it's time to merge this patchset for switch to atomic > > modeset functions if no any objection, just need to rebase of this patch > > based on the patch "drm/exynos: atomic phase 1 : add .mode_set_nofb() > > callback" and except a patch 17/17 from this merge, i think clean up > > patches like it need to more review after merge atomic patchset. > > Thanks Joonyoung. Got it. I will merge this patch series to my local > repository for test and final review. If there is no any big problem, > will merge it. Thanks for that! As I will keep working on exynos I will be around to send any follow up patch to send any follow up patch to fix potential issues of the atomic modesetting patches. 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 v10 17/17] drm/exynos: split exynos_crtc->dpms in enable() and disable()
Hi Inki, 2015-06-02 Inki Dae : > Hi, > > On 2015년 06월 02일 00:04, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > 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. > > Below is the result from checkpatch.pl. Please fix all errors and check > your patch with checkpatch.pl before posting it. > > Thanks, > Inki Dae > > total: 62 errors, 0 warnings, 410 lines checked I think you did something wrong when checking, for me it looks like this: 0016-drm-exynos-split-exynos_crtc-dpms-in-enable-and-disa.patch has no obvious style problems and is ready for submission. WARNING: Do not use whitespace before Signed-off-by: #12: Signed-off-by: Gustavo Padovan total: 0 errors, 1 warnings, 594 lines checked 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 v4 5/5] ARM: dts: Add LEDs to exynos5410-odroidxu
Am 02.06.2015 um 22:02 schrieb Krzysztof Kozlowski: > W dniu 16.03.2015 o 07:00, Andreas Färber pisze: >> Signed-off-by: Hakjoo Kim >> Signed-off-by: Andreas Färber >> --- >> v2 -> v3: Unchanged >> >> v1 -> v2: >> * Filled in Sob from Hakjoo Kim >> >> arch/arm/boot/dts/exynos5410-odroidxu.dts | 25 + >> 1 file changed, 25 insertions(+) > > What is the rationale behind doing this in separate patch, not as part > of 2/5? You can just add new board DTS with all of its features at once, > but maybe I am missing something? This patch depends on the pinctrl driver, 2/5 on nothing. By keeping it a separate patch it was intended to go in more quickly (clear fail there ;)) and it's easier to review the actual changes - squashing is always easier than picking apart. Thanks for your review! Both me and Ben have follow-ups once this moves forward. Kind regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) -- 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 5/5] ARM: dts: Add LEDs to exynos5410-odroidxu
W dniu 16.03.2015 o 07:00, Andreas Färber pisze: > Signed-off-by: Hakjoo Kim > Signed-off-by: Andreas Färber > --- > v2 -> v3: Unchanged > > v1 -> v2: > * Filled in Sob from Hakjoo Kim > > arch/arm/boot/dts/exynos5410-odroidxu.dts | 25 + > 1 file changed, 25 insertions(+) What is the rationale behind doing this in separate patch, not as part of 2/5? You can just add new board DTS with all of its features at once, but maybe I am missing something? 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 v4 1/5] ARM: dts: Clean up exynos5410-smdk5410 indentation
W dniu 16.03.2015 o 07:00, Andreas Färber pisze: > The UART status properties are indented one level too deep, and we want > to derive a device tree for the ODROID-XU. Fix this before it propagates. > > Signed-off-by: Andreas Färber Reviewed-by: Krzysztof Kozlowski Applied to my tree. If Kukjin won't grab it from here, I'll push it later to Kukjin depending on other pull requests. 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 v4 4/5] ARM: dts: add pinctrl support to Exynos5410
W dniu 16.03.2015 o 07:00, Andreas Färber pisze: > From: Hakjoo Kim > > Add the required pin configuration support to Exynos5410 using pinctrl > interface. > > Signed-off-by: Hakjoo Kim > [AF: Rebased, style changes] > Signed-off-by: Andreas Färber > --- > v2 -> v3: > * Added wake-up IRQ controller node (Tomasz Figa) > > v1 -> v2: > * Filled in Sob from Hakjoo Kim > > arch/arm/boot/dts/exynos5410-pinctrl.dtsi | 406 > ++ > arch/arm/boot/dts/exynos5410.dtsi | 36 +++ > 2 files changed, 442 insertions(+) > create mode 100644 arch/arm/boot/dts/exynos5410-pinctrl.dtsi Changes look fine: Reviewed-by: Krzysztof Kozlowski 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: [PATCHv3] ARM: dts: add exynos5422-cpus.dtsi to correct cpu order
Hi Peter, On Tue, Jun 2, 2015 at 12:29 PM, Peter Chubb wrote: >> "Chanho" == Chanho Park writes: > > Chanho> The odroid-xu3 board which is based on exynos5422 not > Chanho> exynos5800 is booted from cortex-a7 core unlike > Chanho> exynos5800. The odroid-xu3's cpu order is quite strange. cpu0 > Chanho> and cpu5-7 are cortex-a7 cores and cpu1-4 are cortex-a15 > Chanho> cores. To correct this mis-odering, I added exynos5422.dtsi > Chanho> and reversing cpu orders from exynos5420. Now, cpu0-3 are > Chanho> cortex-a7 and cpu4-7 are cortex-a15. > > Does this patch make any difference? CPUs are numbered in the kernel > in the order they're enumerated; with this patch or using the old dts > I see the CPUs numbered the same after boot. And only 5 of the 8 come > up: processor 0 is an A7; processors 1 through 4 are A15. My patch is just reordering cpu order not fix previous Little core problem. You'll need below patch from previous mail thread[1]. diff --git a/arch/arm/mach-exynos/platsmp.c b/arch/arm/mach-exynos/platsmp.c index a825bca..e803ec5 100644 --- a/arch/arm/mach-exynos/platsmp.c +++ b/arch/arm/mach-exynos/platsmp.c @@ -124,6 +124,7 @@ void exynos_cpu_power_up(int cpu) if (soc_is_exynos3250()) core_conf |= S5P_CORE_AUTOWAKEUP_EN; + pmu_raw_writel(1, S5P_PMU_SPARE2); pmu_raw_writel(core_conf, EXYNOS_ARM_CORE_CONFIGURATION(cpu)); } [1]: https://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg44023.html -- Best Regards, Chanho Park -- 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 3/5] pinctrl: exynos: add exynos5410 SoC specific data
W dniu 24.03.2015 o 02:22, Tomasz Figa pisze:
> Hi Andreas, Hakjoo,
>
> Thanks for the patch.
>
> 2015-03-16 7:00 GMT+09:00 Andreas Färber :
>> From: Hakjoo Kim
>>
>> Add Samsung EXYNOS5410 SoC specific data to enable pinctrl
>> support for all platforms based on EXYNOS5410.
>>
>> Signed-off-by: Hakjoo Kim
>> [AF: Rebased onto Exynos5260, irq_chip consolidation, const'ification]
>> Signed-off-by: Andreas Färber
>> ---
>> v2 -> v3:
>> * Rebased (.svc, .{g,w}eint_{con,mask,pend} fields dropped)
>>
>> v1 -> v2:
>> * Filled in Sob from Hakjoo Kim
>>
>> .../bindings/pinctrl/samsung-pinctrl.txt | 1 +
>> drivers/pinctrl/samsung/pinctrl-exynos.c | 103
>> +
>> drivers/pinctrl/samsung/pinctrl-samsung.c | 2 +
>> drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
>> 4 files changed, 107 insertions(+)
>>
>
> Acked-by: Tomasz Figa
So I assume this may go through Kukjin tree.
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 v4 2/5] ARM: dts: Prepare exynos5410-odroidxu device tree
W dniu 16.03.2015 o 19:27, Andreas Färber pisze:
> Hi Javier,
>
> Am 16.03.2015 um 08:56 schrieb Javier Martinez Canillas:
>> On Sun, Mar 15, 2015 at 11:00 PM, Andreas Färber wrote:
>>> Derived from exynos5410-smdk5410.dts.
>>>
>>> Signed-off-by: Andreas Färber
>>> ---
>>> v1 -> v2 -> v3: Unchanged
>
> Forgot to update the in-patch changelogs: v4 is unchanged as well
>
>>>
>>> arch/arm/boot/dts/Makefile| 1 +
>>> arch/arm/boot/dts/exynos5410-odroidxu.dts | 78
>>> +++
>>> 2 files changed, 79 insertions(+)
>>> create mode 100644 arch/arm/boot/dts/exynos5410-odroidxu.dts
>>>
>>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>>> index a1c776b8dcec..b040737edcbc 100644
>>> --- a/arch/arm/boot/dts/Makefile
>>> +++ b/arch/arm/boot/dts/Makefile
>>> @@ -103,6 +103,7 @@ dtb-$(CONFIG_ARCH_EXYNOS5) += \
>>> exynos5250-snow.dtb \
>>> exynos5250-spring.dtb \
>>> exynos5260-xyref5260.dtb \
>>> + exynos5410-odroidxu.dtb \
>>> exynos5410-smdk5410.dtb \
>>> exynos5420-arndale-octa.dtb \
>>> exynos5420-peach-pit.dtb \
>>> diff --git a/arch/arm/boot/dts/exynos5410-odroidxu.dts
>>> b/arch/arm/boot/dts/exynos5410-odroidxu.dts
>>> new file mode 100644
>>> index ..97310bb727e2
>>> --- /dev/null
>>> +++ b/arch/arm/boot/dts/exynos5410-odroidxu.dts
>>> @@ -0,0 +1,78 @@
>>> +/*
>>> + * Hardkernel ODROID-XU device tree source
>>> + *
>>> + * Copyright (c) 2014 SUSE LINUX Products GmbH
>>> + *
>>> + * Based on exynos5410-smdk5410.dts:
>>> + *
>>> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
>>> + * http://www.samsung.com
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> +*/
>>> +
>>> +/dts-v1/;
>>> +#include "exynos5410.dtsi"
>>> +/ {
>>> + model = "ODROID-XU based on EXYNOS5410";
>>> + compatible = "hardkernel,odroid-xu", "samsung,exynos5410",
>>> "samsung,exynos5";
>>> +
>>> + memory {
>>> + reg = <0x4000 0x8000>;
>>> + };
>>> +
>>> + chosen {
>>> + bootargs = "console=ttySAC2,115200";
>>> + };
>>> +
>>
>> After commit a208ffd251d0 ("of: Enable console on serial ports
>> specified by /chosen/stdout-path") the kernel is able to know what
>> serial console to use if the DT defined an stdout-path property so
>> should be preferred instead of using a console= parameter.
>>
>> I'll post today a series to change that on all exynos5 boards so you
>> can base on that.
>
> Okay, if no one else does, I could update smdk5410 before splitting.
Could you do this? At least for new board if you cannot test it on SMDK5410.
>
>>> + fin_pll: xxti {
>>> + compatible = "fixed-clock";
>>> + clock-frequency = <2400>;
>>> + clock-output-names = "fin_pll";
>>> + #clock-cells = <0>;
>>> + };
>>> +
>>
>> I think this should be defined in exynos5410.dtsi instead since is an
>> IP block in the SoC and referenced in the .dts using a label to change
>> the clock-frequency in the board.
>
> I hope you understood that this is a literal copy of smdk5410, so I'm
> not going to make random changes here. If the Samsung guys want to make
> this change for smdk5410, then fine, but otherwise - like for Snow and
> Spring - I want to keep the diff -u low between the two.
Moving the node to DTSI won't change the DTB for boards so the change is
safe. However to me it looks unusual that exynos5410.dtsi references
fin_pll phandle which is defined in the board.
However Kukjin mentioned that it is fine so it is okay with me also.
The rest looks fine, so:
Reviewed-by: Krzysztof Kozlowski
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
[PATCH 04/11] clocksource/drivers/exynos_mct: Remove old platform mct_init()
From: Krzysztof Kozlowski
Since commit 228e3023eb04 ("Merge tag 'mct-exynos-for-v3.10' of ...") the
mct_init() was superseded by mct_init_dt() and is not referenced
anywhere. Remove it.
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Daniel Lezcano
---
drivers/clocksource/exynos_mct.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 8b2a9fc..935b059 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -560,18 +560,6 @@ out_irq:
free_percpu_irq(mct_irqs[MCT_L0_IRQ], &percpu_mct_tick);
}
-void __init mct_init(void __iomem *base, int irq_g0, int irq_l0, int irq_l1)
-{
- mct_irqs[MCT_G0_IRQ] = irq_g0;
- mct_irqs[MCT_L0_IRQ] = irq_l0;
- mct_irqs[MCT_L1_IRQ] = irq_l1;
- mct_int_type = MCT_INT_SPI;
-
- exynos4_timer_resources(NULL, base);
- exynos4_clocksource_init();
- exynos4_clockevent_init();
-}
-
static void __init mct_init_dt(struct device_node *np, unsigned int int_type)
{
u32 nr_irqs, i;
--
1.9.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
[PATCH 03/11] clocksource/drivers/exynos_mct: Staticize struct clocksource
From: Krzysztof Kozlowski
The struct clocksource 'mct_frc' is not exported and used outside so
make it static.
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Daniel Lezcano
---
drivers/clocksource/exynos_mct.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 87c2e55..8b2a9fc 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -209,7 +209,7 @@ static void exynos4_frc_resume(struct clocksource *cs)
exynos4_mct_frc_start();
}
-struct clocksource mct_frc = {
+static struct clocksource mct_frc = {
.name = "mct-frc",
.rating = 400,
.read = exynos4_frc_read,
--
1.9.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
[PATCH 02/11] clocksource/drivers/exynos_mct: Change exynos4_mct_tick_clear return type to void
From: Krzysztof Kozlowski
Return value of exynos4_mct_tick_clear() was never checked so it can
be safely changed to void.
Signed-off-by: Krzysztof Kozlowski
Signed-off-by: Daniel Lezcano
---
drivers/clocksource/exynos_mct.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 83564c9..87c2e55 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -413,7 +413,7 @@ static inline void exynos4_tick_set_mode(enum
clock_event_mode mode,
}
}
-static int exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
+static void exynos4_mct_tick_clear(struct mct_clock_event_device *mevt)
{
struct clock_event_device *evt = &mevt->evt;
@@ -426,12 +426,8 @@ static int exynos4_mct_tick_clear(struct
mct_clock_event_device *mevt)
exynos4_mct_tick_stop(mevt);
/* Clear the MCT tick interrupt */
- if (readl_relaxed(reg_base + mevt->base + MCT_L_INT_CSTAT_OFFSET) & 1) {
+ if (readl_relaxed(reg_base + mevt->base + MCT_L_INT_CSTAT_OFFSET) & 1)
exynos4_mct_write(0x1, mevt->base + MCT_L_INT_CSTAT_OFFSET);
- return 1;
- } else {
- return 0;
- }
}
static irqreturn_t exynos4_mct_tick_isr(int irq, void *dev_id)
--
1.9.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 v10 02/17] drm/exynos: use adjusted_mode of crtc_state instead of mode
On 2015년 06월 02일 09:03, Joonyoung Shim wrote:
> On 06/02/2015 12:09 AM, Tobias Jakobi wrote:
>> Hello,
>>
>> as pointed out in [1] before, this gives me an kernel oops during boot.
>>
>> With best wishes,
>> Tobias
>>
>> [1] http://www.spinics.net/lists/linux-samsung-soc/msg44736.html
>>
>
> Yeah, this patch should go after switched by drm_helper_crtc_mode_set,
> e.g. after the patch "drm/exynos: atomic phase 1: add .mode_set_nofb()
> callback". Then crtc->base.state cannot be NULL.
>
> Gustavo, sorry for that, i meant rebase based on the patch "drm/exynos:
> atomic phase 1: add .mode_set_nofb() callback"
>
> Inki, i think it's time to merge this patchset for switch to atomic
> modeset functions if no any objection, just need to rebase of this patch
> based on the patch "drm/exynos: atomic phase 1 : add .mode_set_nofb()
> callback" and except a patch 17/17 from this merge, i think clean up
> patches like it need to more review after merge atomic patchset.
Thanks Joonyoung. Got it. I will merge this patch series to my local
repository for test and final review. If there is no any big problem,
will merge it.
Thanks,
Inki Dae
>
> Thanks.
>
>>
>> On 2015-06-01 17:04, Gustavo Padovan wrote:
>>> From: Joonyoung Shim
>>>
>>> Handle changes by removing copy from adjusted_mode to mode as using
>>> adjusted_mode of crtc_state.
>>>
>>> Signed-off-by: Joonyoung Shim
>>> ---
>>> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 4 ++--
>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
>>> drivers/gpu/drm/exynos/exynos_drm_plane.c | 13 +++--
>>> 3 files changed, 10 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> index 6714e5b..f29e4be 100644
>>> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
>>> @@ -175,7 +175,7 @@ static bool decon_mode_fixup(struct exynos_drm_crtc
>>> *crtc,
>>> static void decon_commit(struct exynos_drm_crtc *crtc)
>>> {
>>> struct decon_context *ctx = crtc->ctx;
>>> -struct drm_display_mode *mode = &crtc->base.mode;
>>> +struct drm_display_mode *mode = &crtc->base.state->adjusted_mode;
>>> u32 val, clkdiv;
>>>
>>> if (ctx->suspended)
>>> @@ -395,7 +395,7 @@ static void decon_shadow_protect_win(struct
>>> decon_context *ctx,
>>> static void decon_win_commit(struct exynos_drm_crtc *crtc, unsigned int
>>> win)
>>> {
>>> struct decon_context *ctx = crtc->ctx;
>>> -struct drm_display_mode *mode = &crtc->base.mode;
>>> +struct drm_display_mode *mode = &crtc->base.state->adjusted_mode;
>>> struct exynos_drm_plane *plane;
>>> int padding;
>>> unsigned long val, alpha;
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index a0edab8..b326b31 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -337,7 +337,7 @@ static bool fimd_mode_fixup(struct exynos_drm_crtc
>>> *crtc,
>>> static void fimd_commit(struct exynos_drm_crtc *crtc)
>>> {
>>> struct fimd_context *ctx = crtc->ctx;
>>> -struct drm_display_mode *mode = &crtc->base.mode;
>>> +struct drm_display_mode *mode = &crtc->base.state->adjusted_mode;
>>> struct fimd_driver_data *driver_data = ctx->driver_data;
>>> void *timing_base = ctx->regs + driver_data->timing_base;
>>> u32 val, clkdiv;
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>> index b1180fb..01d2918 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>> @@ -92,11 +92,12 @@ void exynos_plane_mode_set(struct drm_plane
>>> *plane, struct drm_crtc *crtc,
>>>uint32_t src_w, uint32_t src_h)
>>> {
>>> struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane);
>>> +struct drm_display_mode *mode = &crtc->state->adjusted_mode;
>>> unsigned int actual_w;
>>> unsigned int actual_h;
>>>
>>> -actual_w = exynos_plane_get_size(crtc_x, crtc_w, crtc->mode.hdisplay);
>>> -actual_h = exynos_plane_get_size(crtc_y, crtc_h, crtc->mode.vdisplay);
>>> +actual_w = exynos_plane_get_size(crtc_x, crtc_w, mode->hdisplay);
>>> +actual_h = exynos_plane_get_size(crtc_y, crtc_h, mode->vdisplay);
>>>
>>> if (crtc_x < 0) {
>>> if (actual_w)
>>> @@ -132,10 +133,10 @@ void exynos_plane_mode_set(struct drm_plane
>>> *plane, struct drm_crtc *crtc,
>>> exynos_plane->crtc_height = actual_h;
>>>
>>> /* set drm mode data. */
>>> -exynos_plane->mode_width = crtc->mode.hdisplay;
>>> -exynos_plane->mode_height = crtc->mode.vdisplay;
>>> -exynos_plane->refresh = crtc->mode.vrefresh;
>>> -exynos_plane->scan_flag = crtc->mode.flags;
>>> +exynos_plane->mode_width = mode->hdisplay;
>>> +exynos_plane->mode_height = mode->vdisplay;
>>> +exynos_p
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
>
> 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.
Below is the result from checkpatch.pl. Please fix all errors and check
your patch with checkpatch.pl before posting it.
Thanks,
Inki Dae
total: 62 errors, 0 warnings, 410 lines checked
>
> Signed-off-by: Gustavo Padovan
> ---
> 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);
>
> 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);
> + decon_disable(ctx->crtc);
>
>
Re: [PATCHv3] ARM: dts: add exynos5422-cpus.dtsi to correct cpu order
W dniu 02.06.2015 o 12:29, Peter Chubb pisze: >> "Chanho" == Chanho Park writes: > > Chanho> The odroid-xu3 board which is based on exynos5422 not > Chanho> exynos5800 is booted from cortex-a7 core unlike > Chanho> exynos5800. The odroid-xu3's cpu order is quite strange. cpu0 > Chanho> and cpu5-7 are cortex-a7 cores and cpu1-4 are cortex-a15 > Chanho> cores. To correct this mis-odering, I added exynos5422.dtsi > Chanho> and reversing cpu orders from exynos5420. Now, cpu0-3 are > Chanho> cortex-a7 and cpu4-7 are cortex-a15. > > Does this patch make any difference? CPUs are numbered in the kernel > in the order they're enumerated; with this patch or using the old dts > I see the CPUs numbered the same after boot. And only 5 of the 8 come > up: processor 0 is an A7; processors 1 through 4 are A15. In my case (Odroid XU3 Lite, next-20150529) the patch makes difference. The A7 is 0-3 and A15 is 4-7 so the patch changes the order. 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
[PATCH v3] clocksource: exynos_mct: fix for sleeping in atomic ctx handling cpu hotplug notif.
This is to fix an issue of sleeping in atomic context when processing
hotplug notifications in Exynos MCT(Multi-Core Timer).
The issue was reproducible on Exynos 3250 (Rinato board) and Exynos 5420
(Arndale Octa board).
Whilst testing cpu hotplug events on kernel configured with DEBUG_PREEMPT
and DEBUG_ATOMIC_SLEEP we get following BUG message, caused by calling
request_irq() and free_irq() in the context of hotplug notification
(which is in this case atomic context).
root@target:~# echo 0 > /sys/devices/system/cpu/cpu1/online
[ 25.157867] IRQ18 no longer affine to CPU1
...
[ 25.158445] CPU1: shutdown
root@target:~# echo 1 > /sys/devices/system/cpu/cpu1/online
[ 40.785859] CPU1: Software reset
[ 40.786660] BUG: sleeping function called from invalid context at
mm/slub.c:1241
[ 40.786668] in_atomic(): 1, irqs_disabled(): 128, pid: 0, name: swapper/1
[ 40.786678] Preemption disabled at:[< (null)>] (null)
[ 40.786681]
[ 40.786692] CPU: 1 PID: 0 Comm: swapper/1 Not tainted
3.19.0-rc4-00024-g7dca860 #36
[ 40.786698] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[ 40.786728] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[ 40.786747] [] (show_stack) from []
(dump_stack+0x70/0xbc)
[ 40.786767] [] (dump_stack) from []
(kmem_cache_alloc+0xd8/0x170)
[ 40.786785] [] (kmem_cache_alloc) from []
(request_threaded_irq+0x64/0x128)
[ 40.786804] [] (request_threaded_irq) from []
(exynos4_local_timer_setup+0xc0/0x13c)
[ 40.786820] [] (exynos4_local_timer_setup) from []
(exynos4_mct_cpu_notify+0x30/0xa8)
[ 40.786838] [] (exynos4_mct_cpu_notify) from []
(notifier_call_chain+0x44/0x84)
[ 40.786857] [] (notifier_call_chain) from []
(__cpu_notify+0x28/0x44)
[ 40.786873] [] (__cpu_notify) from []
(secondary_start_kernel+0xec/0x150)
[ 40.786886] [] (secondary_start_kernel) from [<40008764>]
(0x40008764)
Solution:
Clockevent irqs cannot be requested/freed every time cpu is
hot-plugged/unplugged as CPU_STARTING/CPU_DYING notifications
that signals hotplug or unplug events are sent with both preemption
and local interrupts disabled. Since request_irq() may sleep it is
moved to the initialization stage and performed for all possible
cpus prior putting them online. Then, in the case of hotplug event
the irq asociated with the given cpu will simply be enabled.
Similarly on cpu unplug event the interrupt is not freed but just
disabled.
Note that after successful request_irq() call for a clockevent device
associated to given cpu the requested irq is disabled (via disable_irq()).
That is to make things symmetric as we expect hotplug event as a next
thing (which will enable irq again). This should not pose any problems
because at the time of requesting irq the clockevent device is not
fully initialized yet, therefore should not produce interrupts at that point.
For disabling an irq at cpu unplug notification disable_irq_nosync() is
chosen which is a non-blocking function. This again shouldn't be a problem as
prior sending CPU_DYING notification interrupts are migrated away
from the cpu.
Fixes: 7114cd749a12 ("clocksource: exynos_mct: use (request/free)_irq calls for
local timer registration")
Signed-off-by: Damian Eppel
Cc:
Reported-by: Krzysztof Kozlowski
Reviewed-by: Krzysztof Kozlowski
Tested-by: Krzysztof Kozlowski
(Tested on Arndale Octa Board)
Tested-by: Marcin Jabrzyk
(Tested on Rinato B2 (Exynos 3250) board)
---
Notes:
Changes since v1:
o added Krzysztof's and Marcin's Reviewed-by / Tested-by
with information about the test HW.
Changes since v2:
o requesting mct_irq already in disabled state instead of
calling disable_irq() right after request_irq().
drivers/clocksource/exynos_mct.c | 43
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/drivers/clocksource/exynos_mct.c b/drivers/clocksource/exynos_mct.c
index 83564c9..c844616 100644
--- a/drivers/clocksource/exynos_mct.c
+++ b/drivers/clocksource/exynos_mct.c
@@ -466,15 +466,12 @@ static int exynos4_local_timer_setup(struct
clock_event_device *evt)
exynos4_mct_write(TICK_BASE_CNT, mevt->base + MCT_L_TCNTB_OFFSET);
if (mct_int_type == MCT_INT_SPI) {
- evt->irq = mct_irqs[MCT_L0_IRQ + cpu];
- if (request_irq(evt->irq, exynos4_mct_tick_isr,
- IRQF_TIMER | IRQF_NOBALANCING,
- evt->name, mevt)) {
- pr_err("exynos-mct: cannot register IRQ %d\n",
- evt->irq);
+
+ if (evt->irq == -1)
return -EIO;
- }
- irq_force_affinity(mct_irqs[MCT_L0_IRQ + cpu], cpumask_of(cpu));
+
+ irq_force_affinity(evt->irq, cpumask_of(cpu));
+ enable_irq(evt->irq);
} else {
enable_percpu_irq(mct_irqs[MCT_L0_IRQ], 0);
}
@@ -487,10 +484,12 @@ static int
Re: [PATCH 00/21] On-demand device registration
On 2 June 2015 at 10:48, Linus Walleij wrote: > On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso > wrote: > >> 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 is pretty cool, but a too local solution to a global problem. > > Deferred probe and initcall reordering, silly as they may seem, > does not require you to use device tree. > > The real solution, which I think I pointed out already when we > added deferred probe, is to put dependency graphs in the drivers By this you mean something like what Thierry suggested here? http://article.gmane.org/gmane.linux.kernel/1774623 > and have the kernel device driver core percolate dependecies by > walking the graph on probing driver, removing driver (usually the > inverse use case), [runtime] suspend and [runtime] resumeing > a driver. Possibly the dependencies will even be different > depending on use case. > > This is what systemd is doing in userspace for starting services: > ask for your dependencies and wait for them if they are not > there. So drivers ask for resources and wait for them. It also > needs to be abstract, so for example we need to be able to > hang on regulator_get() until the driver is up and providing that > regulator, and as long as everything is in slowpath it should > be OK. (And vice versa mutatis mutandis for clk, gpio, pin > control, interrupts (!) and DMA channels for example.) I understood above that you propose probing devices in order, but now you mention that resource getters would block until the dependency is fulfilled which confuses me because if we are probing in order then all dependencies would be fulfilled before the device in question gets probed. > So if this should be solved it should be solved in an abstract way > in the device driver core available for all, then have calls calling > out to DT, ACPI, possibly even PCI or USB (as these > enumerate devices themselves) to obtain a certain > dependency. Yeah, I was planning looking into this now that I got it working with async probing. Thanks, Tomeu > Yours, > Linus Walleij > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/21] On-demand device registration
On Mon, May 25, 2015 at 4:53 PM, Tomeu Vizoso wrote: > 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 is pretty cool, but a too local solution to a global problem. Deferred probe and initcall reordering, silly as they may seem, does not require you to use device tree. The real solution, which I think I pointed out already when we added deferred probe, is to put dependency graphs in the drivers and have the kernel device driver core percolate dependecies by walking the graph on probing driver, removing driver (usually the inverse use case), [runtime] suspend and [runtime] resumeing a driver. Possibly the dependencies will even be different depending on use case. This is what systemd is doing in userspace for starting services: ask for your dependencies and wait for them if they are not there. So drivers ask for resources and wait for them. It also needs to be abstract, so for example we need to be able to hang on regulator_get() until the driver is up and providing that regulator, and as long as everything is in slowpath it should be OK. (And vice versa mutatis mutandis for clk, gpio, pin control, interrupts (!) and DMA channels for example.) So if this should be solved it should be solved in an abstract way in the device driver core available for all, then have calls calling out to DT, ACPI, possibly even PCI or USB (as these enumerate devices themselves) to obtain a certain dependency. Yours, Linus Walleij -- 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: Exynos 5410 support (was [PATCH 6/6] ARM: dts: exynos5420: add sysmmu nodes)
2015-06-02 17:13 GMT+09:00 Ben Gamari : > > > On 06/01/2015 07:51 PM, Krzysztof Kozłowski wrote: >> >> 2015-06-02 4:12 GMT+09:00 Ben Gamari : >> (...) >> >>> Worse, the few patches >>> that have been submitted for the 5410 have languished in queue-purgatory. >> >> What patches do you have in mind? > > Hmm, my apologies; I guess the reference was dropped somewhere. In > particular I was referring to this set[1], which added pinctrl support for > the 5410 and a devicetree for the Odroid XU. Thanks. I will take a look at them. If you have any other stuff which was missed/skipped/ignored, don't hesitate to resend (if you're the author) or ping. Best regards, Krzysztof > Cheers, > > - Ben > > > [1] > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330819.html > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Exynos 5410 support (was [PATCH 6/6] ARM: dts: exynos5420: add sysmmu nodes)
On 06/01/2015 07:51 PM, Krzysztof Kozłowski wrote: 2015-06-02 4:12 GMT+09:00 Ben Gamari : (...) Worse, the few patches that have been submitted for the 5410 have languished in queue-purgatory. What patches do you have in mind? Hmm, my apologies; I guess the reference was dropped somewhere. In particular I was referring to this set[1], which added pinctrl support for the 5410 and a devicetree for the Odroid XU. Cheers, - Ben [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330819.html -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 7/8] mfd: cros_ec: spi: Add a DT property to delay asserting the CS
From: Alexandru M Stan 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 Reviewed-by: Doug Anderson Signed-off-by: Chris Zhong Signed-off-by: Javier Martinez Canillas Tested-by: Heiko Stuebner Acked-by: Lee Jones --- 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 8009c3d87f33..1777916e9e28 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
[PATCH v4 5/8] mfd: cros_ec: add bus-specific proto v3 code
From: Stephen Barber
Add proto v3 support to the SPI, I2C, and LPC.
Signed-off-by: Stephen Barber
Signed-off-by: Javier Martinez Canillas
Tested-by: Heiko Stuebner
Reviewed-by: Gwendal Grignou
Tested-by: Gwendal Grignou
Acked-by: Lee Jones
---
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
#include
#include
#include
@@ -22,6 +23,32 @@
#include
#include
+/**
+ * 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 data length
+* will be at least sizeof(struct ec_host_response)
+*/
+ if (ec_response_i2c->result == EC_RES_INVALID_COMMAND &&
+ ec_response_i2c->packet_length
[PATCH v4 8/8] mfd: cros_ec: spi: Add delay for asserting CS
From: Alexandru M Stan
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
Reviewed-by: Doug Anderson
Signed-off-by: Chris Zhong
Signed-off-by: Javier Martinez Canillas
Tested-by: Heiko Stuebner
Acked-by: Lee Jones
---
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 v4 6/8] mfd: cros_ec: Support multiple EC in a system
From: Gwendal Grignou
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
Reviewed-by: Dmitry Torokhov
Signed-off-by: Javier Martinez Canillas
---
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
#include
-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);
+
+ if (!ec_p.ec_name)
+ ec_p.ec_name = CROS_EC_DEV_NAME;
+
+ err = mfd_add_devices(ec_dev->dev, CROS_EC_DEV_EC_INDEX, &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, CROS_EC_DEV_PD_INDEX,
+ &ec_pd_cell, 1, NULL, ec_dev->irq, NULL);
+ if (err) {
+ dev_err(dev, "failed to add pd ec\n");
+
[PATCH v4 2/8] mfd: cros_ec: rev cros_ec_commands.h
From: Stephen Barber
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
Reviewed-by: Randall Spangler
Signed-off-by: Javier Martinez Canillas
Tested-by: Heiko Stuebner
Reviewed-by: Gwendal Grignou
Tested-by: Gwendal Grignou
Acked-by: Lee Jones
---
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 s0_idx[2][LB_BATTERY_LEVELS]; /* AP is running */
+ uint8_t s3_idx[2][LB_BATTERY_LEVELS]; /* AP is sleeping */
+
+ /* Color palette */
+ struct rgb_s color[8];
[PATCH v4 3/8] 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
Signed-off-by: Javier Martinez Canillas
Tested-by: Heiko Stuebner
Acked-by: Lee Jones
---
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
#include
#include
-#include
-#include
-
-#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",
- msg->command, msg->result);
- return 0;
- }
-}
-EXPORT_SYMBOL(cros_ec_check_result);
-
-int cros_ec_cmd_xfer(struct cros_ec_dev
[PATCH v4 4/8] mfd: cros_ec: add proto v3 skeleton
From: Stephen Barber
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
Signed-off-by: Javier Martinez Canillas
Reviewed-by: Gwendal Grignou
Tested-by: Gwendal Grignou
Tested-by: Heiko Stuebner
Acked-by: Lee Jones
---
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;
+ ec_dev->pkt_xfer = NULL;
ec_dev->cmd_readmem = cros_ec_lpc_readmem;
+ ec_dev->din_size = sizeof(struct ec_hos
[PATCH v4 1/8] 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
Signed-off-by: Javier Martinez Canillas
Tested-by: Heiko Stuebner
Acked-by: Lee Jones
---
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 message %d\n", result);
+ goto exit;
+ }
+
+ result = ec_i2c_parse_re
[PATCH v4 0/8] 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 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. 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 (1): 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 | 4 + 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 | 158 - 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, 1803 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 support to make multiple EC have a different device id and also exposing a per EC character device interface. Patch #7 adds support to the cros_ec_spi driver to specify a delay before receiving SPI transfers to make sure that the EC has already waked up. Since the changes are quite intrusive and affects all ChromeOS EC related drivers, the patches should be merged through the MFD subsystem tree. Best regards, Javier [0]: https://lkml.org/lkml/2015/5/9/73 [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 "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
