test -M exynos -v -s 31 at 29:720x1280 -s 23 at 21:640x480
setting mode 720x1280-60Hz at XR24 on connectors 31, crtc 29
setting mode 640x480-75Hz at XR24 on connectors 23, crtc 21
freq: 60.18Hz
freq: 49.09Hz
I can see 60Hz for FIMD and 49Hz for vidi.
Thanks,
Inki Dae
>
>
> Gustavo
>
273034] [] (__handle_domain_irq) from []
(gic_handle_irq+0x30/0x68)
[ 35.281366] [] (gic_handle_irq) from []
(__irq_svc+0x40/0x74)
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drive
On 2015ë
06ì 09ì¼ 12:45, Hyungwon Hwang wrote:
> FIMC & GSC driver can calculate the offset of planes. So there are
> use cases which IPP receives just one GEM handle of an image with
> multiple plane. This patch extends ipp_validate_mem_node() to validate
> this case.
Applie
On 2015ë
06ì 09ì¼ 12:45, Hyungwon Hwang wrote:
> Config depends on the opreation. So it must be referenced by an
> operation id, not a property id.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: Hyungwon Hwang
> ---
> drivers/gpu/drm/exynos/exynos_drm_ipp.c | 3 +--
&g
zed, but DSI is still turning down. To prevent it,
> DSI must be set by disabled before starting to be turned down, and
> exynos_dsi_host_transfer() must check whether DSI is enabled or not.
Applied.
Thanks,
Inki Dae
>
> Kernel dump:
> [ 4721.351448] Unhandled fault: synchronous
development.
Applied all patches
Thanks,
Inki Dae
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_drv.c | 221
> +++
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 17 ---
> drivers/gpu/drm/exynos/exynos_drm_ipp.c |
On 2015ë
06ì 04ì¼ 05:17, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Check error and call DRM_ERROR if clk_prepare_enable() fails.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/exynos/exy
On 2015ë
06ì 10ì¼ 20:38, Marek Szyprowski wrote:
> Hello,
>
> On 2015-06-10 12:59, Inki Dae wrote:
>> Hi Marek,
>>
>> On 2015ë
06ì 10ì¼ 19:03, Marek Szyprowski wrote:
>>> Hello,
>>>
>>> On 2015-06-01 17:04, Gustavo Padovan wrote:
&g
interrupts = <5 2>;
clock-names = "sysmmu", "master";
clocks = < CLK_SMMU_FIMD0>, < CLK_FIMD0>;
power-domains = <_lcd0>;
#iommu-cells = <0>;
};
in exynos4412-trats2.dts file:
fimd at 11c0 {
status = "okay";
iommu-reserved-mapping = <0x4000 0x4000 0x4000>;
};
Is that all? You would need to share exact guide about iommu enabling to
other people so that they can test atomic feature with iommu.
Thanks,
Inki Dae
>
>> (...)
>
> Best regards
On 2015ë
06ì 10ì¼ 19:42, Inki Dae wrote:
> Hi Gustavo,
>
> On 2015ë
06ì 09ì¼ 23:27, Gustavo Padovan wrote:
>> Hi Inki and Joonyoung,
>>
>> Any comments on this series?
>
> As you may know, I'm reviewing and testing iommu support patch series
> poste
DMA device more sensitive so it seems that hided
issues happen with iommu support. In this time, let's have more reviews.
Look like that now atomic features aren't safe yet.
Thanks,
Inki Dae
>
> 2015-06-03 Gustavo Padovan :
>
>> From: Gustavo Padovan
>>
>> Rename crtc_{
ch series to exynos-drm-next. However, this patch
especially above codes is required for more clean-up. Even though
decon_enable function never return error number, I think its internal
codes should be considered for some exception cases to check where an
error occurred at. So could you post the
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
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
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ì
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 t
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
Hi Gustavo,
On 2015ë
05ì 28ì¼ 05:27, Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-05-27 Inki Dae :
>
>> Hi Gustavo,
>>
>> On 2015ë
05ì 23ì¼ 00:40, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> Run dpms operat
to use atomic_flush callback to enable global dma
like commit callback did. Is there any reason that you don't use
atomic_begin and atomic_flush callbacks?
atomic relevant codes I looked into do as follows,
atomic_begin();
atomic_update(); /* this will call win_commit callback to set a overlay
relevan
> -static void exynos_drm_crtc_prepare(struct drm_crtc *crtc)
> -{
> - /* drm framework doesn't check NULL. */
> + if (exynos_crtc->ops->win_commit)
> + exynos_crtc->ops->win_commit(exynos_crtc, exynos_plane->zpos);
> +
> + if (exynos_crtc->ops->commit)
> + exynos_crtc->ops->commit(exynos_crtc);
crtc commit already was called by mode_set_nofb callback as soon as it
disables crtc and encoder devices so I think unnecessary. Please see the
drm_atomic_helper_commit_modeset_disable function.
<--snip-->
Thanks,
Inki Dae
ptr->npages = npages;
> -
> - pages = drm_calloc_large(npages, sizeof(struct page *));
The declaration to pages isn't needed anymore because you removed it.
> - if (!pages) {
> - DRM_ERROR("failed to allocate pages.\n");
> - ret = -ENOMEM;
> + vec = g2d_userptr->vec = frame_vector_create(npages);
I think you can use g2d_userptr->vec so it seems that vec isn't needed.
> + if (!vec)
> goto err_free;
> - }
>
> - down_read(>mm->mmap_sem);
> - vma = find_vma(current->mm, userptr);
For vma, ditto.
Thanks,
Inki Dae
[--SNIP--]
On 2015ë
05ì 12ì¼ 03:04, Tobias Jakobi wrote:
> Hey Inki,
>
> Inki Dae wrote:
>> On 2015ë
05ì 06ì¼ 21:10, Tobias Jakobi wrote:
>>> The index for the hardware layer is always >=0. Previous
>>> code that also used -1 as special index is now gone.
&g
rm_crtc.h:24:
+ const struct exynos_drm_crtc_ops
*ops,
I modified and merged all patches.
Thanks,
Inki Dae
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
> Changes since v1:
> New patch.
> ---
> drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
> drivers
nos/exynos_mixer.c:336:
+static void mixer_cfg_layer(struct mixer_context *ctx, unsigned int
win, bool enable)
Please check coding style with checkpath.pl before posting it next time.
I modified and merged them.
Thanks,
Inki Dae
>
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/
2015-05-09 21:13 GMT+09:00 Tobias Jakobi :
> Hello Inki,
>
>
> Inki Dae wrote:
>> Hi,
>>
>> 2015-05-09 6:51 GMT+09:00 Tobias Jakobi :
>>> Hello,
>>>
>>> I've tested this on my Hardkernel Odroid-X2 (connected via HDMI to a
>>> 1080
HDMI or FIMD, HDMI and VIDI
together? For this, dts file for X2 should contain their device nodes
and also should be configurated though menuconfig.
>
> Kernel log is 'clean', so the series works fine for me.
>
> You can add my
> Tested-by: Tobias Jakobi
So you didn't test it corre
ll move them to exynos-drm-next if
the issue is resolved.
Thanks,
Inki Dae
>
> 2015-04-30 Gustavo Padovan :
>
>> Hi,
>>
>> Here goes the full support for atomic modesetting on exynos. I've
>> split the patches in the various phases of atomic support.
>>
>> v
2015-05-04 21:43 GMT+09:00 Krzysztof Kozlowski :
> 2015-05-04 20:34 GMT+09:00 Daniel Stone :
>> Hi,
>>
>> On 4 May 2015 at 08:43, Inki Dae wrote:
>>> On 2015ë
05ì 02ì¼ 13:08, Krzysztof Kozlowski wrote:
>>>> Selecting CONFIG_FB_S3C disables CONFIG_D
2015-05-04 20:34 GMT+09:00 Daniel Stone :
> Hi,
>
> On 4 May 2015 at 08:43, Inki Dae wrote:
>> On 2015ë
05ì 02ì¼ 13:08, Krzysztof Kozlowski wrote:
>>> Selecting CONFIG_FB_S3C disables CONFIG_DRM_EXYNOS_FIMD leading to build
>>> error:
>>
>> No
On 2015ë
05ì 02ì¼ 00:56, Krzysztof Kozlowski wrote:
> The platform_device_id is not modified by the driver and core uses it as
> const.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
> 1 file
xynos_drm_crtc *crtc, bool enable);
> +#else
> +static inline void fimd_dp_clock_enable(struct exynos_drm_crtc *crtc, bool
> enable) {};
> +#endif
So above codes are unnecessary. It's really not good to add #ifdef ~ #endif.
Thanks,
Inki Dae
>
> #endif /* _EXYNOS_DRM_FIMD_H_ */
>
Hi Tobias,
To make patch files, you could use below command,
#git format-patch --cover-letter from..to
With this command, a cover file will be created and you could describe
what this patch series mean in the cover file.
Thanks,
Inki Dae
On 2015ë
04ì 30ì¼ 23:56, Tobias Jakobi wrote
so add handling of RGB565 and XRGB1555 to the switch statement and
> exit early if the plane has an unsupported pf.
Applied.
Thanks,
Inki Dae
>
> Partially based on 'drm/exynos: enable/disable blend based on pixel
> format' by Gustavo Padovan .
>
> v2: Use the shorter MXR_FORMAT
plicit memory locations (which is then called NV12M).
>
> This distinction doesn't exist for DRM. A bi-planar format always
> explicitly comes with the information about its two planes (even
> if these planes should be contiguous).
>
For all patches, Applied.
Thanks,
Inki Dae
> Si
>> wondering what the difference between 'enabled' and 'activated' was.
>> Grepping than revealed that nothing was using that field. I didn't check any
>> other fields.
>>
>
> Actually i don't know about activated field but i think maybe activated
> fiel
mipi");
As I mentioned before, this patch makes existing device tree to be
broken so this cannot be merged even though you posted an another patch
which resolves the dt broken issue. That is because each patch shouldn't
incur any problem on working. So it'd be better to integrate this
ready been posted by Daniel Stone,
https://git.kernel.org/cgit/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm-next
Thanks,
Inki Dae
>
> Signed-off by: Marek Szyprowski
> CC: stable at vger.kernel.org # v4.0+
> ---
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +-
> 1 f
that these features are not only safe enough
but also aren't tested yet. So for them, I'd like to have enough times
for the reviews.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit 1d8ac08d498d579aae36221a80b4b724b2f52f39:
Merge tag 'v4.0-rc7
; +drm_plane_force_disable(plane);
>> }
>
> Which tree did you based this code? I've removed all this code in atomic.
> These two pieces of code makes no sense in atomic modesetting, disable would
> be called from the drm atomic core there.
Mr. Gustavo,
Could yo
On 2015ë
04ì 08ì¼ 03:39, Gustavo Padovan wrote:
> Hi Inki,
>
> 2015-04-07 Inki Dae :
>
>> On 2015ë
04ì 07ì¼ 00:44, Inki Dae wrote:
>>> 2015-04-06 19:46 GMT+09:00 Inki Dae :
>>>> On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
>
On 2015ë
04ì 07ì¼ 15:59, Joonyoung Shim wrote:
> It's more reasonable to use src_x and src_y to represent source as
> counterpart of destination(crtc). Already we are using src_width and
> src_height for width and height of source.
1 thourgh 2, Applied.
Thanks,
Inki Dae
>
On 2015ë
04ì 07ì¼ 08:14, Tobias Jakobi wrote:
> Use the correct spelling for 'progressive'.
1 through 3, Applied.
Thanks,
Inki Dae
>
> Reviewed-by: Gustavo Padovan
> Signed-off-by: Tobias Jakobi
> ---
> drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
> d
On 2015ë
04ì 02ì¼ 18:52, Hyungwon Hwang wrote:
> Because the helper function which calls this callback checks whether
> it is registered or not. It is not necessary if it does nothing.
> So it would be better to remove the function for clarity.
Applied.
Thanks,
Inki Dae
>
On 2015ë
04ì 01ì¼ 13:14, Hyungwon Hwang wrote:
>>From the commit "drm/exynos: fix the execution order in FIMD
> initialization" (598285bfdce46d7c47632a2ba4b980f60be4a677), the error
> checking code is removed improperly. This patch fix the regression.
Applied.
Thanks,
reason for this suggested Andrzej Hajda: the DP clock was disabled.
> This clock is required by Display Port and is enabled by bootloader.
> However when FIMD driver probing was deferred, the display power domain
> was turned off. This effectively reset the value of DP clock enable
>
On 2015ë
04ì 07ì¼ 20:57, Hyungwon Hwang wrote:
> This patch adds support for Exynos5433 mipi dsi.
With this and other dsi relevant patches, display doesn't work - the
screen is flickered and booting is halted. I think there is something
you missed. Check it out again.
Thanks,
Inki
use macro, last is to generalize register setting.
Separate them into three patches.
Thanks,
Inki Dae
>
> Signed-off-by: Hyungwon Hwang
> ---
> Changes for v3:
> - Separated from the patch "drm/exynos: dsi: add support for Exynos5433 SoC"
> in version 2.
>
>
k_clk);
> clk_disable_unprepare(dsi->bus_clk);
>
> ret = regulator_bulk_disable(ARRAY_SIZE(dsi->supplies), dsi->supplies);
> @@ -1720,10 +1711,10 @@ static int exynos_dsi_probe(struct platform_device
> *pdev)
> return -EPROBE_DEFER;
>
on invalid buffers
> (wiht no valid gem object handle i.e.).
> Add some basic checks to rule out those potential issues.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: Beata Michalska
> [mszyprow: rebased onto v4.0-rc1 and adapted to recent ipp changes]
> Signed-off-by: Marek
On 2015ë
04ì 07ì¼ 16:06, Inki Dae wrote:
> On 2015ë
04ì 07ì¼ 00:44, Inki Dae wrote:
>> 2015-04-06 19:46 GMT+09:00 Inki Dae :
>>> On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
>>>> From: Gustavo Padovan
>>>>
>>>> Hi,
>&
On 2015ë
04ì 07ì¼ 00:44, Inki Dae wrote:
> 2015-04-06 19:46 GMT+09:00 Inki Dae :
>> On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> Hi,
>>>
>>> Here goes the full support for atomic modesetting on ex
2015-04-06 19:46 GMT+09:00 Inki Dae :
> On 2015ë
04ì 04ì¼ 03:09, Gustavo Padovan wrote:
>> From: Gustavo Padovan
>>
>> Hi,
>>
>> Here goes the full support for atomic modesetting on exynos. I've
>> split the patches in the various phases of atomic s
_runtime_work>
After that, I tested it again without FIMD and the booting is ok. So I
guess that this atomic feature has a bug to FIMD driver.
Thanks,
Inki Dae
>
> Gustavo
> ---
>
> Gustavo Padovan (11):
> drm/exynos: atomic phase 1: use drm_plane_helper_update()
>
> v4 rebases on top of Daniel Stone patch, currently only applied to
> exynos-drm-fixes
Applied.
Thanks,
Inki Dae
>
> Gustavo Padovan (7):
> drm/exynos: fimd: fix alpha setting for XR24 pixel format
> drm/exynos: remove unused exynos_crtc->win_enable() callback
>
ble callback isn't required
for second argument so the build is failed like below,
drivers/gpu/drm/exynos/exynos_hdmi.c: In function 'hdmi_dpms':
drivers/gpu/drm/exynos/exynos_hdmi.c:2131:4: error: too many arguments
to function 'funcs->disable'
do it ASAP.
Thanks,
Inki Dae
[1] [PATCH -v4 0/8] drm/exynos: clean up patches (preparing for atomic)
[2] [PATCH -v2 00/10] drm/exynos: Add atomic modesetting support
On 2015ë
03ì 26ì¼ 20:15, Hyungwon Hwang wrote:
> From: Joonyoung Shim
>
> DECON(Display and Enhancement Controlle
lity of the existing application which uses set_property ioctl
to be broken. Didn't you check my comment?
http://www.spinics.net/lists/dri-devel/msg78852.html
To other Exynos guys,
Is there no any case that the hardware overlay should be configurable?
If no case, I wil
Hi Dave,
In case of exynos DRM, There are a new driver - mic - , new feature support
- atomic modeset/pageflip, and some cleanup for next. I'll have pull
request ASAP.
thanks,
Inki Dae
2015ë
4ì 1ì¼ ììì¼, Dave Airlieëì´ ìì±í
ë©ìì§:
> Hey,
>
> so outstanding n
Hello Javier,
2015-03-27 20:08 GMT+09:00 Javier Martinez Canillas :
> Hello Inki,
>
> On Fri, Mar 27, 2015 at 2:47 AM, Inki Dae wrote:
>>
>> Right, this is not documented but if you have ever checked exynos drm
>> driver tree, then I think you could know how we use
Hi Daniel,
On 2015ë
03ì 26ì¼ 23:48, Daniel Stone wrote:
> Hi Inki,
>
> On Thu, 26 Mar, 2015 at 2:32 PM, Inki Dae wrote:
>> Applied.
>
> Thanks very much.
>
>> Could you use right prefix of the subject like below when you post patch?
>>
&g
On 2015ë
03ì 27ì¼ 09:15, Tobias Jakobi wrote:
> Inki Dae wrote:
>> Hello Javier,
>>
>> Applied.
>>
>> Could you use right prefix of the subject like below when you post patch?
>>
>> 'drm/exynos: ...', not 'drm: Exynos: ...'
>>
>> You
Hello Javier,
Applied.
Could you use right prefix of the subject like below when you post patch?
'drm/exynos: ...', not 'drm: Exynos: ...'
Your email will be filtered from my mailbox if you don't use the right
prefix so I couldn't check and take care of your patch.
Thanks,
Inki Dae
On 2015ë
c_disable,
> + .post_disable = mic_post_disable,
> + .pre_enable = mic_pre_enable,
> + .enable = mic_enable,
> +};
> +
> +int exynos_mic_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct exynos_mic *mic;
> + struct r
sary file not used and fix trivial issues.
Plese, kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit 046d669c62f37323ef0329c41d83a03c06b2087d:
[PATCH] drm/mm: Fix support 4 GiB and larger ranges (2015-03-16 06:28:50
+1000)
are available in
[]
> (gic_handle_irq+0x64/0x6c)
> [1.956165] [] (gic_handle_irq) from []
> (__irq_svc+0x40/0x74)
> [1.963626] Exception stack(0xee901f98 to 0xee901fe0)
> [1.968661] 1f80:
> 0000
> [1.976823] 1fa0: ee901fe8
nel_init_freeable+0x1d4/0x278)
> [1.510787] [] (kernel_init_freeable) from []
> (kernel_init+0xc/0xe8)
> [1.518859] [] (kernel_init) from []
> (ret_from_fork+0x14/0x24)
> [1.526406] Code: e3130004 1a1e e3a06000 eacf (e7f001f2)
> [1.532505] ---[ end trace
On 2015ë
03ì 13ì¼ 03:45, Gustavo Padovan wrote:
> 2015-03-12 Inki Dae :
>
>> On 2015ë
02ì 19ì¼ 22:22, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> Hi,
>>>
>>> Here goes some clean ups to the exynos drivers.
ne 25
testing 100x100 at XR24 overlay plane 26
Still no screen.
Thanks,
Inki Dae
>
>
> Gustavo Padovan (6):
> drm/exynos: remove unused exynos_crtc->win_enable() callback
> drm/exynos: remove struct *_win_data abstraction on planes
> drm/exynos: preset zpos value fo
leaving warning message 'the hardware overlay cannot be
changed to another anymore' when the set_property ioctl is requested by
user-space, and returning just 0?
Thanks,
Inki Dae
> };
>
> static void exynos_plane_attach_zpos_property(struct drm_plane *plane,
> @@ -216,8 +
On 2015ë
03ì 07ì¼ 06:23, Rob Clark wrote:
> Signed-off-by: Rob Clark
Signed-off-by : Inki Dae
Thanks,
Inki Dae
> ---
> drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exyno
ALPHA_REG(0x618) */
+ /* Global Color and Alpha: Set by ALPHA_REG(0x618) */
for all patches - 1 though 17, Signed-off-by : Inki Dae
Thanks,
Inki Dae
>
>
> With best wishes,
> Tobias
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung
RGB order)
AlphaValue [7:0] Global alpha value
So right comment would be "Global Color and Global Alpha".
Thanks,
Inki Dae
> G2D_COEFF_MODE_GB_COLOR,
> /* (1-SRC alpha)/DST Alpha */
> G2D_COEFF_MODE_DISJOINT_S,
>
lease speak up.
>> I doubt you're going to hear anything from Inki Dae.
> Despite that it might sound a bit rude, I sincerely hope that you're
> wrong on this one. I'm would assume that the lack of reply from Inki was
> due to being him busy, rather than ignoring you.
>
I was busy
On 2015ë
03ì 06ì¼ 23:04, Charles Keepax wrote:
> 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 en
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
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 de
On 2015ë
02ì 20ì¼ 19:54, Dan Carpenter wrote:
> of_iomap() doesn't return error pointers, it returns NULL on error.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> b/drivers/gpu/drm/exynos/e
On 2015ë
02ì 18ì¼ 20:17, Andrzej Hajda wrote:
> These files are not used anymore.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_connector.c | 245
> --
> drivers/gpu/drm/exynos/exynos_
y_mode);
>>> + }
>>> +
>>
>> I guess these ugly ifs could be replaced by simple loop:
>> for (i = 0; i < ARRAY_SIZE(decon_ext_porchs); ++i) {
>> if (mode->hdisplay != decon_ext_porchs[i].hdisplay || ...)
>> continue;
>> decon_ext_set_timing(mode, _ext_porchs[i]);
>> break;
>> }
> Ok, Though the number of checks is the same, your code at least looks better.
> :)
>
>> Anyway I have doubts if commit should modify crtc.base.mode I guess
>> better place for it can be in *_fixup callback.
> Inki? What is your suggestion?
Agree with Andrzej. The fixup callback would be a right place to find
a valid mode. By the way, what if mode->hdisplay/vdisplay/vrefresh are
not supported for all DECON_EXT modes?
Thanks,
Inki Dae
It's my mistake. That is just typo so it should be
DRM_EXYNOS7_DECON instead of DRM_EXYNOS7DECON. It would be fixed at RC1.
Thanks for report,
Inki Dae
>
>
> Paul Bolle
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc"
&g
a new display controller dirver, DECON which is a new display
controller of Exynos7 SoC. This device is much different from
FIMD of Exynos4 and Exynos4 SoC series.
Kindly let me know if there is any problem.
Thanks,
Inki Dae
The following changes since commit
On 2015ë
02ì 05ì¼ 16:11, Joonyoung Shim wrote:
> There is a case called disable_plane callback function even if
> plane->crtc is NULL from exynos_drm_encoder_disable and it will cause
> NULL pointer reference error.
Applied. (patch 1 though 4)
Thanks,
Inki Dae
>
> Signed
,
Inki Dae
On 2015ë
02ì 11ì¼ 19:43, Ajay kumar wrote:
> ping.
>
> On Thu, Feb 5, 2015 at 9:24 PM, Ajay Kumar
> wrote:
>> This patch is based on exynos-drm-next branch of Inki Dae's tree at:
>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos
On 2015ë
02ì 10ì¼ 02:07, Gustavo Padovan wrote:
> 2015-02-09 Daniel Stone :
>
>> Hi Inki,
>>
>> On 9 February 2015 at 14:53, Inki Dae wrote:
>>> I'm merging this patch series but I found two issues. One is already
>>> pointed out
e_release_driver) from []
(device_release_driver+0x1c/0x28)
[ 230.996904] [] (device_release_driver) from []
(unbind_store+0x78/0xf8)
[ 231.005240] [] (unbind_store) from []
(kernfs_fop_write+0xb8/0x19c)
[ 231.013223] [] (kernfs_fop_write) from []
(vfs_write+0xa0/0x1ac)
[ 231.020946] [] (vfs_write) from []
(SyS_write+0x44/0x9c)
[ 231.027983] [] (SyS_write) from []
(ret_fast_syscall+0x0/0x34)
[ 231.035523] ---[ end trace 954377a3aab4ab59 ]---
[ 231.042414] lcd0-power-domain: Power-off latency exceeded, new value
201333 ns
This warning would mean a fb object leak and while I have a review, I
couldn't find why it causes the leak.
However, I'd like to merge this patch series this time and fix this
issue at RC for phase 3.
Thanks,
Inki Dae
On 2015ë
02ì 09ì¼ 19:57, Sylwester Nawrocki wrote:
> On 07/02/15 12:53, Inki Dae wrote:
>> This patch fixes the issue that the try to get a phy object is failed
>> to enable mipi phy.
>>
>> System and power management unit registers should be controlled by
>>
This patch removes mipi phy relevant properties from dsim device node
and makes the pmureg device node to be used instead to enable
mipi phy.
Signed-off-by: Inki Dae
---
arch/arm/boot/dts/exynos5420.dtsi |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts
This patch removes mipi phy relevant properties from dsim device node
and makes the pmureg device node to be used instead to enable
mipi phy.
Signed-off-by: Inki Dae
---
arch/arm/boot/dts/exynos3250.dtsi |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts
This patch removes mipi phy relevant properties from dsim device node
and makes the pmureg device node to be used instead to enable
mipi phy.
Signed-off-by: Inki Dae
---
arch/arm/boot/dts/exynos4.dtsi |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts
};
...
};
With above, we will find below message while booting,
can't request region for resource [mem 0x10020710-0x10020717]
Signed-off-by: Inki Dae
---
.../devicetree/bindings/video/exynos_dsim.txt |9 ++--
drivers/gpu/drm/exynos/exynos_drm_dsi.c
This patch series makes syscon framework to be used
instead of phy framework.
For this, I adds syscon support to mipi dsi driver and
the relevant device tree properties to each dtsi files,
Exynos4, Exynos3250 and Exynos5420.
Inki Dae (4):
drm/exynos: dsim: fix to control mipi phy register
] commit abc0b1447d49 ("drm: Perform basic sanity checks on probed modes")
Signed-off-by: Inki Dae
---
arch/arm/boot/dts/exynos4412-trats2.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-
th mode size for display size from
> the mixer_win_commit().
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: Seung-Woo Kim
> ---
> drivers/gpu/drm/exynos/exynos_mixer.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos
r context as an argument in case of
internal functions. Applied.
Thanks,
Inki Dae
>
> It can reduce unnecessary variable declaration.
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/gpu/drm/exynos/exynos_dp_core.c | 14 ---
> drivers/gpu/drm
On 2015ë
01ì 30ì¼ 16:43, Joonyoung Shim wrote:
> We get wrong pipe value for crtc since commit 93bca243ec96 ("drm/exynos:
> remove struct exynos_drm_manager"). We should should increase pipe value
> before call exynos_drm_crtc_create.
Right, applied.
Thanks,
Inki D
On 2015ë
01ì 27ì¼ 20:40, Joonyoung Shim wrote:
> The exynos drm driver has DRIVER_PRIME capability, then it's reasonable
> to support dmabuf as default. Remove DRM_EXYNOS_DMABUF config, it will
> prevent that user selects the option unnecessarily.
Applied two patches, 1 and 2.
Tha
; DRM driver.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/Kconfig | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
> ind
xynos4 based boards.
Picked it up.
Thanks,
Inki Dae.
>
> Suggested-by: Andrzej Hajda
> Reviewed-by: Javier Martinez Canillas
> Tested-by: Javier Martinez Canillas
> Signed-off-by: Marek Szyprowski
> ---
> Documentation/devicetree/bindings/video/exynos_mixer.tx
interfaces to control hdmyphy, one is I2C, other
is APB bus - memory mapped I/O. So this patch makes hdmiphy reset
to be done according to interfaces, I2C or APB bus.
- And add some exception codes.
Please kindly let me know if there is any problem.
Thanks,
Inki Dae
The following
On 2015ë
01ì 12ì¼ 18:12, Kukjin Kim wrote:
> On 01/03/15 15:50, Inki Dae wrote:
>> On 2014ë
11ì 28ì¼ 20:39, Inki Dae wrote:
>>> This patch adds fimd device node which is a display controller
>>> for Exynos3250 Rinato board.
>>
>> Hi Kukjin,
>&g
801 - 900 of 2980 matches
Mail list logo
