Re: [GIT PULL 2/2] Samsung fixes-2 for v4.0
On Fri, Mar 06, 2015 at 07:16:53PM +0900, Kukjin Kim wrote: > Arnd Bergmann wrote: > > > + Eduardo > > Hi Arnd, > > > On Tuesday 03 March 2015 04:00:14 Kukjin Kim wrote: > > > Please pull Samsung tmu and hdmi regression fixes for v4.0 and I know > > > this is quite big for fixes but I couldn't handle this series for > > > previous merge window because of dependency with driver side...sorry for > > > that and please pull so that we could support them in v4.0 on exynos > > > platforms. > > > > What kind of dependency do you have there? It really should not be > > necessary to wait for driver changes, unless you do an incompatible > > DT binding change, which you should avoid. > > > For TMU patches, I've asked Eduardo to provide topic branch for > 'include/dt-bindings/thermal/thermal_exynos.h' has been added via thermal tree > because if I can't apply the patch in Samsung tree for arm-soc, kernel build > breakage will be happened. But I couldn't get Eduardo's topic branch. Specifically, the developer, while migrating the driver to support DT and OF thermal, decided to create a header with constants. The header is used by DT files and the driver code. The header was the dependency. BR, Eduardo Valentin > > http://www.spinics.net/lists/linux-samsung-soc/msg41877.html > > > For HDMI patches, I thought the DT changes have a dependency with "drm/exynos: > add support for 'hdmi' clock" so waited for its applying then in drm tree. But > I couldn't send it to arm-soc after that... > > http://www.spinics.net/lists/linux-samsung-soc/msg42173.html > > > I asked about the situation (late DT changes?) when I sent a pull-request, > then > I couldn't get a access my kernel.org because of biz. trip to China :( > > http://www.spinics.net/lists/linux-samsung-soc/msg42235.html > > > > I've pulled it into fixes, but won't forward it until I hear a > > good explanation. > > > As you know, basically I tried to make a clear branch for pull-request but in > that case, I couldn't find a solution. Sorry for the inconvenience. > > I hope v4.0 can support them properly. > > Thanks, > Kukjin > signature.asc Description: Digital signature
Re: [PATCH 05/10] ARM: s3c64xx: enable sparse IRQ support
On Mon, Mar 02, 2015 at 01:35:58PM +0100, Arnd Bergmann wrote: > This is another prerequisite for enabling multiplatform > support, and it is the part I am least certain about. > > I assume it will cause the extra boot message "Cannot > allocate irq_descs @ IRQ%d, assuming pre-allocated" to > be printed, but otherwise work ok. This definitely needs > to be tested on real hardware to see if it works. > > Signed-off-by: Arnd Bergmann > --- This one appears to cause some problems with the IRQs on Cragganmore, I need to look into it a bit more but it looks like one of the PMICs can't allocate its IRQs: [0.961455] wm831x 1-0034: WM8311 revision C [0.965066] wm831x 1-0034: Failed to allocate IRQs: -17 And the CODEC can't request its IRQ: [4.252735] arizona spi0.1: WM5102 revision C [4.269763] arizona spi0.1: Failed to request primary IRQ 263: -22 Hopefully I can look into this a little more next week. Thanks, Charles -- 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/1] ARM: exynos_defconfig: Disable IOMMU support
Hello Inki, On 03/06/2015 02:32 PM, Inki Dae wrote: >> >> Another interesting data point is that the error in next-20150303 for >> these 2 boards was the NULL pointer dereference in exynos_plane_destroy >> that I got with 4.0-rc2 (when IOMMU is disabled) in Snow and Peach Pit. > > I think the NULL pointer dereference issue may be fixed with below patch > I merged to exynos-drm-fixes just a while ago, > https://lkml.org/lkml/2015/2/17/434 > > Could you test it with this patch again? > Thanks, I tested v4.0-rc2 + the patch to disable IOMMU + the patch you mentioned and the crash does not happen anymore in Peach Pit and Snow. >> >> Another thing that may be useful to detect these issues early is to have >> exynos-drm-next be pulled by linux-next since otherwise the integration >> is not tested until the changes are picked by the DRM maintainer. >> I know that I may sound like a broken record but could you please make sure that your tree is included in linux-next? That way the fix could be tested by all the machines that are testing linux-next daily since right now Exynos will still be broken until you send a pull request to the DRM maintainer. So it would be nice to get the changes as soon as possible into -next to avoid a recurrent error to mask other possible new issues. 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] drm/exynos: Check for NULL dereference of crtc
On Fri, Mar 06, 2015 at 10:13:42PM +0900, Inki Dae wrote: > On 2015년 02월 18일 02:14, Charles Keepax wrote: > > The commit "drm/exynos: remove exynos_plane_dpms" (d9ea6256) removed the > > use of the enabled flag, which means that the code may attempt to call > > win_enable on a NULL crtc. This results in the following oops on > > Hmm... it's strange. plane->funcs->destroy() is called prior to > crtc->funcs->destroy() so it should be exynos_crtc is not NULL. However, > it seems there is any corner case we didn't catch up. > > Applied. Thanks, it seems the offending path in an error path, looks like Arndale is missing some required DT setting which causes exynos_drm_load to fail: [1.638109] of_graph_get_next_endpoint(): no port node found in /dp-controller@145B [1.646424] exynos-drm exynos-drm: bound 1440.fimd (ops fimd_component_ops) [1.652704] /dp-controller@145B: could not find display-timings node [1.659323] /dp-controller@145B: no timings specified [1.664709] [drm:exynos_dp_bind] *ERROR* failed: of_get_videomode() : -22 [1.671485] exynos-drm exynos-drm: failed to bind 145b.dp-controller (ops exynos_dp_ops): -22 Which ends up calling exynos_plane_destroy as part of the clean up: [1.698655] [] (unwind_backtrace) from [] (show_stack+0x20/0x24) [1.706385] [] (show_stack) from [] (dump_stack+0x78/0xc4) [1.713588] [] (dump_stack) from [] (exynos_disable_plane+0x2c/0x60) [1.721660] [] (exynos_disable_plane) from [] (exynos_plane_destroy+0x1c/0x30) [1.730605] [] (exynos_plane_destroy) from [] (drm_mode_config_cleanup+0x168/0x20c) [1.739982] [] (drm_mode_config_cleanup) from [] (exynos_drm_load+0xac/0x12c) [1.748832] [] (exynos_drm_load) from [] (drm_dev_register+0xb0/0x110) [1.757075] [] (drm_dev_register) from [] (drm_platform_init+0x50/0xe0) [1.765405] [] (drm_platform_init) from [] (exynos_drm_bind+0x20/0x28) [1.773655] [] (exynos_drm_bind) from [] (try_to_bring_up_master.part.1+0xd8/0x114) [1.783027] [] (try_to_bring_up_master.part.1) from [] (component_master_add_with_match+0xb4/0x134) [1.793792] [] (component_master_add_with_match) from [] (exynos_drm_platform_probe+0xfc/0x124) [1.804207] [] (exynos_drm_platform_probe) from [] (platform_drv_probe+0x58/0xb4) [1.813411] [] (platform_drv_probe) from [] (driver_probe_device+0x11c/0x23c) [1.822261] [] (driver_probe_device) from [] (__driver_attach+0x9c/0xa0) [1.830679] [] (__driver_attach) from [] (bus_for_each_dev+0x64/0x98) [1.838838] [] (bus_for_each_dev) from [] (driver_attach+0x2c/0x30) [1.846824] [] (driver_attach) from [] (bus_add_driver+0xe8/0x1e4) [1.854722] [] (bus_add_driver) from [] (driver_register+0x88/0x104) [1.862794] [] (driver_register) from [] (__platform_driver_register+0x58/0x6c) [1.871827] [] (__platform_driver_register) from [] (exynos_drm_init+0xc8/0x124) [1.880936] [] (exynos_drm_init) from [] (do_one_initcall+0x90/0x1e0) [1.889096] [] (do_one_initcall) from [] (kernel_init_freeable+0x114/0x1e0) [1.897779] [] (kernel_init_freeable) from [] (kernel_init+0x18/0xfc) [1.905934] [] (kernel_init) from [] (ret_from_fork+0x14/0x34) Hope that helps some, afraid I am not really familiar enough with the graphics stack to chase that down much more though. Thanks, Charles -- 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: fix typo config name correctly.
This patch fixes DRM_EXYNOS7DECON to DRM_EXYNOS7_DECON. 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 a5e7461..0a67803 100644 --- a/drivers/gpu/drm/exynos/Kconfig +++ b/drivers/gpu/drm/exynos/Kconfig @@ -50,7 +50,7 @@ config DRM_EXYNOS_DSI config DRM_EXYNOS_DP bool "EXYNOS DRM DP driver support" - depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS7DECON) && ARCH_EXYNOS && (DRM_PTN3460=n || DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS) + depends on (DRM_EXYNOS_FIMD || DRM_EXYNOS7_DECON) && ARCH_EXYNOS && (DRM_PTN3460=n || DRM_PTN3460=y || DRM_PTN3460=DRM_EXYNOS) default DRM_EXYNOS select DRM_PANEL help -- 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/1] ARM: exynos_defconfig: Disable IOMMU support
Hi all,
On 2015년 03월 04일 19:24, Javier Martinez Canillas wrote:
> +Gustavo which has been looking at the issues
>
> Hello,
>
> On 03/04/2015 09:50 AM, Marek Szyprowski wrote:
>> Hello,
>>
>> On 2015-03-03 21:36, Kevin Hilman wrote:
>>> Javier Martinez Canillas writes:
>>>
Enabling Exynos DRM IOMMU support for Exynos is currently broken and
causes a BUG on exynos-iommu driver. This was not an issue since the
options was disabled in exynos_defconfig but after commit 8dcc14f82f06
("drm/exynos: IOMMU support should not be selectable by user"), it is
selected if EXYNOS_IOMMU is enabled which is in exynos_defconfig.
So a kernel built using exynos_defconfig after the mentioned commit
fails to boot [0]. Disable IOMMU support in Exynos defconfig until
things get sorted out.
>>> So some other exynos boards started failing in next-20150303[1], and
>>> appear are DRM failures.
>>>
>>> Interestingly, (re)enabling CONFIG_EXYNOS_IOMMU for these cause things to
>>> work again. Even more intersting, with IOMMU enabled, peach-pi is
>>>
>
> I built both 4.0-rc2 and linux-next (tag next-20150303) with and without
> CONFIG_EXYNOS_IOMMU and boot tested on Snow, Peach Pit and Pi.
>
> We still don't have a Peach Pit hooked in LAVA so I tested it locally
> and pasted the boot logs.
>
> 4.0-rc2 (which has CONFIG_EXYNOS_IOMMU enabled)
> ---
>
> * Snow: NULL pointer dereference at fimd_wait_for_vblank [0]
>
> * Peach Pi: kernel BUG at drivers/iommu/exynos-iommu.c:481 [1]
>
> * Peach Pit: NULL pointer dereference at fimd_wait_for_vblank [2]
>
> 4.0-rc2 + CONFIG_EXYNOS_IOMMU disabled
> --
>
> * Snow: NULL pointer dereference at exynos_plane_destroy [3]
>
> * Peach Pi: no error, kernel booted successfully [4]
>
> * Peach Pit: NULL pointer dereference at exynos_plane_destroy [5]
>
> next-20150303 (which has CONFIG_EXYNOS_IOMMU disabled)
> -
>
> * Snow: no error, kernel booted successfully [6]
> * Peach Pi: no error, kernel booted successfully [7]
> * Peach Pit: no error, kernel booted successfully [8]
>
> next-20150303 + CONFIG_EXYNOS_IOMMU (re)enabled
> ---
>
> Snow: no error, kernel booted successfully [9]
> Peach Pi: no error, kernel booted successfully [10]
> Peach Pit: no error, kernel booted successfully [11]
>
> Is interesting that the only Exynos5 machines that failed to boot in
> next-20150303 were exynos5250-arndale and exynos5422-odroidxu3 [12].
>
> Also, only the exynos5250-arndale failed to boot with next-20150304 [13]
> while exynos5422-odroidxu3 booted successfully and there were no changes
> for the exynos drm driver between next-20150303 and next-20150304.
>
> Another interesting data point is that the error in next-20150303 for
> these 2 boards was the NULL pointer dereference in exynos_plane_destroy
> that I got with 4.0-rc2 (when IOMMU is disabled) in Snow and Peach Pit.
I think the NULL pointer dereference issue may be fixed with below patch
I merged to exynos-drm-fixes just a while ago,
https://lkml.org/lkml/2015/2/17/434
Could you test it with this patch again?
Thanks,
Inki Dae
>
> So it appears the error is not consistent and may be a race condition.
>
>>> I'm starting to think it's the DRM driver that needs to be disabled
>>> until it actually gets some testing, rathre than disabling IOMMU.
>>
>
> It's true that there are a lot of issues with the Exynos DRM driver
> but OTOH those are exposed because the config is enabled by default.
>
> My fear is that if we disable the driver, it could silently break
> and be noticed much later when a user enables the option.
>
>> Well, this only shows that broken patch has been merged to exynos-drm-next
>> kernel tree. I think that we should keep Exynos DRM enabled and give Exynos
>> DRM developers a chance to fix their stuff and then test their stuff.
>>
>
> Agree, hopefully all these issues are sorted out during the -rc cycle but
> if not then I think we would have to disable the driver as Kevin suggests.
>
> Another thing that may be useful to detect these issues early is to have
> exynos-drm-next be pulled by linux-next since otherwise the integration
> is not tested until the changes are picked by the DRM maintainer.
>
>> Best regards
>>
>
> Best regards,
> Javier
>
> [0]: https://lava.collabora.co.uk/scheduler/job/8559/log_file
> [1]: https://lava.collabora.co.uk/scheduler/job/8558/log_file
> [2]: http://hastebin.com/gupoworepa.xml
> [3]: https://lava.collabora.co.uk/scheduler/job/8560/log_file
> [4]: https://lava.collabora.co.uk/scheduler/job/8566/log_file
> [5]: http://hastebin.com/ziyiruretu.xml
> [6]: https://lava.collabora.co.uk/scheduler/job/8570/log_file
> [7]: https://lava.collabora.co.uk/scheduler/job/8571/log_file
> [8]: http://hastebin.com/felopehimi.vhdl
> [9]: https://lava.collabora.co.uk/schedule
Re: [PATCH] drm/exynos: Check for NULL dereference of crtc
On 2015년 02월 18일 02:14, Charles Keepax wrote: > The commit "drm/exynos: remove exynos_plane_dpms" (d9ea6256) removed the > use of the enabled flag, which means that the code may attempt to call > win_enable on a NULL crtc. This results in the following oops on Hmm... it's strange. plane->funcs->destroy() is called prior to crtc->funcs->destroy() so it should be exynos_crtc is not NULL. However, it seems there is any corner case we didn't catch up. Applied. Thanks, Inki Dae > Arndale: > > [1.673479] Unable to handle kernel NULL pointer dereference at virtual > address 0368 > [1.681500] pgd = c0004000 > [1.684154] [0368] *pgd= > [1.687713] Internal error: Oops: 5 [#1] PREEMPT SMP ARM > [1.693012] Modules linked in: > [1.696045] CPU: 1 PID: 1 Comm: swapper/0 Not tainted > 3.19.0-07545-g57485fa #1907 > [1.703524] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) > () > [2.014803] [] (exynos_plane_destroy) from [] > (drm_mode_config_cleanup+0x168/0x20c) > [2.024178] [] (drm_mode_config_cleanup) from [] > (exynos_drm_load+0xac/0x12c) > > This patch adds in a check to ensure exynos_crtc is not NULL before it > is dereferenced. > > Signed-off-by: Charles Keepax > --- > drivers/gpu/drm/exynos/exynos_drm_plane.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c > b/drivers/gpu/drm/exynos/exynos_drm_plane.c > index 2dfb847..78fc0a1 100644 > --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c > +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c > @@ -176,7 +176,7 @@ static int exynos_disable_plane(struct drm_plane *plane) > struct exynos_drm_plane *exynos_plane = to_exynos_plane(plane); > struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(plane->crtc); > > - if (exynos_crtc->ops->win_disable) > + if (exynos_crtc && exynos_crtc->ops->win_disable) > exynos_crtc->ops->win_disable(exynos_crtc, > exynos_plane->zpos); > > -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
Hi, On 03/06/2015 08:40 PM, Mark Rutland wrote: >> CPU0 (boot CPU) is only well working for CPU_OFF. >> But when I try to turn on the CPU0 after CPU_OFF, I failed it. > > That's rather worrying. Can you look into what's going on here? I'd > rather not have dts describing things which are known to be broken. The board dts don't include any node for CPU_ON/OFF. >>> >>> I don't understand. The CPU_ON and CPU_OFF IDs are in the psci node >>> quoted above, and all the CPUs had enable-method = "psci". >> >> I mean that there are not additional dt node except for 'cpu' and 'psci' >> node. > > The psci node and cpu enable-method are sufficient. No other nodes > should be relevant. You're right. > >>> When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup happen. After lockup happen, I cannot use the console. >>> >>> That sounds like a pretty major bug. >>> >>> Are you able to investigate with a hardware debugger? >> >> I can't do because there are not any jtag connector. > > That is very unfortunate. Which PSCI implementation are you using? > Surely whoever developed it has access to debug. Surely they should have > tested this? I just used the lateset Linux 4.0-rc2 for PSCI (arch/arm64/kernel/psci.c) without any modification. Unfortunately, I don't know who is the h/w developer of Exynos5433 SoC. > >>> Do other CPUs eventually log errors regarding the lockup? Or is the >>> machine completely dead from this point on? >> >> I tested CPU0 on/off. When I turn on the CPU0, I fail it. But, kernel just >> show the error log without lockup. >> I gave you wrong infromation about CPU0 off. > > Ok. However that's still a major bug. > > [...] > >>> I take it CPUs boot at EL2? > > Do the CPUs boot at EL1 or EL2? Unfortunately, I cannot check the secure firmware for Exynos5433 SoC. I think that a few SoC provider probably would know it. >>> >>> I guess I asked the wrong question. >>> >>> Do CPUs enter the kernel at EL2 or at EL1? >> >> Could you give me a tip how to check the kernel at EL2 or EL1? > > Hmm... I thought we logged this but it looks like we don't. > > You could hack in a check of is_hyp_mode_available() and > is_hyp_mode_mismatched(). That will tell you if EL2/hyp is available, > and whether all CPUs enter at the same mode (mandatory per the boot > protocol). OK, I'll try it. Thanks, Chanwoo Choi -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] pinctrl: exynos: Add support for Exynos5433
On Tue, Feb 24, 2015 at 3:47 AM, Chanwoo Choi wrote: > This patch adds driver data for Exynos5433 SoC. Exynos5433 includes 228 multi- > functional input/output port pins and 135 memory port pins. There are 41 > general > port groups and 2 memory port groups. > > Cc: Tomasz Figa > Cc: Thomas Abraham > Cc: Linus Walleij > Signed-off-by: Chanwoo Choi > Acked-by: Inki Dae > Acked-by: Tomasz Figa > --- > Changes from v3: > - Rebase it on Linux 4.0-rc1 > - Add acked messgae of Tomasz Figa Already merged v3. Thanks anyway! 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: [PATCH v5 1/9] arm64: dts: exynos: Add dts files for 64-bit Exynos5433 SoC
> CPU0 (boot CPU) is only well working for CPU_OFF. > But when I try to turn on the CPU0 after CPU_OFF, I failed it. > >>> > >>> That's rather worrying. Can you look into what's going on here? I'd > >>> rather not have dts describing things which are known to be broken. > >> > >> The board dts don't include any node for CPU_ON/OFF. > > > > I don't understand. The CPU_ON and CPU_OFF IDs are in the psci node > > quoted above, and all the CPUs had enable-method = "psci". > > I mean that there are not additional dt node except for 'cpu' and 'psci' node. The psci node and cpu enable-method are sufficient. No other nodes should be relevant. > > > >> When I try to turn on the CPU0 (boot CPU), fail to turn on and lockup > >> happen. > >> After lockup happen, I cannot use the console. > > > > That sounds like a pretty major bug. > > > > Are you able to investigate with a hardware debugger? > > I can't do because there are not any jtag connector. That is very unfortunate. Which PSCI implementation are you using? Surely whoever developed it has access to debug. Surely they should have tested this? > > Do other CPUs eventually log errors regarding the lockup? Or is the > > machine completely dead from this point on? > > I tested CPU0 on/off. When I turn on the CPU0, I fail it. But, kernel just > show the error log without lockup. > I gave you wrong infromation about CPU0 off. Ok. However that's still a major bug. [...] > > I take it CPUs boot at EL2? > >>> > >>> Do the CPUs boot at EL1 or EL2? > >> > >> Unfortunately, I cannot check the secure firmware for Exynos5433 SoC. > >> I think that a few SoC provider probably would know it. > > > > I guess I asked the wrong question. > > > > Do CPUs enter the kernel at EL2 or at EL1? > > Could you give me a tip how to check the kernel at EL2 or EL1? Hmm... I thought we logged this but it looks like we don't. You could hack in a check of is_hyp_mode_available() and is_hyp_mode_mismatched(). That will tell you if EL2/hyp is available, and whether all CPUs enter at the same mode (mandatory per the boot protocol). Thanks, Mark. -- 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: [PATCHv2 2/2] media: s5p-jpeg: add 5420 family support
Hi Andrzej,
On 03/06/2015 11:32 AM, Andrzej Pietrasiewicz wrote:
JPEG IP found in Exynos5420 is similar to what is in Exynos3250, but
there are some subtle differences which this patch takes into account.
Signed-off-by: Andrzej Pietrasiewicz
---
Acked-by: Jacek Anaszewski
.../bindings/media/exynos-jpeg-codec.txt | 2 +-
drivers/media/platform/s5p-jpeg/jpeg-core.c| 59 +++---
drivers/media/platform/s5p-jpeg/jpeg-core.h| 12 +++--
3 files changed, 51 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
index bf52ed4..4ef4563 100644
--- a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
+++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
@@ -4,7 +4,7 @@ Required properties:
- compatible : should be one of:
"samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg",
- "samsung,exynos3250-jpeg";
+ "samsung,exynos3250-jpeg", "samsung,exynos5420-jpeg";
- reg : address and length of the JPEG codec IP register set;
- interrupts : specifies the JPEG codec IP interrupt;
- clock-names : should contain:
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 12f7452..8b0ca2e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -621,6 +621,7 @@ static int s5p_jpeg_to_user_subsampling(struct s5p_jpeg_ctx
*ctx)
return V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY;
return ctx->subsampling;
case SJPEG_EXYNOS3250:
+ case SJPEG_EXYNOS5420:
if (ctx->subsampling > 3)
return V4L2_JPEG_CHROMA_SUBSAMPLING_411;
return exynos3250_decoded_subsampling[ctx->subsampling];
@@ -1142,13 +1143,13 @@ static void jpeg_bound_align_image(struct s5p_jpeg_ctx
*ctx,
w_step = 1 << walign;
h_step = 1 << halign;
- if (ctx->jpeg->variant->version == SJPEG_EXYNOS3250) {
+ if (ctx->jpeg->variant->hw3250_compat) {
/*
* Rightmost and bottommost pixels are cropped by the
-* Exynos3250 JPEG IP for RGB formats, for the specific
-* width and height values respectively. This assignment
-* will result in v4l_bound_align_image returning dimensions
-* reduced by 1 for the aforementioned cases.
+* Exynos3250/compatible JPEG IP for RGB formats, for the
+* specific width and height values respectively. This
+* assignment will result in v4l_bound_align_image returning
+* dimensions reduced by 1 for the aforementioned cases.
*/
if (w_step == 4 && ((width & 3) == 1)) {
wmax = width;
@@ -1384,12 +1385,12 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx *ct,
struct v4l2_format *f)
/*
* Prevent downscaling to YUV420 format by more than 2
-* for Exynos3250 SoC as it produces broken raw image
+* for Exynos3250/compatible SoC as it produces broken raw image
* in such cases.
*/
if (ct->mode == S5P_JPEG_DECODE &&
f_type == FMT_TYPE_CAPTURE &&
- ct->jpeg->variant->version == SJPEG_EXYNOS3250 &&
+ ct->jpeg->variant->hw3250_compat &&
pix->pixelformat == V4L2_PIX_FMT_YUV420 &&
ct->scale_factor > 2) {
scale_rect.width = ct->out_q.w / 2;
@@ -1569,12 +1570,12 @@ static int s5p_jpeg_s_selection(struct file *file, void
*fh,
if (s->target == V4L2_SEL_TGT_COMPOSE) {
if (ctx->mode != S5P_JPEG_DECODE)
return -EINVAL;
- if (ctx->jpeg->variant->version == SJPEG_EXYNOS3250)
+ if (ctx->jpeg->variant->hw3250_compat)
ret = exynos3250_jpeg_try_downscale(ctx, rect);
} else if (s->target == V4L2_SEL_TGT_CROP) {
if (ctx->mode != S5P_JPEG_ENCODE)
return -EINVAL;
- if (ctx->jpeg->variant->version == SJPEG_EXYNOS3250)
+ if (ctx->jpeg->variant->hw3250_compat)
ret = exynos3250_jpeg_try_crop(ctx, rect);
}
@@ -1604,8 +1605,9 @@ static int s5p_jpeg_adjust_subs_ctrl(struct s5p_jpeg_ctx
*ctx, int *ctrl_val)
case SJPEG_S5P:
return 0;
case SJPEG_EXYNOS3250:
+ case SJPEG_EXYNOS5420:
/*
-* The exynos3250 device can produce JPEG image only
+* The exynos3250/compatible device can produce JPEG image only
* of 4:4:4 subsampling when given RGB32 source image.
*/
if (ctx->out_q.fmt->fourcc == V4L2_PIX_FMT_RGB32)
@@ -1624,7 +1626,7 @@ st
[PATCHv2 1/2] ARM: dts: exynos5420: add nodes for jpeg codec
Signed-off-by: Andrzej Pietrasiewicz
---
arch/arm/boot/dts/exynos5420.dtsi | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index 73c1851..f8f583c 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -775,6 +775,22 @@
iommus = <&sysmmu_gscl1>;
};
+ jpeg_0: jpeg@11F5 {
+ compatible = "samsung,exynos5420-jpeg";
+ reg = <0x11F5 0x1000>;
+ interrupts = <0 89 0>;
+ clock-names = "jpeg";
+ clocks = <&clock CLK_JPEG>;
+ };
+
+ jpeg_1: jpeg@11F6 {
+ compatible = "samsung,exynos5420-jpeg";
+ reg = <0x11F6 0x1000>;
+ interrupts = <0 168 0>;
+ clock-names = "jpeg";
+ clocks = <&clock CLK_JPEG2>;
+ };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5420-pmu", "syscon";
reg = <0x1004 0x5000>;
--
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
[PATCHv2 2/2] media: s5p-jpeg: add 5420 family support
JPEG IP found in Exynos5420 is similar to what is in Exynos3250, but
there are some subtle differences which this patch takes into account.
Signed-off-by: Andrzej Pietrasiewicz
---
.../bindings/media/exynos-jpeg-codec.txt | 2 +-
drivers/media/platform/s5p-jpeg/jpeg-core.c| 59 +++---
drivers/media/platform/s5p-jpeg/jpeg-core.h| 12 +++--
3 files changed, 51 insertions(+), 22 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
index bf52ed4..4ef4563 100644
--- a/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
+++ b/Documentation/devicetree/bindings/media/exynos-jpeg-codec.txt
@@ -4,7 +4,7 @@ Required properties:
- compatible : should be one of:
"samsung,s5pv210-jpeg", "samsung,exynos4210-jpeg",
- "samsung,exynos3250-jpeg";
+ "samsung,exynos3250-jpeg", "samsung,exynos5420-jpeg";
- reg : address and length of the JPEG codec IP register set;
- interrupts : specifies the JPEG codec IP interrupt;
- clock-names : should contain:
diff --git a/drivers/media/platform/s5p-jpeg/jpeg-core.c
b/drivers/media/platform/s5p-jpeg/jpeg-core.c
index 12f7452..8b0ca2e 100644
--- a/drivers/media/platform/s5p-jpeg/jpeg-core.c
+++ b/drivers/media/platform/s5p-jpeg/jpeg-core.c
@@ -621,6 +621,7 @@ static int s5p_jpeg_to_user_subsampling(struct s5p_jpeg_ctx
*ctx)
return V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY;
return ctx->subsampling;
case SJPEG_EXYNOS3250:
+ case SJPEG_EXYNOS5420:
if (ctx->subsampling > 3)
return V4L2_JPEG_CHROMA_SUBSAMPLING_411;
return exynos3250_decoded_subsampling[ctx->subsampling];
@@ -1142,13 +1143,13 @@ static void jpeg_bound_align_image(struct s5p_jpeg_ctx
*ctx,
w_step = 1 << walign;
h_step = 1 << halign;
- if (ctx->jpeg->variant->version == SJPEG_EXYNOS3250) {
+ if (ctx->jpeg->variant->hw3250_compat) {
/*
* Rightmost and bottommost pixels are cropped by the
-* Exynos3250 JPEG IP for RGB formats, for the specific
-* width and height values respectively. This assignment
-* will result in v4l_bound_align_image returning dimensions
-* reduced by 1 for the aforementioned cases.
+* Exynos3250/compatible JPEG IP for RGB formats, for the
+* specific width and height values respectively. This
+* assignment will result in v4l_bound_align_image returning
+* dimensions reduced by 1 for the aforementioned cases.
*/
if (w_step == 4 && ((width & 3) == 1)) {
wmax = width;
@@ -1384,12 +1385,12 @@ static int s5p_jpeg_s_fmt(struct s5p_jpeg_ctx *ct,
struct v4l2_format *f)
/*
* Prevent downscaling to YUV420 format by more than 2
-* for Exynos3250 SoC as it produces broken raw image
+* for Exynos3250/compatible SoC as it produces broken raw image
* in such cases.
*/
if (ct->mode == S5P_JPEG_DECODE &&
f_type == FMT_TYPE_CAPTURE &&
- ct->jpeg->variant->version == SJPEG_EXYNOS3250 &&
+ ct->jpeg->variant->hw3250_compat &&
pix->pixelformat == V4L2_PIX_FMT_YUV420 &&
ct->scale_factor > 2) {
scale_rect.width = ct->out_q.w / 2;
@@ -1569,12 +1570,12 @@ static int s5p_jpeg_s_selection(struct file *file, void
*fh,
if (s->target == V4L2_SEL_TGT_COMPOSE) {
if (ctx->mode != S5P_JPEG_DECODE)
return -EINVAL;
- if (ctx->jpeg->variant->version == SJPEG_EXYNOS3250)
+ if (ctx->jpeg->variant->hw3250_compat)
ret = exynos3250_jpeg_try_downscale(ctx, rect);
} else if (s->target == V4L2_SEL_TGT_CROP) {
if (ctx->mode != S5P_JPEG_ENCODE)
return -EINVAL;
- if (ctx->jpeg->variant->version == SJPEG_EXYNOS3250)
+ if (ctx->jpeg->variant->hw3250_compat)
ret = exynos3250_jpeg_try_crop(ctx, rect);
}
@@ -1604,8 +1605,9 @@ static int s5p_jpeg_adjust_subs_ctrl(struct s5p_jpeg_ctx
*ctx, int *ctrl_val)
case SJPEG_S5P:
return 0;
case SJPEG_EXYNOS3250:
+ case SJPEG_EXYNOS5420:
/*
-* The exynos3250 device can produce JPEG image only
+* The exynos3250/compatible device can produce JPEG image only
* of 4:4:4 subsampling when given RGB32 source image.
*/
if (ctx->out_q.fmt->fourcc == V4L2_PIX_FMT_RGB32)
@@ -1624,7 +1626,7 @@ static int s5p_jpeg_adjust_subs_ctrl(struct s5p_jpeg_ctx
*ctx, int *ctrl_val)
}
/*
-
[PATCHv2 0/2] Support for JPEG IP on Exynos542x
This short series adds support for JPEG IP on Exynos542x SoC. The first patch adds necessary device tree nodes and the second one does JPEG IP support proper. The JPEG IP on Exynos542x is similar to what is on Exynos3250, there just slight differences. v1..v2: - implemented changes resulting from Jacek's review - removed iommu entries in device tree nodes as iommu is not available at this moment - added hw3250_compat and htbl_reinit flags to s5p_jpeg_variant, which simplifies the code a bit Andrzej Pietrasiewicz (2): ARM: dts: exynos5420: add nodes for jpeg codec media: s5p-jpeg: add 5420 family support .../bindings/media/exynos-jpeg-codec.txt | 2 +- arch/arm/boot/dts/exynos5420.dtsi | 16 ++ drivers/media/platform/s5p-jpeg/jpeg-core.c| 59 +++--- drivers/media/platform/s5p-jpeg/jpeg-core.h| 12 +++-- 4 files changed, 67 insertions(+), 22 deletions(-) -- 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: [GIT PULL 2/2] Samsung fixes-2 for v4.0
Arnd Bergmann wrote: > + Eduardo Hi Arnd, > On Tuesday 03 March 2015 04:00:14 Kukjin Kim wrote: > > Please pull Samsung tmu and hdmi regression fixes for v4.0 and I know > > this is quite big for fixes but I couldn't handle this series for > > previous merge window because of dependency with driver side...sorry for > > that and please pull so that we could support them in v4.0 on exynos > > platforms. > > What kind of dependency do you have there? It really should not be > necessary to wait for driver changes, unless you do an incompatible > DT binding change, which you should avoid. > For TMU patches, I've asked Eduardo to provide topic branch for 'include/dt-bindings/thermal/thermal_exynos.h' has been added via thermal tree because if I can't apply the patch in Samsung tree for arm-soc, kernel build breakage will be happened. But I couldn't get Eduardo's topic branch. http://www.spinics.net/lists/linux-samsung-soc/msg41877.html For HDMI patches, I thought the DT changes have a dependency with "drm/exynos: add support for 'hdmi' clock" so waited for its applying then in drm tree. But I couldn't send it to arm-soc after that... http://www.spinics.net/lists/linux-samsung-soc/msg42173.html I asked about the situation (late DT changes?) when I sent a pull-request, then I couldn't get a access my kernel.org because of biz. trip to China :( http://www.spinics.net/lists/linux-samsung-soc/msg42235.html > I've pulled it into fixes, but won't forward it until I hear a > good explanation. > As you know, basically I tried to make a clear branch for pull-request but in that case, I couldn't find a solution. Sorry for the inconvenience. I hope v4.0 can support them properly. 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: [GIT PULL 2/2] Samsung fixes-2 for v4.0
Hello Kukjin,
On Fri, Mar 6, 2015 at 10:43 AM, Kukjin Kim wrote:
> Javier Martinez Canillas wrote:
>>
>> Hello Arnd,
>>
> Hi,
>
>> On Thu, Mar 5, 2015 at 12:04 AM, Arnd Bergmann wrote:
>> > On Wednesday 04 March 2015 21:04:40 Arnd Bergmann wrote:
>> >> On Tuesday 03 March 2015 04:00:14 Kukjin Kim wrote:
>> >> > Please pull Samsung tmu and hdmi regression fixes for v4.0 and I know
>> >> > this is quite big for fixes but I couldn't handle this series for
>> >> > previous merge window because of dependency with driver side...sorry for
>> >> > that and please pull so that we could support them in v4.0 on exynos
>> >> > platforms.
>> >>
>> >> What kind of dependency do you have there? It really should not be
>> >> necessary to wait for driver changes, unless you do an incompatible
>> >> DT binding change, which you should avoid.
>> >>
>> >> I've pulled it into fixes, but won't forward it until I hear a
>> >> good explanation.
>> >
>> > Even with both fixes-1 and fixes-2 applied, we still get boot failures
>> > on Exynos:
>> >
>> > http://arm-soc.lixom.net/bootlogs/arm-soc/v4.0-rc2-104-g2ee4716/
>> >
>> > Any idea what is going on?
>> >
>>
>> Yes, the problem is the Exynos DRM driver which has a lot of issues.
>> It's broken if CONFIG_DRM_EXYNOS_IOMMU is enabled which defaults to
>> yes after commit 8dcc14f82f06 ("drm/exynos: IOMMU support should not
>> be selectable by user").
>>
>> I posted a patch to disable IOMMU support on Exynos to avoid these
>> boot failures and also mentioned to Kukjin that it should be a fix for
>> 4.0 [0]. But even with IOMMU disabled, the Exynos DRM is broken in
>> some boards [1] so we may have to disable that driver until everything
>> gets sorted out and is stable again.
>>
> Yes, the fix is in my tree and it will be sent to upstream via arm-soc soon.
>
Thanks a lot for your help. You meant the patch to disable IOMMU
support right? While being there could you please also disable the DRM
driver as discussed since is unlikely that the Exynos DRM maintainers
would be able to sort out all the issues in time for 4.0.
> Thanks,
> Kukjin
>
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 2/2] Samsung fixes-2 for v4.0
Javier Martinez Canillas wrote:
>
> Hello Arnd,
>
Hi,
> On Thu, Mar 5, 2015 at 12:04 AM, Arnd Bergmann wrote:
> > On Wednesday 04 March 2015 21:04:40 Arnd Bergmann wrote:
> >> On Tuesday 03 March 2015 04:00:14 Kukjin Kim wrote:
> >> > Please pull Samsung tmu and hdmi regression fixes for v4.0 and I know
> >> > this is quite big for fixes but I couldn't handle this series for
> >> > previous merge window because of dependency with driver side...sorry for
> >> > that and please pull so that we could support them in v4.0 on exynos
> >> > platforms.
> >>
> >> What kind of dependency do you have there? It really should not be
> >> necessary to wait for driver changes, unless you do an incompatible
> >> DT binding change, which you should avoid.
> >>
> >> I've pulled it into fixes, but won't forward it until I hear a
> >> good explanation.
> >
> > Even with both fixes-1 and fixes-2 applied, we still get boot failures
> > on Exynos:
> >
> > http://arm-soc.lixom.net/bootlogs/arm-soc/v4.0-rc2-104-g2ee4716/
> >
> > Any idea what is going on?
> >
>
> Yes, the problem is the Exynos DRM driver which has a lot of issues.
> It's broken if CONFIG_DRM_EXYNOS_IOMMU is enabled which defaults to
> yes after commit 8dcc14f82f06 ("drm/exynos: IOMMU support should not
> be selectable by user").
>
> I posted a patch to disable IOMMU support on Exynos to avoid these
> boot failures and also mentioned to Kukjin that it should be a fix for
> 4.0 [0]. But even with IOMMU disabled, the Exynos DRM is broken in
> some boards [1] so we may have to disable that driver until everything
> gets sorted out and is stable again.
>
Yes, the fix is in my tree and it will be sent to upstream via arm-soc soon.
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
[alsa-devel] [PATCH] ARM: dts: Support audio on Exynos5422-odroidxu3 using simple-audio-card
Add MAX98090 audio codec, I2S interface and the sound nodes to support
audio on Exynos5422 SoC Based Odroid-XU3 board. Now we can support audio
in Odroid-XU3 board using simple-audio-card DT binding.
Signed-off-by: Inha Song
---
arch/arm/boot/dts/exynos5420.dtsi | 9 +
arch/arm/boot/dts/exynos5422-odroidxu3.dts | 57 ++
2 files changed, 66 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi
index c0e98cf..a70005e 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -411,6 +411,9 @@
<&clock_audss EXYNOS_I2S_BUS>,
<&clock_audss EXYNOS_SCLK_I2S>;
clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
+ #clock-cells = <1>;
+ clock-output-names = "i2s_cdclk0";
+ #sound-dai-cells = <1>;
samsung,idma-addr = <0x0300>;
pinctrl-names = "default";
pinctrl-0 = <&i2s0_bus>;
@@ -425,6 +428,9 @@
dma-names = "tx", "rx";
clocks = <&clock CLK_I2S1>, <&clock CLK_SCLK_I2S1>;
clock-names = "iis", "i2s_opclk0";
+ #clock-cells = <1>;
+ clock-output-names = "i2s_cdclk1";
+ #sound-dai-cells = <1>;
pinctrl-names = "default";
pinctrl-0 = <&i2s1_bus>;
status = "disabled";
@@ -438,6 +444,9 @@
dma-names = "tx", "rx";
clocks = <&clock CLK_I2S2>, <&clock CLK_SCLK_I2S2>;
clock-names = "iis", "i2s_opclk0";
+ #clock-cells = <1>;
+ clock-output-names = "i2s_cdclk2";
+ #sound-dai-cells = <1>;
pinctrl-names = "default";
pinctrl-0 = <&i2s2_bus>;
status = "disabled";
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
index edc25cf..9275ad6 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu3.dts
@@ -11,6 +11,7 @@
*/
/dts-v1/;
+#include
#include "exynos5800.dtsi"
/ {
@@ -285,6 +286,62 @@
rtc@101E {
status = "okay";
};
+
+ sound: sound {
+ compatible = "simple-audio-card";
+ assigned-clocks = <&clock_audss EXYNOS_MOUT_AUDSS>,
+ <&clock_audss EXYNOS_MOUT_I2S>,
+ <&clock_audss EXYNOS_DOUT_AUD_BUS>;
+ assigned-clock-parents = <&clock CLK_FIN_PLL>,
+ <&clock_audss EXYNOS_MOUT_AUDSS>;
+ assigned-clock-rates = <0>,
+ <0>,
+ <1920>;
+
+ simple-audio-card,name = "Odroid-XU3";
+
+ simple-audio-card,widgets =
+ "Headphone", "Headphone Jack",
+ "Speakers", "Speakers";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPL",
+ "Headphone Jack", "HPR",
+ "Headphone Jack", "MICBIAS",
+ "IN1", "Headphone Jack",
+ "Speakers", "SPKL",
+ "Speakers", "SPKR";
+
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <&link0_codec>;
+ simple-audio-card,frame-master = <&link0_codec>;
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s0 0>;
+ system-clock-frequency = <1920>;
+ };
+
+ link0_codec: simple-audio-card,codec {
+ sound-dai = <&max98090>;
+ clocks = <&i2s0 CLK_I2S_CDCLK>;
+ };
+ };
+};
+
+&hsi2c_5 {
+ status = "okay";
+ max98090: max98090@10 {
+ compatible = "maxim,max98090";
+ reg = <0x10>;
+ interrupt-parent = <&gpx3>;
+ interrupts = <2 0>;
+ clocks = <&i2s0 CLK_I2S_CDCLK>;
+ clock-names = "mclk";
+ #sound-dai-cells = <0>;
+ };
+};
+
+&i2s0 {
+ status = "okay";
};
&hdmi {
--
2.0.0.390.gcb682f8
--
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
