f could be accessed by two more devices. So I guess that the
fence_excl could be used for write access(may need buffer sync like
blocking) and read access for the fence_shared(may not need buffer
sync). I'm not sure that I understand these two things correctly so
could you please give me
;flags has FENCE_FLAG_ACCESS_WRITE_BIT as write
operation and then other sides(read or write operation) would wait for
the write operation completion.
And also consumer calls that function with FENCE_FLAG_ACCESS_READ_BIT
so that other consumers could ignore the fence-wait to any read
operations.
T
2013/1/31 Daniel Vetter :
> On Thu, Jan 31, 2013 at 06:32:15PM +0900, Inki Dae wrote:
>> Hi,
>>
>> below is my opinion.
>>
>> > +struct fence;
>> > +struct fence_ops;
>> > +struct fence_cb;
>> > +
>> > +/**
>> > + * s
2013/1/16 Maarten Lankhorst :
> Op 16-01-13 07:28, Inki Dae schreef:
>> 2013/1/15 Maarten Lankhorst :
>>> This type of fence can be used with hardware synchronization for simple
>>> hardware that can block execution until the condition
>>> (dma_buf[offset] -
Hi, thank you for your contribution and the below is my short comments,
2013/10/2 Sean Paul :
> This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
> bridge chip.
>
> Signed-off-by: Sean Paul
> ---
> .../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
> drivers/gpu/d
ree I recommend,
In board dts,
i2c@I2CD000 {
ptn3460_bridge: prn3460-bridge@20 {
...
}
}
fimd@11c0 {
...
output_dev = <&ptn3460_bridge>;
}
With this, I believe that you
2013/10/4 Sean Paul :
> On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae wrote:
>> 2013/10/2 Sean Paul :
>>> This patch adds code to look for the ptn3460 in the device tree file on
>>> exynos initialization. If ptn node is found, the driver will initialize
>>> the p
2013/10/3 Sean Paul :
> On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae wrote:
>> Hi, thank you for your contribution and the below is my short comments,
>>
>> 2013/10/2 Sean Paul :
>>> This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
>>> b
2013/10/4 Sean Paul :
> On Thu, Oct 3, 2013 at 1:18 PM, Inki Dae wrote:
>> 2013/10/4 Sean Paul :
>>> On Thu, Oct 3, 2013 at 10:43 AM, Inki Dae wrote:
>>>> 2013/10/2 Sean Paul :
>>>>> This patch adds code to look for the ptn3460 in the device tree fil
2013/10/4 Sean Paul :
> On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae wrote:
>> 2013/10/3 Sean Paul :
>>> On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae wrote:
>>>> Hi, thank you for your contribution and the below is my short comments,
>>>>
>>>> 20
2013/10/4 Sean Paul :
> On Thu, Oct 3, 2013 at 2:23 PM, Inki Dae wrote:
>> 2013/10/4 Sean Paul :
>>> On Thu, Oct 3, 2013 at 1:39 PM, Inki Dae wrote:
>>>> 2013/10/3 Sean Paul :
>>>>> On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae wrote:
>>>>&
2013/10/4 Olof Johansson :
> On Thu, Oct 3, 2013 at 10:39 AM, Inki Dae wrote:
>> 2013/10/3 Sean Paul :
>>> On Thu, Oct 3, 2013 at 9:55 AM, Inki Dae wrote:
>>>> Can a regulator be used instead of gpio in other board case?
>>>>
>>>
>>> No
2013/10/4 Sean Paul :
> This patch adds code to look for the ptn3460 in the device tree file on
> exynos initialization. If ptn node is found, the driver will initialize
> the ptn3460 driver and skip creating a DP connector (since the bridge
> driver will register its own connector).
>
> Signed-off
2013/10/4 Sean Paul :
> On Thu, Oct 3, 2013 at 10:29 PM, Inki Dae wrote:
>> 2013/10/4 Sean Paul :
>>> This patch adds code to look for the ptn3460 in the device tree file on
>>> exynos initialization. If ptn node is found, the driver will initialize
>>> the p
> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Friday, October 04, 2013 11:17 PM
> To: Inki Dae
> Cc: Kukjin Kim; DRI mailing list; linux-samsung-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kern
> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Saturday, October 05, 2013 12:05 AM
> To: Inki Dae
> Cc: Kukjin Kim; DRI mailing list; linux-samsung-soc; Linux ARM Kernel;
> Linux Kernel Mailing List; linux-...@vger.kernel.org;
> devic
> -Original Message-
> From: Geert Uytterhoeven [mailto:ge...@linux-m68k.org]
> Sent: Thursday, September 05, 2013 5:21 PM
> To: David Herrmann; H. Peter Anvin
> Cc: Inki Dae; David Airlie; Geoff Levand; dri-de...@lists.freedesktop.org;
> linux-fb...@vger.kernel
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Thursday, October 10, 2013 3:29 AM
> To: Inki Dae
> Cc: Olof Johansson; Sean Paul; devicet...@vger.kernel.org; linux-samsung-
> s...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> k
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Thursday, October 10, 2013 6:37 PM
> To: Inki Dae
> Cc: 'Olof Johansson'; 'Sean Paul'; devicet...@vger.kernel.org; linux-
> samsung-...@vger.kernel.org; linux-...@vger.kerne
r:
>
> [6.363842] drm_prime_init_file edc2e5d0
> [6.363994] drm_prime_destroy_file edc2e5d0
> [6.364260] drm_prime_init_file edc2e750
> [8.004837] drm_prime_init_file ee36ded0
>
> Signed-off-by: Mandeep Singh Baines
> CC: Stéphane Marchesin
> CC: Pawel Osciak
> CC
Hi,
2012/9/6 Paul Menzel :
> Dear Inki Dae,
>
>
> Am Donnerstag, den 06.09.2012, 11:35 +0900 schrieb InKi Dae:
>
>> 2012/9/6 Mandeep Singh Baines :
>> > The double invocations are incorrect but seem to be safe so I don't
>> > think this will fix any bug
Applied.
Thanks,
Inki Dae
2012/9/7 Mandeep Singh Baines :
> The double invocations are incorrect but seem to be safe so I don't
> think this will fix any bugs.
>
> Before:
>
> [7.639366] drm_prime_init_file ee3675d0
> [7.639377] drm_prime_init_fil
priv->da_space_size,
> > priv->da_space_order);
> > - if (!mapping)
> > + if (IS_ERR(mapping))
> > return -ENOMEM;
>
> One more fix is needed here.
> -
That doesn't have any meaning we have to use
iommu group feature. I think the implementation should be one more devices
per a group. So I guess a given device object should be wrapped by higher
device object than the given device object. For a good example, you can
refer to intel-iommu.c
> -Original Message-
> From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
> Sent: Tuesday, July 23, 2013 8:00 PM
> To: Inki Dae
> Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
KyongHo;
> Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei
> -Original Message-
> From: Antonios Motakis [mailto:a.mota...@virtualopensystems.com]
> Sent: Tuesday, July 23, 2013 9:05 PM
> To: Inki Dae
> Cc: Linux ARM Kernel; Linux IOMMU; Linux Samsung SOC; kvm-arm; Cho
KyongHo;
> Joerg Roedel; Sachin Kamat; Jiri Kosina; Wei
e determined by type
argument because the definition of 'of_device_id' should be fixed.
So this patch makes 'of_devce_id' definition to be fixed and
only its instance name to be defined by type.
Signed-off-by: Inki Dae
---
include/linux/module.h |2 +-
1 files changed, 1
Hi,
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Uwe Kleine-Konig
> Sent: Monday, April 29, 2013 4:35 PM
> To: Inki Dae
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.ker
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Monday, April 29, 2013 6:52 PM
> To: Inki Dae
> Cc: gre...@linuxfoundation.org; linux-kernel@vger.ker
Applied.
Thanks,
Inki Dae
2013/3/12 Alexandru Gheorghiu :
> Replaced calls to kzalloc followed by memcpy with call to kmemdup.
> Patch found using coccinelle.
>
> Signed-off-by: Alexandru Gheorghiu
> ---
> drivers/gpu/drm/exynos/exynos_drm_vidi.c |6 ++
> 1 file
> -Original Message-
> From: Thomas Meyer [mailto:tho...@m3y3r.de]
> Sent: Tuesday, August 07, 2012 3:57 PM
> To: inki@samsung.com; jy0922.s...@samsung.com; sw0312@samsung.com;
> kyungmin.p...@samsung.com; airl...@linux.ie; dri-
> de...@lists.freedesktop.org; linux-kernel@vger.ker
Checked it out and applied. For ARCH_MULTIPLATFORM support, Such
header files shouldn't be included. And for this, we are planning on
supporting device tree for ipp driver.
Thanks,
Inki Dae
2013/1/22 Arnd Bergmann :
> While the exynos DRM support in principle can work on
> multipl
mode should be physically
contiguous and also maybe OMAP but now dma-mapping framework doesn't
guarantee physically continuous memory allocation so this patch set
would make it possible.
Tested-by: Inki Dae
Reviewed-by: Inki Dae
Thanks,
Inki Dae
> Best regards
> --
> Marek
Hi Hiroshi,
2012/10/16 Hiroshi Doyu :
> Hi Inki/Marek,
>
> On Tue, 16 Oct 2012 02:50:16 +0200
> Inki Dae wrote:
>
>> 2012/10/15 Marek Szyprowski :
>> > Hello,
>> >
>> > Some devices, which have IOMMU, for some use cases might require to
>&g
Hi Russell,
2012/10/16 Russell King - ARM Linux :
> On Tue, Oct 16, 2012 at 07:12:49PM +0900, Inki Dae wrote:
>> Hi Hiroshi,
>>
>> I'm not sure I understand what you mean but we had already tried this
>> way and for this, you can refer to below link,
>&
Hi Hiroshi,
2012. 10. 16. 오후 11:13 Hiroshi Doyu 작성:
> Hi Inki,
>
> Inki Dae wrote @ Tue, 16 Oct 2012 12:12:49 +0200:
>
>> Hi Hiroshi,
>>
>> 2012/10/16 Hiroshi Doyu :
>>> Hi Inki/Marek,
>>>
>>> On Tue, 16 Oct 2012 02:50:16 +0200
&
elper_signal(struct fence_helper *fh, int id);
- This function is called by device's interrupt handler or somewhere
when dma access to this buffer has been completed and calls
fence_signal() with each fence registed to each reservation object in
fh->entries to notify dma access completion to o
2013/1/16 Maarten Lankhorst :
> Op 16-01-13 07:28, Inki Dae schreef:
>> 2013/1/15 Maarten Lankhorst :
>>> This type of fence can be used with hardware synchronization for simple
>>> hardware that can block execution until the condition
>>> (dma_buf[offset] -
Yeah, forgot this. Merged.
Thanks,
Inki Dae
>
> Changes for V2:
>
> - Checked for rebase 4.12-rc2
>
> Best regards,
> Hoegeun
>
> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/exyno
Hi, Ingi.
Merged. Thanks for your first patch to drm world. :)
This patch isn't trivial so will go to next.
Thanks,
Inki Dae
2015년 10월 02일 17:59에 Ingi Kim 이(가) 쓴 글:
> This patch fixes spelling errors in drm fimc/gsc
> inavild -> invaild
>
> Signed-off-by: Ingi Kim
>
2018년 07월 25일 17:11에 Andrzej Hajda 이(가) 쓴 글:
> On 24.07.2018 09:49, Inki Dae wrote:
>> Hi,
>>
>> 2018년 06월 19일 17:19에 Maciej Purski 이(가) 쓴 글:
>>> When adding support for peripheral out bridges, the "bridge" name
>>> becomes imprecise as it refe
2018년 01월 09일 19:56에 Maxime Ripard 이(가) 쓴 글:
> Now that the core has a drm format helper to tell if a format embeds an
> alpha component in it, let's use it.
>
> Cc: Inki Dae
> Cc: Joonyoung Shim
> Cc: Kyungmin Park
> Cc: Seung-Woo Kim
> Signed-off-by: Maxim
maphore _before_ calling the
> cache flushing function (__do_cache_op()).
>
> The point is that if __do_cache_op() faults, it will enter
> do_page_fault(), which will try to take the mmap_sem again, causing
> a deadlock.
I'm not sure but seems this patch tries to do cache-flush only in-memory pages.
So I think the page fault wouldn't happen becasue flush_cache_user_range
function returns always 0.
Thanks,
Inki Dae
>
Hi Sylwester,
2018년 03월 09일 20:52에 Sylwester Nawrocki 이(가) 쓴 글:
> Hi Inki,
>
> On 03/09/2018 03:40 AM, Inki Dae wrote:
>> 2018년 03월 08일 02:27에 Sylwester Nawrocki 이(가) 쓴 글:
>>> This property is required for specifying link between the HDMI IP block
>>&
operty to hdmi device node which is bound by HDMI driver
of Exynos DRM. As we talked about this at other email thread, seems this
property is required mandatorily for Odroid XU3/4 board which uses Exynos5422.
There may be something I'm missing so could you let me know how this property
is required?
Thanks,
Inki Dae
> status = "disabled";
> };
>
>
or 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
> register.
;static"
when defining of_graph_get_endpoint_by_regs function,
a0f7001c18ca ("of: add helper for getting endpoint node of specific
identifiers")
For this, I will fix and post it soon.
Thanks,
Inki Dae
>
> drivers/media/i2c/adv7604.o: In function `of_graph_get_endpoint_by_
1). I have used the patch from Inki for today.
As you know, I posted below patch which fixes the build error,
[PATCH] of: fix a build error to f_graph_get_endpoint_by_regs function
However, I think we need Acked-by from device tree maintainer to merge
it to drm-next.
Thanks,
Inki Dae
On 2015년 06월 24일 10:21, Inki Dae wrote:
> Hi Dave and Stephen,
>
> On 2015년 06월 24일 10:01, Stephen Rothwell wrote:
>> Hi Dave,
>>
>> On Tue, 23 Jun 2015 11:52:45 +1000 Stephen Rothwell
>> wrote:
>>>
>>> After merging the drm-exynos tree, today&
ynos_drm_gem_obj' may be mapped to multiple
> user-space VMAs so 'vma' field does not look useful anyway.
Krzysztof,
The vma member would be removed by below patch,
http://lists.freedesktop.org/archives/dri-devel/2015-May/082764.html
Thanks,
Inki Dae
>
> Signed-off-by:
On 2015년 06월 19일 14:46, Krzysztof Kozlowski wrote:
> 2015-06-19 14:28 GMT+09:00 Inki Dae :
>> On 2015년 06월 19일 14:23, Krzysztof Kozlowski wrote:
>>> The field 'vma' of 'exynos_drm_gem_obj' structure was introduced in
>>> 2a3098ff6c21 ("drm
served field.
>
> I noticed an extra bug while testing it, but the bug also hits upstream,
> and should be backported all the way down all stable/LTS versions.
> So, I'll send it the usual way, after merging upsream.
Really thanks for doing this. :) There would be many users who
2018년 03월 29일 13:25에 Greg KH 이(가) 쓴 글:
> On Thu, Mar 29, 2018 at 08:22:08AM +0900, Inki Dae wrote:
>> Really thanks for doing this. :) There would be many users who use
>> Linux-3.18 for their products yet.
>
> For new products? They really should not be. The kernel is
2018년 03월 29일 16:00에 Greg KH 이(가) 쓴 글:
> On Thu, Mar 29, 2018 at 03:39:54PM +0900, Inki Dae wrote:
>> 2018년 03월 29일 13:25에 Greg KH 이(가) 쓴 글:
>>> On Thu, Mar 29, 2018 at 08:22:08AM +0900, Inki Dae wrote:
>>>> Really thanks for doing this. :) There would be many use
20. 5. 21. 오후 11:22에 Tamseel Shams 이(가) 쓴 글:
> platform_get_irq() will call dev_err() itself on failure,
> so there is no need for the driver to also do this.
> This is detected by coccinelle.
Picked it up.
Thanks,
Inki Dae
>
> Signed-off-by: Tamseel Shams
> ---
&g
Hi Tamseel,
Same patch[1] has been merged. So could you re-post this patch after rebasing
it on top of exynos-drm-next branch?
After rebase, only g2d part would be valid.
Thanks,
Inki Dae
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git/commit/?h=exynos-drm-next&am
nos_mixer.o: in
> function `mixer_bind':
> exynos_mixer.c:(.text+0x958): undefined reference to `clk_set_parent'
>
> Reported-by: kernel test robot
> Signed-off-by: Krzysztof Kozlowski
Picked it up.
Thanks,
Inki Dae
> ---
> drivers/gpu/drm/exynos/Kconfig
Applied.
Thanks,
Inki Dae
2014-03-17 12:28 GMT+09:00 Daniel Kurtz :
> The following commit [0] fixed a use-after-free, but left the subdrv open
> in the error path.
>
> [0] commit 6ca605f7c70895a35737435f17ae9cc5e36f1466
> drm/exynos: Fix freeing issues in exynos_drm_drv.
2014-03-18 14:45 GMT+09:00 Kukjin Kim :
> Inki Dae wrote:
>>
>> Applied.
>>
>> Thanks,
>> Inki Dae
>>
>> 2014-03-17 12:28 GMT+09:00 Daniel Kurtz :
>> > The following commit [0] fixed a use-after-free, but left the subdr
Hi Tomasz,
I have merged the re-factoring patch set from Sean Paul. Can you
re-base your patch set at top of exynos-drm-next?
Thanks,
Inki Dae
2013/10/21 Tomasz Stanislawski :
> This patchset adds support for HDMI at SoCs from Exynos4 family. The patches
> are rebased on kisho
2013/10/29 Kukjin Kim :
> On 10/28/13 06:42, Inki Dae wrote:
>>
>> Hi Tomasz,
>>
>> I have merged the re-factoring patch set from Sean Paul. Can you
>> re-base your patch set at top of exynos-drm-next?
>>
> Basically, RFC is not patch for merge. So To
On 2014년 07월 21일 18:23, Andrzej Hajda wrote:
> Hi Inki,
>
> On 07/09/2014 04:47 PM, Inki Dae wrote:
>> On 2014년 07월 03일 22:10, Andrzej Hajda wrote:
>>> This set of independent patches contains various improvement and fixes
>>> for exynos_drm ipp framework.
>&g
ied all patches except patch #5. As of now, it seems good to merge
also patch #5 if you couldn't post next version of that patch until the
end of this week. In this case, I will have a pull request including
that patch so that we can fix it up correctly later. Give me your
opinion if there is other
nup of crtcs to core,
> this way planes and crtcs are cleaned in correct order.
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi Inki, Joonyoung,
>
> This is 2nd version of the patch with addressed comments of Joonyoung.
Picked it up.
Thanks,
Inki Dae
>
> Regards
2014-09-20 1:04 GMT+09:00 Inki Dae :
> 2014-09-19 21:58 GMT+09:00 Andrzej Hajda :
>> The patch replaces legacy functions
>> drm_plane_init() / drm_crtc_init() with
>> drm_universal_plane_init() and drm_crtc_init_with_planes().
>> It allows to replace fake prim
he 2nd version of the series I have included changes proposed by
> Joonyoung Shim.
> I have decided to resend whole series because the changes caused merge
> conflicts and
> two separate patches have been added to the series.
> Changes are described in comit messages.
Applied.
Than
rtc = crtc;
> plane->fb = crtc->primary->fb;
> drm_framebuffer_reference(plane->fb);
>
> + if (old_fb)
> + drm_framebuffer_unreference(old_fb);
This time would be a good chance that we can consider drm flip queue to
make sure that who
On 2014년 09월 12일 17:57, Daniel Vetter wrote:
> On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote:
>> Hi Andrzej,
>>
>> On 2014년 09월 09일 22:16, Andrzej Hajda wrote:
>>> Adding reference to framebuffer should be accompanied with removing
>>> reference t
On 2014년 09월 12일 18:27, Andrzej Hajda wrote:
> On 09/12/2014 10:57 AM, Daniel Vetter wrote:
>> On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote:
>>> Hi Andrzej,
>>>
>>> On 2014년 09월 09일 22:16, Andrzej Hajda wrote:
>>>> Adding reference to
On 2014년 09월 12일 20:04, Andrzej Hajda wrote:
> On 09/12/2014 12:45 PM, Inki Dae wrote:
>> On 2014년 09월 12일 18:27, Andrzej Hajda wrote:
>>> On 09/12/2014 10:57 AM, Daniel Vetter wrote:
>>>> On Fri, Sep 12, 2014 at 05:34:50PM +0900, Inki Dae wrote:
>>>>>
, but thank you for your explanation.
>
> Is this limitation exynos4 specific, or does it also apply for the
> exynos5 mixer?
It seems that exynos5260/5420 mixers also have same limitation: SX/Y
fields is 11 bits.
> Was the limitation perhaps the number of bits in the SXY register
&
the
problem more exactly than below one.
http://www.spinics.net/lists/dri-devel/msg58586.html
So picked it up instead of previous one.
Thanks,
Inki Dae
>
> return 0;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
x27;s good report. Applied.
Thanks,
Inki Dae
> The NULL pointer exception may theoretically also happen as a effect of race
> between
> adding components and main driver: if suspend of the driver happens
> before adding components.
>
> Trace:
> [1.190295] [drm] Initiali
ze(&fimd_manager, drm_dev);
And here would be good to call clk_disable_unprepare() and
pm_runtime_put_sync(). Below codes don't access any fimd register. Or
move these function calls into fimd_mgr_initialize().
Thanks,
Inki Dae
> exynos_drm_crtc_create(&fimd_manager);
>
to test this patch series before merging them. Mainline libdrm
has no any ipp interfaces.
Thanks,
Inki Dae
> Regards
> Andrzej
>
>
> Andrzej Hajda (12):
> drm/exynos/ipp: remove type casting
> drm/exynos/ipp: remove unused field from exynos_drm_ipp_private
On 2014년 07월 03일 22:10, Andrzej Hajda wrote:
> This set of independent patches contains various improvement and fixes
> for exynos_drm ipp framework.
> The patchset is based on exynos-drm-next branch.
Applied.
Thanks,
Inki Dae
>
> Regards
> Andrzej
>
>
> Andrzej
On 2014년 05월 19일 19:54, Andrzej Hajda wrote:
> This set of independent patches contains various improvement and fixes
> for exynos_drm ipp framework and drivers.
> The patchset is based on drm-exynos/exynos-drm-next branch.
Thanks for contributions and merged.
Thanks,
Inki Dae
>
nel.org; Sylwester Nawrocki;
> InKi Dae
> Subject: Re: [PATCH] video: exynos_mipi_dsim: Remove unused variable
>
> On Thu, Nov 14, 2013 at 5:32 PM, Greg Kroah-Hartman
> wrote:
> > On Thu, Nov 14, 2013 at 01:09:24PM -0800, Olof Johansson wrote:
> >> commit
*/
> - if (ch_enabled)
> + if (ch_enabled) {
> + state = ctx->suspended;
int state = ctx->suspended;
> + ctx->suspended = 0;
> fimd_wait_for_vblank(mgr);
> + ctx->suspended = state;
> + }
> }
>
> stati
== -EPROBE_DEFER) {
> + return ret;
> + } else {
WARNING: else is not generally useful after a break or return
#146: FILE: drivers/gpu/drm/exynos/exynos_dp_core.c:1208:
+ return ret;
+ } else {
How about just returning ret like
gt; duplication
>> and finally it does not allow to handle more than one device in system.
>> It seems better to embed such structures in private context of the device.
>
> Gently ping.
This patch series already is in exynos-drm-next-todo branch. I will move
it to exynos-drm-n
s device registration
>> related ifdefs to header file.
>>
>> Signed-off-by: Andrzej Hajda
>
> ping
>
Oops, this is one of them I missed. Sorry for this. Can you rebase this
patch on top of exynos-drm-next?. I just had a setup to exynos-drm-next.
Thanks,
In
On 2014년 10월 10일 21:39, Andrzej Hajda wrote:
> On 10/02/2014 12:52 PM, Inki Dae wrote:
>> On 2014년 10월 02일 17:58, Joonyoung Shim wrote:
>>> Hi Andrzej,
>>>
>>> On 10/01/2014 05:14 PM, Andrzej Hajda wrote:
>>>> The patch disables vblanks during dpms
it could attempt to disabling vblank for non-existing crtc,
which in turn, null pointer access occurs.
Thanks,
Inki Dae
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_drv.c | 18 +-
>> 1 file changed, 9 insertions(+), 9 de
On 2014년 10월 08일 00:28, Inki Dae wrote:
>
> Sorry for late.
>
> On 2014년 10월 07일 21:27, Andrzej Hajda wrote:
>> Hi Inki,
>>
>> Gently ping.
>>
>> Andrzej
>>
>>
>> On 09/19/2014 02:57 PM, Andrzej Hajda wrote:
>>> Initialization
ne give me tested-by after test? I cannot test this module
because I have no any board equipped with dp panel.
Jingoo or other?
Thanks,
Inki Dae
>> drivers/gpu/drm/exynos/exynos_dp_core.c | 58
>> +++
>> drivers/gpu/drm/exynos/exynos_dp_core.h |
detest with -v option from second
times.
2. error occurs when we try to test unbind.
Now we are checking these problems. Can you try to also check it?
Thanks,
Inki Dae
>
> Andrzej
>
> On 09/10/2014 01:53 PM, Andrzej Hajda wrote:
>> The patch replaces separate calls to driver (
On 2014년 10월 01일 14:48, Inki Dae wrote:
> On 2014년 09월 30일 20:29, Andrzej Hajda wrote:
>> Hi Inki,
>>
>> Gently ping.
>
> Hi Andrzej,
>
> I merged it to local repository to test. But now exynos drm doesn't work
> correctly since pulling drm-next of Dav
f(crtc); //<- store the latest
vblank frame count.
} else {
drm_crtc_vblank_on(crtc); //<- restore the vblank
frame count.
}
[snip]
}
Tested and worked well with above patch. How about it?
Thanks,
Inki Dae
>
>>From 6de01473746af2
On 2015년 07월 22일 19:08, Inki Dae wrote:
> On 2015년 07월 22일 17:42, Joonyoung Shim wrote:
>> On 07/22/2015 05:22 PM, Inki Dae wrote:
>>> On 2015년 07월 22일 17:12, Joonyoung Shim wrote:
>>>> On 07/22/2015 01:55 PM, Inki Dae wrote:
>>>>> On 2015년 07월 22일 11:0
in Dave's tree) and you should continue your work from there.
Right, I had requested git-pull. Will do re-base on top of Dave's tree.
Thanks,
Inki Dae
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...
e(res, VP_DST_HEIGHT, plane->crtc_height);
>>> ^
>>> drivers/gpu/drm/exynos/exynos_mixer.c:472:27: error: 'struct
>>> exynos_drm_plane' has no member named 'mode_height'
>>> mixer_cfg_scan(ctx, plane-
h_device_if_possible and then we can remove
>> drm_iommu_attach_device_if_possible and clear_channels function pointer.
>>
>> Signed-off-by: Joonyoung Shim
>> Tested-by: Marek Szyprowski
>> Signed-off-by: Inki Dae
>>
>> :04 04 8337
On 2015년 07월 22일 17:12, Joonyoung Shim wrote:
> On 07/22/2015 01:55 PM, Inki Dae wrote:
>> On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
>>> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
>>>> Hi,
>>>>
>>>> Today's linux-next (
On 2015년 07월 22일 17:42, Joonyoung Shim wrote:
> On 07/22/2015 05:22 PM, Inki Dae wrote:
>> On 2015년 07월 22일 17:12, Joonyoung Shim wrote:
>>> On 07/22/2015 01:55 PM, Inki Dae wrote:
>>>> On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
>>>>> On 07/21/2015 1
I can prepare similar patches for other Exynos
> DRM components.
Sorry for late. Applied. Can you prepare similar patches for other? If
so, I'd happy.
Thanks,
Inki Dae
>
> [1]: https://lkml.org/lkml/2014/9/22/148
>
> Regards
> Andrzej
>
>
> Andrzej Hajda (4):
&g
On 2014년 11월 12일 18:42, Vivek Gautam wrote:
> Now that we have moved to generic phy based bindings,
> we don't need to have any code related to older dptx-phy.
> Nobody is using this dptx-phy anymore, so removing the
> same.
Applied.
Thanks,
Inki Dae
>
> Signed-off-by: V
7;omapdrm'...failed.
trying to open device 'exynos'...success.
setting mode 720x1280-0Hz@XR24 on connectors 15, crtc 12
select timed out or error (ret 0)
I'm not sure why this issue is incurred with this patch even through
this patch is reasonable and correct. So we need more che
d to turn on because of system resume in progress.
>
> Forcing mode should not be needed and removing it solves this particular
> problem.
only this patch, Applied.
Thanks,
Inki Dae
>
> This necessary fix for following scenario reproduced on Exynos DRM:
> 1. Power domain is of
>> __driver_attach+0x48/0x98
>
>
> This is caused by patch moving platform devices to
> /sys/devices/platform[1]. Since this patch registering platform
> drivers/devices in probe of platform device causes deadlocks. I guess
> now all driver registration should be moved t
1 - 100 of 184 matches
Mail list logo
