Re: [PATCH v7 3/4] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 06일 14:22에 Andi Shyti 이(가) 쓴 글:
> Hi Hoegeun,
> 
>> +static const struct drm_display_mode default_mode = {
>> +.clock = 222372,
>> +.hdisplay = 1440,
>> +.hsync_start = 1440 + 1,
>> +.hsync_end = 1440 + 1 + 1,
>> +.htotal = 1440 + 1 + 1 + 1,
>> +.vdisplay = 2560,
>> +.vsync_start = 2560 + 1,
>> +.vsync_end = 2560 + 1 + 1,
>> +.vtotal = 2560 + 1 + 1 + 15,
>> +.vrefresh = 60,
>> +.flags = 0,
>> +};
> 
> how is this working with tm2e? Are these values valid for both
> the boards?

We don't need to consider tm2e board with two reasones,
1. there is no tm2e board support in mainline
2. the panel on tm2 would be a little bit different from one on tm2e

Thanks,
Inki Dae

> 
> Andi
> 
> 

Re: [PATCH v5 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 05일 15:55에 Andrzej Hajda 이(가) 쓴 글:
> On 04.01.2017 15:44, Rob Herring wrote:
>> On Wed, Jan 04, 2017 at 05:15:10PM +0900, Hoegeun Kwon wrote:
>>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>>> driver. This panel has 1440x2560 resolution in 5.7-inch physical
>>> panel in the TM2 device.
>>>
>>> Signed-off-by: Donghwa Lee 
>>> Signed-off-by: Hyungwon Hwang 
>>> Signed-off-by: Hoegeun Kwon 
>>> ---
>>>  .../bindings/display/panel/samsung,s6e3ha2.txt |  40 ++
>>>  drivers/gpu/drm/panel/Kconfig  |   6 +
>>>  drivers/gpu/drm/panel/Makefile |   1 +
>>>  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 741 
>>> +
>>>  4 files changed, 788 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>>  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
>>> b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>> new file mode 100644
>>> index 000..6879f51
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>> @@ -0,0 +1,40 @@
>>> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
>>> +
>>> +Required properties:
>>> +  - compatible: "samsung,s6e3ha2"
>>> +  - reg: the virtual channel number of a DSI peripheral
>>> +  - vdd3-supply: I/O voltage supply
>>> +  - vci-supply: voltage supply for analog circuits
>>> +  - reset-gpios: a GPIO spec for the reset pin (active low)
>>> +  - enable-gpios: a GPIO spec for the panel enable pin (active high)
>>> +  - te-gpios: a GPIO spec for the tearing effect synchronization signal
>>> +gpio pin (active high)
>>> +
>>> +The device node can contain one 'port' child node with one child
>>> +'endpoint' node, according to the bindings defined in [1]. This
>>> +node should describe panel's video bus.
>>> +
>>> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>> +
>>> +Example:
>>> +
>>> + {
>>> +   ...
>>> +
>>> +   panel@0 {
>>> +   compatible = "samsung,s6e3ha2";
>>> +   reg = <0>;
>>> +   vdd3-supply = <_reg>;
>>> +   vci-supply = <_reg>;
>>> +   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>>> +   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
>>> +   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
>>> +
>>> +   port {
>>> +   panel_in: endpoint {
>>> +   remote-endpoint = <_out>;
>> As I said previously, it makes no sense to have a graph to dsi_out it is 
>> simply the parent node.
> 
> The problem is that exynos_dsi requires presence of endpoint node, when
> it was written the policy was that graphs must be always present.
> DSI reads from this node samsung,burst-clock-frequency and
> samsung,esc-clock-frequency. For example in exynos4412-trats2.dts:
> 
>> dsi_0: dsi@11C8 {
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>  
>> port@1 {
>> reg = <1>;
>>
>> dsi_out: endpoint {
>> remote-endpoint = <_in>;
>> samsung,burst-clock-frequency
>> = <5>;
>> samsung,esc-clock-frequency =
>> <2000>;
>> };
>> };
>> };
>> 
>> panel@0 {
>> ...
>> port {
>> dsi_in: endpoint {
>> remote-endpoint = <_out>;
>> };
>> };
>> };
>> };
> 
> However, DSI driver does not use remote-endpoint property, it is here
> only to fulfill of_graph policy.
> So if something like below is acceptable, we can get rid of port node in
> panel:
> 
>> dsi_0: dsi@11C8 {
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>  
>> port@1 {
>> reg = <1>;
>>
>> dsi_out: endpoint {
>> samsung,burst-clock-frequency
>> = <5>;
>> samsung,esc-clock-frequency =
>> <2000>;
>> };
>> };
>> };
>> 
>> panel@0 {
>> ...
>> };
>> };
> 
> What do you think?
> 
> Other solution is to move problematic properties somewhere else, 

Re: [PATCH v5 2/3] drm/panel: Add support for S6E3HA2 panel driver on TM2 board

[Inki Dae]

2017년 01월 05일 15:55에 Andrzej Hajda 이(가) 쓴 글:
> On 04.01.2017 15:44, Rob Herring wrote:
>> On Wed, Jan 04, 2017 at 05:15:10PM +0900, Hoegeun Kwon wrote:
>>> This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
>>> driver. This panel has 1440x2560 resolution in 5.7-inch physical
>>> panel in the TM2 device.
>>>
>>> Signed-off-by: Donghwa Lee 
>>> Signed-off-by: Hyungwon Hwang 
>>> Signed-off-by: Hoegeun Kwon 
>>> ---
>>>  .../bindings/display/panel/samsung,s6e3ha2.txt |  40 ++
>>>  drivers/gpu/drm/panel/Kconfig  |   6 +
>>>  drivers/gpu/drm/panel/Makefile |   1 +
>>>  drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c  | 741 
>>> +
>>>  4 files changed, 788 insertions(+)
>>>  create mode 100644 
>>> Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>>  create mode 100644 drivers/gpu/drm/panel/panel-samsung-s6e3ha2.c
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt 
>>> b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>> new file mode 100644
>>> index 000..6879f51
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/display/panel/samsung,s6e3ha2.txt
>>> @@ -0,0 +1,40 @@
>>> +Samsung S6E3HA2 5.7" 1440x2560 AMOLED panel
>>> +
>>> +Required properties:
>>> +  - compatible: "samsung,s6e3ha2"
>>> +  - reg: the virtual channel number of a DSI peripheral
>>> +  - vdd3-supply: I/O voltage supply
>>> +  - vci-supply: voltage supply for analog circuits
>>> +  - reset-gpios: a GPIO spec for the reset pin (active low)
>>> +  - enable-gpios: a GPIO spec for the panel enable pin (active high)
>>> +  - te-gpios: a GPIO spec for the tearing effect synchronization signal
>>> +gpio pin (active high)
>>> +
>>> +The device node can contain one 'port' child node with one child
>>> +'endpoint' node, according to the bindings defined in [1]. This
>>> +node should describe panel's video bus.
>>> +
>>> +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>> +
>>> +Example:
>>> +
>>> + {
>>> +   ...
>>> +
>>> +   panel@0 {
>>> +   compatible = "samsung,s6e3ha2";
>>> +   reg = <0>;
>>> +   vdd3-supply = <_reg>;
>>> +   vci-supply = <_reg>;
>>> +   reset-gpios = < 0 GPIO_ACTIVE_LOW>;
>>> +   enable-gpios = < 5 GPIO_ACTIVE_HIGH>;
>>> +   te-gpios = < 3 GPIO_ACTIVE_HIGH>;
>>> +
>>> +   port {
>>> +   panel_in: endpoint {
>>> +   remote-endpoint = <_out>;
>> As I said previously, it makes no sense to have a graph to dsi_out it is 
>> simply the parent node.
> 
> The problem is that exynos_dsi requires presence of endpoint node, when
> it was written the policy was that graphs must be always present.
> DSI reads from this node samsung,burst-clock-frequency and
> samsung,esc-clock-frequency. For example in exynos4412-trats2.dts:
> 
>> dsi_0: dsi@11C8 {
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>  
>> port@1 {
>> reg = <1>;
>>
>> dsi_out: endpoint {
>> remote-endpoint = <_in>;
>> samsung,burst-clock-frequency
>> = <5>;
>> samsung,esc-clock-frequency =
>> <2000>;
>> };
>> };
>> };
>> 
>> panel@0 {
>> ...
>> port {
>> dsi_in: endpoint {
>> remote-endpoint = <_out>;
>> };
>> };
>> };
>> };
> 
> However, DSI driver does not use remote-endpoint property, it is here
> only to fulfill of_graph policy.
> So if something like below is acceptable, we can get rid of port node in
> panel:
> 
>> dsi_0: dsi@11C8 {
>> ...
>> ports {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>  
>> port@1 {
>> reg = <1>;
>>
>> dsi_out: endpoint {
>> samsung,burst-clock-frequency
>> = <5>;
>> samsung,esc-clock-frequency =
>> <2000>;
>> };
>> };
>> };
>> 
>> panel@0 {
>> ...
>> };
>> };
> 
> What do you think?
> 
> Other solution is to move problematic properties somewhere else, but
> this require change of bindings.
> Anyway I would be glad to remove 

Re: [PATCH v4 1/3] drm/exynos: mic: Add mode_set callback function

[Inki Dae]

2017년 01월 04일 15:58에 Hoegeun Kwon 이(가) 쓴 글:
> Before applying the patch, used the of_get_videomode function to
> parse the display-timings in the panel which is the child driver
> of dsi in the devicetree. this is wrong. So removed the
> of_get_videomode and fixed to get videomode struct through
> mode_set callback function.
> 
> Signed-off-by: Hoegeun Kwon 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_mic.c | 33 
> ++---
>  1 file changed, 22 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index a0def0b..9a50ceb 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -286,13 +286,6 @@ static int parse_dt(struct exynos_mic *mic)
>   }
>   nodes[j++] = remote_node;
>  
> - ret = of_get_videomode(remote_node,
> - >vm, 0);
> - if (ret) {
> - DRM_ERROR("mic: failed to get videomode");
> - goto exit;
> - }
> -
>   break;
>   default:
>   DRM_ERROR("mic: Unknown endpoint from MIC");
> @@ -329,6 +322,27 @@ static void mic_post_disable(struct drm_bridge *bridge)
>   mutex_unlock(_mutex);
>  }
>  
> +static void mic_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct exynos_mic *mic = bridge->driver_private;
> +
> + mutex_lock(_mutex);
> + if (mic->enabled)
> + goto already_enabled;

mode setting should be performed every time mode_set callback is called so 
remove above two lines.

> +
> + drm_display_mode_to_videomode(mode, >vm);
> +
> + if (!mic->i80_mode)
> + mic_set_porch_timing(mic);
> + mic_set_img_size(mic);
> + mic_set_output_timing(mic);
> +
> +already_enabled:

So this label is unnecessary.

> + mutex_unlock(_mutex);
> +}
> +
>  static void mic_pre_enable(struct drm_bridge *bridge)
>  {
>   struct exynos_mic *mic = bridge->driver_private;
> @@ -355,10 +369,6 @@ static void mic_pre_enable(struct drm_bridge *bridge)
>   goto turn_off_clks;
>   }
>  
> - if (!mic->i80_mode)
> - mic_set_porch_timing(mic);
> - mic_set_img_size(mic);
> - mic_set_output_timing(mic);
>   mic_set_reg_on(mic, 1);
>   mic->enabled = 1;
>   mutex_unlock(_mutex);
> @@ -377,6 +387,7 @@ static void mic_enable(struct drm_bridge *bridge) { }
>  static const struct drm_bridge_funcs mic_bridge_funcs = {
>   .disable = mic_disable,
>   .post_disable = mic_post_disable,
> + .mode_set = mic_mode_set,
>   .pre_enable = mic_pre_enable,
>   .enable = mic_enable,
>  };
> 

Re: [PATCH v4 1/3] drm/exynos: mic: Add mode_set callback function

[Inki Dae]

2017년 01월 04일 15:58에 Hoegeun Kwon 이(가) 쓴 글:
> Before applying the patch, used the of_get_videomode function to
> parse the display-timings in the panel which is the child driver
> of dsi in the devicetree. this is wrong. So removed the
> of_get_videomode and fixed to get videomode struct through
> mode_set callback function.
> 
> Signed-off-by: Hoegeun Kwon 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_mic.c | 33 
> ++---
>  1 file changed, 22 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index a0def0b..9a50ceb 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -286,13 +286,6 @@ static int parse_dt(struct exynos_mic *mic)
>   }
>   nodes[j++] = remote_node;
>  
> - ret = of_get_videomode(remote_node,
> - >vm, 0);
> - if (ret) {
> - DRM_ERROR("mic: failed to get videomode");
> - goto exit;
> - }
> -
>   break;
>   default:
>   DRM_ERROR("mic: Unknown endpoint from MIC");
> @@ -329,6 +322,27 @@ static void mic_post_disable(struct drm_bridge *bridge)
>   mutex_unlock(_mutex);
>  }
>  
> +static void mic_mode_set(struct drm_bridge *bridge,
> + struct drm_display_mode *mode,
> + struct drm_display_mode *adjusted_mode)
> +{
> + struct exynos_mic *mic = bridge->driver_private;
> +
> + mutex_lock(_mutex);
> + if (mic->enabled)
> + goto already_enabled;

mode setting should be performed every time mode_set callback is called so 
remove above two lines.

> +
> + drm_display_mode_to_videomode(mode, >vm);
> +
> + if (!mic->i80_mode)
> + mic_set_porch_timing(mic);
> + mic_set_img_size(mic);
> + mic_set_output_timing(mic);
> +
> +already_enabled:

So this label is unnecessary.

> + mutex_unlock(_mutex);
> +}
> +
>  static void mic_pre_enable(struct drm_bridge *bridge)
>  {
>   struct exynos_mic *mic = bridge->driver_private;
> @@ -355,10 +369,6 @@ static void mic_pre_enable(struct drm_bridge *bridge)
>   goto turn_off_clks;
>   }
>  
> - if (!mic->i80_mode)
> - mic_set_porch_timing(mic);
> - mic_set_img_size(mic);
> - mic_set_output_timing(mic);
>   mic_set_reg_on(mic, 1);
>   mic->enabled = 1;
>   mutex_unlock(_mutex);
> @@ -377,6 +387,7 @@ static void mic_enable(struct drm_bridge *bridge) { }
>  static const struct drm_bridge_funcs mic_bridge_funcs = {
>   .disable = mic_disable,
>   .post_disable = mic_post_disable,
> + .mode_set = mic_mode_set,
>   .pre_enable = mic_pre_enable,
>   .enable = mic_enable,
>  };
> 

Re: [PATCH v2] dma-buf: Wait on the reservation object when sync'ing before CPU access

[Inki Dae]

2016년 08월 16일 01:02에 Daniel Vetter 이(가) 쓴 글:
> On Mon, Aug 15, 2016 at 04:42:18PM +0100, Chris Wilson wrote:
>> Rendering operations to the dma-buf are tracked implicitly via the
>> reservation_object (dmabuf->resv). This is used to allow poll() to
>> wait upon outstanding rendering (or just query the current status of
>> rendering). The dma-buf sync ioctl allows userspace to prepare the
>> dma-buf for CPU access, which should include waiting upon rendering.
>> (Some drivers may need to do more work to ensure that the dma-buf mmap
>> is coherent as well as complete.)
>>
>> v2: Always wait upon the reservation object implicitly. We choose to do
>> it after the native handler in case it can do so more efficiently.
>>
>> Testcase: igt/prime_vgem
>> Testcase: igt/gem_concurrent_blit # *vgem*
>> Signed-off-by: Chris Wilson 
>> Cc: Sumit Semwal 
>> Cc: Daniel Vetter 
>> Cc: Eric Anholt 
>> Cc: linux-me...@vger.kernel.org
>> Cc: dri-de...@lists.freedesktop.org
>> Cc: linaro-mm-...@lists.linaro.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>>  drivers/dma-buf/dma-buf.c | 23 +++
>>  1 file changed, 23 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index ddaee60ae52a..cf04d249a6a4 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -586,6 +586,22 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
>> *attach,
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
>>  
>> +static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
>> +  enum dma_data_direction direction)
>> +{
>> +bool write = (direction == DMA_BIDIRECTIONAL ||
>> +  direction == DMA_TO_DEVICE);
>> +struct reservation_object *resv = dmabuf->resv;
>> +long ret;
>> +
>> +/* Wait on any implicit rendering fences */
>> +ret = reservation_object_wait_timeout_rcu(resv, write, true,
>> +  MAX_SCHEDULE_TIMEOUT);
>> +if (ret < 0)
>> +return ret;
>> +
>> +return 0;
>> +}
>>  
>>  /**
>>   * dma_buf_begin_cpu_access - Must be called before accessing a dma_buf 
>> from the
>> @@ -608,6 +624,13 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
>>  if (dmabuf->ops->begin_cpu_access)
>>  ret = dmabuf->ops->begin_cpu_access(dmabuf, direction);
>>  
>> +/* Ensure that all fences are waited upon - but we first allow
>> + * the native handler the chance to do so more efficiently if it
>> + * chooses. A double invocation here will be reasonably cheap no-op.
>> + */
>> +if (ret == 0)
>> +ret = __dma_buf_begin_cpu_access(dmabuf, direction);
> 
> Not sure we should wait first and the flush or the other way round. But I
> don't think it'll matter for any current dma-buf exporter, so meh.
> 

Sorry for late comment. I wonder there is no problem in case that GPU or other 
DMA device tries to access this dma buffer after dma_buf_begin_cpu_access call.
I think in this case, they - GPU or DMA devices - would make a mess of the dma 
buffer while CPU is accessing the buffer.

This patch is in mainline already so if this is real problem then I think we 
sould choose,
1. revert this patch from mainline
2. make sure to prevent other DMA devices to try to access the buffer while CPU 
is accessing the buffer.

Thanks.

> Reviewed-by: Daniel Vetter 
> 
> Sumits, can you pls pick this one up and put into drm-misc?
> -Daniel
> 
>> +
>>  return ret;
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>> -- 
>> 2.8.1
>>
> 

Re: [PATCH v2] dma-buf: Wait on the reservation object when sync'ing before CPU access

[Inki Dae]

2016년 08월 16일 01:02에 Daniel Vetter 이(가) 쓴 글:
> On Mon, Aug 15, 2016 at 04:42:18PM +0100, Chris Wilson wrote:
>> Rendering operations to the dma-buf are tracked implicitly via the
>> reservation_object (dmabuf->resv). This is used to allow poll() to
>> wait upon outstanding rendering (or just query the current status of
>> rendering). The dma-buf sync ioctl allows userspace to prepare the
>> dma-buf for CPU access, which should include waiting upon rendering.
>> (Some drivers may need to do more work to ensure that the dma-buf mmap
>> is coherent as well as complete.)
>>
>> v2: Always wait upon the reservation object implicitly. We choose to do
>> it after the native handler in case it can do so more efficiently.
>>
>> Testcase: igt/prime_vgem
>> Testcase: igt/gem_concurrent_blit # *vgem*
>> Signed-off-by: Chris Wilson 
>> Cc: Sumit Semwal 
>> Cc: Daniel Vetter 
>> Cc: Eric Anholt 
>> Cc: linux-me...@vger.kernel.org
>> Cc: dri-de...@lists.freedesktop.org
>> Cc: linaro-mm-...@lists.linaro.org
>> Cc: linux-kernel@vger.kernel.org
>> ---
>>  drivers/dma-buf/dma-buf.c | 23 +++
>>  1 file changed, 23 insertions(+)
>>
>> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
>> index ddaee60ae52a..cf04d249a6a4 100644
>> --- a/drivers/dma-buf/dma-buf.c
>> +++ b/drivers/dma-buf/dma-buf.c
>> @@ -586,6 +586,22 @@ void dma_buf_unmap_attachment(struct dma_buf_attachment 
>> *attach,
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
>>  
>> +static int __dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
>> +  enum dma_data_direction direction)
>> +{
>> +bool write = (direction == DMA_BIDIRECTIONAL ||
>> +  direction == DMA_TO_DEVICE);
>> +struct reservation_object *resv = dmabuf->resv;
>> +long ret;
>> +
>> +/* Wait on any implicit rendering fences */
>> +ret = reservation_object_wait_timeout_rcu(resv, write, true,
>> +  MAX_SCHEDULE_TIMEOUT);
>> +if (ret < 0)
>> +return ret;
>> +
>> +return 0;
>> +}
>>  
>>  /**
>>   * dma_buf_begin_cpu_access - Must be called before accessing a dma_buf 
>> from the
>> @@ -608,6 +624,13 @@ int dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
>>  if (dmabuf->ops->begin_cpu_access)
>>  ret = dmabuf->ops->begin_cpu_access(dmabuf, direction);
>>  
>> +/* Ensure that all fences are waited upon - but we first allow
>> + * the native handler the chance to do so more efficiently if it
>> + * chooses. A double invocation here will be reasonably cheap no-op.
>> + */
>> +if (ret == 0)
>> +ret = __dma_buf_begin_cpu_access(dmabuf, direction);
> 
> Not sure we should wait first and the flush or the other way round. But I
> don't think it'll matter for any current dma-buf exporter, so meh.
> 

Sorry for late comment. I wonder there is no problem in case that GPU or other 
DMA device tries to access this dma buffer after dma_buf_begin_cpu_access call.
I think in this case, they - GPU or DMA devices - would make a mess of the dma 
buffer while CPU is accessing the buffer.

This patch is in mainline already so if this is real problem then I think we 
sould choose,
1. revert this patch from mainline
2. make sure to prevent other DMA devices to try to access the buffer while CPU 
is accessing the buffer.

Thanks.

> Reviewed-by: Daniel Vetter 
> 
> Sumits, can you pls pick this one up and put into drm-misc?
> -Daniel
> 
>> +
>>  return ret;
>>  }
>>  EXPORT_SYMBOL_GPL(dma_buf_begin_cpu_access);
>> -- 
>> 2.8.1
>>
> 

Re: [PATCH] exynos-drm: Fix error messages to print flags and size

[Inki Dae]

2016-10-06 22:09 GMT+09:00 Tobias Jakobi <tjak...@math.uni-bielefeld.de>:
> Hello,
>
> I think this patch was never picked up. So just a short 'ping' from my side.
>

Oops. one I missed. Will pick it up soon.

Thanks,
Inki Dae

> With best wishes,
> Tobias
>
>
> Shuah Khan wrote:
>> Fix exynos_drm_gem_create() error messages to include flags and size when
>> flags and size are invalid.
>>
>> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index cdf9f1a..4c4cb0e 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -231,12 +231,12 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct 
>> drm_device *dev,
>>   int ret;
>>
>>   if (flags & ~(EXYNOS_BO_MASK)) {
>> - DRM_ERROR("invalid flags.\n");
>> + DRM_ERROR("invalid GEM buffer flags: %u\n", flags);
>>   return ERR_PTR(-EINVAL);
>>   }
>>
>>   if (!size) {
>> - DRM_ERROR("invalid size.\n");
>> + DRM_ERROR("invalid GEM buffer size: %lu\n", size);
>>   return ERR_PTR(-EINVAL);
>>   }
>>
>>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] exynos-drm: Fix error messages to print flags and size

[Inki Dae]

2016-10-06 22:09 GMT+09:00 Tobias Jakobi :
> Hello,
>
> I think this patch was never picked up. So just a short 'ping' from my side.
>

Oops. one I missed. Will pick it up soon.

Thanks,
Inki Dae

> With best wishes,
> Tobias
>
>
> Shuah Khan wrote:
>> Fix exynos_drm_gem_create() error messages to include flags and size when
>> flags and size are invalid.
>>
>> Signed-off-by: Shuah Khan 
>> ---
>>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
>> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> index cdf9f1a..4c4cb0e 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
>> @@ -231,12 +231,12 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct 
>> drm_device *dev,
>>   int ret;
>>
>>   if (flags & ~(EXYNOS_BO_MASK)) {
>> - DRM_ERROR("invalid flags.\n");
>> + DRM_ERROR("invalid GEM buffer flags: %u\n", flags);
>>   return ERR_PTR(-EINVAL);
>>   }
>>
>>   if (!size) {
>> - DRM_ERROR("invalid size.\n");
>> + DRM_ERROR("invalid GEM buffer size: %lu\n", size);
>>   return ERR_PTR(-EINVAL);
>>   }
>>
>>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2] gpu/drm/exynos/exynos_hdmi - Unmap region obtained by of_iomap

[Inki Dae]

Will pick it up soon.

Thanks,
Inki Dae

2016-10-19 19:04 GMT+09:00 Arvind Yadav <arvind.yadav...@gmail.com>:
> Free memory mapping, if hdmi_probe is not successful.
>
> Signed-off-by: Arvind Yadav <arvind.yadav...@gmail.com>
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c |5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2275efe..ba28dec 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1901,6 +1901,8 @@ err_disable_pm_runtime:
>  err_hdmiphy:
> if (hdata->hdmiphy_port)
> put_device(>hdmiphy_port->dev);
> +   if (hdata->regs_hdmiphy)
> +   iounmap(hdata->regs_hdmiphy);
>  err_ddc:
> put_device(>ddc_adpt->dev);
>
> @@ -1923,6 +1925,9 @@ static int hdmi_remove(struct platform_device *pdev)
> if (hdata->hdmiphy_port)
> put_device(>hdmiphy_port->dev);
>
> +   if (hdata->regs_hdmiphy)
> +   iounmap(hdata->regs_hdmiphy);
> +
> put_device(>ddc_adpt->dev);
>
> return 0;
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH V2] gpu/drm/exynos/exynos_hdmi - Unmap region obtained by of_iomap

[Inki Dae]

Will pick it up soon.

Thanks,
Inki Dae

2016-10-19 19:04 GMT+09:00 Arvind Yadav :
> Free memory mapping, if hdmi_probe is not successful.
>
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/gpu/drm/exynos/exynos_hdmi.c |5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
> b/drivers/gpu/drm/exynos/exynos_hdmi.c
> index 2275efe..ba28dec 100644
> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
> @@ -1901,6 +1901,8 @@ err_disable_pm_runtime:
>  err_hdmiphy:
> if (hdata->hdmiphy_port)
> put_device(>hdmiphy_port->dev);
> +   if (hdata->regs_hdmiphy)
> +   iounmap(hdata->regs_hdmiphy);
>  err_ddc:
> put_device(>ddc_adpt->dev);
>
> @@ -1923,6 +1925,9 @@ static int hdmi_remove(struct platform_device *pdev)
> if (hdata->hdmiphy_port)
> put_device(>hdmiphy_port->dev);
>
> +   if (hdata->regs_hdmiphy)
> +   iounmap(hdata->regs_hdmiphy);
> +
> put_device(>ddc_adpt->dev);
>
> return 0;
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

[Inki Dae]

Hi Shuah,

2016-10-13 8:11 GMT+09:00 Shuah Khan <shua...@osg.samsung.com>:
> Hi Inki,
>
> On 08/15/2016 10:40 PM, Inki Dae wrote:
>
>>>
>>> okay the very first commit that added IOMMU support
>>> introduced the code that rejects non-contig gem memory
>>> type without IOMMU.
>>>
>>> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c
>>> Author: Inki Dae <inki@samsung.com>
>>> Date:   Sat Oct 20 07:53:42 2012 -0700
>>>
>>> drm/exynos: add iommu support for exynos drm framework
>>>
>
> I haven't given up on this yet. I am still seeing the following failure:
>
> Additional debug messages I added:
> [   15.287403] exynos_drm_gem_create_ioctl() 1
> [   15.287419] exynos_drm_gem_create() flags 1
>
> [   15.311511] [drm:exynos_drm_framebuffer_init] *ERROR* Non-contiguous GEM 
> memory is not supported.
>
> Additional debug message I added:
> [   15.318981] [drm:exynos_user_fb_create] *ERROR* failed to initialize 
> framebuffer
>
> This is what happens:
>
> 1. exynos_drm_gem_create_ioctl() gets called with EXYNOS_BO_NONCONTIG request
> 2. exynos_drm_gem_create(0 goes ahead and creates the GEM buffers
> 3. exynos_user_fb_create() tries to associate GEM to fb and fails during
>check_fb_gem_memory_type()
>
> At this point, there is no recovery and lightdm fails
>
> xf86-video-armsoc/src/drmmode_exynos/drmmode_exynos.c assumes contiguous
> allocations are not supported in some exynos drm versions: The following
> commit introduced this change:
>
> https://git.linaro.org/arm/xorg/driver/xf86-video-armsoc.git/commitdiff/3be1f6273441fe95dd442f44064387322e16b7e9
>
> excerpts from the diff:-   if (create_gem->buf_type == ARMSOC_BO_SCANOUT)
> -   create_exynos.flags = EXYNOS_BO_CONTIG;
> -   else
> -   create_exynos.flags = EXYNOS_BO_NONCONTIG;
> +
> +   /* Contiguous allocations are not supported in some exynos drm 
> versions.
> +* When they are supported all allocations are effectively contiguous
> +* anyway, so for simplicity we always request non contiguous buffers.
> +*/
> +   create_exynos.flags = EXYNOS_BO_NONCONTIG;
>

Above comment, "Contiguous allocations are not supported in some
exynos drm versions.", seems wrong assumption.
The root cause, contiguous allocation is not supported, would be that
they used Linux kernel which didn't have CMA region enough - as
default 16MB, or didn't declare CMA region enough for the DMA device.
So I think they should not force to flag EXYNOS_BO_NONCONTIG and they
should manage the error case if the allocation failed.

> There might have been logic on exynos_drm that forced Contig when it coudn't
> support NONCONTIG. At least, that is what this comment suggests. This 
> assumption
> doesn't appear to be a good one and not sure if this change was made to fix a 
> bug.
>
> After the IOMMU support, this assumption is no longer true. Hence, with IOMMU
> support, latest kernels have a mismatch with the installed xf86-video-armsoc
>
> This is what I am running into. This leads to the following question:
>
> 1. How do we ensure exynos_drm kernel changes don't break user-space
>specifically xf86-video-armsoc
> 2. This seems to have gone undetected for a while. I see a change in
>exynos_drm_gem_dumb_create() that is probably addressing this type
>of breakage. Commit 122beea84bb90236b1ae545f08267af58591c21b adds
>handling for IOMMU NONCONTIG case.

Seems this patch has a problem. This patch forces to flag NONCONTIG if
iommu is enabled. The flag should be depend on the argument from
user-space.
I.e., if user-space requested a gem allocation with CONTIG flag, then
Exynos drm driver should allocate contiguous memory even though iommu
is enabled.

>
> Anyway, I am interested in getting the exynos_drm kernel side code
> and xf86-video-armsoc in sync to resolve the issue.
>
> Could you recommend a going forward plan?

My opinion are,

1. Do not force to flag EXYNOS_BO_NONCONTIG at xf86-video-armsoc
2. Do not force to flag NONCONTIG at Exynos drm driver even though
iommu is enabled and flag allocation type with the argument from
user-space.

I think you could try to post above patches.

Thanks,
Inki Dae

>
> I can submit a patch to xf86-video-armsoc. I am also looking ahead to
> see if we can avoid such breaks in the future by keeping kernel and
> xf86-video-armsoc in sync.
>
> thanks,
> -- Shuah
> --
> 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] exynos-drm: Fix display manager failing to start without IOMMU problem

[Inki Dae]

Hi Shuah,

2016-10-13 8:11 GMT+09:00 Shuah Khan :
> Hi Inki,
>
> On 08/15/2016 10:40 PM, Inki Dae wrote:
>
>>>
>>> okay the very first commit that added IOMMU support
>>> introduced the code that rejects non-contig gem memory
>>> type without IOMMU.
>>>
>>> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c
>>> Author: Inki Dae 
>>> Date:   Sat Oct 20 07:53:42 2012 -0700
>>>
>>> drm/exynos: add iommu support for exynos drm framework
>>>
>
> I haven't given up on this yet. I am still seeing the following failure:
>
> Additional debug messages I added:
> [   15.287403] exynos_drm_gem_create_ioctl() 1
> [   15.287419] exynos_drm_gem_create() flags 1
>
> [   15.311511] [drm:exynos_drm_framebuffer_init] *ERROR* Non-contiguous GEM 
> memory is not supported.
>
> Additional debug message I added:
> [   15.318981] [drm:exynos_user_fb_create] *ERROR* failed to initialize 
> framebuffer
>
> This is what happens:
>
> 1. exynos_drm_gem_create_ioctl() gets called with EXYNOS_BO_NONCONTIG request
> 2. exynos_drm_gem_create(0 goes ahead and creates the GEM buffers
> 3. exynos_user_fb_create() tries to associate GEM to fb and fails during
>check_fb_gem_memory_type()
>
> At this point, there is no recovery and lightdm fails
>
> xf86-video-armsoc/src/drmmode_exynos/drmmode_exynos.c assumes contiguous
> allocations are not supported in some exynos drm versions: The following
> commit introduced this change:
>
> https://git.linaro.org/arm/xorg/driver/xf86-video-armsoc.git/commitdiff/3be1f6273441fe95dd442f44064387322e16b7e9
>
> excerpts from the diff:-   if (create_gem->buf_type == ARMSOC_BO_SCANOUT)
> -   create_exynos.flags = EXYNOS_BO_CONTIG;
> -   else
> -   create_exynos.flags = EXYNOS_BO_NONCONTIG;
> +
> +   /* Contiguous allocations are not supported in some exynos drm 
> versions.
> +* When they are supported all allocations are effectively contiguous
> +* anyway, so for simplicity we always request non contiguous buffers.
> +*/
> +   create_exynos.flags = EXYNOS_BO_NONCONTIG;
>

Above comment, "Contiguous allocations are not supported in some
exynos drm versions.", seems wrong assumption.
The root cause, contiguous allocation is not supported, would be that
they used Linux kernel which didn't have CMA region enough - as
default 16MB, or didn't declare CMA region enough for the DMA device.
So I think they should not force to flag EXYNOS_BO_NONCONTIG and they
should manage the error case if the allocation failed.

> There might have been logic on exynos_drm that forced Contig when it coudn't
> support NONCONTIG. At least, that is what this comment suggests. This 
> assumption
> doesn't appear to be a good one and not sure if this change was made to fix a 
> bug.
>
> After the IOMMU support, this assumption is no longer true. Hence, with IOMMU
> support, latest kernels have a mismatch with the installed xf86-video-armsoc
>
> This is what I am running into. This leads to the following question:
>
> 1. How do we ensure exynos_drm kernel changes don't break user-space
>specifically xf86-video-armsoc
> 2. This seems to have gone undetected for a while. I see a change in
>exynos_drm_gem_dumb_create() that is probably addressing this type
>of breakage. Commit 122beea84bb90236b1ae545f08267af58591c21b adds
>handling for IOMMU NONCONTIG case.

Seems this patch has a problem. This patch forces to flag NONCONTIG if
iommu is enabled. The flag should be depend on the argument from
user-space.
I.e., if user-space requested a gem allocation with CONTIG flag, then
Exynos drm driver should allocate contiguous memory even though iommu
is enabled.

>
> Anyway, I am interested in getting the exynos_drm kernel side code
> and xf86-video-armsoc in sync to resolve the issue.
>
> Could you recommend a going forward plan?

My opinion are,

1. Do not force to flag EXYNOS_BO_NONCONTIG at xf86-video-armsoc
2. Do not force to flag NONCONTIG at Exynos drm driver even though
iommu is enabled and flag allocation type with the argument from
user-space.

I think you could try to post above patches.

Thanks,
Inki Dae

>
> I can submit a patch to xf86-video-armsoc. I am also looking ahead to
> see if we can avoid such breaks in the future by keeping kernel and
> xf86-video-armsoc in sync.
>
> thanks,
> -- Shuah
> --
> 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] exynos-drm: Fix display manager failing to start without IOMMU problem

[Inki Dae]

Hi Shuah,

2016년 08월 13일 02:52에 Shuah Khan 이(가) 쓴 글:
> On 08/12/2016 11:28 AM, Shuah Khan wrote:
>> On 08/10/2016 05:05 PM, Shuah Khan wrote:
>>> On 08/10/2016 04:59 PM, Inki Dae wrote:
>>>> Hi Shuah,
>>>>
>>>> 2016년 08월 11일 02:30에 Shuah Khan 이(가) 쓴 글:
>>>>> Fix exynos_drm_gem_create_ioctl() attempts to allocate non-contiguous GEM
>>>>> memory without IOMMU. In this case, there is no point in attempting to
>>>>
>>>> DRM gem can be used for Non-DRM drivers such as GPU, V4L2 based Multimedia 
>>>> device and other DMA devices.
>>>> Even though IOMMU support is disabled, other framework based DMA drivers 
>>>> can use IOMMU - i.e., GPU driver -
>>>> and they can use non-contiguous GEM buffer through UMM. (DMABUF) 
>>>>
>>>> So GEM allocation type is not dependent on IOMMU.
>>>
>>> Hi Inki,
>>>
>>> I am seeing the following failure without IOMMU and light dm fails
>>> to start:
>>>
>>> [drm:exynos_drm_framebuffer_init] *ERROR* Non-continguous GEM memory is not 
>>> supported.
>>>
>>> The change I made fixed that problem and light dm starts without IOMMU.
>>> Is there a better way to fix this problem? Currently without IOMMU,
>>> light dm doesn't start.
>>>
>>> This is on linux_next
>>
>> Hi Inki,
>>
>> I am looking into this further and I am finding inconsistent
>> commits with regards to GEM contiguous and non-contiguous
>> buffers.
>>
>> Okay what you said is that:
>>
>> exymod-drm should support non-continguous and contiguous GEM memory
>> type with or without IOMMU

Right.

>>
>> However, the code currently isn't doing that. The following
>> commit allocates non-contiguous buffers when IOMMU is enabled
>> to handle contiguous allocation failures.
>>
>> There are other commits that removed checks for non-contig type.
>> Let's look at the following cases to see what should be the driver
>> behavior in these cases:
>>
>> IOMMU is disabled:
>>
>> exynos_drm_gem_create_ioctl() gets called with NONCONTIG
>> - driver should try to allocate non-contig
>> - if it can't allocate non-contig, allocate contig
>>   ( this will allow avoid failure like the one I am seeing)
>>
>> exynos_drm_gem_create_ioctl() gets called with CONTIG
>> - driver should try to allocate contig
>> - if it can't allocate contig, allocate non-contig
>>
>> What is confusing is there are several code paths in the
>> GEN allocation and checking memory types are enforcing
>> non-contig with IOMMU. Check this routine:
>>
>> exynos_drm_framebuffer_init() will reject non-contig
>> memory type when check_fb_gem_memory_type() rejects
>> non-contig GEM memory type without IOMMU.

Only in case that the gem buffer is used for framebuffer, gem memory type 
should be checked because this means the DMA of Display controller accesses the 
gem buffer so without IOMMU the DMA device cannot access non-contiguous memory 
region.
That is why exynos_drm_framebuffer_init checks gem memory type for fb not when 
gem is created.

> 
> 
> okay the very first commit that added IOMMU support
> introduced the code that rejects non-contig gem memory
> type without IOMMU.
> 
> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c
> Author: Inki Dae <inki@samsung.com>
> Date:   Sat Oct 20 07:53:42 2012 -0700
> 
> drm/exynos: add iommu support for exynos drm framework
> 
> Anyway, if it is th right change to fix check_fb_gem_memory_type()
> to not reject NONCONTIG_BUFFER, then I can make that change

No, as I mentioned above, the gem buffer for fb is dependent on IOMMU because 
the gem buffer for fb is used by DMA device - FIMD, DECON or Mixer.
You would need to understand that gem buffer can be used for other purposes - 
2D/3D or post process devices which don't use framebuffer - not display 
controller which uses framebuffer to scanout

Thanks,
Inki Dae

> instead of this patch I sent.
> 
>>
>> So there is inconsistency in the non-contig vs. contig
>> GEM support in exynos-drm. I think this needs to be cleaned
>> up to get the desired behavior.
>>
>> The following commit allocates non-contiguous buffers when IOMMU is
>> enabled to handle contiguous allocation failures.
>>
>> There are other commits that removed checks for non-contig type.
>> Let's look at the following cases to see what should be the driver
>> behavior in these cases:
>>
>> commit 122beea84bb90236b1ae545f08267af58591c21b
>> Author: Rahul

Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

[Inki Dae]

Hi Shuah,

2016년 08월 13일 02:52에 Shuah Khan 이(가) 쓴 글:
> On 08/12/2016 11:28 AM, Shuah Khan wrote:
>> On 08/10/2016 05:05 PM, Shuah Khan wrote:
>>> On 08/10/2016 04:59 PM, Inki Dae wrote:
>>>> Hi Shuah,
>>>>
>>>> 2016년 08월 11일 02:30에 Shuah Khan 이(가) 쓴 글:
>>>>> Fix exynos_drm_gem_create_ioctl() attempts to allocate non-contiguous GEM
>>>>> memory without IOMMU. In this case, there is no point in attempting to
>>>>
>>>> DRM gem can be used for Non-DRM drivers such as GPU, V4L2 based Multimedia 
>>>> device and other DMA devices.
>>>> Even though IOMMU support is disabled, other framework based DMA drivers 
>>>> can use IOMMU - i.e., GPU driver -
>>>> and they can use non-contiguous GEM buffer through UMM. (DMABUF) 
>>>>
>>>> So GEM allocation type is not dependent on IOMMU.
>>>
>>> Hi Inki,
>>>
>>> I am seeing the following failure without IOMMU and light dm fails
>>> to start:
>>>
>>> [drm:exynos_drm_framebuffer_init] *ERROR* Non-continguous GEM memory is not 
>>> supported.
>>>
>>> The change I made fixed that problem and light dm starts without IOMMU.
>>> Is there a better way to fix this problem? Currently without IOMMU,
>>> light dm doesn't start.
>>>
>>> This is on linux_next
>>
>> Hi Inki,
>>
>> I am looking into this further and I am finding inconsistent
>> commits with regards to GEM contiguous and non-contiguous
>> buffers.
>>
>> Okay what you said is that:
>>
>> exymod-drm should support non-continguous and contiguous GEM memory
>> type with or without IOMMU

Right.

>>
>> However, the code currently isn't doing that. The following
>> commit allocates non-contiguous buffers when IOMMU is enabled
>> to handle contiguous allocation failures.
>>
>> There are other commits that removed checks for non-contig type.
>> Let's look at the following cases to see what should be the driver
>> behavior in these cases:
>>
>> IOMMU is disabled:
>>
>> exynos_drm_gem_create_ioctl() gets called with NONCONTIG
>> - driver should try to allocate non-contig
>> - if it can't allocate non-contig, allocate contig
>>   ( this will allow avoid failure like the one I am seeing)
>>
>> exynos_drm_gem_create_ioctl() gets called with CONTIG
>> - driver should try to allocate contig
>> - if it can't allocate contig, allocate non-contig
>>
>> What is confusing is there are several code paths in the
>> GEN allocation and checking memory types are enforcing
>> non-contig with IOMMU. Check this routine:
>>
>> exynos_drm_framebuffer_init() will reject non-contig
>> memory type when check_fb_gem_memory_type() rejects
>> non-contig GEM memory type without IOMMU.

Only in case that the gem buffer is used for framebuffer, gem memory type 
should be checked because this means the DMA of Display controller accesses the 
gem buffer so without IOMMU the DMA device cannot access non-contiguous memory 
region.
That is why exynos_drm_framebuffer_init checks gem memory type for fb not when 
gem is created.

> 
> 
> okay the very first commit that added IOMMU support
> introduced the code that rejects non-contig gem memory
> type without IOMMU.
> 
> commit 0519f9a12d0113caab78980c48a7902d2bd40c2c
> Author: Inki Dae 
> Date:   Sat Oct 20 07:53:42 2012 -0700
> 
> drm/exynos: add iommu support for exynos drm framework
> 
> Anyway, if it is th right change to fix check_fb_gem_memory_type()
> to not reject NONCONTIG_BUFFER, then I can make that change

No, as I mentioned above, the gem buffer for fb is dependent on IOMMU because 
the gem buffer for fb is used by DMA device - FIMD, DECON or Mixer.
You would need to understand that gem buffer can be used for other purposes - 
2D/3D or post process devices which don't use framebuffer - not display 
controller which uses framebuffer to scanout

Thanks,
Inki Dae

> instead of this patch I sent.
> 
>>
>> So there is inconsistency in the non-contig vs. contig
>> GEM support in exynos-drm. I think this needs to be cleaned
>> up to get the desired behavior.
>>
>> The following commit allocates non-contiguous buffers when IOMMU is
>> enabled to handle contiguous allocation failures.
>>
>> There are other commits that removed checks for non-contig type.
>> Let's look at the following cases to see what should be the driver
>> behavior in these cases:
>>
>> commit 122beea84bb90236b1ae545f08267af58591c21b
>> Author: Rahul Sharma 
>> Date:   W

Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

[Inki Dae]

Hi Shuah,

2016년 08월 11일 02:30에 Shuah Khan 이(가) 쓴 글:
> Fix exynos_drm_gem_create_ioctl() attempts to allocate non-contiguous GEM
> memory without IOMMU. In this case, there is no point in attempting to

DRM gem can be used for Non-DRM drivers such as GPU, V4L2 based Multimedia 
device and other DMA devices.
Even though IOMMU support is disabled, other framework based DMA drivers can 
use IOMMU - i.e., GPU driver -
and they can use non-contiguous GEM buffer through UMM. (DMABUF) 

So GEM allocation type is not dependent on IOMMU.

Thanks,
Inki Dae

> allocate non-contiguous memory, only to return error during the next step
> from exynos_drm_framebuffer_init() which leads to display manager failing
> to start.
> 
> Check if non-contiguous GEM memory is requested without IOMMU. If so,
> allocate contiguous GEM memory to help display manager start.
> 
> Signed-off-by: Shuah Khan <shua...@osg.samsung.com>
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 4c4cb0e..4719116 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -266,6 +266,20 @@ int exynos_drm_gem_create_ioctl(struct drm_device *dev, 
> void *data,
>   struct exynos_drm_gem *exynos_gem;
>   int ret;
>  
> + /*
> +  * Check if non-contiguous GEM memory is requested without IOMMU.
> +  * If so, allocate contiguous GEM memory.
> +  *
> +  * There is no point in attempting to allocate non-contiguous memory,
> +  * only to return error from exynos_drm_framebuffer_init() which leads
> +  * to display manager failing to start.
> + */
> + if (!is_drm_iommu_supported(dev) &&
> + (args->flags & EXYNOS_BO_NONCONTIG)) {
> + args->flags &= ~EXYNOS_BO_NONCONTIG;
> + args->flags |= EXYNOS_BO_CONTIG;
> + }
> +
>   exynos_gem = exynos_drm_gem_create(dev, args->flags, args->size);
>   if (IS_ERR(exynos_gem))
>   return PTR_ERR(exynos_gem);
> 

Re: [PATCH] exynos-drm: Fix display manager failing to start without IOMMU problem

[Inki Dae]

Hi Shuah,

2016년 08월 11일 02:30에 Shuah Khan 이(가) 쓴 글:
> Fix exynos_drm_gem_create_ioctl() attempts to allocate non-contiguous GEM
> memory without IOMMU. In this case, there is no point in attempting to

DRM gem can be used for Non-DRM drivers such as GPU, V4L2 based Multimedia 
device and other DMA devices.
Even though IOMMU support is disabled, other framework based DMA drivers can 
use IOMMU - i.e., GPU driver -
and they can use non-contiguous GEM buffer through UMM. (DMABUF) 

So GEM allocation type is not dependent on IOMMU.

Thanks,
Inki Dae

> allocate non-contiguous memory, only to return error during the next step
> from exynos_drm_framebuffer_init() which leads to display manager failing
> to start.
> 
> Check if non-contiguous GEM memory is requested without IOMMU. If so,
> allocate contiguous GEM memory to help display manager start.
> 
> Signed-off-by: Shuah Khan 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> index 4c4cb0e..4719116 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
> @@ -266,6 +266,20 @@ int exynos_drm_gem_create_ioctl(struct drm_device *dev, 
> void *data,
>   struct exynos_drm_gem *exynos_gem;
>   int ret;
>  
> + /*
> +  * Check if non-contiguous GEM memory is requested without IOMMU.
> +  * If so, allocate contiguous GEM memory.
> +  *
> +  * There is no point in attempting to allocate non-contiguous memory,
> +  * only to return error from exynos_drm_framebuffer_init() which leads
> +  * to display manager failing to start.
> + */
> + if (!is_drm_iommu_supported(dev) &&
> + (args->flags & EXYNOS_BO_NONCONTIG)) {
> + args->flags &= ~EXYNOS_BO_NONCONTIG;
> + args->flags |= EXYNOS_BO_CONTIG;
> + }
> +
>   exynos_gem = exynos_drm_gem_create(dev, args->flags, args->size);
>   if (IS_ERR(exynos_gem))
>   return PTR_ERR(exynos_gem);
> 

Re: [PATCH] drm/exynos: don't use HW trigger for Exynos5420/5422/5800

[Inki Dae]

2016년 06월 10일 09:24에 Javier Martinez Canillas 이(가) 쓴 글:
> Hello Inki,
> 
> On Thu, Jun 9, 2016 at 6:35 PM, Inki Dae <inki@samsung.com> wrote:
> 
> [snip]
> 
>>> I know that removing .trg_type is enough but I also removed those lines
>>> because the fields are not used if .trg_type != I80_HW_TRG. So there is
>>> no point to leave a set for unused fields.
>>>
>>> We can latter add those one HW trigger support is fixed for Exynos5420.
>>>
>>
>> As of now, I can merge it but I think it would be not reasonable solution 
>> because potential problem still exists even we use SW trigger mode in 
>> default - ie., in case of using HW trigger mode at bootloader, same problem 
>> would happen as long as we don't support PSR mode support.
>>
> 
> Yes, I understand that the problem will show again if the bootloader
> uses HW trigger mode and that we need proper Panel Self Refresh
> support but I think that's a separate issue. That's why I said that
> those can be addressed for v4.8 but revert to SW trigger for v4.7 as a
> short term fix for the regression.
> 
> In other words, enabling HW trigger mode breaks the display for the
> Exynos5420 and Exynos5800 Peach Pi Chromebooks with the shipped
> bootloaders (which are probably the most popular Exynos5 devices with
> display and mainline support so is likely to affect users).

I thought to add PSR support somehow but put me other things to trouble.
Anyway, we could support it later so picked it up.

Thanks,
Inki Dae

> 
> Best regards,
> Javier
> 
> 
> 

Re: [PATCH] drm/exynos: don't use HW trigger for Exynos5420/5422/5800

[Inki Dae]

2016년 06월 10일 09:24에 Javier Martinez Canillas 이(가) 쓴 글:
> Hello Inki,
> 
> On Thu, Jun 9, 2016 at 6:35 PM, Inki Dae  wrote:
> 
> [snip]
> 
>>> I know that removing .trg_type is enough but I also removed those lines
>>> because the fields are not used if .trg_type != I80_HW_TRG. So there is
>>> no point to leave a set for unused fields.
>>>
>>> We can latter add those one HW trigger support is fixed for Exynos5420.
>>>
>>
>> As of now, I can merge it but I think it would be not reasonable solution 
>> because potential problem still exists even we use SW trigger mode in 
>> default - ie., in case of using HW trigger mode at bootloader, same problem 
>> would happen as long as we don't support PSR mode support.
>>
> 
> Yes, I understand that the problem will show again if the bootloader
> uses HW trigger mode and that we need proper Panel Self Refresh
> support but I think that's a separate issue. That's why I said that
> those can be addressed for v4.8 but revert to SW trigger for v4.7 as a
> short term fix for the regression.
> 
> In other words, enabling HW trigger mode breaks the display for the
> Exynos5420 and Exynos5800 Peach Pi Chromebooks with the shipped
> bootloaders (which are probably the most popular Exynos5 devices with
> display and mainline support so is likely to affect users).

I thought to add PSR support somehow but put me other things to trouble.
Anyway, we could support it later so picked it up.

Thanks,
Inki Dae

> 
> Best regards,
> Javier
> 
> 
> 

Re: [PATCH] drm/exynos: don't use HW trigger for Exynos5420/5422/5800

[Inki Dae]

Hi Javier,

2016년 06월 09일 09:17에 Javier Martinez Canillas 이(가) 쓴 글:
> Hello Inki,
> 
> Thanks for your feedback.
> 
> On 06/08/2016 07:09 PM, Inki Dae wrote:
>> Hi Javier,
>>
>> 2016년 06월 02일 23:20에 Javier Martinez Canillas 이(가) 쓴 글:
>>> Commit a6f75aa161c5 ("drm/exynos: fimd: add HW trigger support") added
>>> hardware trigger support to the FIMD controller driver. But this broke
>>> the display in at least the Exynos5800 Peach Pi Chromebook.
>>>
>>> So until the issue is fixed, avoid using HW trigger for the Exynos5420
>>> based boards and use SW trigger as it was before the mentioned commit.
>>>
>>> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
>>>
>>> ---
>>>
>>> Hello Inki,
>>>
>>> Since commit a6f75aa161c5 landed in v4.7-rc1, I think $SUBJECT should be
>>> picked to make sure that v4.7 is released with the display working for
>>> the Exynos5420 based Chromebooks.
>>>
>>> We can then figure out what's wrong with the HW trigger support and fix
>>> it for v4.8.
>>
>> Agree. And below is a trivial comment.
>>
> 
> I'm glad that you agree.
> 
>>>
>>> Best regards,
>>> Javier
>>>
>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ---
>>>  1 file changed, 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index 1c23a8ff5e83..f10030ff00e6 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -170,14 +170,11 @@ static struct fimd_driver_data 
>>> exynos5420_fimd_driver_data = {
>>> .lcdblk_vt_shift = 24,
>>> .lcdblk_bypass_shift = 15,
>>> .lcdblk_mic_bypass_shift = 11,
>>> -   .trg_type = I80_HW_TRG,
>>> .has_shadowcon = 1,
>>> .has_vidoutcon = 1,
>>> .has_vtsel = 1,
>>> .has_mic_bypass = 1,
>>> .has_dp_clk = 1,
>>> -   .has_hw_trigger = 1,
>>> -   .has_trigger_per_te = 1,
>>
>> We don't need to remove above two lines. It would be enough to remove 
>> 'trg_type = I80_HW_TRG', which makes FIMD to be worked with SW trigger in 
>> default.
>>
> 
> I know that removing .trg_type is enough but I also removed those lines
> because the fields are not used if .trg_type != I80_HW_TRG. So there is
> no point to leave a set for unused fields.
> 
> We can latter add those one HW trigger support is fixed for Exynos5420.
> 

As of now, I can merge it but I think it would be not reasonable solution 
because potential problem still exists even we use SW trigger mode in default - 
ie., in case of using HW trigger mode at bootloader, same problem would happen 
as long as we don't support PSR mode support.

Thanks,
Inki Dae

>> Thanks,
>> Inki Dae
>>
>>>  };
>>>  
>>>  struct fimd_context {
>>>
>> --
>> 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
>>
> 
> Best regards,
> 

Re: [PATCH] drm/exynos: don't use HW trigger for Exynos5420/5422/5800

[Inki Dae]

Hi Javier,

2016년 06월 09일 09:17에 Javier Martinez Canillas 이(가) 쓴 글:
> Hello Inki,
> 
> Thanks for your feedback.
> 
> On 06/08/2016 07:09 PM, Inki Dae wrote:
>> Hi Javier,
>>
>> 2016년 06월 02일 23:20에 Javier Martinez Canillas 이(가) 쓴 글:
>>> Commit a6f75aa161c5 ("drm/exynos: fimd: add HW trigger support") added
>>> hardware trigger support to the FIMD controller driver. But this broke
>>> the display in at least the Exynos5800 Peach Pi Chromebook.
>>>
>>> So until the issue is fixed, avoid using HW trigger for the Exynos5420
>>> based boards and use SW trigger as it was before the mentioned commit.
>>>
>>> Signed-off-by: Javier Martinez Canillas 
>>>
>>> ---
>>>
>>> Hello Inki,
>>>
>>> Since commit a6f75aa161c5 landed in v4.7-rc1, I think $SUBJECT should be
>>> picked to make sure that v4.7 is released with the display working for
>>> the Exynos5420 based Chromebooks.
>>>
>>> We can then figure out what's wrong with the HW trigger support and fix
>>> it for v4.8.
>>
>> Agree. And below is a trivial comment.
>>
> 
> I'm glad that you agree.
> 
>>>
>>> Best regards,
>>> Javier
>>>
>>>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ---
>>>  1 file changed, 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
>>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> index 1c23a8ff5e83..f10030ff00e6 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>>> @@ -170,14 +170,11 @@ static struct fimd_driver_data 
>>> exynos5420_fimd_driver_data = {
>>> .lcdblk_vt_shift = 24,
>>> .lcdblk_bypass_shift = 15,
>>> .lcdblk_mic_bypass_shift = 11,
>>> -   .trg_type = I80_HW_TRG,
>>> .has_shadowcon = 1,
>>> .has_vidoutcon = 1,
>>> .has_vtsel = 1,
>>> .has_mic_bypass = 1,
>>> .has_dp_clk = 1,
>>> -   .has_hw_trigger = 1,
>>> -   .has_trigger_per_te = 1,
>>
>> We don't need to remove above two lines. It would be enough to remove 
>> 'trg_type = I80_HW_TRG', which makes FIMD to be worked with SW trigger in 
>> default.
>>
> 
> I know that removing .trg_type is enough but I also removed those lines
> because the fields are not used if .trg_type != I80_HW_TRG. So there is
> no point to leave a set for unused fields.
> 
> We can latter add those one HW trigger support is fixed for Exynos5420.
> 

As of now, I can merge it but I think it would be not reasonable solution 
because potential problem still exists even we use SW trigger mode in default - 
ie., in case of using HW trigger mode at bootloader, same problem would happen 
as long as we don't support PSR mode support.

Thanks,
Inki Dae

>> Thanks,
>> Inki Dae
>>
>>>  };
>>>  
>>>  struct fimd_context {
>>>
>> --
>> 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
>>
> 
> Best regards,
> 

Re: [PATCH] drm/exynos: don't use HW trigger for Exynos5420/5422/5800

[Inki Dae]

Hi Javier,

2016년 06월 02일 23:20에 Javier Martinez Canillas 이(가) 쓴 글:
> Commit a6f75aa161c5 ("drm/exynos: fimd: add HW trigger support") added
> hardware trigger support to the FIMD controller driver. But this broke
> the display in at least the Exynos5800 Peach Pi Chromebook.
> 
> So until the issue is fixed, avoid using HW trigger for the Exynos5420
> based boards and use SW trigger as it was before the mentioned commit.
> 
> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> 
> ---
> 
> Hello Inki,
> 
> Since commit a6f75aa161c5 landed in v4.7-rc1, I think $SUBJECT should be
> picked to make sure that v4.7 is released with the display working for
> the Exynos5420 based Chromebooks.
> 
> We can then figure out what's wrong with the HW trigger support and fix
> it for v4.8.

Agree. And below is a trivial comment.

> 
> Best regards,
> Javier
> 
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 1c23a8ff5e83..f10030ff00e6 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -170,14 +170,11 @@ static struct fimd_driver_data 
> exynos5420_fimd_driver_data = {
>   .lcdblk_vt_shift = 24,
>   .lcdblk_bypass_shift = 15,
>   .lcdblk_mic_bypass_shift = 11,
> - .trg_type = I80_HW_TRG,
>   .has_shadowcon = 1,
>   .has_vidoutcon = 1,
>   .has_vtsel = 1,
>   .has_mic_bypass = 1,
>   .has_dp_clk = 1,
> - .has_hw_trigger = 1,
> - .has_trigger_per_te = 1,

We don't need to remove above two lines. It would be enough to remove 'trg_type 
= I80_HW_TRG', which makes FIMD to be worked with SW trigger in default.

Thanks,
Inki Dae

>  };
>  
>  struct fimd_context {
> 

Re: [PATCH] drm/exynos: don't use HW trigger for Exynos5420/5422/5800

[Inki Dae]

Hi Javier,

2016년 06월 02일 23:20에 Javier Martinez Canillas 이(가) 쓴 글:
> Commit a6f75aa161c5 ("drm/exynos: fimd: add HW trigger support") added
> hardware trigger support to the FIMD controller driver. But this broke
> the display in at least the Exynos5800 Peach Pi Chromebook.
> 
> So until the issue is fixed, avoid using HW trigger for the Exynos5420
> based boards and use SW trigger as it was before the mentioned commit.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
> Hello Inki,
> 
> Since commit a6f75aa161c5 landed in v4.7-rc1, I think $SUBJECT should be
> picked to make sure that v4.7 is released with the display working for
> the Exynos5420 based Chromebooks.
> 
> We can then figure out what's wrong with the HW trigger support and fix
> it for v4.8.

Agree. And below is a trivial comment.

> 
> Best regards,
> Javier
> 
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 1c23a8ff5e83..f10030ff00e6 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -170,14 +170,11 @@ static struct fimd_driver_data 
> exynos5420_fimd_driver_data = {
>   .lcdblk_vt_shift = 24,
>   .lcdblk_bypass_shift = 15,
>   .lcdblk_mic_bypass_shift = 11,
> - .trg_type = I80_HW_TRG,
>   .has_shadowcon = 1,
>   .has_vidoutcon = 1,
>   .has_vtsel = 1,
>   .has_mic_bypass = 1,
>   .has_dp_clk = 1,
> - .has_hw_trigger = 1,
> - .has_trigger_per_te = 1,

We don't need to remove above two lines. It would be enough to remove 'trg_type 
= I80_HW_TRG', which makes FIMD to be worked with SW trigger in default.

Thanks,
Inki Dae

>  };
>  
>  struct fimd_context {
> 

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

2016년 03월 31일 23:10에 Rob Clark 이(가) 쓴 글:
> On Thu, Mar 31, 2016 at 7:26 AM, Inki Dae <daei...@gmail.com> wrote:
>> Hi Daniel,
>>
>> 2016-03-31 19:56 GMT+09:00 Daniel Stone <dan...@fooishbar.org>:
>>> Hi Inki,
>>>
>>> On 31 March 2016 at 11:05, Inki Dae <inki@samsung.com> wrote:
>>>> 2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
>>>>> On 31 March 2016 at 08:45, Inki Dae <inki@samsung.com> wrote:
>>>>>> As of now, it seems that this wouldn't be optional but mandatory if 
>>>>>> explicit fence support is added to the atomic helper framework. This 
>>>>>> would definitely be duplication and it seems not clear enough even if 
>>>>>> one of them is just skipped in runtime.
>>>>>
>>>>> Drivers would have to opt in to explicit fencing support, and part of
>>>>> that would be ensuring that the driver does not wait on implicit
>>>>> fences when the user has requested explicit fencing be used.
>>>>>
>>>>
>>>> Then, existing drivers would need additional works for explicit fencing 
>>>> support. This wouldn't be really what the drivers have to but should be 
>>>> handled with this patch series because this would affect exising device 
>>>> drivers which use implicit fencing.
>>>
>>> Well, yes. Anyone implementing their own atomic commit would need to
>>> ensure that the commit works properly for fences. The helpers could
>>> also add it, but the helpers are not mandatory, and you are not
>>> required to use every part of the helper to use one part of the
>>> helper. There is no magic wand you can wave that instantly makes it
>>> work for every driver
>>
>> I meant there are already several DRM drivers which work properly for
>> implicit fence. So if atomic helper framework of DRM core is
>> considered only for the explicit fence, then fencing operation would
>> affect the existing DRM drivers. So I hope this trying could consider
>> existing implicit fence users.
>>
> 
> Note that there would be a new flag on the atomic ioctl to request

What is the new flag? And Where I could find the new flag?

> explicit fencing, and with an old kernel or a driver that does not
> support it, the ioctl would be rejected and an error returned.  The
> atomic/kms framework would of course continue to support implicit

I couldn't find where such exceptions are considered.
And as of now, I think implicit fence is implemented by drivers so hided from 
drm core framework. So how atomic/kms framework knows whether explicit or 
implicit fence is supported by driver?
Otherwise, you mean such things are TODO in the future?

There may be some logic I don't understand yet.

Thanks,
Inki Dae

> fencing.   And an explicit-fencing userspace would require a
> sufficiently new kernel and possibly some minor driver support (above
> and beyond 'struct fence' conversion).
> 
> BR,
> -R
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

2016년 03월 31일 23:10에 Rob Clark 이(가) 쓴 글:
> On Thu, Mar 31, 2016 at 7:26 AM, Inki Dae  wrote:
>> Hi Daniel,
>>
>> 2016-03-31 19:56 GMT+09:00 Daniel Stone :
>>> Hi Inki,
>>>
>>> On 31 March 2016 at 11:05, Inki Dae  wrote:
>>>> 2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
>>>>> On 31 March 2016 at 08:45, Inki Dae  wrote:
>>>>>> As of now, it seems that this wouldn't be optional but mandatory if 
>>>>>> explicit fence support is added to the atomic helper framework. This 
>>>>>> would definitely be duplication and it seems not clear enough even if 
>>>>>> one of them is just skipped in runtime.
>>>>>
>>>>> Drivers would have to opt in to explicit fencing support, and part of
>>>>> that would be ensuring that the driver does not wait on implicit
>>>>> fences when the user has requested explicit fencing be used.
>>>>>
>>>>
>>>> Then, existing drivers would need additional works for explicit fencing 
>>>> support. This wouldn't be really what the drivers have to but should be 
>>>> handled with this patch series because this would affect exising device 
>>>> drivers which use implicit fencing.
>>>
>>> Well, yes. Anyone implementing their own atomic commit would need to
>>> ensure that the commit works properly for fences. The helpers could
>>> also add it, but the helpers are not mandatory, and you are not
>>> required to use every part of the helper to use one part of the
>>> helper. There is no magic wand you can wave that instantly makes it
>>> work for every driver
>>
>> I meant there are already several DRM drivers which work properly for
>> implicit fence. So if atomic helper framework of DRM core is
>> considered only for the explicit fence, then fencing operation would
>> affect the existing DRM drivers. So I hope this trying could consider
>> existing implicit fence users.
>>
> 
> Note that there would be a new flag on the atomic ioctl to request

What is the new flag? And Where I could find the new flag?

> explicit fencing, and with an old kernel or a driver that does not
> support it, the ioctl would be rejected and an error returned.  The
> atomic/kms framework would of course continue to support implicit

I couldn't find where such exceptions are considered.
And as of now, I think implicit fence is implemented by drivers so hided from 
drm core framework. So how atomic/kms framework knows whether explicit or 
implicit fence is supported by driver?
Otherwise, you mean such things are TODO in the future?

There may be some logic I don't understand yet.

Thanks,
Inki Dae

> fencing.   And an explicit-fencing userspace would require a
> sufficiently new kernel and possibly some minor driver support (above
> and beyond 'struct fence' conversion).
> 
> BR,
> -R
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

2016-03-31 19:04 GMT+09:00 Daniel Vetter <dan...@ffwll.ch>:
> On Thu, Mar 31, 2016 at 10:35:11AM +0100, Daniel Stone wrote:
>> Well, it has to be one or the other: mixing explicit and implicit,
>> defeats the purpose of using explicit fencing. So, when explicit
>> fencing is in use, implicit fences must be ignored.
>
> You can mix it, if you're careful. CrOS wants that to better mesh android
> with Ozone, and we'll be discussing what needs to be added to be able to
> make it work implicit and explicit fencing work together, in both
> directions. Of course this should only be used for shared buffers, e.g.
> explicit syncing in an android client running on top of implicitly synced
> ozone/kms.

Good idea. I hope fence things of mainline would be more discussed so
could be considered for many cases.

Thanks,
Inki Dae

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

2016-03-31 19:04 GMT+09:00 Daniel Vetter :
> On Thu, Mar 31, 2016 at 10:35:11AM +0100, Daniel Stone wrote:
>> Well, it has to be one or the other: mixing explicit and implicit,
>> defeats the purpose of using explicit fencing. So, when explicit
>> fencing is in use, implicit fences must be ignored.
>
> You can mix it, if you're careful. CrOS wants that to better mesh android
> with Ozone, and we'll be discussing what needs to be added to be able to
> make it work implicit and explicit fencing work together, in both
> directions. Of course this should only be used for shared buffers, e.g.
> explicit syncing in an android client running on top of implicitly synced
> ozone/kms.

Good idea. I hope fence things of mainline would be more discussed so
could be considered for many cases.

Thanks,
Inki Dae

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

Hi Daniel,

2016-03-31 19:56 GMT+09:00 Daniel Stone <dan...@fooishbar.org>:
> Hi Inki,
>
> On 31 March 2016 at 11:05, Inki Dae <inki@samsung.com> wrote:
>> 2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
>>> On 31 March 2016 at 08:45, Inki Dae <inki@samsung.com> wrote:
>>>> As of now, it seems that this wouldn't be optional but mandatory if 
>>>> explicit fence support is added to the atomic helper framework. This would 
>>>> definitely be duplication and it seems not clear enough even if one of 
>>>> them is just skipped in runtime.
>>>
>>> Drivers would have to opt in to explicit fencing support, and part of
>>> that would be ensuring that the driver does not wait on implicit
>>> fences when the user has requested explicit fencing be used.
>>>
>>
>> Then, existing drivers would need additional works for explicit fencing 
>> support. This wouldn't be really what the drivers have to but should be 
>> handled with this patch series because this would affect exising device 
>> drivers which use implicit fencing.
>
> Well, yes. Anyone implementing their own atomic commit would need to
> ensure that the commit works properly for fences. The helpers could
> also add it, but the helpers are not mandatory, and you are not
> required to use every part of the helper to use one part of the
> helper. There is no magic wand you can wave that instantly makes it
> work for every driver

I meant there are already several DRM drivers which work properly for
implicit fence. So if atomic helper framework of DRM core is
considered only for the explicit fence, then fencing operation would
affect the existing DRM drivers. So I hope this trying could consider
existing implicit fence users.

Thanks,
Inki Dae
.
>
> Cheers,
> Daniel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

Hi Daniel,

2016-03-31 19:56 GMT+09:00 Daniel Stone :
> Hi Inki,
>
> On 31 March 2016 at 11:05, Inki Dae  wrote:
>> 2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
>>> On 31 March 2016 at 08:45, Inki Dae  wrote:
>>>> As of now, it seems that this wouldn't be optional but mandatory if 
>>>> explicit fence support is added to the atomic helper framework. This would 
>>>> definitely be duplication and it seems not clear enough even if one of 
>>>> them is just skipped in runtime.
>>>
>>> Drivers would have to opt in to explicit fencing support, and part of
>>> that would be ensuring that the driver does not wait on implicit
>>> fences when the user has requested explicit fencing be used.
>>>
>>
>> Then, existing drivers would need additional works for explicit fencing 
>> support. This wouldn't be really what the drivers have to but should be 
>> handled with this patch series because this would affect exising device 
>> drivers which use implicit fencing.
>
> Well, yes. Anyone implementing their own atomic commit would need to
> ensure that the commit works properly for fences. The helpers could
> also add it, but the helpers are not mandatory, and you are not
> required to use every part of the helper to use one part of the
> helper. There is no magic wand you can wave that instantly makes it
> work for every driver

I meant there are already several DRM drivers which work properly for
implicit fence. So if atomic helper framework of DRM core is
considered only for the explicit fence, then fencing operation would
affect the existing DRM drivers. So I hope this trying could consider
existing implicit fence users.

Thanks,
Inki Dae
.
>
> Cheers,
> Daniel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

Hi Daniel,

2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
> Hi Inki,
> 
> On 31 March 2016 at 08:45, Inki Dae <inki@samsung.com> wrote:
>> 2016년 03월 29일 22:23에 Rob Clark 이(가) 쓴 글:
>>> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae <inki@samsung.com> wrote:
>>>> In addition, I wonder how explicit and implicit fences could coexist 
>>>> together.
>>>> Rob said,
>>>> "Implicit sync ofc remains the default, but userspace could opt-in to 
>>>> explicit sync instead"
>>>>
>>>> This would mean that if we use explicit sync for user-space then it 
>>>> coexists with implicit sync. However, these two sync fences can't see same 
>>>> DMA buffer because explicit fence has a different file object from 
>>>> implicit one.
>>>> So in this case, I think explicit fence would need to be hung up on the 
>>>> reservation object of dmabuf object somehow. Otherwise, although they 
>>>> coexist together, are these fences - explicit and implicit - used for 
>>>> differenct purpose separately?
>>>>
>>>
>>> I'm not entirely sure about coexistance at the same time.  It ofc
>>> shouldn't be a problem for one kernel to support both kinds of
>>> userspace (pure explicit and pure implicit).  And how this would work
>>> on kms atomic ioctl (compositor/consumer) side seems clear enough..
>>> ie. some sort of flag, which if set user provides an explicit fence
>>> fd, and if not set we fall back to current behaviour (ie. get fences
>>> from resv object).
>>
>> With this patch series, users can register explicit fence(s) to atomic 
>> kms(consumer side) through kms property interface for the explicit sync.
>>
>> However, now several DRM drivers(also consumer) already have beeen using 
>> implicit fence. So while GPU(producer side) is accessing DMA buffer after 
>> registering its explicit fence to atomic kms, and if atomic commit is 
>> requested by user-space, then atomic helper framework will try to 
>> synchronize with the producer - waiting for the signal of GPU 
>> side(producer), and device specific page flip function will also try to do 
>> same thing.
> 
> Well, it has to be one or the other: mixing explicit and implicit,
> defeats the purpose of using explicit fencing. So, when explicit
> fencing is in use, implicit fences must be ignored.
> 
>> As of now, it seems that this wouldn't be optional but mandatory if explicit 
>> fence support is added to the atomic helper framework. This would definitely 
>> be duplication and it seems not clear enough even if one of them is just 
>> skipped in runtime.
> 
> Drivers would have to opt in to explicit fencing support, and part of
> that would be ensuring that the driver does not wait on implicit
> fences when the user has requested explicit fencing be used.
> 

Then, existing drivers would need additional works for explicit fencing 
support. This wouldn't be really what the drivers have to but should be handled 
with this patch series because this would affect exising device drivers which 
use implicit fencing.


Thanks,
Inki Dae

> Cheers,
> Daniel
> 
> 

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

Hi Daniel,

2016년 03월 31일 18:35에 Daniel Stone 이(가) 쓴 글:
> Hi Inki,
> 
> On 31 March 2016 at 08:45, Inki Dae  wrote:
>> 2016년 03월 29일 22:23에 Rob Clark 이(가) 쓴 글:
>>> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae  wrote:
>>>> In addition, I wonder how explicit and implicit fences could coexist 
>>>> together.
>>>> Rob said,
>>>> "Implicit sync ofc remains the default, but userspace could opt-in to 
>>>> explicit sync instead"
>>>>
>>>> This would mean that if we use explicit sync for user-space then it 
>>>> coexists with implicit sync. However, these two sync fences can't see same 
>>>> DMA buffer because explicit fence has a different file object from 
>>>> implicit one.
>>>> So in this case, I think explicit fence would need to be hung up on the 
>>>> reservation object of dmabuf object somehow. Otherwise, although they 
>>>> coexist together, are these fences - explicit and implicit - used for 
>>>> differenct purpose separately?
>>>>
>>>
>>> I'm not entirely sure about coexistance at the same time.  It ofc
>>> shouldn't be a problem for one kernel to support both kinds of
>>> userspace (pure explicit and pure implicit).  And how this would work
>>> on kms atomic ioctl (compositor/consumer) side seems clear enough..
>>> ie. some sort of flag, which if set user provides an explicit fence
>>> fd, and if not set we fall back to current behaviour (ie. get fences
>>> from resv object).
>>
>> With this patch series, users can register explicit fence(s) to atomic 
>> kms(consumer side) through kms property interface for the explicit sync.
>>
>> However, now several DRM drivers(also consumer) already have beeen using 
>> implicit fence. So while GPU(producer side) is accessing DMA buffer after 
>> registering its explicit fence to atomic kms, and if atomic commit is 
>> requested by user-space, then atomic helper framework will try to 
>> synchronize with the producer - waiting for the signal of GPU 
>> side(producer), and device specific page flip function will also try to do 
>> same thing.
> 
> Well, it has to be one or the other: mixing explicit and implicit,
> defeats the purpose of using explicit fencing. So, when explicit
> fencing is in use, implicit fences must be ignored.
> 
>> As of now, it seems that this wouldn't be optional but mandatory if explicit 
>> fence support is added to the atomic helper framework. This would definitely 
>> be duplication and it seems not clear enough even if one of them is just 
>> skipped in runtime.
> 
> Drivers would have to opt in to explicit fencing support, and part of
> that would be ensuring that the driver does not wait on implicit
> fences when the user has requested explicit fencing be used.
> 

Then, existing drivers would need additional works for explicit fencing 
support. This wouldn't be really what the drivers have to but should be handled 
with this patch series because this would affect exising device drivers which 
use implicit fencing.


Thanks,
Inki Dae

> Cheers,
> Daniel
> 
> 

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

2016년 03월 29일 22:23에 Rob Clark 이(가) 쓴 글:
> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae <inki@samsung.com> wrote:
>>
>> In addition, I wonder how explicit and implicit fences could coexist 
>> together.
>> Rob said,
>> "Implicit sync ofc remains the default, but userspace could opt-in to 
>> explicit sync instead"
>>
>> This would mean that if we use explicit sync for user-space then it coexists 
>> with implicit sync. However, these two sync fences can't see same DMA buffer 
>> because explicit fence has a different file object from implicit one.
>> So in this case, I think explicit fence would need to be hung up on the 
>> reservation object of dmabuf object somehow. Otherwise, although they 
>> coexist together, are these fences - explicit and implicit - used for 
>> differenct purpose separately?
>>
> 
> I'm not entirely sure about coexistance at the same time.  It ofc
> shouldn't be a problem for one kernel to support both kinds of
> userspace (pure explicit and pure implicit).  And how this would work
> on kms atomic ioctl (compositor/consumer) side seems clear enough..
> ie. some sort of flag, which if set user provides an explicit fence
> fd, and if not set we fall back to current behaviour (ie. get fences
> from resv object).

With this patch series, users can register explicit fence(s) to atomic 
kms(consumer side) through kms property interface for the explicit sync.

However, now several DRM drivers(also consumer) already have beeen using 
implicit fence. So while GPU(producer side) is accessing DMA buffer after 
registering its explicit fence to atomic kms, and if atomic commit is requested 
by user-space, then atomic helper framework will try to synchronize with the 
producer - waiting for the signal of GPU side(producer), and device specific 
page flip function will also try to do same thing.

As of now, it seems that this wouldn't be optional but mandatory if explicit 
fence support is added to the atomic helper framework. This would definitely be 
duplication and it seems not clear enough even if one of them is just skipped 
in runtime.

> 
> On the gpu/producer side, I think what makes sense is to both attach
> the fence to the resv objects and (optionally, specified by an submit
> ioctl flag) return a fence fd.  The other option is to add a new ioctl
> to convert an internal per-ring fence/seqno (that is already returned
> by submit ioctl) to a fence fd.. but I think that would end up with
> duplicate 'struct fence' objects on the kernel side (not sure if that

I think the problem is not that kernel just keeps duplicate fence objects 
separately but is that these fences can be performed separately for same 
purpose.

> would cause issues somehow), and might be unneeded since with
> EGL_ANDROID_native_fence_sync since we should know before glFlush() is
> called whether we want an fd or not.  But main thing I'm pondering

So I think this is not user-space issue. All users don't have to know whether 
DMA drivers support implicit fence or not so as soon as user uses explicit 
fence, the duplication would happen.

There may be something I missed so your comment would be helpful in 
understanding it.


Thanks,
Inki Dae

> here is how to sanely support the old way of userspace gl driver
> internal synchronization with new userspace on old kernel, but also
> conditionally support EGL_ANDROID_native_fence_sync if you have a new
> enough kernel.
> 
> BR,
> -R
> 
> 

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

2016년 03월 29일 22:23에 Rob Clark 이(가) 쓴 글:
> On Mon, Mar 28, 2016 at 10:18 PM, Inki Dae  wrote:
>>
>> In addition, I wonder how explicit and implicit fences could coexist 
>> together.
>> Rob said,
>> "Implicit sync ofc remains the default, but userspace could opt-in to 
>> explicit sync instead"
>>
>> This would mean that if we use explicit sync for user-space then it coexists 
>> with implicit sync. However, these two sync fences can't see same DMA buffer 
>> because explicit fence has a different file object from implicit one.
>> So in this case, I think explicit fence would need to be hung up on the 
>> reservation object of dmabuf object somehow. Otherwise, although they 
>> coexist together, are these fences - explicit and implicit - used for 
>> differenct purpose separately?
>>
> 
> I'm not entirely sure about coexistance at the same time.  It ofc
> shouldn't be a problem for one kernel to support both kinds of
> userspace (pure explicit and pure implicit).  And how this would work
> on kms atomic ioctl (compositor/consumer) side seems clear enough..
> ie. some sort of flag, which if set user provides an explicit fence
> fd, and if not set we fall back to current behaviour (ie. get fences
> from resv object).

With this patch series, users can register explicit fence(s) to atomic 
kms(consumer side) through kms property interface for the explicit sync.

However, now several DRM drivers(also consumer) already have beeen using 
implicit fence. So while GPU(producer side) is accessing DMA buffer after 
registering its explicit fence to atomic kms, and if atomic commit is requested 
by user-space, then atomic helper framework will try to synchronize with the 
producer - waiting for the signal of GPU side(producer), and device specific 
page flip function will also try to do same thing.

As of now, it seems that this wouldn't be optional but mandatory if explicit 
fence support is added to the atomic helper framework. This would definitely be 
duplication and it seems not clear enough even if one of them is just skipped 
in runtime.

> 
> On the gpu/producer side, I think what makes sense is to both attach
> the fence to the resv objects and (optionally, specified by an submit
> ioctl flag) return a fence fd.  The other option is to add a new ioctl
> to convert an internal per-ring fence/seqno (that is already returned
> by submit ioctl) to a fence fd.. but I think that would end up with
> duplicate 'struct fence' objects on the kernel side (not sure if that

I think the problem is not that kernel just keeps duplicate fence objects 
separately but is that these fences can be performed separately for same 
purpose.

> would cause issues somehow), and might be unneeded since with
> EGL_ANDROID_native_fence_sync since we should know before glFlush() is
> called whether we want an fd or not.  But main thing I'm pondering

So I think this is not user-space issue. All users don't have to know whether 
DMA drivers support implicit fence or not so as soon as user uses explicit 
fence, the duplication would happen.

There may be something I missed so your comment would be helpful in 
understanding it.


Thanks,
Inki Dae

> here is how to sanely support the old way of userspace gl driver
> internal synchronization with new userspace on old kernel, but also
> conditionally support EGL_ANDROID_native_fence_sync if you have a new
> enough kernel.
> 
> BR,
> -R
> 
> 

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

Hi Daniel,

2016년 03월 28일 22:26에 Daniel Stone 이(가) 쓴 글:
> Hi Inki,
> 
> On 28 March 2016 at 02:26, Inki Dae <inki@samsung.com> wrote:
>> 2016년 03월 25일 21:10에 Daniel Stone 이(가) 쓴 글:
>>> Second, really. Vulkan avoids implicit sync entirely, and exposes
>>> fence-like primitives throughout its whole API. These include being
>>> able to pass prerequisite fences for display (what Gustavo is adding
>>> here: something to block on before display), and also when the user
>>> acquires a buffer as a render target, it is given another prerequisite
>>> fence (the other side of what Gustavo is suggesting, i.e. the fence
>>> triggers when the buffer is no longer displayed and becomes available
>>> for rendering).
>>>
>>> In order to implement this correctly, and avoid performance bubbles,
>>> we need a primitive like this exposed through the KMS API, from both
>>> sides. This is especially important when you take the case of
>>> userspace suballocation, where userspace allocates larger blocks and
>>> divides the allocation internally for different uses. Implicit sync
>>> does not work at all for that case.
>>
>> Can you give me more details why implicit sync cannot take care of the case 
>> of userspace suballocation?
> 
> Implicit sync does not know about suballocation, so implicit will
> operate for every range in the buffer, not just the one you want.
> 
> Say you have one kernel buffer, which userspace subdivides into four
> independent buffers. It can perform operations on these buffers which
> are completely independent of each other, and an explicit sync model
> allows this independence to be kept. Implicit sync ties them together,
> so that you cannot do any operations on buffer 1 until all operations
> on buffer 2 have completed.
> 
>> And is there any reason that fence fd shouldn't dependent of DMABUF - now 
>> fence fd is a new file, not DMABUF fd?
> 
> Because dmabuf is for buffer sharing, and fences aren't buffers (they
> will never export page ranges). Is there any particular benefit you
> think you would get from doing this?

Just for consistency. As you know, implicit sync hangs DMA fence up on dmabuf 
object through reservation object so dmabuf independent explicit sync looked 
strange to me.
As you mentioned above, the suballocation would be why explicit sync should be 
indepenent of DMABUF.

In addition, I wonder how explicit and implicit fences could coexist together.
Rob said,
"Implicit sync ofc remains the default, but userspace could opt-in to explicit 
sync instead"

This would mean that if we use explicit sync for user-space then it coexists 
with implicit sync. However, these two sync fences can't see same DMA buffer 
because explicit fence has a different file object from implicit one.
So in this case, I think explicit fence would need to be hung up on the 
reservation object of dmabuf object somehow. Otherwise, although they coexist 
together, are these fences - explicit and implicit - used for differenct 
purpose separately? 

Thanks,
Inki Dae

> 
>>> good thing. This is also the model that ChromeOS is moving towards, so
>>> it becomes more important from that point of view as well.
>>
>> I think Gustavo should had explaned this path series enough to other people 
>> when posting them - ie, what relationship explict and implicit fences have, 
>> and why implicit fence - which is independent of DMABUF - is required, and 
>> what use cases there are in real users, and etc.
> 
> Fair enough, the summary could perhaps contain something like this.
> 
> Cheers,
> Daniel
> 
> 

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

Hi Daniel,

2016년 03월 28일 22:26에 Daniel Stone 이(가) 쓴 글:
> Hi Inki,
> 
> On 28 March 2016 at 02:26, Inki Dae  wrote:
>> 2016년 03월 25일 21:10에 Daniel Stone 이(가) 쓴 글:
>>> Second, really. Vulkan avoids implicit sync entirely, and exposes
>>> fence-like primitives throughout its whole API. These include being
>>> able to pass prerequisite fences for display (what Gustavo is adding
>>> here: something to block on before display), and also when the user
>>> acquires a buffer as a render target, it is given another prerequisite
>>> fence (the other side of what Gustavo is suggesting, i.e. the fence
>>> triggers when the buffer is no longer displayed and becomes available
>>> for rendering).
>>>
>>> In order to implement this correctly, and avoid performance bubbles,
>>> we need a primitive like this exposed through the KMS API, from both
>>> sides. This is especially important when you take the case of
>>> userspace suballocation, where userspace allocates larger blocks and
>>> divides the allocation internally for different uses. Implicit sync
>>> does not work at all for that case.
>>
>> Can you give me more details why implicit sync cannot take care of the case 
>> of userspace suballocation?
> 
> Implicit sync does not know about suballocation, so implicit will
> operate for every range in the buffer, not just the one you want.
> 
> Say you have one kernel buffer, which userspace subdivides into four
> independent buffers. It can perform operations on these buffers which
> are completely independent of each other, and an explicit sync model
> allows this independence to be kept. Implicit sync ties them together,
> so that you cannot do any operations on buffer 1 until all operations
> on buffer 2 have completed.
> 
>> And is there any reason that fence fd shouldn't dependent of DMABUF - now 
>> fence fd is a new file, not DMABUF fd?
> 
> Because dmabuf is for buffer sharing, and fences aren't buffers (they
> will never export page ranges). Is there any particular benefit you
> think you would get from doing this?

Just for consistency. As you know, implicit sync hangs DMA fence up on dmabuf 
object through reservation object so dmabuf independent explicit sync looked 
strange to me.
As you mentioned above, the suballocation would be why explicit sync should be 
indepenent of DMABUF.

In addition, I wonder how explicit and implicit fences could coexist together.
Rob said,
"Implicit sync ofc remains the default, but userspace could opt-in to explicit 
sync instead"

This would mean that if we use explicit sync for user-space then it coexists 
with implicit sync. However, these two sync fences can't see same DMA buffer 
because explicit fence has a different file object from implicit one.
So in this case, I think explicit fence would need to be hung up on the 
reservation object of dmabuf object somehow. Otherwise, although they coexist 
together, are these fences - explicit and implicit - used for differenct 
purpose separately? 

Thanks,
Inki Dae

> 
>>> good thing. This is also the model that ChromeOS is moving towards, so
>>> it becomes more important from that point of view as well.
>>
>> I think Gustavo should had explaned this path series enough to other people 
>> when posting them - ie, what relationship explict and implicit fences have, 
>> and why implicit fence - which is independent of DMABUF - is required, and 
>> what use cases there are in real users, and etc.
> 
> Fair enough, the summary could perhaps contain something like this.
> 
> Cheers,
> Daniel
> 
> 

Re: [PATCH 0/3] drm/exynos: Kconfig dependency fixes

[Inki Dae]

Hi Javier,

Thanks for your patch set.

Will merge them if there is no issue.

Thanks,
Inki Dae

2016년 03월 29일 10:28에 Javier Martinez Canillas 이(가) 쓴 글:
> Hello Inki,
> 
> This patch series contains some fixes for the Kconfig symbol dependencies
> of the Exynos DRM driver. They make sure that the Exynos DRM components
> and the media platform drivers that makes use of the same HW IP block are
> not enabled at the same time.
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (3):
>   drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency
>   drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency
>   drm/exynos: Make DRM_EXYNOS_FIMC depend on VIDEO_S5P_FIMC=n
> 
>  drivers/gpu/drm/exynos/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 

Re: [PATCH 0/3] drm/exynos: Kconfig dependency fixes

[Inki Dae]

Hi Javier,

Thanks for your patch set.

Will merge them if there is no issue.

Thanks,
Inki Dae

2016년 03월 29일 10:28에 Javier Martinez Canillas 이(가) 쓴 글:
> Hello Inki,
> 
> This patch series contains some fixes for the Kconfig symbol dependencies
> of the Exynos DRM driver. They make sure that the Exynos DRM components
> and the media platform drivers that makes use of the same HW IP block are
> not enabled at the same time.
> 
> Best regards,
> Javier
> 
> 
> Javier Martinez Canillas (3):
>   drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency
>   drm/exynos: Use VIDEO_SAMSUNG_EXYNOS_GSC=n as GSC Kconfig dependency
>   drm/exynos: Make DRM_EXYNOS_FIMC depend on VIDEO_S5P_FIMC=n
> 
>  drivers/gpu/drm/exynos/Kconfig | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

Hi Rob and Daniel,

2016년 03월 25일 21:10에 Daniel Stone 이(가) 쓴 글:
> Hi all,
> 
> On 25 March 2016 at 11:58, Rob Clark <robdcl...@gmail.com> wrote:
>> On Thu, Mar 24, 2016 at 7:49 PM, Inki Dae <inki@samsung.com> wrote:
>>> It's definitely different case. This tries to add new user-space interfaces 
>>> to expose fences to user-space. At least, implicit interfaces are embedded 
>>> into drivers.
>>> So I'd like to give you a question. Why exposing fences to user-space is 
>>> required? To provide easy-to-debug solution to rendering pipleline? To 
>>> provide merge fence feature?
>>
>> Well, implicit sync and explicit sync are two different cases.
>> Implicit sync ofc remains the default, but userspace could opt-in to
>> explicit sync instead.  For example, on the gpu side of things,
>> depending on flags userspace passes in to the submit ioctl we would
>> either attach the fence to all the written buffers (implicit) or
>> return it as a fence fd to userspace (explicit), which userspace could
>> then pass in to atomic ioctl to synchronize pageflip.
>>
>> And visa-versa, we can pass the pageflip (atomic) completion fence
>> back in to gpu so it doesn't start rendering the next frame until the
>> buffer is off screen.
>>
>> fwiw, currently android is the first user of explicit sync (although I
>> expect wayland/weston to follow suit).
> 
> Second, really. Vulkan avoids implicit sync entirely, and exposes
> fence-like primitives throughout its whole API. These include being
> able to pass prerequisite fences for display (what Gustavo is adding
> here: something to block on before display), and also when the user
> acquires a buffer as a render target, it is given another prerequisite
> fence (the other side of what Gustavo is suggesting, i.e. the fence
> triggers when the buffer is no longer displayed and becomes available
> for rendering).
> 
> In order to implement this correctly, and avoid performance bubbles,
> we need a primitive like this exposed through the KMS API, from both
> sides. This is especially important when you take the case of
> userspace suballocation, where userspace allocates larger blocks and
> divides the allocation internally for different uses. Implicit sync
> does not work at all for that case.

Can you give me more details why implicit sync cannot take care of the case of 
userspace suballocation?
And is there any reason that fence fd shouldn't dependent of DMABUF - now fence 
fd is a new file, not DMABUF fd?

> 
> As stated before, there are other benefits, including much better
> traceability. I would expect Wayland/Weston to also start pushing
> support for this API relatively soon.
> 
>> A couple linaro folks have
>> android running with an upstream kernel + mesa + atomic/kms hwc on a
>> couple devices (nexus7 and db410c with freedreno, and qemu with
>> virgl).  But there are some limitations due to missing the
>> EGL_ANDROID_native_fence_sync extension in mesa.  I plan to implement
>> that, but I ofc need the fence fd stuff in order to do so ;-)
> 
> Yes, having that would be a godsend for a lot of people.
> 
>>> And if we need really to expose fences to user-space and there is really 
>>> real user, then we have already good candidates, DMA-BUF-IOCTL-SYNC or 
>>> maybe fcntl system call because we share already DMA buffer between CPU <-> 
>>> DMA and DMA <-> DMA using DMABUF.
>>> For DMA-BUF-IOCTL-SYNC, I think you remember that was what I tried long 
>>> time ago because you was there. Several years ago, I tried to couple 
>>> exposing the fences to user-space with cache operation although at that 
>>> time, I really misleaded the fence machnism. My trying was also for the 
>>> potential users.
>>
>> Note that this is not (just) about sw sync, but also sync between
>> multiple hw devices.
> 
> Sync isn't quite good enough, because it's a mandatory blocking point
> for userspace. We want to push the explicit fences further down the
> line, so userspace can parallelise its work.
> 
> Even if none of the above requirements held true, I don't think being
> able to support Android is a bad thing. It's completely right to be
> worried about pushing in Android work and APIs for the sake of it -
> hence why we didn't take ADF! - but in this case it's definitely a

As least Google's ADF boosted up atomic KMS. :) 

> good thing. This is also the model that ChromeOS is moving towards, so
> it becomes more important from that point of view as well.

I think Gustavo should had explaned this path series enough to other people 
when posting them - ie, what relationship explict and implicit fences have, and 
why implicit fence - which is independent of DMABUF - is required, and what use 
cases there are in real users, and etc.


Thanks,
Inki Dae

> 
> Cheers,
> Daniel
> 
> 

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

Hi Rob and Daniel,

2016년 03월 25일 21:10에 Daniel Stone 이(가) 쓴 글:
> Hi all,
> 
> On 25 March 2016 at 11:58, Rob Clark  wrote:
>> On Thu, Mar 24, 2016 at 7:49 PM, Inki Dae  wrote:
>>> It's definitely different case. This tries to add new user-space interfaces 
>>> to expose fences to user-space. At least, implicit interfaces are embedded 
>>> into drivers.
>>> So I'd like to give you a question. Why exposing fences to user-space is 
>>> required? To provide easy-to-debug solution to rendering pipleline? To 
>>> provide merge fence feature?
>>
>> Well, implicit sync and explicit sync are two different cases.
>> Implicit sync ofc remains the default, but userspace could opt-in to
>> explicit sync instead.  For example, on the gpu side of things,
>> depending on flags userspace passes in to the submit ioctl we would
>> either attach the fence to all the written buffers (implicit) or
>> return it as a fence fd to userspace (explicit), which userspace could
>> then pass in to atomic ioctl to synchronize pageflip.
>>
>> And visa-versa, we can pass the pageflip (atomic) completion fence
>> back in to gpu so it doesn't start rendering the next frame until the
>> buffer is off screen.
>>
>> fwiw, currently android is the first user of explicit sync (although I
>> expect wayland/weston to follow suit).
> 
> Second, really. Vulkan avoids implicit sync entirely, and exposes
> fence-like primitives throughout its whole API. These include being
> able to pass prerequisite fences for display (what Gustavo is adding
> here: something to block on before display), and also when the user
> acquires a buffer as a render target, it is given another prerequisite
> fence (the other side of what Gustavo is suggesting, i.e. the fence
> triggers when the buffer is no longer displayed and becomes available
> for rendering).
> 
> In order to implement this correctly, and avoid performance bubbles,
> we need a primitive like this exposed through the KMS API, from both
> sides. This is especially important when you take the case of
> userspace suballocation, where userspace allocates larger blocks and
> divides the allocation internally for different uses. Implicit sync
> does not work at all for that case.

Can you give me more details why implicit sync cannot take care of the case of 
userspace suballocation?
And is there any reason that fence fd shouldn't dependent of DMABUF - now fence 
fd is a new file, not DMABUF fd?

> 
> As stated before, there are other benefits, including much better
> traceability. I would expect Wayland/Weston to also start pushing
> support for this API relatively soon.
> 
>> A couple linaro folks have
>> android running with an upstream kernel + mesa + atomic/kms hwc on a
>> couple devices (nexus7 and db410c with freedreno, and qemu with
>> virgl).  But there are some limitations due to missing the
>> EGL_ANDROID_native_fence_sync extension in mesa.  I plan to implement
>> that, but I ofc need the fence fd stuff in order to do so ;-)
> 
> Yes, having that would be a godsend for a lot of people.
> 
>>> And if we need really to expose fences to user-space and there is really 
>>> real user, then we have already good candidates, DMA-BUF-IOCTL-SYNC or 
>>> maybe fcntl system call because we share already DMA buffer between CPU <-> 
>>> DMA and DMA <-> DMA using DMABUF.
>>> For DMA-BUF-IOCTL-SYNC, I think you remember that was what I tried long 
>>> time ago because you was there. Several years ago, I tried to couple 
>>> exposing the fences to user-space with cache operation although at that 
>>> time, I really misleaded the fence machnism. My trying was also for the 
>>> potential users.
>>
>> Note that this is not (just) about sw sync, but also sync between
>> multiple hw devices.
> 
> Sync isn't quite good enough, because it's a mandatory blocking point
> for userspace. We want to push the explicit fences further down the
> line, so userspace can parallelise its work.
> 
> Even if none of the above requirements held true, I don't think being
> able to support Android is a bad thing. It's completely right to be
> worried about pushing in Android work and APIs for the sake of it -
> hence why we didn't take ADF! - but in this case it's definitely a

As least Google's ADF boosted up atomic KMS. :) 

> good thing. This is also the model that ChromeOS is moving towards, so
> it becomes more important from that point of view as well.

I think Gustavo should had explaned this path series enough to other people 
when posting them - ie, what relationship explict and implicit fences have, and 
why implicit fence - which is independent of DMABUF - is required, and what use 
cases there are in real users, and etc.


Thanks,
Inki Dae

> 
> Cheers,
> Daniel
> 
> 

Re: [patch 2/2] drm/exynos: mic: remove some dead code

[Inki Dae]

Hi Dan,

2016년 03월 17일 19:39에 Dan Carpenter 이(가) 쓴 글:
> We know "ret" is zero and the test makes static checkers complain so
> let's delete this printk.
> 
> Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index 890c9b1..12db353 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -130,8 +130,6 @@ static void mic_set_path(struct exynos_mic *mic, bool 
> enable)
>   val &= ~(MIC0_RGB_MUX | MIC0_I80_MUX | MIC0_ON_MUX);
>  
>   regmap_write(mic->sysreg, DSD_CFG_MUX, val);
> - if (ret)
> - DRM_ERROR("mic: Failed to read system register\n");

I think we missed to keep return value from regmap_write function,
ret = regmap_write(mic->sysreg, );
if (ret)
...

Thanks,
Inki Dae

>  }
>  
>  static int mic_sw_reset(struct exynos_mic *mic)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: [patch 2/2] drm/exynos: mic: remove some dead code

[Inki Dae]

Hi Dan,

2016년 03월 17일 19:39에 Dan Carpenter 이(가) 쓴 글:
> We know "ret" is zero and the test makes static checkers complain so
> let's delete this printk.
> 
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_mic.c 
> b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> index 890c9b1..12db353 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_mic.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_mic.c
> @@ -130,8 +130,6 @@ static void mic_set_path(struct exynos_mic *mic, bool 
> enable)
>   val &= ~(MIC0_RGB_MUX | MIC0_I80_MUX | MIC0_ON_MUX);
>  
>   regmap_write(mic->sysreg, DSD_CFG_MUX, val);
> - if (ret)
> - DRM_ERROR("mic: Failed to read system register\n");

I think we missed to keep return value from regmap_write function,
ret = regmap_write(mic->sysreg, );
if (ret)
...

Thanks,
Inki Dae

>  }
>  
>  static int mic_sw_reset(struct exynos_mic *mic)
> --
> 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: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

2016년 03월 25일 00:40에 Rob Clark 이(가) 쓴 글:
> On Thu, Mar 24, 2016 at 4:18 AM, Inki Dae <inki@samsung.com> wrote:
>> Hi,
>>
>> 2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글:
>>> From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
>>>
>>> Hi,
>>>
>>> This is a first proposal to discuss the addition of in-fences support
>>> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
>>> in DRM drivers. The new struct fence_collection contains a array with all
>>> fences that a atomic commit needs to wait on
>>
>> As I mentioned already like below,
>> http://www.spinics.net/lists/dri-devel/msg103225.html
>>
>> I don't see why Android specific thing is tried to propagate to Linux DRM. 
>> In Linux mainline, it has already implicit sync interfaces for DMA devices 
>> called dma fence which forces registering a fence obejct to DMABUF through a 
>> reservation obejct when a dmabuf object is created. However, Android sync 
>> driver creates a new file for a sync object and this would have different 
>> point of view.
>>
>> Is there anyone who can explan why Android specific thing is tried to spread 
>> into Linux DRM? Was there any consensus to use Android sync driver - which 
>> uses explicit sync interfaces - as Linux standard?
>>
> 
> btw, there is already plane_state->fence .. which I don't think has
> any users yet, but I start to use it in my patchset that converts
> drm/msm to 'struct fence'

Yes, Exynos also started it.

> 
> That said, we do need syncpt as the way to expose fences to userspace
> for explicit synchronization, but I'm not entirely sure that the

It's definitely different case. This tries to add new user-space interfaces to 
expose fences to user-space. At least, implicit interfaces are embedded into 
drivers.
So I'd like to give you a question. Why exposing fences to user-space is 
required? To provide easy-to-debug solution to rendering pipleline? To provide 
merge fence feature? 

And if we need really to expose fences to user-space and there is really real 
user, then we have already good candidates, DMA-BUF-IOCTL-SYNC or maybe fcntl 
system call because we share already DMA buffer between CPU <-> DMA and DMA <-> 
DMA using DMABUF.
For DMA-BUF-IOCTL-SYNC, I think you remember that was what I tried long time 
ago because you was there. Several years ago, I tried to couple exposing the 
fences to user-space with cache operation although at that time, I really 
misleaded the fence machnism. My trying was also for the potential users.

Anyway, my opinion is that we could expose the fences hided by DMABUF to 
user-space using interfaces it exists already around us. And for this, below 
Chromium solution would also give us some helps,
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.18/drivers/gpu/drm/drm_sync_helper.c

And in /driver/dma-buf/, there are DMABUF-centric modules so looks strange 
sync_file module of Android is placed in that directory - Android sync driver 
doesn't use really DMABUF but creates new file for their sync fence instead. 
For implicit sync interfaces for DMA devices, we use DMABUF and for explict 
sync interfaces for user-space, we use sync_file not DMABUF? That doesn't make 
sense. 

I love really Android but I feel as if we try to give a seat available to 
Android somehow.

Thanks,
Inki Dae

> various drivers ever need to see that (vs just struct fence), at least
> on the kms side of things.
> 
> BR,
> -R
> 
> 
>> Thanks,
>> Inki Dae
>>
>>>
>>> /**
>>>  * struct fence_collection - aggregate fences together
>>>  * @num_fences: number of fence in the collection.
>>>  * @user_data: user data.
>>>  * @func: user callback to put user data.
>>>  * @fences: array of @num_fences fences.
>>>  */
>>> struct fence_collection {
>>>int num_fences;
>>>void *user_data;
>>>collection_put_func_t func;
>>>struct fence *fences[];
>>> };
>>>
>>>
>>> The fence_collection is allocated and filled by sync_file_fences_get() and
>>> atomic_commit helpers can use fence_collection_wait() to wait the fences to
>>> signal.
>>>
>>> These patches depends on the sync ABI rework:
>>>
>>> https://www.spinics.net/lists/dri-devel/msg102795.html
>>>
>>> and the patch to de-stage the sync framework:
>>>
>>> https://www.spinics.net/lists/dri-devel/msg102799.html
>>>
>>>
>>> I also hacked together some sync support into modetest for testing:
>>>
>>> https

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

2016년 03월 25일 00:40에 Rob Clark 이(가) 쓴 글:
> On Thu, Mar 24, 2016 at 4:18 AM, Inki Dae  wrote:
>> Hi,
>>
>> 2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글:
>>> From: Gustavo Padovan 
>>>
>>> Hi,
>>>
>>> This is a first proposal to discuss the addition of in-fences support
>>> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
>>> in DRM drivers. The new struct fence_collection contains a array with all
>>> fences that a atomic commit needs to wait on
>>
>> As I mentioned already like below,
>> http://www.spinics.net/lists/dri-devel/msg103225.html
>>
>> I don't see why Android specific thing is tried to propagate to Linux DRM. 
>> In Linux mainline, it has already implicit sync interfaces for DMA devices 
>> called dma fence which forces registering a fence obejct to DMABUF through a 
>> reservation obejct when a dmabuf object is created. However, Android sync 
>> driver creates a new file for a sync object and this would have different 
>> point of view.
>>
>> Is there anyone who can explan why Android specific thing is tried to spread 
>> into Linux DRM? Was there any consensus to use Android sync driver - which 
>> uses explicit sync interfaces - as Linux standard?
>>
> 
> btw, there is already plane_state->fence .. which I don't think has
> any users yet, but I start to use it in my patchset that converts
> drm/msm to 'struct fence'

Yes, Exynos also started it.

> 
> That said, we do need syncpt as the way to expose fences to userspace
> for explicit synchronization, but I'm not entirely sure that the

It's definitely different case. This tries to add new user-space interfaces to 
expose fences to user-space. At least, implicit interfaces are embedded into 
drivers.
So I'd like to give you a question. Why exposing fences to user-space is 
required? To provide easy-to-debug solution to rendering pipleline? To provide 
merge fence feature? 

And if we need really to expose fences to user-space and there is really real 
user, then we have already good candidates, DMA-BUF-IOCTL-SYNC or maybe fcntl 
system call because we share already DMA buffer between CPU <-> DMA and DMA <-> 
DMA using DMABUF.
For DMA-BUF-IOCTL-SYNC, I think you remember that was what I tried long time 
ago because you was there. Several years ago, I tried to couple exposing the 
fences to user-space with cache operation although at that time, I really 
misleaded the fence machnism. My trying was also for the potential users.

Anyway, my opinion is that we could expose the fences hided by DMABUF to 
user-space using interfaces it exists already around us. And for this, below 
Chromium solution would also give us some helps,
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.18/drivers/gpu/drm/drm_sync_helper.c

And in /driver/dma-buf/, there are DMABUF-centric modules so looks strange 
sync_file module of Android is placed in that directory - Android sync driver 
doesn't use really DMABUF but creates new file for their sync fence instead. 
For implicit sync interfaces for DMA devices, we use DMABUF and for explict 
sync interfaces for user-space, we use sync_file not DMABUF? That doesn't make 
sense. 

I love really Android but I feel as if we try to give a seat available to 
Android somehow.

Thanks,
Inki Dae

> various drivers ever need to see that (vs just struct fence), at least
> on the kms side of things.
> 
> BR,
> -R
> 
> 
>> Thanks,
>> Inki Dae
>>
>>>
>>> /**
>>>  * struct fence_collection - aggregate fences together
>>>  * @num_fences: number of fence in the collection.
>>>  * @user_data: user data.
>>>  * @func: user callback to put user data.
>>>  * @fences: array of @num_fences fences.
>>>  */
>>> struct fence_collection {
>>>int num_fences;
>>>void *user_data;
>>>collection_put_func_t func;
>>>struct fence *fences[];
>>> };
>>>
>>>
>>> The fence_collection is allocated and filled by sync_file_fences_get() and
>>> atomic_commit helpers can use fence_collection_wait() to wait the fences to
>>> signal.
>>>
>>> These patches depends on the sync ABI rework:
>>>
>>> https://www.spinics.net/lists/dri-devel/msg102795.html
>>>
>>> and the patch to de-stage the sync framework:
>>>
>>> https://www.spinics.net/lists/dri-devel/msg102799.html
>>>
>>>
>>> I also hacked together some sync support into modetest for testing:
>>>
>>> https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic
>>>
>>>

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

Hi Guestavo,

2016년 03월 24일 23:39에 Gustavo Padovan 이(가) 쓴 글:
> Hi Inki,
> 
> 2016-03-24 Inki Dae <inki@samsung.com>:
> 
>> Hi,
>>
>> 2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글:
>>> From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
>>>
>>> Hi,
>>>
>>> This is a first proposal to discuss the addition of in-fences support
>>> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
>>> in DRM drivers. The new struct fence_collection contains a array with all
>>> fences that a atomic commit needs to wait on
>>
>> As I mentioned already like below,
>> http://www.spinics.net/lists/dri-devel/msg103225.html
>>
>> I don't see why Android specific thing is tried to propagate to Linux DRM. 
>> In Linux mainline, it has already implicit sync interfaces for DMA devices 
>> called dma fence which forces registering a fence obejct to DMABUF through a 
>> reservation obejct when a dmabuf object is created. However, Android sync 
>> driver creates a new file for a sync object and this would have different 
>> point of view.
>>
>> Is there anyone who can explan why Android specific thing is tried to spread 
>> into Linux DRM? Was there any consensus to use Android sync driver - which 
>> uses explicit sync interfaces - as Linux standard?
> 
> Because we want explicit fencing as the Linux standard in the future to
> be able to do smart scheduling, e.g., send async jobs to the gpu and at
> the same time send async atomic commits with sync_file fd attached so
> they can wait the GPU to finish and we don't block in userspace anymore,
> quite similar to what Android does.

GPU is also DMA device so I think the synchonization should be handled 
transparent to user-space.
And I know that Chromium guy already did similar thing with non-atomic commit 
only using implicit sync,
https://chromium.googlesource.com/chromiumos/third_party/kernel
branch name : chromeos-3.14

Of course, this approach uses a new helper framework placed in drm directory so 
I think if this framework can be moved into dma-buf directory after some 
cleanup and refactoring them if necessary.
Anyway, I'm not sure I understood the smart scheduling you mentioned but I 
think we could do what you try to do without the explicit fence.

> 
> This would still use dma-buf fences in the driver level, but it has a
> lot more advantages than implicit fencing.

You means things for rendering pipeline debugging and merging sync fences?

Thanks,
Inki Dae

> 
>   Gustavo
> 
> 

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

Hi Guestavo,

2016년 03월 24일 23:39에 Gustavo Padovan 이(가) 쓴 글:
> Hi Inki,
> 
> 2016-03-24 Inki Dae :
> 
>> Hi,
>>
>> 2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글:
>>> From: Gustavo Padovan 
>>>
>>> Hi,
>>>
>>> This is a first proposal to discuss the addition of in-fences support
>>> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
>>> in DRM drivers. The new struct fence_collection contains a array with all
>>> fences that a atomic commit needs to wait on
>>
>> As I mentioned already like below,
>> http://www.spinics.net/lists/dri-devel/msg103225.html
>>
>> I don't see why Android specific thing is tried to propagate to Linux DRM. 
>> In Linux mainline, it has already implicit sync interfaces for DMA devices 
>> called dma fence which forces registering a fence obejct to DMABUF through a 
>> reservation obejct when a dmabuf object is created. However, Android sync 
>> driver creates a new file for a sync object and this would have different 
>> point of view.
>>
>> Is there anyone who can explan why Android specific thing is tried to spread 
>> into Linux DRM? Was there any consensus to use Android sync driver - which 
>> uses explicit sync interfaces - as Linux standard?
> 
> Because we want explicit fencing as the Linux standard in the future to
> be able to do smart scheduling, e.g., send async jobs to the gpu and at
> the same time send async atomic commits with sync_file fd attached so
> they can wait the GPU to finish and we don't block in userspace anymore,
> quite similar to what Android does.

GPU is also DMA device so I think the synchonization should be handled 
transparent to user-space.
And I know that Chromium guy already did similar thing with non-atomic commit 
only using implicit sync,
https://chromium.googlesource.com/chromiumos/third_party/kernel
branch name : chromeos-3.14

Of course, this approach uses a new helper framework placed in drm directory so 
I think if this framework can be moved into dma-buf directory after some 
cleanup and refactoring them if necessary.
Anyway, I'm not sure I understood the smart scheduling you mentioned but I 
think we could do what you try to do without the explicit fence.

> 
> This would still use dma-buf fences in the driver level, but it has a
> lot more advantages than implicit fencing.

You means things for rendering pipeline debugging and merging sync fences?

Thanks,
Inki Dae

> 
>   Gustavo
> 
> 

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

Hi,

2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글:
> From: Gustavo Padovan <gustavo.pado...@collabora.co.uk>
> 
> Hi,
> 
> This is a first proposal to discuss the addition of in-fences support
> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
> in DRM drivers. The new struct fence_collection contains a array with all
> fences that a atomic commit needs to wait on

As I mentioned already like below,
http://www.spinics.net/lists/dri-devel/msg103225.html

I don't see why Android specific thing is tried to propagate to Linux DRM. In 
Linux mainline, it has already implicit sync interfaces for DMA devices called 
dma fence which forces registering a fence obejct to DMABUF through a 
reservation obejct when a dmabuf object is created. However, Android sync 
driver creates a new file for a sync object and this would have different point 
of view.

Is there anyone who can explan why Android specific thing is tried to spread 
into Linux DRM? Was there any consensus to use Android sync driver - which uses 
explicit sync interfaces - as Linux standard?

Thanks,
Inki Dae

> 
> /**
>  * struct fence_collection - aggregate fences together
>  * @num_fences: number of fence in the collection.
>  * @user_data: user data.
>  * @func: user callback to put user data.
>  * @fences: array of @num_fences fences.
>  */
> struct fence_collection {
>int num_fences;
>void *user_data;
>collection_put_func_t func;
>struct fence *fences[];
> };
> 
> 
> The fence_collection is allocated and filled by sync_file_fences_get() and
> atomic_commit helpers can use fence_collection_wait() to wait the fences to
> signal.
> 
> These patches depends on the sync ABI rework:
> 
> https://www.spinics.net/lists/dri-devel/msg102795.html
> 
> and the patch to de-stage the sync framework:
> 
> https://www.spinics.net/lists/dri-devel/msg102799.html
> 
> 
> I also hacked together some sync support into modetest for testing:
> 
> https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic
> 
> 
>   Gustavo
> 
> 
> Gustavo Padovan (6):
>   drm/fence: add FENCE_FD property to planes
>   dma-buf/fence: add struct fence_collection
>   dma-buf/sync_file: add sync_file_fences_get()
>   dma-buf/fence: add fence_collection_put()
>   dma-buf/fence: add fence_collection_wait()
>   drm/fence: support fence_collection on atomic commit
> 
>  drivers/dma-buf/fence.c | 33 +
>  drivers/dma-buf/sync_file.c | 36 
>  drivers/gpu/drm/drm_atomic.c| 13 +
>  drivers/gpu/drm/drm_atomic_helper.c | 10 ++
>  drivers/gpu/drm/drm_crtc.c  |  7 +++
>  include/drm/drm_crtc.h  |  5 -
>  include/linux/fence.h   | 19 +++
>  include/linux/sync_file.h   |  8 
>  8 files changed, 126 insertions(+), 5 deletions(-)
> 

Re: [RFC 0/6] drm/fences: add in-fences to DRM

[Inki Dae]

Hi,

2016년 03월 24일 03:47에 Gustavo Padovan 이(가) 쓴 글:
> From: Gustavo Padovan 
> 
> Hi,
> 
> This is a first proposal to discuss the addition of in-fences support
> to DRM. It adds a new struct to fence.c to abstract the use of sync_file
> in DRM drivers. The new struct fence_collection contains a array with all
> fences that a atomic commit needs to wait on

As I mentioned already like below,
http://www.spinics.net/lists/dri-devel/msg103225.html

I don't see why Android specific thing is tried to propagate to Linux DRM. In 
Linux mainline, it has already implicit sync interfaces for DMA devices called 
dma fence which forces registering a fence obejct to DMABUF through a 
reservation obejct when a dmabuf object is created. However, Android sync 
driver creates a new file for a sync object and this would have different point 
of view.

Is there anyone who can explan why Android specific thing is tried to spread 
into Linux DRM? Was there any consensus to use Android sync driver - which uses 
explicit sync interfaces - as Linux standard?

Thanks,
Inki Dae

> 
> /**
>  * struct fence_collection - aggregate fences together
>  * @num_fences: number of fence in the collection.
>  * @user_data: user data.
>  * @func: user callback to put user data.
>  * @fences: array of @num_fences fences.
>  */
> struct fence_collection {
>int num_fences;
>void *user_data;
>collection_put_func_t func;
>struct fence *fences[];
> };
> 
> 
> The fence_collection is allocated and filled by sync_file_fences_get() and
> atomic_commit helpers can use fence_collection_wait() to wait the fences to
> signal.
> 
> These patches depends on the sync ABI rework:
> 
> https://www.spinics.net/lists/dri-devel/msg102795.html
> 
> and the patch to de-stage the sync framework:
> 
> https://www.spinics.net/lists/dri-devel/msg102799.html
> 
> 
> I also hacked together some sync support into modetest for testing:
> 
> https://git.collabora.com/cgit/user/padovan/libdrm.git/log/?h=atomic
> 
> 
>   Gustavo
> 
> 
> Gustavo Padovan (6):
>   drm/fence: add FENCE_FD property to planes
>   dma-buf/fence: add struct fence_collection
>   dma-buf/sync_file: add sync_file_fences_get()
>   dma-buf/fence: add fence_collection_put()
>   dma-buf/fence: add fence_collection_wait()
>   drm/fence: support fence_collection on atomic commit
> 
>  drivers/dma-buf/fence.c | 33 +
>  drivers/dma-buf/sync_file.c | 36 
>  drivers/gpu/drm/drm_atomic.c| 13 +
>  drivers/gpu/drm/drm_atomic_helper.c | 10 ++
>  drivers/gpu/drm/drm_crtc.c  |  7 +++
>  include/drm/drm_crtc.h  |  5 -
>  include/linux/fence.h   | 19 +++
>  include/linux/sync_file.h   |  8 
>  8 files changed, 126 insertions(+), 5 deletions(-)
> 

Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

[Inki Dae]

2016년 03월 23일 08:39에 Russell King - ARM Linux 이(가) 쓴 글:
> On Wed, Mar 23, 2016 at 08:09:33AM +0900, Inki Dae wrote:
>> In this case, someone else may send an email again like you "who is going to 
>> merge?"
>> That would be why we need a maintainer.
>>
>> drm panel is already managed well by Thierry Reding without such confusion. 
> 
> You don't need a maintainer for every subdirectory just because it's
> a subdirectory...
> 
> Sometimes, having too many maintainers adds beaurocracy which becomes

Yes, but... if there is no someone who is responsible for maintainership, then 
we would receive such emails like Heiko sent "who is going to merge" 
I don't also want adding many maintainers unnecessary but drm bridge - although 
the framework is a thin and small - is used *over the ARM SoC* so that many 
confusions may happen for upstream.

So although it's small framework or just subdirectory, we would need someone 
who can manage the framework to avoid further confusion if necessary.

Thanks,
Inki Dae

> counter-productive.  dw_hdmi seems to be adequately managed so far
> without there needing to be a "DRM bridge maintainer".
> 

Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

[Inki Dae]

2016년 03월 23일 08:39에 Russell King - ARM Linux 이(가) 쓴 글:
> On Wed, Mar 23, 2016 at 08:09:33AM +0900, Inki Dae wrote:
>> In this case, someone else may send an email again like you "who is going to 
>> merge?"
>> That would be why we need a maintainer.
>>
>> drm panel is already managed well by Thierry Reding without such confusion. 
> 
> You don't need a maintainer for every subdirectory just because it's
> a subdirectory...
> 
> Sometimes, having too many maintainers adds beaurocracy which becomes

Yes, but... if there is no someone who is responsible for maintainership, then 
we would receive such emails like Heiko sent "who is going to merge" 
I don't also want adding many maintainers unnecessary but drm bridge - although 
the framework is a thin and small - is used *over the ARM SoC* so that many 
confusions may happen for upstream.

So although it's small framework or just subdirectory, we would need someone 
who can manage the framework to avoid further confusion if necessary.

Thanks,
Inki Dae

> counter-productive.  dw_hdmi seems to be adequately managed so far
> without there needing to be a "DRM bridge maintainer".
> 

Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

[Inki Dae]

2016년 03월 23일 07:52에 Heiko Stübner 이(가) 쓴 글:
> Am Mittwoch, 23. März 2016, 07:44:59 schrieb Inki Dae:
>> + Ajay kumar with Samsung email
>>
>> Hi,
>>
>> 2016년 03월 23일 07:12에 Heiko Stübner 이(가) 쓴 글:
>>> Hi,
>>>
>>> Am Dienstag, 22. März 2016, 16:19:37 schrieb Javier Martinez Canillas:
>>>> On 03/18/2016 07:53 PM, Doug Anderson wrote:
>>>>> On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang
>>>>> <caesar.upstr...@gmail.com>
>>>
>>> wrote:
>>>> Same here, this is the second time I tested this series (first time was
>>>> v6 on October 25 [2]) and I think that has been out there for too long.
>>>>
>>>>> Tested-by: Douglas Anderson <diand...@chromium.org>
>>>>
>>>> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>
>>>
>>> So we have 3 tests (Doug, Caesar and me) for the Rockchip side as well as
>>> Javier for the Exynos side based on the most recent drm state.
>>>
>>> As said by a lot of people it would be cool to get this merged soon -
>>> hopefully directly after -rc1. The only remaining question is through
>>> which
>>> tree it should go.
>>>
>>> I guess there are two basic options:
>>> - Inki takes the series - we could see the Rockchip-Ack being implied but
>>> maybe Mark can provide an explicit one
>>> - Mark takes the series with an Ack from Inki for the shared parts
>>>
>>> Inki, Mark do you have a preference?
>>
>> The problem would be that there is no drm bridge maintainer. I think the
>> most suitable person as the maintainer would be Ajay Kumar who is an author
>> of drm bridge framework. Of course, I could take them and have pull-request
>> again. But it seems a little late. Dave had already pull-request.
> 
> I really meant that for 4.7, not for the current merge window. I just want to 
> make sure it goes into a maintainer tree shortly after v4.6-rc1, before 
> something else changes the exynos-dp again :-).
> 
> 
>> To Ajay,
>> How about adding you as a drm bridge maintainer? DRM SoC driver maintainers
>> would need a person who can manage the drm bridge relevant pathes.
> 
> The previous example (dw_hdmi generalization between imx and rockchip) did 
> just go through the imx tree. So either the Samsung or Rockchip drm-trees 
> might be enough?

In this case, someone else may send an email again like you "who is going to 
merge?"
That would be why we need a maintainer.

drm panel is already managed well by Thierry Reding without such confusion. 

Thanks,
Inki Dae

> 
> 
> Heiko
> 
> 

Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

[Inki Dae]

2016년 03월 23일 07:52에 Heiko Stübner 이(가) 쓴 글:
> Am Mittwoch, 23. März 2016, 07:44:59 schrieb Inki Dae:
>> + Ajay kumar with Samsung email
>>
>> Hi,
>>
>> 2016년 03월 23일 07:12에 Heiko Stübner 이(가) 쓴 글:
>>> Hi,
>>>
>>> Am Dienstag, 22. März 2016, 16:19:37 schrieb Javier Martinez Canillas:
>>>> On 03/18/2016 07:53 PM, Doug Anderson wrote:
>>>>> On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang
>>>>> 
>>>
>>> wrote:
>>>> Same here, this is the second time I tested this series (first time was
>>>> v6 on October 25 [2]) and I think that has been out there for too long.
>>>>
>>>>> Tested-by: Douglas Anderson 
>>>>
>>>> Tested-by: Javier Martinez Canillas 
>>>
>>> So we have 3 tests (Doug, Caesar and me) for the Rockchip side as well as
>>> Javier for the Exynos side based on the most recent drm state.
>>>
>>> As said by a lot of people it would be cool to get this merged soon -
>>> hopefully directly after -rc1. The only remaining question is through
>>> which
>>> tree it should go.
>>>
>>> I guess there are two basic options:
>>> - Inki takes the series - we could see the Rockchip-Ack being implied but
>>> maybe Mark can provide an explicit one
>>> - Mark takes the series with an Ack from Inki for the shared parts
>>>
>>> Inki, Mark do you have a preference?
>>
>> The problem would be that there is no drm bridge maintainer. I think the
>> most suitable person as the maintainer would be Ajay Kumar who is an author
>> of drm bridge framework. Of course, I could take them and have pull-request
>> again. But it seems a little late. Dave had already pull-request.
> 
> I really meant that for 4.7, not for the current merge window. I just want to 
> make sure it goes into a maintainer tree shortly after v4.6-rc1, before 
> something else changes the exynos-dp again :-).
> 
> 
>> To Ajay,
>> How about adding you as a drm bridge maintainer? DRM SoC driver maintainers
>> would need a person who can manage the drm bridge relevant pathes.
> 
> The previous example (dw_hdmi generalization between imx and rockchip) did 
> just go through the imx tree. So either the Samsung or Rockchip drm-trees 
> might be enough?

In this case, someone else may send an email again like you "who is going to 
merge?"
That would be why we need a maintainer.

drm panel is already managed well by Thierry Reding without such confusion. 

Thanks,
Inki Dae

> 
> 
> Heiko
> 
> 

Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

[Inki Dae]

+ Ajay kumar with Samsung email

Hi,

2016년 03월 23일 07:12에 Heiko Stübner 이(가) 쓴 글:
> Hi,
> 
> Am Dienstag, 22. März 2016, 16:19:37 schrieb Javier Martinez Canillas:
>> On 03/18/2016 07:53 PM, Doug Anderson wrote:
>>> On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang <caesar.upstr...@gmail.com> 
> wrote:
>> Same here, this is the second time I tested this series (first time was
>> v6 on October 25 [2]) and I think that has been out there for too long.
>>
>>> Tested-by: Douglas Anderson <diand...@chromium.org>
>> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> 
> So we have 3 tests (Doug, Caesar and me) for the Rockchip side as well as 
> Javier for the Exynos side based on the most recent drm state.
> 
> As said by a lot of people it would be cool to get this merged soon - 
> hopefully directly after -rc1. The only remaining question is through which 
> tree it should go.
> 
> I guess there are two basic options:
> - Inki takes the series - we could see the Rockchip-Ack being implied but 
> maybe Mark can provide an explicit one
> - Mark takes the series with an Ack from Inki for the shared parts
> 
> Inki, Mark do you have a preference?

The problem would be that there is no drm bridge maintainer. I think the most 
suitable person as the maintainer would be Ajay Kumar who is an author of drm 
bridge framework.
Of course, I could take them and have pull-request again. But it seems a little 
late. Dave had already pull-request.

To Ajay,
How about adding you as a drm bridge maintainer? DRM SoC driver maintainers 
would need a person who can manage the drm bridge relevant pathes.

Thanks,
Inki Dae
 
> 
> Thanks
> Heiko
> 
> 

Re: Who is going to merge it [Was: Re: [PATCH v14 0/17] Add Analogix Core Display Port Driver]

[Inki Dae]

+ Ajay kumar with Samsung email

Hi,

2016년 03월 23일 07:12에 Heiko Stübner 이(가) 쓴 글:
> Hi,
> 
> Am Dienstag, 22. März 2016, 16:19:37 schrieb Javier Martinez Canillas:
>> On 03/18/2016 07:53 PM, Doug Anderson wrote:
>>> On Thu, Mar 17, 2016 at 11:41 PM, Caesar Wang  
> wrote:
>> Same here, this is the second time I tested this series (first time was
>> v6 on October 25 [2]) and I think that has been out there for too long.
>>
>>> Tested-by: Douglas Anderson 
>> Tested-by: Javier Martinez Canillas 
> 
> So we have 3 tests (Doug, Caesar and me) for the Rockchip side as well as 
> Javier for the Exynos side based on the most recent drm state.
> 
> As said by a lot of people it would be cool to get this merged soon - 
> hopefully directly after -rc1. The only remaining question is through which 
> tree it should go.
> 
> I guess there are two basic options:
> - Inki takes the series - we could see the Rockchip-Ack being implied but 
> maybe Mark can provide an explicit one
> - Mark takes the series with an Ack from Inki for the shared parts
> 
> Inki, Mark do you have a preference?

The problem would be that there is no drm bridge maintainer. I think the most 
suitable person as the maintainer would be Ajay Kumar who is an author of drm 
bridge framework.
Of course, I could take them and have pull-request again. But it seems a little 
late. Dave had already pull-request.

To Ajay,
How about adding you as a drm bridge maintainer? DRM SoC driver maintainers 
would need a person who can manage the drm bridge relevant pathes.

Thanks,
Inki Dae
 
> 
> Thanks
> Heiko
> 
> 

Re: [PATCH v8 01/17] drm: exynos: dp: convert to drm bridge mode

[Inki Dae]

2015년 10월 28일 17:19에 Yakir Yang 이(가) 쓴 글:
> In order to move exynos dp code to bridge directory,
> we need to convert driver drm bridge mode first. As
> dp driver already have a ptn3460 bridge, so we need
> to move ptn bridge to the next bridge of dp bridge.
> 
> Tested-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> Signed-off-by: Yakir Yang <y...@rock-chips.com>

Acked-by: Inki Dae <inki@samsung.com>

Thanks,
Inki Dae

> ---
> Changes in v8: None
> Changes in v7: None
> Changes in v6:
> - Fix the wrong code in previous series, and test on Samsung snow Chromebook
>   successfully, here are the detail changes:
> =>
> -   if (!dp->panel && !dp->bridge) {
> +   if (!dp->panel && !dp->ptn_bridge) {
> ret = exynos_dp_dt_parse_panel(dp);
> if (ret)
> =>
> +   encoder->bridge = bridge;
>   bridge->driver_private = dp;
> bridge->encoder = encoder;
> bridge->funcs = _dp_bridge_funcs;
> ret = drm_bridge_attach(drm_dev, bridge);
> 
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Keep author name list no changed (Jingoo)
> 
>  drivers/gpu/drm/exynos/exynos_dp_core.c | 103 
> 
>  drivers/gpu/drm/exynos/exynos_dp_core.h |   1 +
>  2 files changed, 78 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 124fb9a..aedd074 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1009,9 +1009,9 @@ static int exynos_drm_attach_lcd_bridge(struct 
> exynos_dp_device *dp,
>  {
>   int ret;
>  
> - encoder->bridge = dp->bridge;
> - dp->bridge->encoder = encoder;
> - ret = drm_bridge_attach(encoder->dev, dp->bridge);
> + encoder->bridge->next = dp->ptn_bridge;
> + dp->ptn_bridge->encoder = encoder;
> + ret = drm_bridge_attach(encoder->dev, dp->ptn_bridge);
>   if (ret) {
>   DRM_ERROR("Failed to attach bridge to drm\n");
>   return ret;
> @@ -1020,14 +1020,15 @@ static int exynos_drm_attach_lcd_bridge(struct 
> exynos_dp_device *dp,
>   return 0;
>  }
>  
> -static int exynos_dp_create_connector(struct drm_encoder *encoder)
> +static int exynos_dp_bridge_attach(struct drm_bridge *bridge)
>  {
> - struct exynos_dp_device *dp = encoder_to_dp(encoder);
> + struct exynos_dp_device *dp = bridge->driver_private;
> + struct drm_encoder *encoder = >encoder;
>   struct drm_connector *connector = >connector;
>   int ret;
>  
>   /* Pre-empt DP connector creation if there's a bridge */
> - if (dp->bridge) {
> + if (dp->ptn_bridge) {
>   ret = exynos_drm_attach_lcd_bridge(dp, encoder);
>   if (!ret)
>   return 0;
> @@ -1052,22 +1053,9 @@ static int exynos_dp_create_connector(struct 
> drm_encoder *encoder)
>   return ret;
>  }
>  
> -static bool exynos_dp_mode_fixup(struct drm_encoder *encoder,
> -  const struct drm_display_mode *mode,
> -  struct drm_display_mode *adjusted_mode)
> -{
> - return true;
> -}
> -
> -static void exynos_dp_mode_set(struct drm_encoder *encoder,
> -struct drm_display_mode *mode,
> -struct drm_display_mode *adjusted_mode)
> -{
> -}
> -
> -static void exynos_dp_enable(struct drm_encoder *encoder)
> +static void exynos_dp_bridge_enable(struct drm_bridge *bridge)
>  {
> - struct exynos_dp_device *dp = encoder_to_dp(encoder);
> + struct exynos_dp_device *dp = bridge->driver_private;
>   struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
>  
>   if (dp->dpms_mode == DRM_MODE_DPMS_ON)
> @@ -1092,9 +1080,9 @@ static void exynos_dp_enable(struct drm_encoder 
> *encoder)
>   dp->dpms_mode = DRM_MODE_DPMS_ON;
>  }
>  
> -static void exynos_dp_disable(struct drm_encoder *encoder)
> +static void exynos_dp_bridge_disable(struct drm_bridge *bridge)
>  {
> - struct exynos_dp_device *dp = encoder_to_dp(encoder);
> + struct exynos_dp_device *dp = bridge->driver_private;
>   struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
>  
>   if (dp->dpms_mode != DRM_MODE_DPMS_ON)
> @@ -1123,6 +,69 @@ static void exynos_dp_disable(struct drm_encoder 
> *encoder)
>   dp->dpms_mode = DRM_MODE_DPMS_OFF;
>  }
>  
> +static void exynos_dp_bri

Re: [PATCH v8 01/17] drm: exynos: dp: convert to drm bridge mode

[Inki Dae]

2015년 10월 28일 17:19에 Yakir Yang 이(가) 쓴 글:
> In order to move exynos dp code to bridge directory,
> we need to convert driver drm bridge mode first. As
> dp driver already have a ptn3460 bridge, so we need
> to move ptn bridge to the next bridge of dp bridge.
> 
> Tested-by: Javier Martinez Canillas 
> Signed-off-by: Yakir Yang 

Acked-by: Inki Dae 

Thanks,
Inki Dae

> ---
> Changes in v8: None
> Changes in v7: None
> Changes in v6:
> - Fix the wrong code in previous series, and test on Samsung snow Chromebook
>   successfully, here are the detail changes:
> =>
> -   if (!dp->panel && !dp->bridge) {
> +   if (!dp->panel && !dp->ptn_bridge) {
> ret = exynos_dp_dt_parse_panel(dp);
> if (ret)
> =>
> +   encoder->bridge = bridge;
>   bridge->driver_private = dp;
> bridge->encoder = encoder;
> bridge->funcs = _dp_bridge_funcs;
> ret = drm_bridge_attach(drm_dev, bridge);
> 
> Changes in v5: None
> Changes in v4: None
> Changes in v3: None
> Changes in v2:
> - Keep author name list no changed (Jingoo)
> 
>  drivers/gpu/drm/exynos/exynos_dp_core.c | 103 
> 
>  drivers/gpu/drm/exynos/exynos_dp_core.h |   1 +
>  2 files changed, 78 insertions(+), 26 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index 124fb9a..aedd074 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -1009,9 +1009,9 @@ static int exynos_drm_attach_lcd_bridge(struct 
> exynos_dp_device *dp,
>  {
>   int ret;
>  
> - encoder->bridge = dp->bridge;
> - dp->bridge->encoder = encoder;
> - ret = drm_bridge_attach(encoder->dev, dp->bridge);
> + encoder->bridge->next = dp->ptn_bridge;
> + dp->ptn_bridge->encoder = encoder;
> + ret = drm_bridge_attach(encoder->dev, dp->ptn_bridge);
>   if (ret) {
>   DRM_ERROR("Failed to attach bridge to drm\n");
>   return ret;
> @@ -1020,14 +1020,15 @@ static int exynos_drm_attach_lcd_bridge(struct 
> exynos_dp_device *dp,
>   return 0;
>  }
>  
> -static int exynos_dp_create_connector(struct drm_encoder *encoder)
> +static int exynos_dp_bridge_attach(struct drm_bridge *bridge)
>  {
> - struct exynos_dp_device *dp = encoder_to_dp(encoder);
> + struct exynos_dp_device *dp = bridge->driver_private;
> + struct drm_encoder *encoder = >encoder;
>   struct drm_connector *connector = >connector;
>   int ret;
>  
>   /* Pre-empt DP connector creation if there's a bridge */
> - if (dp->bridge) {
> + if (dp->ptn_bridge) {
>   ret = exynos_drm_attach_lcd_bridge(dp, encoder);
>   if (!ret)
>   return 0;
> @@ -1052,22 +1053,9 @@ static int exynos_dp_create_connector(struct 
> drm_encoder *encoder)
>   return ret;
>  }
>  
> -static bool exynos_dp_mode_fixup(struct drm_encoder *encoder,
> -  const struct drm_display_mode *mode,
> -  struct drm_display_mode *adjusted_mode)
> -{
> - return true;
> -}
> -
> -static void exynos_dp_mode_set(struct drm_encoder *encoder,
> -struct drm_display_mode *mode,
> -struct drm_display_mode *adjusted_mode)
> -{
> -}
> -
> -static void exynos_dp_enable(struct drm_encoder *encoder)
> +static void exynos_dp_bridge_enable(struct drm_bridge *bridge)
>  {
> - struct exynos_dp_device *dp = encoder_to_dp(encoder);
> + struct exynos_dp_device *dp = bridge->driver_private;
>   struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
>  
>   if (dp->dpms_mode == DRM_MODE_DPMS_ON)
> @@ -1092,9 +1080,9 @@ static void exynos_dp_enable(struct drm_encoder 
> *encoder)
>   dp->dpms_mode = DRM_MODE_DPMS_ON;
>  }
>  
> -static void exynos_dp_disable(struct drm_encoder *encoder)
> +static void exynos_dp_bridge_disable(struct drm_bridge *bridge)
>  {
> - struct exynos_dp_device *dp = encoder_to_dp(encoder);
> + struct exynos_dp_device *dp = bridge->driver_private;
>   struct exynos_drm_crtc *crtc = dp_to_crtc(dp);
>  
>   if (dp->dpms_mode != DRM_MODE_DPMS_ON)
> @@ -1123,6 +,69 @@ static void exynos_dp_disable(struct drm_encoder 
> *encoder)
>   dp->dpms_mode = DRM_MODE_DPMS_OFF;
>  }
>  
> +static void exynos_dp_bridge_nop(struct drm_bridge *bridge)
> +{
> + /* do nothing */
> +}
> +

Re: [PATCH] drm/exynos: fix building without CONFIG_PM_SLEEP

[Inki Dae]

Hi Arnd,

Sorry for late.

2015년 11월 18일 00:08에 Arnd Bergmann 이(가) 쓴 글:
> The runtime PM operations use the suspend/resume functions
> even when CONFIG_PM_SLEEP is not set, but this now fails
> for the exynos DRM driver:
> 
> exynos_mixer.c:1289:61: error: 'exynos_mixer_resume' undeclared here (not in 
> a function)
>   SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
> 
> This removes the #ifdef and instead marks the functions as
> __maybe_unused, which does the right thing in all cases and
> also looks nicer.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: ("drm/exynos: add pm_runtime to Mixer")
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 7498c6e76a53..fcaf71df77c1 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -1230,8 +1230,7 @@ static int mixer_remove(struct platform_device *pdev)
>   return 0;
>  }
>  
> -#ifdef CONFIG_PM_SLEEP

How about just changing it to CONFIG_PM for consistency of other kms drivers?
Actually, I had modified it to PM since original auther, Gustavo Padovan, 
posted runtime pm support.
However, it seems missing this one.

Thanks,
Inki Dae

> -static int exynos_mixer_suspend(struct device *dev)
> +static int __maybe_unused exynos_mixer_suspend(struct device *dev)
>  {
>   struct mixer_context *ctx = dev_get_drvdata(dev);
>   struct mixer_resources *res = >mixer_res;
> @@ -1247,7 +1246,7 @@ static int exynos_mixer_suspend(struct device *dev)
>   return 0;
>  }
>  
> -static int exynos_mixer_resume(struct device *dev)
> +static int __maybe_unused exynos_mixer_resume(struct device *dev)
>  {
>   struct mixer_context *ctx = dev_get_drvdata(dev);
>   struct mixer_resources *res = >mixer_res;
> @@ -1283,7 +1282,6 @@ static int exynos_mixer_resume(struct device *dev)
>  
>   return 0;
>  }
> -#endif
>  
>  static const struct dev_pm_ops exynos_mixer_pm_ops = {
>   SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
> 
> 

Re: [PATCH] drm/exynos: fix building without CONFIG_PM_SLEEP

[Inki Dae]

2016년 01월 26일 08:40에 Krzysztof Kozlowski 이(가) 쓴 글:
> 2015-11-18 0:08 GMT+09:00 Arnd Bergmann :
>> The runtime PM operations use the suspend/resume functions
>> even when CONFIG_PM_SLEEP is not set, but this now fails
>> for the exynos DRM driver:
>>
>> exynos_mixer.c:1289:61: error: 'exynos_mixer_resume' undeclared here (not in 
>> a function)
>>   SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
>>
>> This removes the #ifdef and instead marks the functions as
>> __maybe_unused, which does the right thing in all cases and
>> also looks nicer.
>>
>> Signed-off-by: Arnd Bergmann 
>> Fixes:   ("drm/exynos: add pm_runtime to Mixer")
> 
> Dear Inki,
> 
> Ping? On 4.5-rc1 this is still broken. Can you apply this for fixes
> for current rc-cycle?

Got it.

Thanks,
Inki Dae

> 
> Reviewed-by: Krzysztof Kozlowski 
> 
> Best regards,
> Krzysztof
> 
> 
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 7498c6e76a53..fcaf71df77c1 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -1230,8 +1230,7 @@ static int mixer_remove(struct platform_device *pdev)
>> return 0;
>>  }
>>
>> -#ifdef CONFIG_PM_SLEEP
>> -static int exynos_mixer_suspend(struct device *dev)
>> +static int __maybe_unused exynos_mixer_suspend(struct device *dev)
>>  {
>> struct mixer_context *ctx = dev_get_drvdata(dev);
>> struct mixer_resources *res = >mixer_res;
>> @@ -1247,7 +1246,7 @@ static int exynos_mixer_suspend(struct device *dev)
>> return 0;
>>  }
>>
>> -static int exynos_mixer_resume(struct device *dev)
>> +static int __maybe_unused exynos_mixer_resume(struct device *dev)
>>  {
>> struct mixer_context *ctx = dev_get_drvdata(dev);
>> struct mixer_resources *res = >mixer_res;
>> @@ -1283,7 +1282,6 @@ static int exynos_mixer_resume(struct device *dev)
>>
>> return 0;
>>  }
>> -#endif
>>
>>  static const struct dev_pm_ops exynos_mixer_pm_ops = {
>> SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: [PATCH] drm/exynos: fix building without CONFIG_PM_SLEEP

[Inki Dae]

Hi Arnd,

Sorry for late.

2015년 11월 18일 00:08에 Arnd Bergmann 이(가) 쓴 글:
> The runtime PM operations use the suspend/resume functions
> even when CONFIG_PM_SLEEP is not set, but this now fails
> for the exynos DRM driver:
> 
> exynos_mixer.c:1289:61: error: 'exynos_mixer_resume' undeclared here (not in 
> a function)
>   SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
> 
> This removes the #ifdef and instead marks the functions as
> __maybe_unused, which does the right thing in all cases and
> also looks nicer.
> 
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> Fixes: ("drm/exynos: add pm_runtime to Mixer")
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 7498c6e76a53..fcaf71df77c1 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -1230,8 +1230,7 @@ static int mixer_remove(struct platform_device *pdev)
>   return 0;
>  }
>  
> -#ifdef CONFIG_PM_SLEEP

How about just changing it to CONFIG_PM for consistency of other kms drivers?
Actually, I had modified it to PM since original auther, Gustavo Padovan, 
posted runtime pm support.
However, it seems missing this one.

Thanks,
Inki Dae

> -static int exynos_mixer_suspend(struct device *dev)
> +static int __maybe_unused exynos_mixer_suspend(struct device *dev)
>  {
>   struct mixer_context *ctx = dev_get_drvdata(dev);
>   struct mixer_resources *res = >mixer_res;
> @@ -1247,7 +1246,7 @@ static int exynos_mixer_suspend(struct device *dev)
>   return 0;
>  }
>  
> -static int exynos_mixer_resume(struct device *dev)
> +static int __maybe_unused exynos_mixer_resume(struct device *dev)
>  {
>   struct mixer_context *ctx = dev_get_drvdata(dev);
>   struct mixer_resources *res = >mixer_res;
> @@ -1283,7 +1282,6 @@ static int exynos_mixer_resume(struct device *dev)
>  
>   return 0;
>  }
> -#endif
>  
>  static const struct dev_pm_ops exynos_mixer_pm_ops = {
>   SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
> 
> 

Re: [PATCH] drm/exynos: fix building without CONFIG_PM_SLEEP

[Inki Dae]

2016년 01월 26일 08:40에 Krzysztof Kozlowski 이(가) 쓴 글:
> 2015-11-18 0:08 GMT+09:00 Arnd Bergmann <a...@arndb.de>:
>> The runtime PM operations use the suspend/resume functions
>> even when CONFIG_PM_SLEEP is not set, but this now fails
>> for the exynos DRM driver:
>>
>> exynos_mixer.c:1289:61: error: 'exynos_mixer_resume' undeclared here (not in 
>> a function)
>>   SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
>>
>> This removes the #ifdef and instead marks the functions as
>> __maybe_unused, which does the right thing in all cases and
>> also looks nicer.
>>
>> Signed-off-by: Arnd Bergmann <a...@arndb.de>
>> Fixes:   ("drm/exynos: add pm_runtime to Mixer")
> 
> Dear Inki,
> 
> Ping? On 4.5-rc1 this is still broken. Can you apply this for fixes
> for current rc-cycle?

Got it.

Thanks,
Inki Dae

> 
> Reviewed-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> 
> Best regards,
> Krzysztof
> 
> 
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 7498c6e76a53..fcaf71df77c1 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -1230,8 +1230,7 @@ static int mixer_remove(struct platform_device *pdev)
>> return 0;
>>  }
>>
>> -#ifdef CONFIG_PM_SLEEP
>> -static int exynos_mixer_suspend(struct device *dev)
>> +static int __maybe_unused exynos_mixer_suspend(struct device *dev)
>>  {
>> struct mixer_context *ctx = dev_get_drvdata(dev);
>> struct mixer_resources *res = >mixer_res;
>> @@ -1247,7 +1246,7 @@ static int exynos_mixer_suspend(struct device *dev)
>> return 0;
>>  }
>>
>> -static int exynos_mixer_resume(struct device *dev)
>> +static int __maybe_unused exynos_mixer_resume(struct device *dev)
>>  {
>> struct mixer_context *ctx = dev_get_drvdata(dev);
>> struct mixer_resources *res = >mixer_res;
>> @@ -1283,7 +1282,6 @@ static int exynos_mixer_resume(struct device *dev)
>>
>> return 0;
>>  }
>> -#endif
>>
>>  static const struct dev_pm_ops exynos_mixer_pm_ops = {
>> SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: [PATCH] drm/exynos: fix spelling errors

[Inki Dae]

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 
> ---
>   drivers/gpu/drm/exynos/exynos_drm_fimc.c | 16 
>   drivers/gpu/drm/exynos/exynos_drm_gsc.c  | 12 ++--
>   2 files changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 2a65235..5d00f86 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -466,7 +466,7 @@ static int fimc_src_set_fmt_order(struct fimc_context 
> *ctx, u32 fmt)
>   EXYNOS_MSCTRL_C_INT_IN_2PLANE);
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid source yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid source yuv order 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -513,7 +513,7 @@ static int fimc_src_set_fmt(struct device *dev, u32 fmt)
>   cfg |= EXYNOS_MSCTRL_INFORMAT_YCBCR420;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid source format 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid source format 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -578,7 +578,7 @@ static int fimc_src_set_transf(struct device *dev,
>   cfg1 &= ~EXYNOS_MSCTRL_FLIP_Y_MIRROR;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid degree value %d.\n", degree);
> + dev_err(ippdrv->dev, "invalid degree value %d.\n", degree);
>   return -EINVAL;
>   }
>   
> @@ -701,7 +701,7 @@ static int fimc_src_set_addr(struct device *dev,
>   property->prop_id, buf_id, buf_type);
>   
>   if (buf_id > FIMC_MAX_SRC) {
> - dev_info(ippdrv->dev, "inavlid buf_id %d.\n", buf_id);
> + dev_info(ippdrv->dev, "invalid buf_id %d.\n", buf_id);
>   return -ENOMEM;
>   }
>   
> @@ -812,7 +812,7 @@ static int fimc_dst_set_fmt_order(struct fimc_context 
> *ctx, u32 fmt)
>   cfg |= EXYNOS_CIOCTRL_YCBCR_2PLANE;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid target yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid target yuv order 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -865,7 +865,7 @@ static int fimc_dst_set_fmt(struct device *dev, u32 fmt)
>   cfg |= EXYNOS_CITRGFMT_OUTFORMAT_YCBCR420;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid target format 0x%x.\n",
> + dev_err(ippdrv->dev, "invalid target format 0x%x.\n",
>   fmt);
>   return -EINVAL;
>   }
> @@ -929,7 +929,7 @@ static int fimc_dst_set_transf(struct device *dev,
>   cfg &= ~EXYNOS_CITRGFMT_FLIP_Y_MIRROR;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid degree value %d.\n", degree);
> + dev_err(ippdrv->dev, "invalid degree value %d.\n", degree);
>   return -EINVAL;
>   }
>   
> @@ -1160,7 +1160,7 @@ static int fimc_dst_set_addr(struct device *dev,
>   property->prop_id, buf_id, buf_type);
>   
>   if (buf_id > FIMC_MAX_DST) {
> - dev_info(ippdrv->dev, "inavlid buf_id %d.\n", buf_id);
> + dev_info(ippdrv->dev, "invalid buf_id %d.\n", buf_id);
>   return -ENOMEM;
>   }
>   
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 808a0a0..11b87d2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -543,7 +543,7 @@ static int gsc_src_set_fmt(struct device *dev, u32 fmt)
>   GSC_IN_YUV420_2P);
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid target yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid target yuv order 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -595,7 +595,7 @@ static int gsc_src_set_transf(struct dev

Re: [PATCH] drm/exynos: fix spelling errors

[Inki Dae]

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 <ingi2@samsung.com>
> ---
>   drivers/gpu/drm/exynos/exynos_drm_fimc.c | 16 
>   drivers/gpu/drm/exynos/exynos_drm_gsc.c  | 12 ++--
>   2 files changed, 14 insertions(+), 14 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> index 2a65235..5d00f86 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
> @@ -466,7 +466,7 @@ static int fimc_src_set_fmt_order(struct fimc_context 
> *ctx, u32 fmt)
>   EXYNOS_MSCTRL_C_INT_IN_2PLANE);
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid source yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid source yuv order 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -513,7 +513,7 @@ static int fimc_src_set_fmt(struct device *dev, u32 fmt)
>   cfg |= EXYNOS_MSCTRL_INFORMAT_YCBCR420;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid source format 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid source format 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -578,7 +578,7 @@ static int fimc_src_set_transf(struct device *dev,
>   cfg1 &= ~EXYNOS_MSCTRL_FLIP_Y_MIRROR;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid degree value %d.\n", degree);
> + dev_err(ippdrv->dev, "invalid degree value %d.\n", degree);
>   return -EINVAL;
>   }
>   
> @@ -701,7 +701,7 @@ static int fimc_src_set_addr(struct device *dev,
>   property->prop_id, buf_id, buf_type);
>   
>   if (buf_id > FIMC_MAX_SRC) {
> - dev_info(ippdrv->dev, "inavlid buf_id %d.\n", buf_id);
> + dev_info(ippdrv->dev, "invalid buf_id %d.\n", buf_id);
>   return -ENOMEM;
>   }
>   
> @@ -812,7 +812,7 @@ static int fimc_dst_set_fmt_order(struct fimc_context 
> *ctx, u32 fmt)
>   cfg |= EXYNOS_CIOCTRL_YCBCR_2PLANE;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid target yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid target yuv order 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -865,7 +865,7 @@ static int fimc_dst_set_fmt(struct device *dev, u32 fmt)
>   cfg |= EXYNOS_CITRGFMT_OUTFORMAT_YCBCR420;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid target format 0x%x.\n",
> + dev_err(ippdrv->dev, "invalid target format 0x%x.\n",
>   fmt);
>   return -EINVAL;
>   }
> @@ -929,7 +929,7 @@ static int fimc_dst_set_transf(struct device *dev,
>   cfg &= ~EXYNOS_CITRGFMT_FLIP_Y_MIRROR;
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid degree value %d.\n", degree);
> + dev_err(ippdrv->dev, "invalid degree value %d.\n", degree);
>   return -EINVAL;
>   }
>   
> @@ -1160,7 +1160,7 @@ static int fimc_dst_set_addr(struct device *dev,
>   property->prop_id, buf_id, buf_type);
>   
>   if (buf_id > FIMC_MAX_DST) {
> - dev_info(ippdrv->dev, "inavlid buf_id %d.\n", buf_id);
> + dev_info(ippdrv->dev, "invalid buf_id %d.\n", buf_id);
>   return -ENOMEM;
>   }
>   
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> index 808a0a0..11b87d2 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
> @@ -543,7 +543,7 @@ static int gsc_src_set_fmt(struct device *dev, u32 fmt)
>   GSC_IN_YUV420_2P);
>   break;
>   default:
> - dev_err(ippdrv->dev, "inavlid target yuv order 0x%x.\n", fmt);
> + dev_err(ippdrv->dev, "invalid target yuv order 0x%x.\n", fmt);
>   return -EINVAL;
>   }
>   
> @@ -595,7 +595,7 @@ 

Re: linux-next: rebase of the drm-exynos tree

[Inki Dae]

Hi Stephen,

On 2015년 08월 18일 07:50, Stephen Rothwell wrote:
> Hi Inki,
> 
> I noticed today that your tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next)
> has been merged by Dave into his drm tree.  Unfortunately, your tree
> has also been rebased onto Linus's v4.2-rc7.  So now the commits
> 0cb600d9be30-f8f66412fa6c in your tree are duplicated of commits
> d36b3004ca2c-2a8cb4894540 in Dave's.  Please tidy this up (i.e. your
> exynos-drm/for-next branch should be commit 2a8cb4894540 or something
> later 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...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the drm-exynos tree

[Inki Dae]

t; drivers/gpu/drm/exynos/exynos_mixer.c:446:40: error: 'struct 
>>> exynos_drm_plane' has no member named 'src_height'
>>>   vp_reg_write(res, VP_SRC_HEIGHT, plane->src_height);
>>> ^
>>> drivers/gpu/drm/exynos/exynos_mixer.c:451:39: error: 'struct 
>>> exynos_drm_plane' has no member named 'crtc_width'
>>>   vp_reg_write(res, VP_DST_WIDTH, plane->crtc_width);
>>>^
>>> drivers/gpu/drm/exynos/exynos_mixer.c:454:41: error: 'struct 
>>> exynos_drm_plane' has no member named 'crtc_height'
>>>vp_reg_write(res, VP_DST_HEIGHT, plane->crtc_height / 2);
>>>  ^
>>> drivers/gpu/drm/exynos/exynos_mixer.c:457:41: error: 'struct 
>>> exynos_drm_plane' has no member named 'crtc_height'
>>>vp_reg_write(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->mode_height);
>>>^
>>> drivers/gpu/drm/exynos/exynos_mixer.c:473:30: error: 'struct 
>>> exynos_drm_plane' has no member named 'mode_height'
>>>   mixer_cfg_rgb_fmt(ctx, plane->mode_height);
>>>   ^
>>> drivers/gpu/drm/exynos/exynos_mixer.c: In function 'mixer_setup_scale':
>>> drivers/gpu/drm/exynos/exynos_mixer.c:494:11: error: 'const struct 
>>> exynos_drm_plane' has no member named 'crtc_width
>>
>> Hmm, my message was truncated ...
>>
>> I assume that there was a conflicting change in some other tree, and so
>> have dropped this tree for today (hopefully it will be fixed up soon or
>> you can tell me how to fix this).
> 
> Actually it looks like this was caused by commit
> 
>   a97f353797b4 ("drm/exynos: remove unused fields from struct 
> exynos_drm_plane")
> 
> but only exposed today (maybe by some Kconfig dependency changing so
> that drivers/gpu/drm/exynos/exynos_mixer.c is now built).

I tried to build it with multi_v7_defconfig but I couldn't see any build
error.

Below is commit of linux-next tree I tested,
commit b00278812ebaae29769666ef556abc20a4680581
Merge: ad1d24c c098dc8
Author: Stephen Rothwell 
Date:   Fri Aug 14 12:06:53 2015 +1000

Merge remote-tracking branch 'drm-exynos/exynos-drm/for-next


And today, I re-based exynos-drm/for-next on top of mainline. Could you
update and try to build it again?

Thanks,
Inki Dae

> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: rebase of the drm-exynos tree

[Inki Dae]

Hi Stephen,

On 2015년 08월 18일 07:50, Stephen Rothwell wrote:
 Hi Inki,
 
 I noticed today that your tree
 (git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git#exynos-drm/for-next)
 has been merged by Dave into his drm tree.  Unfortunately, your tree
 has also been rebased onto Linus's v4.2-rc7.  So now the commits
 0cb600d9be30-f8f66412fa6c in your tree are duplicated of commits
 d36b3004ca2c-2a8cb4894540 in Dave's.  Please tidy this up (i.e. your
 exynos-drm/for-next branch should be commit 2a8cb4894540 or something
 later 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...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the drm-exynos tree

[Inki Dae]

 'mode_height'
   mixer_cfg_rgb_fmt(ctx, plane-mode_height);
   ^
 drivers/gpu/drm/exynos/exynos_mixer.c: In function 'mixer_setup_scale':
 drivers/gpu/drm/exynos/exynos_mixer.c:494:11: error: 'const struct 
 exynos_drm_plane' has no member named 'crtc_width

 Hmm, my message was truncated ...

 I assume that there was a conflicting change in some other tree, and so
 have dropped this tree for today (hopefully it will be fixed up soon or
 you can tell me how to fix this).
 
 Actually it looks like this was caused by commit
 
   a97f353797b4 (drm/exynos: remove unused fields from struct 
 exynos_drm_plane)
 
 but only exposed today (maybe by some Kconfig dependency changing so
 that drivers/gpu/drm/exynos/exynos_mixer.c is now built).

I tried to build it with multi_v7_defconfig but I couldn't see any build
error.

Below is commit of linux-next tree I tested,
commit b00278812ebaae29769666ef556abc20a4680581
Merge: ad1d24c c098dc8
Author: Stephen Rothwell s...@canb.auug.org.au
Date:   Fri Aug 14 12:06:53 2015 +1000

Merge remote-tracking branch 'drm-exynos/exynos-drm/for-next


And today, I re-based exynos-drm/for-next on top of mainline. Could you
update and try to build it again?

Thanks,
Inki Dae

 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"

[Inki Dae]

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:02, Joonyoung Shim wrote:
>>>>>> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Today's linux-next (next-20150721) encounters boot failures on Exynos
>>>>>>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
>>>>>>>
>>>>>>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
>>>>>>> commit d80167b85024982c5f18d0481a5c248100360118
>>>>>>> Author: Joonyoung Shim 
>>>>>>> Date:   Thu Jul 2 21:49:39 2015 +0900
>>>>>>>
>>>>>>> drm/exynos: remove drm_iommu_attach_device_if_possible
>>>>>>>
>>>>>>> Already drm_iommu_attach_device checks whether support iommu 
>>>>>>> internally.
>>>>>>> It should clear channels always regardless iommu support. We didn't 
>>>>>>> know
>>>>>>> because we can detect the problem when iommu is enabled, so we don't
>>>>>>> have to use drm_iommu_attach_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 83379efbf4960f58d680371628ec04387935bd53
>>>>>>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
>>>>>>>
>>>>>>>
>>>>>>> Config: exynos
>>>>>>> Boot log from Odroid XU3-Lite attached.
>>>>>>>
>>>>>>> Any hints or ideas?
>>>>>>
>>>>>> The point that hangs is when accesses fimd register in
>>>>>> fimd_clear_channels function, so i doubt clock setting for fimd.
>>>>>>
>>>>>> It's gone something that hangs after i enable gating for ACLK_200_DISP1
>>>>>> clock.
>>>>>>
>>>>>> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
>>>>>> support. Any ideas?
>>>>>
>>>>> I think bootloader should have enabled ACLK_200_DISP1 clock and also
>>>>> device driver should enable all relevant clocks before the device
>>>>> accesses its own registers.
>>>>>
>>>>> Best way would be that the clock is enabled by common clock framework
>>>>> but it seems there is no anything that the clock framework can do it. So
>>>>> I think what we have to do is to add the clock support to device tree.
>>>>
>>>> It's not easy problem to me. Should we add which clock? I think we
>>>> cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
>>>> hierarchy, right? Then we should control gate clocks, but we have not
>>>> controlled any gate clocks using BTS_ prefix.
>>>>
>>>> The clock hierarchy from Exynos5422 user manual,
>>>> ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
>>>>HDMI PHY
>>>>MIC1
>>>>DSIM1
>>>>DPTX LINK
>>>>MDNIE1
>>>>SYSMMU_MIXER
>>>>SYSMMU_FIMD1_M0
>>>>SYSMMU_FIMD1_M1
>>>>BTS_TVM0
>>>>BTS_TVM1
>>>>BTS_FIMD1_M0
>>>>BTS_FIMD1_M1
>>>>
>>>> Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
>>>> just it should be controlled by connector drivers, e.g. dsi, dp because
>>>> fimd only can

Re: Linux-next, Exynos Octa boot fail, bisected to: drm/exynos: remove drm_iommu_attach_device_if_possible

[Inki Dae]

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:02, Joonyoung Shim wrote:
 On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
 Hi,

 Today's linux-next (next-20150721) encounters boot failures on Exynos
 Octa (Exynos5422) based boards. The boards hangs. I bisected it to:

 d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
 commit d80167b85024982c5f18d0481a5c248100360118
 Author: Joonyoung Shim jy0922.s...@samsung.com
 Date:   Thu Jul 2 21:49:39 2015 +0900

 drm/exynos: remove drm_iommu_attach_device_if_possible

 Already drm_iommu_attach_device checks whether support iommu 
 internally.
 It should clear channels always regardless iommu support. We didn't 
 know
 because we can detect the problem when iommu is enabled, so we don't
 have to use drm_iommu_attach_device_if_possible and then we can 
 remove
 drm_iommu_attach_device_if_possible and clear_channels function 
 pointer.

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 Tested-by: Marek Szyprowski m.szyprow...@samsung.com
 Signed-off-by: Inki Dae inki@samsung.com

 :04 04 83379efbf4960f58d680371628ec04387935bd53
 da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers


 Config: exynos
 Boot log from Odroid XU3-Lite attached.

 Any hints or ideas?

 The point that hangs is when accesses fimd register in
 fimd_clear_channels function, so i doubt clock setting for fimd.

 It's gone something that hangs after i enable gating for ACLK_200_DISP1
 clock.

 If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
 support. Any ideas?

 I think bootloader should have enabled ACLK_200_DISP1 clock and also
 device driver should enable all relevant clocks before the device
 accesses its own registers.

 Best way would be that the clock is enabled by common clock framework
 but it seems there is no anything that the clock framework can do it. So
 I think what we have to do is to add the clock support to device tree.

 It's not easy problem to me. Should we add which clock? I think we
 cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
 hierarchy, right? Then we should control gate clocks, but we have not
 controlled any gate clocks using BTS_ prefix.

 The clock hierarchy from Exynos5422 user manual,
 ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
HDMI PHY
MIC1
DSIM1
DPTX LINK
MDNIE1
SYSMMU_MIXER
SYSMMU_FIMD1_M0
SYSMMU_FIMD1_M1
BTS_TVM0
BTS_TVM1
BTS_FIMD1_M0
BTS_FIMD1_M1

 Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
 just it should be controlled by connector drivers, e.g. dsi, dp because
 fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
 about this, just i thought that Exynos5 SoCs don't have any gpios for
 dpi, so they cannot use dpi, right?).

 It needs to probe connector driver like dsi or dp earlier than fimd and
 fimd_bind function should return error if connector driver like dsi or
 dp was not probed. This is also not easy to me.

 In this case, if one of above gate clocks is enabled, the ACLK_200_DISP1
 should be enabled. So I guess the problem would be due to below line of
 clk-exynos5420.c,

 GATE(CLK_FIMD1, fimd1, aclk300_disp1, GATE_IP_DISP1, 0, 0, 0),

 Can you check it again after modifying it like below?,
 GATE(CLK_FIMD1, fimd1, aclk200_disp1, GATE_IP_DISP1, 0, 0, 0),

 No, parent clock of fimd1 gate clock is ACLK_300_DISP1.
 
 Yes, I checked just it through exynos5420 and exynos5422 document. I
 just guessed. So do you mean that aclk200_disp1 affects FIMD controller
 even though aclk200_disp1 isn't a parent clock of FIMD? If so, it's very
 strange.

Root problem was because it had tried to access FIMD registers before
crtc and connector driver binding is completed.

ACLK200_DISP1 will be enabled by connector driver - MIPI-DSI - of FIMD
like above clock hierarchy commented by Joonyoung.

So all we have to do would be,
1. to put off clearing channel and attaching iommu just after the
binding completion between crtc and connector drivers - in case of
Exynos drm driver, the binding is done before modeset operation.

Or 2. to enable FIMD relevant clock gates, BTS_FIMD1_M0/1 in FIMD driver.

In case of number 1, we would need to add a new interface which can
notify that crtc drivers enable their iommu units just after the binding
completion

Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"

[Inki Dae]

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 10:19 PM, Krzysztof Kozlowski wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Today's linux-next (next-20150721) encounters boot failures on Exynos
>>>>>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
>>>>>>
>>>>>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
>>>>>> commit d80167b85024982c5f18d0481a5c248100360118
>>>>>> Author: Joonyoung Shim 
>>>>>> Date:   Thu Jul 2 21:49:39 2015 +0900
>>>>>>
>>>>>> drm/exynos: remove drm_iommu_attach_device_if_possible
>>>>>>
>>>>>> Already drm_iommu_attach_device checks whether support iommu 
>>>>>> internally.
>>>>>> It should clear channels always regardless iommu support. We didn't 
>>>>>> know
>>>>>> because we can detect the problem when iommu is enabled, so we don't
>>>>>> have to use drm_iommu_attach_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 83379efbf4960f58d680371628ec04387935bd53
>>>>>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
>>>>>>
>>>>>>
>>>>>> Config: exynos
>>>>>> Boot log from Odroid XU3-Lite attached.
>>>>>>
>>>>>> Any hints or ideas?
>>>>>
>>>>> The point that hangs is when accesses fimd register in
>>>>> fimd_clear_channels function, so i doubt clock setting for fimd.
>>>>>
>>>>> It's gone something that hangs after i enable gating for ACLK_200_DISP1
>>>>> clock.
>>>>>
>>>>> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
>>>>> support. Any ideas?
>>>>
>>>> I think bootloader should have enabled ACLK_200_DISP1 clock and also
>>>> device driver should enable all relevant clocks before the device
>>>> accesses its own registers.
>>>>
>>>> Best way would be that the clock is enabled by common clock framework
>>>> but it seems there is no anything that the clock framework can do it. So
>>>> I think what we have to do is to add the clock support to device tree.
>>>
>>> It's not easy problem to me. Should we add which clock? I think we
>>> cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
>>> hierarchy, right? Then we should control gate clocks, but we have not
>>> controlled any gate clocks using BTS_ prefix.
>>>
>>> The clock hierarchy from Exynos5422 user manual,
>>> ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
>>>HDMI PHY
>>>MIC1
>>>DSIM1
>>>DPTX LINK
>>>MDNIE1
>>>SYSMMU_MIXER
>>>SYSMMU_FIMD1_M0
>>>SYSMMU_FIMD1_M1
>>>BTS_TVM0
>>>BTS_TVM1
>>>BTS_FIMD1_M0
>>>BTS_FIMD1_M1
>>>
>>> Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
>>> just it should be controlled by connector drivers, e.g. dsi, dp because
>>> fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
>>> about this, just i thought that Exynos5 SoCs don't have any gpios for
>>> dpi, so they cannot use dpi, right?).
>>>
>>> It needs to probe connector driver like dsi or dp earlier than fimd and
>>> fimd_bind function should return error if connector driver lik

Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"

[Inki Dae]

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 (next-20150721) encounters boot failures on Exynos
>>>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
>>>>
>>>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
>>>> commit d80167b85024982c5f18d0481a5c248100360118
>>>> Author: Joonyoung Shim 
>>>> Date:   Thu Jul 2 21:49:39 2015 +0900
>>>>
>>>> drm/exynos: remove drm_iommu_attach_device_if_possible
>>>>
>>>> Already drm_iommu_attach_device checks whether support iommu 
>>>> internally.
>>>> It should clear channels always regardless iommu support. We didn't 
>>>> know
>>>> because we can detect the problem when iommu is enabled, so we don't
>>>> have to use drm_iommu_attach_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 83379efbf4960f58d680371628ec04387935bd53
>>>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
>>>>
>>>>
>>>> Config: exynos
>>>> Boot log from Odroid XU3-Lite attached.
>>>>
>>>> Any hints or ideas?
>>>
>>> The point that hangs is when accesses fimd register in
>>> fimd_clear_channels function, so i doubt clock setting for fimd.
>>>
>>> It's gone something that hangs after i enable gating for ACLK_200_DISP1
>>> clock.
>>>
>>> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
>>> support. Any ideas?
>>
>> I think bootloader should have enabled ACLK_200_DISP1 clock and also
>> device driver should enable all relevant clocks before the device
>> accesses its own registers.
>>
>> Best way would be that the clock is enabled by common clock framework
>> but it seems there is no anything that the clock framework can do it. So
>> I think what we have to do is to add the clock support to device tree.
> 
> It's not easy problem to me. Should we add which clock? I think we
> cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
> hierarchy, right? Then we should control gate clocks, but we have not
> controlled any gate clocks using BTS_ prefix.
> 
> The clock hierarchy from Exynos5422 user manual,
> ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
>HDMI PHY
>MIC1
>DSIM1
>DPTX LINK
>MDNIE1
>SYSMMU_MIXER
>SYSMMU_FIMD1_M0
>SYSMMU_FIMD1_M1
>BTS_TVM0
>BTS_TVM1
>BTS_FIMD1_M0
>BTS_FIMD1_M1
> 
> Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
> just it should be controlled by connector drivers, e.g. dsi, dp because
> fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
> about this, just i thought that Exynos5 SoCs don't have any gpios for
> dpi, so they cannot use dpi, right?).
> 
> It needs to probe connector driver like dsi or dp earlier than fimd and
> fimd_bind function should return error if connector driver like dsi or
> dp was not probed. This is also not easy to me.

In this case, if one of above gate clocks is enabled, the ACLK_200_DISP1
should be enabled. So I guess the problem would be due to below line of
clk-exynos5420.c,

GATE(CLK_FIMD1, "fimd1", "aclk300_disp1", GATE_IP_DISP1, 0, 0, 0),

Can you check it again after modifying it like below?,
GATE(CLK_FIMD1, "fimd1", "aclk200_disp1", GATE_IP_DISP1, 0, 0, 0),

Thanks,
Inki Dae

> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux-next, Exynos Octa boot fail, bisected to: drm/exynos: remove drm_iommu_attach_device_if_possible

[Inki Dae]

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 (next-20150721) encounters boot failures on Exynos
 Octa (Exynos5422) based boards. The boards hangs. I bisected it to:

 d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
 commit d80167b85024982c5f18d0481a5c248100360118
 Author: Joonyoung Shim jy0922.s...@samsung.com
 Date:   Thu Jul 2 21:49:39 2015 +0900

 drm/exynos: remove drm_iommu_attach_device_if_possible

 Already drm_iommu_attach_device checks whether support iommu 
 internally.
 It should clear channels always regardless iommu support. We didn't 
 know
 because we can detect the problem when iommu is enabled, so we don't
 have to use drm_iommu_attach_device_if_possible and then we can remove
 drm_iommu_attach_device_if_possible and clear_channels function 
 pointer.

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 Tested-by: Marek Szyprowski m.szyprow...@samsung.com
 Signed-off-by: Inki Dae inki@samsung.com

 :04 04 83379efbf4960f58d680371628ec04387935bd53
 da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers


 Config: exynos
 Boot log from Odroid XU3-Lite attached.

 Any hints or ideas?

 The point that hangs is when accesses fimd register in
 fimd_clear_channels function, so i doubt clock setting for fimd.

 It's gone something that hangs after i enable gating for ACLK_200_DISP1
 clock.

 If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
 support. Any ideas?

 I think bootloader should have enabled ACLK_200_DISP1 clock and also
 device driver should enable all relevant clocks before the device
 accesses its own registers.

 Best way would be that the clock is enabled by common clock framework
 but it seems there is no anything that the clock framework can do it. So
 I think what we have to do is to add the clock support to device tree.
 
 It's not easy problem to me. Should we add which clock? I think we
 cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
 hierarchy, right? Then we should control gate clocks, but we have not
 controlled any gate clocks using BTS_ prefix.
 
 The clock hierarchy from Exynos5422 user manual,
 ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
HDMI PHY
MIC1
DSIM1
DPTX LINK
MDNIE1
SYSMMU_MIXER
SYSMMU_FIMD1_M0
SYSMMU_FIMD1_M1
BTS_TVM0
BTS_TVM1
BTS_FIMD1_M0
BTS_FIMD1_M1
 
 Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
 just it should be controlled by connector drivers, e.g. dsi, dp because
 fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
 about this, just i thought that Exynos5 SoCs don't have any gpios for
 dpi, so they cannot use dpi, right?).
 
 It needs to probe connector driver like dsi or dp earlier than fimd and
 fimd_bind function should return error if connector driver like dsi or
 dp was not probed. This is also not easy to me.

In this case, if one of above gate clocks is enabled, the ACLK_200_DISP1
should be enabled. So I guess the problem would be due to below line of
clk-exynos5420.c,

GATE(CLK_FIMD1, fimd1, aclk300_disp1, GATE_IP_DISP1, 0, 0, 0),

Can you check it again after modifying it like below?,
GATE(CLK_FIMD1, fimd1, aclk200_disp1, GATE_IP_DISP1, 0, 0, 0),

Thanks,
Inki Dae

 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux-next, Exynos Octa boot fail, bisected to: drm/exynos: remove drm_iommu_attach_device_if_possible

[Inki Dae]

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 10:19 PM, Krzysztof Kozlowski wrote:
 Hi,

 Today's linux-next (next-20150721) encounters boot failures on Exynos
 Octa (Exynos5422) based boards. The boards hangs. I bisected it to:

 d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
 commit d80167b85024982c5f18d0481a5c248100360118
 Author: Joonyoung Shim jy0922.s...@samsung.com
 Date:   Thu Jul 2 21:49:39 2015 +0900

 drm/exynos: remove drm_iommu_attach_device_if_possible

 Already drm_iommu_attach_device checks whether support iommu 
 internally.
 It should clear channels always regardless iommu support. We didn't 
 know
 because we can detect the problem when iommu is enabled, so we don't
 have to use drm_iommu_attach_device_if_possible and then we can 
 remove
 drm_iommu_attach_device_if_possible and clear_channels function 
 pointer.

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 Tested-by: Marek Szyprowski m.szyprow...@samsung.com
 Signed-off-by: Inki Dae inki@samsung.com

 :04 04 83379efbf4960f58d680371628ec04387935bd53
 da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers


 Config: exynos
 Boot log from Odroid XU3-Lite attached.

 Any hints or ideas?

 The point that hangs is when accesses fimd register in
 fimd_clear_channels function, so i doubt clock setting for fimd.

 It's gone something that hangs after i enable gating for ACLK_200_DISP1
 clock.

 If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
 support. Any ideas?

 I think bootloader should have enabled ACLK_200_DISP1 clock and also
 device driver should enable all relevant clocks before the device
 accesses its own registers.

 Best way would be that the clock is enabled by common clock framework
 but it seems there is no anything that the clock framework can do it. So
 I think what we have to do is to add the clock support to device tree.

 It's not easy problem to me. Should we add which clock? I think we
 cannot control ACLK_200_DISP1 or CLKDIV2_DISP1_BLK directly by below
 hierarchy, right? Then we should control gate clocks, but we have not
 controlled any gate clocks using BTS_ prefix.

 The clock hierarchy from Exynos5422 user manual,
 ACLK_200_DISP1 -- CLKDIV2_DISP1_BLK -- HDMI LINK
HDMI PHY
MIC1
DSIM1
DPTX LINK
MDNIE1
SYSMMU_MIXER
SYSMMU_FIMD1_M0
SYSMMU_FIMD1_M1
BTS_TVM0
BTS_TVM1
BTS_FIMD1_M0
BTS_FIMD1_M1

 Other way, IMHO, fimd driver doesn't have to enable ACLK_200_DISP1 clock,
 just it should be controlled by connector drivers, e.g. dsi, dp because
 fimd only cannot operate, so dsi or dp must need (Actually i'm not sure
 about this, just i thought that Exynos5 SoCs don't have any gpios for
 dpi, so they cannot use dpi, right?).

 It needs to probe connector driver like dsi or dp earlier than fimd and
 fimd_bind function should return error if connector driver like dsi or
 dp was not probed. This is also not easy to me.

 In this case, if one of above gate clocks is enabled, the ACLK_200_DISP1
 should be enabled. So I guess the problem would be due to below line of
 clk-exynos5420.c,

 GATE(CLK_FIMD1, fimd1, aclk300_disp1, GATE_IP_DISP1, 0, 0, 0),

 Can you check it again after modifying it like below?,
 GATE(CLK_FIMD1, fimd1, aclk200_disp1, GATE_IP_DISP1, 0, 0, 0),
 
 No, parent clock of fimd1 gate clock is ACLK_300_DISP1.

Yes, I checked just it through exynos5420 and exynos5422 document. I
just guessed. So do you mean that aclk200_disp1 affects FIMD controller
even though aclk200_disp1 isn't a parent clock of FIMD? If so, it's very
strange.

 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux-next, Exynos Octa boot fail, bisected to: "drm/exynos: remove drm_iommu_attach_device_if_possible"

[Inki Dae]

On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
> On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
>> Hi,
>>
>> Today's linux-next (next-20150721) encounters boot failures on Exynos
>> Octa (Exynos5422) based boards. The boards hangs. I bisected it to:
>>
>> d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
>> commit d80167b85024982c5f18d0481a5c248100360118
>> Author: Joonyoung Shim 
>> Date:   Thu Jul 2 21:49:39 2015 +0900
>>
>> drm/exynos: remove drm_iommu_attach_device_if_possible
>>
>> Already drm_iommu_attach_device checks whether support iommu internally.
>> It should clear channels always regardless iommu support. We didn't know
>> because we can detect the problem when iommu is enabled, so we don't
>> have to use drm_iommu_attach_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 83379efbf4960f58d680371628ec04387935bd53
>> da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers
>>
>>
>> Config: exynos
>> Boot log from Odroid XU3-Lite attached.
>>
>> Any hints or ideas?
> 
> The point that hangs is when accesses fimd register in
> fimd_clear_channels function, so i doubt clock setting for fimd.
> 
> It's gone something that hangs after i enable gating for ACLK_200_DISP1
> clock.
> 
> If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
> support. Any ideas?

I think bootloader should have enabled ACLK_200_DISP1 clock and also
device driver should enable all relevant clocks before the device
accesses its own registers.

Best way would be that the clock is enabled by common clock framework
but it seems there is no anything that the clock framework can do it. So
I think what we have to do is to add the clock support to device tree.

Other idea?

Thanks,
Inki Dae

> 
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Linux-next, Exynos Octa boot fail, bisected to: drm/exynos: remove drm_iommu_attach_device_if_possible

[Inki Dae]

On 2015년 07월 22일 11:02, Joonyoung Shim wrote:
 On 07/21/2015 10:19 PM, Krzysztof Kozlowski wrote:
 Hi,

 Today's linux-next (next-20150721) encounters boot failures on Exynos
 Octa (Exynos5422) based boards. The boards hangs. I bisected it to:

 d80167b85024982c5f18d0481a5c248100360118 is the first bad commit
 commit d80167b85024982c5f18d0481a5c248100360118
 Author: Joonyoung Shim jy0922.s...@samsung.com
 Date:   Thu Jul 2 21:49:39 2015 +0900

 drm/exynos: remove drm_iommu_attach_device_if_possible

 Already drm_iommu_attach_device checks whether support iommu internally.
 It should clear channels always regardless iommu support. We didn't know
 because we can detect the problem when iommu is enabled, so we don't
 have to use drm_iommu_attach_device_if_possible and then we can remove
 drm_iommu_attach_device_if_possible and clear_channels function pointer.

 Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
 Tested-by: Marek Szyprowski m.szyprow...@samsung.com
 Signed-off-by: Inki Dae inki@samsung.com

 :04 04 83379efbf4960f58d680371628ec04387935bd53
 da03c338b88e7cb6bda895b3dd52d78d9b6eba30 M drivers


 Config: exynos
 Boot log from Odroid XU3-Lite attached.

 Any hints or ideas?
 
 The point that hangs is when accesses fimd register in
 fimd_clear_channels function, so i doubt clock setting for fimd.
 
 It's gone something that hangs after i enable gating for ACLK_200_DISP1
 clock.
 
 If ACLK_200_DISP1 clock needs for fimd really, i'm thinking how can it
 support. Any ideas?

I think bootloader should have enabled ACLK_200_DISP1 clock and also
device driver should enable all relevant clocks before the device
accesses its own registers.

Best way would be that the clock is enabled by common clock framework
but it seems there is no anything that the clock framework can do it. So
I think what we have to do is to add the clock support to device tree.

Other idea?

Thanks,
Inki Dae

 
 Thanks.
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the drm-exynos tree

[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's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
>>> drivers/media/i2c/adv7604.o: In function `of_graph_get_endpoint_by_regs':
>>> adv7604.c:(.text+0x586c): multiple definition of 
>>> `of_graph_get_endpoint_by_regs'
>>> drivers/media/i2c/adv7343.o:adv7343.c:(.text+0xa13): first defined here
>>> drivers/media/platform/soc_camera/atmel-isi.o: In function 
>>> `of_graph_get_endpoint_by_regs':
>>> atmel-isi.c:(.text+0x1ec9): multiple definition of 
>>> `of_graph_get_endpoint_by_regs'
>>> drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
>>> first defined here
>>> drivers/media/platform/soc_camera/rcar_vin.o: In function 
>>> `of_graph_get_endpoint_by_regs':
>>> rcar_vin.c:(.text+0x307c): multiple definition of 
>>> `of_graph_get_endpoint_by_regs'
>>> drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
>>> first defined here
>>>
>>> Caused by commit:
>>>
>>>   a0f7001c18ca ("of: add helper for getting endpoint node of specific 
>>> identifiers")
>>
>> This failure is now in the drm tree (where above patch is commit
>> 8ccd0d0ca041).  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.

Sorry, Rob did already Acked-by. :)

Thanks,
Inki Dae

> 
> Thanks,
> Inki Dae
> 
>>
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the drm-exynos tree

[Inki Dae]

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's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/media/i2c/adv7604.o: In function `of_graph_get_endpoint_by_regs':
>> adv7604.c:(.text+0x586c): multiple definition of 
>> `of_graph_get_endpoint_by_regs'
>> drivers/media/i2c/adv7343.o:adv7343.c:(.text+0xa13): first defined here
>> drivers/media/platform/soc_camera/atmel-isi.o: In function 
>> `of_graph_get_endpoint_by_regs':
>> atmel-isi.c:(.text+0x1ec9): multiple definition of 
>> `of_graph_get_endpoint_by_regs'
>> drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
>> first defined here
>> drivers/media/platform/soc_camera/rcar_vin.o: In function 
>> `of_graph_get_endpoint_by_regs':
>> rcar_vin.c:(.text+0x307c): multiple definition of 
>> `of_graph_get_endpoint_by_regs'
>> drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
>> first defined here
>>
>> Caused by commit:
>>
>>   a0f7001c18ca ("of: add helper for getting endpoint node of specific 
>> identifiers")
> 
> This failure is now in the drm tree (where above patch is commit
> 8ccd0d0ca041).  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

> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the drm-exynos tree

[Inki Dae]

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 s...@canb.auug.org.au 
 wrote:

 After merging the drm-exynos tree, today's linux-next build (x86_64
 allmodconfig) failed like this:

 drivers/media/i2c/adv7604.o: In function `of_graph_get_endpoint_by_regs':
 adv7604.c:(.text+0x586c): multiple definition of 
 `of_graph_get_endpoint_by_regs'
 drivers/media/i2c/adv7343.o:adv7343.c:(.text+0xa13): first defined here
 drivers/media/platform/soc_camera/atmel-isi.o: In function 
 `of_graph_get_endpoint_by_regs':
 atmel-isi.c:(.text+0x1ec9): multiple definition of 
 `of_graph_get_endpoint_by_regs'
 drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
 first defined here
 drivers/media/platform/soc_camera/rcar_vin.o: In function 
 `of_graph_get_endpoint_by_regs':
 rcar_vin.c:(.text+0x307c): multiple definition of 
 `of_graph_get_endpoint_by_regs'
 drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
 first defined here

 Caused by commit:

   a0f7001c18ca (of: add helper for getting endpoint node of specific 
 identifiers)
 
 This failure is now in the drm tree (where above patch is commit
 8ccd0d0ca041).  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

 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the drm-exynos tree

[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 s...@canb.auug.org.au 
 wrote:

 After merging the drm-exynos tree, today's linux-next build (x86_64
 allmodconfig) failed like this:

 drivers/media/i2c/adv7604.o: In function `of_graph_get_endpoint_by_regs':
 adv7604.c:(.text+0x586c): multiple definition of 
 `of_graph_get_endpoint_by_regs'
 drivers/media/i2c/adv7343.o:adv7343.c:(.text+0xa13): first defined here
 drivers/media/platform/soc_camera/atmel-isi.o: In function 
 `of_graph_get_endpoint_by_regs':
 atmel-isi.c:(.text+0x1ec9): multiple definition of 
 `of_graph_get_endpoint_by_regs'
 drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
 first defined here
 drivers/media/platform/soc_camera/rcar_vin.o: In function 
 `of_graph_get_endpoint_by_regs':
 rcar_vin.c:(.text+0x307c): multiple definition of 
 `of_graph_get_endpoint_by_regs'
 drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
 first defined here

 Caused by commit:

   a0f7001c18ca (of: add helper for getting endpoint node of specific 
 identifiers)

 This failure is now in the drm tree (where above patch is commit
 8ccd0d0ca041).  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.

Sorry, Rob did already Acked-by. :)

Thanks,
Inki Dae

 
 Thanks,
 Inki Dae
 

 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the drm-exynos tree

[Inki Dae]

Hi Stephen,

On 2015년 06월 23일 10:52, Stephen Rothwell wrote:
> Hi Inki,
> 
> After merging the drm-exynos tree, today's linux-next build (x86_64
> allmodconfig) failed like this:

Thanks for report.

I found out this problem. That is because below patch missed "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_regs':
> adv7604.c:(.text+0x586c): multiple definition of 
> `of_graph_get_endpoint_by_regs'
> drivers/media/i2c/adv7343.o:adv7343.c:(.text+0xa13): first defined here
> drivers/media/platform/soc_camera/atmel-isi.o: In function 
> `of_graph_get_endpoint_by_regs':
> atmel-isi.c:(.text+0x1ec9): multiple definition of 
> `of_graph_get_endpoint_by_regs'
> drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
> first defined here
> drivers/media/platform/soc_camera/rcar_vin.o: In function 
> `of_graph_get_endpoint_by_regs':
> rcar_vin.c:(.text+0x307c): multiple definition of 
> `of_graph_get_endpoint_by_regs'
> drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
> first defined here
> 
> Caused by commit:
> 
>   a0f7001c18ca ("of: add helper for getting endpoint node of specific 
> identifiers")
> 
> I have used the drm-exynos from next-20150622 for today.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: build failure after merge of the drm-exynos tree

[Inki Dae]

Hi Stephen,

On 2015년 06월 23일 10:52, Stephen Rothwell wrote:
 Hi Inki,
 
 After merging the drm-exynos tree, today's linux-next build (x86_64
 allmodconfig) failed like this:

Thanks for report.

I found out this problem. That is because below patch missed 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_regs':
 adv7604.c:(.text+0x586c): multiple definition of 
 `of_graph_get_endpoint_by_regs'
 drivers/media/i2c/adv7343.o:adv7343.c:(.text+0xa13): first defined here
 drivers/media/platform/soc_camera/atmel-isi.o: In function 
 `of_graph_get_endpoint_by_regs':
 atmel-isi.c:(.text+0x1ec9): multiple definition of 
 `of_graph_get_endpoint_by_regs'
 drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
 first defined here
 drivers/media/platform/soc_camera/rcar_vin.o: In function 
 `of_graph_get_endpoint_by_regs':
 rcar_vin.c:(.text+0x307c): multiple definition of 
 `of_graph_get_endpoint_by_regs'
 drivers/media/platform/soc_camera/soc_camera.o:soc_camera.c:(.text+0x2ce3): 
 first defined here
 
 Caused by commit:
 
   a0f7001c18ca (of: add helper for getting endpoint node of specific 
 identifiers)
 
 I have used the drm-exynos from next-20150622 for today.
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/exynos: Remove unused vma field of exynos_drm_gem_obj

[Inki Dae]

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/exynos: add userptr feature for g2d module") but is
>>> not referenced anywhere.
>>>
>>> One instance of 'exynos_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
>>
> 
> I think it is a different object. The patch above removes it from
> struct g2d_cmdlist_userptr.
> However I removed it from struct exynos_drm_gem_obj, where it was
> never referenced.

Ah, right. There was my mistake.

Thanks,
Inki Dae

> 
> Best regards,
> Krzysztof
> 
>> Thanks,
>> Inki Dae
>>
>>>
>>> Signed-off-by: Krzysztof Kozlowski 
>>> ---
>>>  drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
>>>  1 file changed, 2 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
>>> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> index 308173cb4f0a..6f42e2248288 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
>>> @@ -61,7 +61,6 @@ struct exynos_drm_gem_buf {
>>>   *   or at framebuffer creation.
>>>   * @size: size requested from user, in bytes and this size is aligned
>>>   *   in page unit.
>>> - * @vma: a pointer to vm_area.
>>>   * @flags: indicate memory type to allocated buffer and cache attruibute.
>>>   *
>>>   * P.S. this object would be transferred to user as kms_bo.handle so
>>> @@ -71,7 +70,6 @@ struct exynos_drm_gem_obj {
>>>   struct drm_gem_object   base;
>>>   struct exynos_drm_gem_buf   *buffer;
>>>   unsigned long   size;
>>> - struct vm_area_struct   *vma;
>>>   unsigned intflags;
>>>  };
>>>
>>>
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/exynos: Remove unused vma field of exynos_drm_gem_obj

[Inki Dae]

On 2015년 06월 19일 14:46, Krzysztof Kozlowski wrote:
 2015-06-19 14:28 GMT+09:00 Inki Dae inki@samsung.com:
 On 2015년 06월 19일 14:23, Krzysztof Kozlowski wrote:
 The field 'vma' of 'exynos_drm_gem_obj' structure was introduced in
 2a3098ff6c21 (drm/exynos: add userptr feature for g2d module) but is
 not referenced anywhere.

 One instance of 'exynos_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

 
 I think it is a different object. The patch above removes it from
 struct g2d_cmdlist_userptr.
 However I removed it from struct exynos_drm_gem_obj, where it was
 never referenced.

Ah, right. There was my mistake.

Thanks,
Inki Dae

 
 Best regards,
 Krzysztof
 
 Thanks,
 Inki Dae


 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
  1 file changed, 2 deletions(-)

 diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
 b/drivers/gpu/drm/exynos/exynos_drm_gem.h
 index 308173cb4f0a..6f42e2248288 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
 +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
 @@ -61,7 +61,6 @@ struct exynos_drm_gem_buf {
   *   or at framebuffer creation.
   * @size: size requested from user, in bytes and this size is aligned
   *   in page unit.
 - * @vma: a pointer to vm_area.
   * @flags: indicate memory type to allocated buffer and cache attruibute.
   *
   * P.S. this object would be transferred to user as kms_bo.handle so
 @@ -71,7 +70,6 @@ struct exynos_drm_gem_obj {
   struct drm_gem_object   base;
   struct exynos_drm_gem_buf   *buffer;
   unsigned long   size;
 - struct vm_area_struct   *vma;
   unsigned intflags;
  };




 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 --
 To unsubscribe from this list: send the line unsubscribe linux-samsung-soc 
 in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/exynos: Remove unused vma field of exynos_drm_gem_obj

[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/exynos: add userptr feature for g2d module") but is
> not referenced anywhere.
> 
> One instance of 'exynos_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: Krzysztof Kozlowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
> b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> index 308173cb4f0a..6f42e2248288 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
> @@ -61,7 +61,6 @@ struct exynos_drm_gem_buf {
>   *   or at framebuffer creation.
>   * @size: size requested from user, in bytes and this size is aligned
>   *   in page unit.
> - * @vma: a pointer to vm_area.
>   * @flags: indicate memory type to allocated buffer and cache attruibute.
>   *
>   * P.S. this object would be transferred to user as kms_bo.handle so
> @@ -71,7 +70,6 @@ struct exynos_drm_gem_obj {
>   struct drm_gem_object   base;
>   struct exynos_drm_gem_buf   *buffer;
>   unsigned long   size;
> - struct vm_area_struct   *vma;
>   unsigned intflags;
>  };
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/exynos: Remove unused vma field of exynos_drm_gem_obj

[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/exynos: add userptr feature for g2d module) but is
 not referenced anywhere.
 
 One instance of 'exynos_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: Krzysztof Kozlowski k.kozlow...@samsung.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_gem.h | 2 --
  1 file changed, 2 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.h 
 b/drivers/gpu/drm/exynos/exynos_drm_gem.h
 index 308173cb4f0a..6f42e2248288 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_gem.h
 +++ b/drivers/gpu/drm/exynos/exynos_drm_gem.h
 @@ -61,7 +61,6 @@ struct exynos_drm_gem_buf {
   *   or at framebuffer creation.
   * @size: size requested from user, in bytes and this size is aligned
   *   in page unit.
 - * @vma: a pointer to vm_area.
   * @flags: indicate memory type to allocated buffer and cache attruibute.
   *
   * P.S. this object would be transferred to user as kms_bo.handle so
 @@ -71,7 +70,6 @@ struct exynos_drm_gem_obj {
   struct drm_gem_object   base;
   struct exynos_drm_gem_buf   *buffer;
   unsigned long   size;
 - struct vm_area_struct   *vma;
   unsigned intflags;
  };
  
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFT PATCH v2 2/3] drm/exynos: Constify exynos_drm_crtc_ops

[Inki Dae]

On 2015년 05월 07일 09:04, Krzysztof Kozlowski wrote:
> From: Krzysztof Kozlowski 
> 
> The Exynos DRM code does not modify the ops provided by CRTC driver in
> exynos_drm_crtc_create() call.

Please check coding style with checkpatch.pl before posting it. I can
see below warning,

WARNING: line over 80 characters
#146: FILE: drivers/gpu/drm/exynos/exynos_drm_crtc.c:244:
+  const struct exynos_drm_crtc_ops 
*ops,

WARNING: line over 80 characters
#159: FILE: drivers/gpu/drm/exynos/exynos_drm_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/gpu/drm/exynos/exynos_drm_crtc.c   | 2 +-
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h   | 2 +-
>  drivers/gpu/drm/exynos/exynos_drm_drv.h| 2 +-
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 2 +-
>  drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 2 +-
>  drivers/gpu/drm/exynos/exynos_mixer.c  | 2 +-
>  7 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
> b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> index 1f7e33f59de6..3d00df76220d 100644
> --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
> @@ -710,7 +710,7 @@ static void decon_dpms(struct exynos_drm_crtc *crtc, int 
> mode)
>   }
>  }
>  
> -static struct exynos_drm_crtc_ops decon_crtc_ops = {
> +static const struct exynos_drm_crtc_ops decon_crtc_ops = {
>   .dpms = decon_dpms,
>   .mode_fixup = decon_mode_fixup,
>   .commit = decon_commit,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> index eb49195cec5c..93f873f11f64 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
> @@ -241,7 +241,7 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
> drm_device *drm_dev,
>  struct drm_plane *plane,
>  int pipe,
>  enum exynos_drm_output_type type,
> -struct exynos_drm_crtc_ops *ops,
> +const struct exynos_drm_crtc_ops 
> *ops,
>  void *ctx)
>  {
>   struct exynos_drm_crtc *exynos_crtc;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
> b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
> index 0ecd8fc45cff..ed0994b3cb47 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
> @@ -21,7 +21,7 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
> drm_device *drm_dev,
>  struct drm_plane *plane,
>  int pipe,
>  enum exynos_drm_output_type type,
> -struct exynos_drm_crtc_ops *ops,
> +const struct exynos_drm_crtc_ops 
> *ops,
>  void *context);
>  int exynos_drm_crtc_enable_vblank(struct drm_device *dev, int pipe);
>  void exynos_drm_crtc_disable_vblank(struct drm_device *dev, int pipe);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 44f128a03aea..0e951226ca06 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -226,7 +226,7 @@ struct exynos_drm_crtc {
>   unsigned intdpms;
>   wait_queue_head_t   pending_flip_queue;
>   struct drm_pending_vblank_event *event;
> - struct exynos_drm_crtc_ops  *ops;
> + const struct exynos_drm_crtc_ops*ops;
>   void*ctx;
>  };
>  
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index 2fb95ccb5841..5c1a148525f8 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -962,7 +962,7 @@ static void fimd_dp_clock_enable(struct exynos_drm_crtc 
> *crtc, bool enable)
>   writel(DP_MIE_CLK_DP_ENABLE, ctx->regs + DP_MIE_CLKCON);
>  }
>  
> -static struct exynos_drm_crtc_ops fimd_crtc_ops = {
> +static const struct exynos_drm_crtc_ops fimd_crtc_ops = {
>   .dpms = fimd_dpms,
>

Re: [RFT PATCH v2 2/3] drm/exynos: Constify exynos_drm_crtc_ops

[Inki Dae]

On 2015년 05월 07일 09:04, Krzysztof Kozlowski wrote:
 From: Krzysztof Kozlowski k.kozlowsk...@gmail.com
 
 The Exynos DRM code does not modify the ops provided by CRTC driver in
 exynos_drm_crtc_create() call.

Please check coding style with checkpatch.pl before posting it. I can
see below warning,

WARNING: line over 80 characters
#146: FILE: drivers/gpu/drm/exynos/exynos_drm_crtc.c:244:
+  const struct exynos_drm_crtc_ops 
*ops,

WARNING: line over 80 characters
#159: FILE: drivers/gpu/drm/exynos/exynos_drm_crtc.h:24:
+  const struct exynos_drm_crtc_ops 
*ops,


I modified and merged all patches.

Thanks,
Inki Dae

 
 Signed-off-by: Krzysztof Kozlowski k.kozlowsk...@gmail.com
 
 ---
 Changes since v1:
 New patch.
 ---
  drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +-
  drivers/gpu/drm/exynos/exynos_drm_crtc.c   | 2 +-
  drivers/gpu/drm/exynos/exynos_drm_crtc.h   | 2 +-
  drivers/gpu/drm/exynos/exynos_drm_drv.h| 2 +-
  drivers/gpu/drm/exynos/exynos_drm_fimd.c   | 2 +-
  drivers/gpu/drm/exynos/exynos_drm_vidi.c   | 2 +-
  drivers/gpu/drm/exynos/exynos_mixer.c  | 2 +-
  7 files changed, 7 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c 
 b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
 index 1f7e33f59de6..3d00df76220d 100644
 --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
 +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
 @@ -710,7 +710,7 @@ static void decon_dpms(struct exynos_drm_crtc *crtc, int 
 mode)
   }
  }
  
 -static struct exynos_drm_crtc_ops decon_crtc_ops = {
 +static const struct exynos_drm_crtc_ops decon_crtc_ops = {
   .dpms = decon_dpms,
   .mode_fixup = decon_mode_fixup,
   .commit = decon_commit,
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 index eb49195cec5c..93f873f11f64 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
 @@ -241,7 +241,7 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
 drm_device *drm_dev,
  struct drm_plane *plane,
  int pipe,
  enum exynos_drm_output_type type,
 -struct exynos_drm_crtc_ops *ops,
 +const struct exynos_drm_crtc_ops 
 *ops,
  void *ctx)
  {
   struct exynos_drm_crtc *exynos_crtc;
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h 
 b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
 index 0ecd8fc45cff..ed0994b3cb47 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
 +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
 @@ -21,7 +21,7 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct 
 drm_device *drm_dev,
  struct drm_plane *plane,
  int pipe,
  enum exynos_drm_output_type type,
 -struct exynos_drm_crtc_ops *ops,
 +const struct exynos_drm_crtc_ops 
 *ops,
  void *context);
  int exynos_drm_crtc_enable_vblank(struct drm_device *dev, int pipe);
  void exynos_drm_crtc_disable_vblank(struct drm_device *dev, int pipe);
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
 b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 index 44f128a03aea..0e951226ca06 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
 +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
 @@ -226,7 +226,7 @@ struct exynos_drm_crtc {
   unsigned intdpms;
   wait_queue_head_t   pending_flip_queue;
   struct drm_pending_vblank_event *event;
 - struct exynos_drm_crtc_ops  *ops;
 + const struct exynos_drm_crtc_ops*ops;
   void*ctx;
  };
  
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 index 2fb95ccb5841..5c1a148525f8 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 @@ -962,7 +962,7 @@ static void fimd_dp_clock_enable(struct exynos_drm_crtc 
 *crtc, bool enable)
   writel(DP_MIE_CLK_DP_ENABLE, ctx-regs + DP_MIE_CLKCON);
  }
  
 -static struct exynos_drm_crtc_ops fimd_crtc_ops = {
 +static const struct exynos_drm_crtc_ops fimd_crtc_ops = {
   .dpms = fimd_dpms,
   .mode_fixup = fimd_mode_fixup,
   .commit = fimd_commit,
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c 
 b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
 index 27e84ec21694..1b3479a8db5f 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
 @@ -217,7 +217,7 @@ static int

Re: [PATCH] drm/exynos: Fix build breakage on !DRM_EXYNOS_FIMD

[Inki Dae]

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_DRM_EXYNOS_FIMD leading to build
>>>> error:
>>>
>>> No, eDP has no any dependency of FIMD but DECON. Just add dependency
>>> code like below,
>>>
>>>  config DRM_EXYNOS7_DECON
>>> bool "Exynos DRM DECON"
>>> -   depends on DRM_EXYNOS
>>> +   depends on DRM_EXYNOS && !FB_S3C
>
> Actually my commit message was not detailed enough. The FB_S3C here
> won't solve the issue because you may:
> 1, disable FIMD and FB_S3C,
> 2, enabke DECON and DP,
> and it won't compile.
>
> Currently the FIMD must be enabled if DRM_EXYNOS_DP is enabled.
>
>>
>> But it does clearly and explicitly call fimd_dp_clock_enable from
>> exynos_dp_powero{n,ff}. So the dependency you're proposing seems
>> backwards: it's not an expression of the requirements of the current
>> code (that FIMD DP code be available, i.e. CONFIG_DRM_EXYNOS_FIMD is
>> selected), but an indirect expression of another dependency
>> (CONFIG_FB_S3C disables CONFIG_DRM_EXYNOS_FIMD, so disable
>> CONFIG_FB_S3C).
>>
>> Additionally, as the call comes from exynos_dp_core.c, which is built
>> by CONFIG_DRM_EXYNOS_DP (an explicitly user-selectable option), why
>> shouldn't the dependency be there? Ah, because the dependency on DP is
>> for (DECON || FIMD), but as DECON doesn't provide
>> fimd_dp_clock_enable(), it doesn't seem like it would compile if you
>> selected DECON and not FIMD.
>>
>> So, for me, the cleanest solution would be config DRM_EXYNOS_DP gains
>> a hard dependency on DRM_EXYNOS_FIMD, at least until it can be fixed
>> to compile without FIMD.
>
> Right, you correctly pointed current dependencies. Still it looks little
> hacky because EXYNOS_DP may work with FIMD or DECON. It does not really
> need FIMD. Using ifdefs in headers is not uncommon - many core
> subsystems do this that way to provide stubs.
>
> Probably the cleanest way would be to provide by FIMD and DECON a common
> interface for DP for such operation, something like:
> struct exynos_drm_crtc {
> struct drm_crtc base;
> ...
> void (*clock_enable)(struct exynos_drm_crtc *crtc, bool enable)
> );
>
> which, if non-NULL, will be called by exynos_dp_core.c:
> static void exynos_dp_poweron(struct exynos_dp_device *dp)
> {
> ...
> if (crtc->clock_enable)
> crtc->clock_enable(crtc, true);
> }
>
> What do you think?

Good idea and you should have done so. the directly call was not good
way. Anyway, with this, fimd driver can set fimd's callbacks to
exynos_drm_crtc structure and eDP driver can call the callbacks
through its encoder. But please, keep in mind that you should set the
callbacks to Exynos specific structure - exynos_drm_crtc - because
this hardware dependency is really specific to Exynos SoC.

Thanks,
Inki Dae

>
> Best regards,
> Krzysztof
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/exynos: Fix build breakage on !DRM_EXYNOS_FIMD

[Inki Dae]

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, eDP has no any dependency of FIMD but DECON. Just add dependency
>> code like below,
>>
>>  config DRM_EXYNOS7_DECON
>> bool "Exynos DRM DECON"
>> -   depends on DRM_EXYNOS
>> +   depends on DRM_EXYNOS && !FB_S3C
>
> But it does clearly and explicitly call fimd_dp_clock_enable from
> exynos_dp_powero{n,ff}. So the dependency you're proposing seems
> backwards: it's not an expression of the requirements of the current
> code (that FIMD DP code be available, i.e. CONFIG_DRM_EXYNOS_FIMD is
> selected), but an indirect expression of another dependency
> (CONFIG_FB_S3C disables CONFIG_DRM_EXYNOS_FIMD, so disable
> CONFIG_FB_S3C).
>
> Additionally, as the call comes from exynos_dp_core.c, which is built
> by CONFIG_DRM_EXYNOS_DP (an explicitly user-selectable option), why
> shouldn't the dependency be there? Ah, because the dependency on DP is
> for (DECON || FIMD), but as DECON doesn't provide
> fimd_dp_clock_enable(), it doesn't seem like it would compile if you

Please know that the output data of DECON and FIMD can go to DSI or
Panel directly not through eDP. This means that they - FIMD and eDP or
DECON and eDP - have hardware dependency each other. DECON driver
missed this - only one of Linux framebuffer and DRM KMS driver should
be selected because Linux framebuffer and DRM KMS drivers control same
hardware. So the reason that DECON driver should have dependency on
eDP is not because dp core functions are called by FIMD driver.

In addition, from hw point of view, eDP has depencency on DECON and
FIMD because eDP cannot work itself without DECON or FIMD. Therefore,
if DECON or FIMD is not selected, then eDP should also be disabled  so
that user cannot disable eDP with FIMD because FIMD driver calls eDP's
functions directly. My missing point was that even though we add
!S3C_FB to DECON Kconfig, we can disable eDP with FIMD so build error
can still occur. The best way to resolve this issue would be to move
the functions called by FIMD driver directly to Exynos specific KMS
structure such as exynos crtc - eDP driver implements encoder which
know crtc to FIMD or DECON. The directly call was not good way.

Thanks,
Inki Dae

> selected DECON and not FIMD.
>
> So, for me, the cleanest solution would be config DRM_EXYNOS_DP gains
> a hard dependency on DRM_EXYNOS_FIMD, at least until it can be fixed
> to compile without FIMD.
>
> Cheers,
> Daniel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/exynos: mixer: Constify platform_device_id

[Inki Dae]

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 changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index fbec750574e6..512549a35e96 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -1156,7 +1156,7 @@ static struct mixer_drv_data exynos4210_mxr_drv_data = {
>   .has_sclk = 1,
>  };
>  
> -static struct platform_device_id mixer_driver_types[] = {
> +static const struct platform_device_id mixer_driver_types[] = {
>   {
>   .name   = "s5p-mixer",
>   .driver_data= (unsigned long)_mxr_drv_data,
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/exynos: Fix build breakage on !DRM_EXYNOS_FIMD

[Inki Dae]

On 2015년 05월 02일 13:08, Krzysztof Kozlowski wrote:
> Selecting CONFIG_FB_S3C disables CONFIG_DRM_EXYNOS_FIMD leading to build
> error:

No, eDP has no any dependency of FIMD but DECON. Just add dependency
code like below,

 config DRM_EXYNOS7_DECON
bool "Exynos DRM DECON"
-   depends on DRM_EXYNOS
+   depends on DRM_EXYNOS && !FB_S3C

> 
> drivers/built-in.o: In function `exynos_dp_dpms':
> binder.c:(.text+0xd6a840): undefined reference to `fimd_dp_clock_enable'
> binder.c:(.text+0xd6ab54): undefined reference to `fimd_dp_clock_enable'
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_fimd.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.h 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.h
> index b4fcaa568456..db67f3d9786d 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.h
> @@ -10,6 +10,10 @@
>  #ifndef _EXYNOS_DRM_FIMD_H_
>  #define _EXYNOS_DRM_FIMD_H_
>  
> +#ifdef CONFIG_DRM_EXYNOS_FIMD
>  extern void fimd_dp_clock_enable(struct exynos_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_ */
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/exynos: Fix build breakage on !DRM_EXYNOS_FIMD

[Inki Dae]

On 2015년 05월 02일 13:08, Krzysztof Kozlowski wrote:
 Selecting CONFIG_FB_S3C disables CONFIG_DRM_EXYNOS_FIMD leading to build
 error:

No, eDP has no any dependency of FIMD but DECON. Just add dependency
code like below,

 config DRM_EXYNOS7_DECON
bool Exynos DRM DECON
-   depends on DRM_EXYNOS
+   depends on DRM_EXYNOS  !FB_S3C

 
 drivers/built-in.o: In function `exynos_dp_dpms':
 binder.c:(.text+0xd6a840): undefined reference to `fimd_dp_clock_enable'
 binder.c:(.text+0xd6ab54): undefined reference to `fimd_dp_clock_enable'
 
 Signed-off-by: Krzysztof Kozlowski k.kozlowsk...@gmail.com
 ---
  drivers/gpu/drm/exynos/exynos_drm_fimd.h | 4 
  1 file changed, 4 insertions(+)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.h 
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.h
 index b4fcaa568456..db67f3d9786d 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.h
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.h
 @@ -10,6 +10,10 @@
  #ifndef _EXYNOS_DRM_FIMD_H_
  #define _EXYNOS_DRM_FIMD_H_
  
 +#ifdef CONFIG_DRM_EXYNOS_FIMD
  extern void fimd_dp_clock_enable(struct exynos_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_ */
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/exynos: mixer: Constify platform_device_id

[Inki Dae]

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 k.kozlowsk...@gmail.com
 ---
  drivers/gpu/drm/exynos/exynos_mixer.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
 b/drivers/gpu/drm/exynos/exynos_mixer.c
 index fbec750574e6..512549a35e96 100644
 --- a/drivers/gpu/drm/exynos/exynos_mixer.c
 +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
 @@ -1156,7 +1156,7 @@ static struct mixer_drv_data exynos4210_mxr_drv_data = {
   .has_sclk = 1,
  };
  
 -static struct platform_device_id mixer_driver_types[] = {
 +static const struct platform_device_id mixer_driver_types[] = {
   {
   .name   = s5p-mixer,
   .driver_data= (unsigned long)exynos4210_mxr_drv_data,
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/exynos: Fix build breakage on !DRM_EXYNOS_FIMD

[Inki Dae]

2015-05-04 20:34 GMT+09:00 Daniel Stone dan...@fooishbar.org:
 Hi,

 On 4 May 2015 at 08:43, Inki Dae inki@samsung.com wrote:
 On 2015년 05월 02일 13:08, Krzysztof Kozlowski wrote:
 Selecting CONFIG_FB_S3C disables CONFIG_DRM_EXYNOS_FIMD leading to build
 error:

 No, eDP has no any dependency of FIMD but DECON. Just add dependency
 code like below,

  config DRM_EXYNOS7_DECON
 bool Exynos DRM DECON
 -   depends on DRM_EXYNOS
 +   depends on DRM_EXYNOS  !FB_S3C

 But it does clearly and explicitly call fimd_dp_clock_enable from
 exynos_dp_powero{n,ff}. So the dependency you're proposing seems
 backwards: it's not an expression of the requirements of the current
 code (that FIMD DP code be available, i.e. CONFIG_DRM_EXYNOS_FIMD is
 selected), but an indirect expression of another dependency
 (CONFIG_FB_S3C disables CONFIG_DRM_EXYNOS_FIMD, so disable
 CONFIG_FB_S3C).

 Additionally, as the call comes from exynos_dp_core.c, which is built
 by CONFIG_DRM_EXYNOS_DP (an explicitly user-selectable option), why
 shouldn't the dependency be there? Ah, because the dependency on DP is
 for (DECON || FIMD), but as DECON doesn't provide
 fimd_dp_clock_enable(), it doesn't seem like it would compile if you

Please know that the output data of DECON and FIMD can go to DSI or
Panel directly not through eDP. This means that they - FIMD and eDP or
DECON and eDP - have hardware dependency each other. DECON driver
missed this - only one of Linux framebuffer and DRM KMS driver should
be selected because Linux framebuffer and DRM KMS drivers control same
hardware. So the reason that DECON driver should have dependency on
eDP is not because dp core functions are called by FIMD driver.

In addition, from hw point of view, eDP has depencency on DECON and
FIMD because eDP cannot work itself without DECON or FIMD. Therefore,
if DECON or FIMD is not selected, then eDP should also be disabled  so
that user cannot disable eDP with FIMD because FIMD driver calls eDP's
functions directly. My missing point was that even though we add
!S3C_FB to DECON Kconfig, we can disable eDP with FIMD so build error
can still occur. The best way to resolve this issue would be to move
the functions called by FIMD driver directly to Exynos specific KMS
structure such as exynos crtc - eDP driver implements encoder which
know crtc to FIMD or DECON. The directly call was not good way.

Thanks,
Inki Dae

 selected DECON and not FIMD.

 So, for me, the cleanest solution would be config DRM_EXYNOS_DP gains
 a hard dependency on DRM_EXYNOS_FIMD, at least until it can be fixed
 to compile without FIMD.

 Cheers,
 Daniel
 ___
 dri-devel mailing list
 dri-de...@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/exynos: Fix build breakage on !DRM_EXYNOS_FIMD

[Inki Dae]

2015-05-04 21:43 GMT+09:00 Krzysztof Kozlowski k.kozlowsk...@gmail.com:
 2015-05-04 20:34 GMT+09:00 Daniel Stone dan...@fooishbar.org:
 Hi,

 On 4 May 2015 at 08:43, Inki Dae inki@samsung.com wrote:
 On 2015년 05월 02일 13:08, Krzysztof Kozlowski wrote:
 Selecting CONFIG_FB_S3C disables CONFIG_DRM_EXYNOS_FIMD leading to build
 error:

 No, eDP has no any dependency of FIMD but DECON. Just add dependency
 code like below,

  config DRM_EXYNOS7_DECON
 bool Exynos DRM DECON
 -   depends on DRM_EXYNOS
 +   depends on DRM_EXYNOS  !FB_S3C

 Actually my commit message was not detailed enough. The FB_S3C here
 won't solve the issue because you may:
 1, disable FIMD and FB_S3C,
 2, enabke DECON and DP,
 and it won't compile.

 Currently the FIMD must be enabled if DRM_EXYNOS_DP is enabled.


 But it does clearly and explicitly call fimd_dp_clock_enable from
 exynos_dp_powero{n,ff}. So the dependency you're proposing seems
 backwards: it's not an expression of the requirements of the current
 code (that FIMD DP code be available, i.e. CONFIG_DRM_EXYNOS_FIMD is
 selected), but an indirect expression of another dependency
 (CONFIG_FB_S3C disables CONFIG_DRM_EXYNOS_FIMD, so disable
 CONFIG_FB_S3C).

 Additionally, as the call comes from exynos_dp_core.c, which is built
 by CONFIG_DRM_EXYNOS_DP (an explicitly user-selectable option), why
 shouldn't the dependency be there? Ah, because the dependency on DP is
 for (DECON || FIMD), but as DECON doesn't provide
 fimd_dp_clock_enable(), it doesn't seem like it would compile if you
 selected DECON and not FIMD.

 So, for me, the cleanest solution would be config DRM_EXYNOS_DP gains
 a hard dependency on DRM_EXYNOS_FIMD, at least until it can be fixed
 to compile without FIMD.

 Right, you correctly pointed current dependencies. Still it looks little
 hacky because EXYNOS_DP may work with FIMD or DECON. It does not really
 need FIMD. Using ifdefs in headers is not uncommon - many core
 subsystems do this that way to provide stubs.

 Probably the cleanest way would be to provide by FIMD and DECON a common
 interface for DP for such operation, something like:
 struct exynos_drm_crtc {
 struct drm_crtc base;
 ...
 void (*clock_enable)(struct exynos_drm_crtc *crtc, bool enable)
 );

 which, if non-NULL, will be called by exynos_dp_core.c:
 static void exynos_dp_poweron(struct exynos_dp_device *dp)
 {
 ...
 if (crtc-clock_enable)
 crtc-clock_enable(crtc, true);
 }

 What do you think?

Good idea and you should have done so. the directly call was not good
way. Anyway, with this, fimd driver can set fimd's callbacks to
exynos_drm_crtc structure and eDP driver can call the callbacks
through its encoder. But please, keep in mind that you should set the
callbacks to Exynos specific structure - exynos_drm_crtc - because
this hardware dependency is really specific to Exynos SoC.

Thanks,
Inki Dae


 Best regards,
 Krzysztof

 ___
 linux-arm-kernel mailing list
 linux-arm-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFT PATCHv2] drm/exynos: Enable DP clock to fix display on Exynos5250 and other

[Inki Dae]

On 2015년 03월 28일 01:08, Krzysztof Kozlowski wrote:
> After adding display power domain for Exynos5250 in commit
> 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250") the
> display on Chromebook Snow and others stopped working after boot.
> 
> The 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
> register.

Applied.

Thanks,
Inki Dae

> 
> When exynos-dp is later probed, the clock is not enabled and display is
> not properly configured:
> 
> exynos-dp 145b.dp-controller: Timeout of video streamclk ok
> exynos-dp 145b.dp-controller: unable to config video
> 
> Signed-off-by: Krzysztof Kozlowski 
> Reported-by: Javier Martinez Canillas 
> Fixes: 2d2c9a8d0a4f ("ARM: dts: add display power domain for exynos5250")
> Cc: 
> 
> ---
> 
> This should fix issue reported by Javier [1][2].
> 
> Tested on Chromebook Snow (Exynos 5250). More testing would be great,
> especially on other Exynos 5xxx products.
> 
> [1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/43889
> [2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/400290
> 
> Changes since v1:
> 1. Added missing exynos_drm_fimd.h.
> ---
>  drivers/gpu/drm/exynos/exynos_dp_core.c  | 10 ++
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 19 +++
>  drivers/gpu/drm/exynos/exynos_drm_fimd.h | 15 +++
>  include/video/samsung_fimd.h |  6 ++
>  4 files changed, 50 insertions(+)
>  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd.h
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
> b/drivers/gpu/drm/exynos/exynos_dp_core.c
> index bf17a60b40ed..1dbfba58f909 100644
> --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
> +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
> @@ -32,10 +32,16 @@
>  #include 
>  
>  #include "exynos_dp_core.h"
> +#include "exynos_drm_fimd.h"
>  
>  #define ctx_from_connector(c)container_of(c, struct 
> exynos_dp_device, \
>   connector)
>  
> +static inline struct exynos_drm_crtc *dp_to_crtc(struct exynos_dp_device *dp)
> +{
> + return to_exynos_crtc(dp->encoder->crtc);
> +}
> +
>  static inline struct exynos_dp_device *
>  display_to_dp(struct exynos_drm_display *d)
>  {
> @@ -1070,6 +1076,8 @@ static void exynos_dp_poweron(struct exynos_dp_device 
> *dp)
>   }
>   }
>  
> + fimd_dp_clock_enable(dp_to_crtc(dp), true);
> +
>   clk_prepare_enable(dp->clock);
>   exynos_dp_phy_init(dp);
>   exynos_dp_init_dp(dp);
> @@ -1094,6 +1102,8 @@ static void exynos_dp_poweroff(struct exynos_dp_device 
> *dp)
>   exynos_dp_phy_exit(dp);
>   clk_disable_unprepare(dp->clock);
>  
> + fimd_dp_clock_enable(dp_to_crtc(dp), false);
> +
>   if (dp->panel) {
>   if (drm_panel_unprepare(dp->panel))
>   DRM_ERROR("failed to turnoff the panel\n");
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> index c300e22da8ac..bdf0818dc8f5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
> @@ -32,6 +32,7 @@
>  #include "exynos_drm_fbdev.h"
>  #include "exynos_drm_crtc.h"
>  #include "exynos_drm_iommu.h"
> +#include "exynos_drm_fimd.h"
>  
>  /*
>   * FIMD stands for Fully Interactive Mobile Display and
> @@ -1231,6 +1232,24 @@ static int fimd_remove(struct platform_device *pdev)
>   return 0;
>  }
>  
> +void fimd_dp_clock_enable(struct exynos_drm_crtc *crtc, bool enable)
> +{
> + struct fimd_context *ctx = crtc->ctx;
> + u32 val;
> +
> + /*
> +  * Only Exynos 5250, 5260, 5410 and 542x requires enabling DP/MIE
> +  * clock. On these SoCs the bootloader may enable it but any
> +  * power domain off/on will reset it to disable state.
> +  */
> + if (ctx->driver_data != _fimd_driver_data)
> + return;
> +
> + val = enable ? DP_MIE_CLK_DP_ENABLE : DP_MIE_CLK_DISABLE;
> + writel(DP_MIE_CLK_DP_ENABLE, ctx->regs + DP_MIE_CLKCON);
> +}
> +EXPORT_SYMBOL_GPL(fimd_dp_clock_enable);
> +
>  struct platform_driver fimd_driver = {
>   .probe  = fimd_probe,
>   .remove = fimd_remove,
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.h 
> b/drivers/gpu/drm/exynos/exynos

Re: [RFT PATCHv2] drm/exynos: Enable DP clock to fix display on Exynos5250 and other

[Inki Dae]

On 2015년 03월 28일 01:08, Krzysztof Kozlowski wrote:
 After adding display power domain for Exynos5250 in commit
 2d2c9a8d0a4f (ARM: dts: add display power domain for exynos5250) the
 display on Chromebook Snow and others stopped working after boot.
 
 The 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
 register.

Applied.

Thanks,
Inki Dae

 
 When exynos-dp is later probed, the clock is not enabled and display is
 not properly configured:
 
 exynos-dp 145b.dp-controller: Timeout of video streamclk ok
 exynos-dp 145b.dp-controller: unable to config video
 
 Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
 Reported-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
 Fixes: 2d2c9a8d0a4f (ARM: dts: add display power domain for exynos5250)
 Cc: sta...@vger.kernel.org
 
 ---
 
 This should fix issue reported by Javier [1][2].
 
 Tested on Chromebook Snow (Exynos 5250). More testing would be great,
 especially on other Exynos 5xxx products.
 
 [1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/43889
 [2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/400290
 
 Changes since v1:
 1. Added missing exynos_drm_fimd.h.
 ---
  drivers/gpu/drm/exynos/exynos_dp_core.c  | 10 ++
  drivers/gpu/drm/exynos/exynos_drm_fimd.c | 19 +++
  drivers/gpu/drm/exynos/exynos_drm_fimd.h | 15 +++
  include/video/samsung_fimd.h |  6 ++
  4 files changed, 50 insertions(+)
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_fimd.h
 
 diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
 b/drivers/gpu/drm/exynos/exynos_dp_core.c
 index bf17a60b40ed..1dbfba58f909 100644
 --- a/drivers/gpu/drm/exynos/exynos_dp_core.c
 +++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
 @@ -32,10 +32,16 @@
  #include drm/bridge/ptn3460.h
  
  #include exynos_dp_core.h
 +#include exynos_drm_fimd.h
  
  #define ctx_from_connector(c)container_of(c, struct 
 exynos_dp_device, \
   connector)
  
 +static inline struct exynos_drm_crtc *dp_to_crtc(struct exynos_dp_device *dp)
 +{
 + return to_exynos_crtc(dp-encoder-crtc);
 +}
 +
  static inline struct exynos_dp_device *
  display_to_dp(struct exynos_drm_display *d)
  {
 @@ -1070,6 +1076,8 @@ static void exynos_dp_poweron(struct exynos_dp_device 
 *dp)
   }
   }
  
 + fimd_dp_clock_enable(dp_to_crtc(dp), true);
 +
   clk_prepare_enable(dp-clock);
   exynos_dp_phy_init(dp);
   exynos_dp_init_dp(dp);
 @@ -1094,6 +1102,8 @@ static void exynos_dp_poweroff(struct exynos_dp_device 
 *dp)
   exynos_dp_phy_exit(dp);
   clk_disable_unprepare(dp-clock);
  
 + fimd_dp_clock_enable(dp_to_crtc(dp), false);
 +
   if (dp-panel) {
   if (drm_panel_unprepare(dp-panel))
   DRM_ERROR(failed to turnoff the panel\n);
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c 
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 index c300e22da8ac..bdf0818dc8f5 100644
 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
 @@ -32,6 +32,7 @@
  #include exynos_drm_fbdev.h
  #include exynos_drm_crtc.h
  #include exynos_drm_iommu.h
 +#include exynos_drm_fimd.h
  
  /*
   * FIMD stands for Fully Interactive Mobile Display and
 @@ -1231,6 +1232,24 @@ static int fimd_remove(struct platform_device *pdev)
   return 0;
  }
  
 +void fimd_dp_clock_enable(struct exynos_drm_crtc *crtc, bool enable)
 +{
 + struct fimd_context *ctx = crtc-ctx;
 + u32 val;
 +
 + /*
 +  * Only Exynos 5250, 5260, 5410 and 542x requires enabling DP/MIE
 +  * clock. On these SoCs the bootloader may enable it but any
 +  * power domain off/on will reset it to disable state.
 +  */
 + if (ctx-driver_data != exynos5_fimd_driver_data)
 + return;
 +
 + val = enable ? DP_MIE_CLK_DP_ENABLE : DP_MIE_CLK_DISABLE;
 + writel(DP_MIE_CLK_DP_ENABLE, ctx-regs + DP_MIE_CLKCON);
 +}
 +EXPORT_SYMBOL_GPL(fimd_dp_clock_enable);
 +
  struct platform_driver fimd_driver = {
   .probe  = fimd_probe,
   .remove = fimd_remove,
 diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.h 
 b/drivers/gpu/drm/exynos/exynos_drm_fimd.h
 new file mode 100644
 index ..b4fcaa568456
 --- /dev/null
 +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.h
 @@ -0,0 +1,15 @@
 +/*
 + * Copyright (c) 2015 Samsung Electronics Co., Ltd.
 + *
 + * This program is free software; you can redistribute  it and/or modify it
 + * under  the terms of  the GNU General  Public License as published by the
 + * Free Software Foundation;  either version 2 of the  License, or (at your
 + * option) any later version.
 + */
 +
 +#ifndef _EXYNOS_DRM_FIMD_H_
 +#define

Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support

[Inki Dae]

On 2015년 03월 07일 00:07, Javier Martinez Canillas wrote:
> 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?

Got it. I got several requests before. I have created a new branch -
exynos-drm/for-next - based on top of drm-next, which would have same
patch set as existing exynos-drm-next.

I will request Stephen Rothwell to merge remote-tracking branch,
'exynos-drm/for-next'.

Thanks,
Inki Dae

> 
> 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
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support

[Inki Dae]

On 2015년 03월 07일 00:07, Javier Martinez Canillas wrote:
 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?

Got it. I got several requests before. I have created a new branch -
exynos-drm/for-next - based on top of drm-next, which would have same
patch set as existing exynos-drm-next.

I will request Stephen Rothwell to merge remote-tracking branch,
'exynos-drm/for-next'.

Thanks,
Inki Dae

 
 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
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/exynos: Check for NULL dereference of crtc

[Inki Dae]

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 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:

Right. With quick look, it seems that this issue is incurred because it
tried to access plane->crtc object to call win_disable callback of FIMD
driver before mode_set callback is called: plane->crtc would be set by
mode_set callback so if it has no pair of encoder and crtc then the
plane can never point a crtc object created by FIMD driver.

Thanks,
Inki Dae

> 
> [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
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drm/exynos: Check for NULL dereference of crtc

[Inki Dae]

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 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:

Right. With quick look, it seems that this issue is incurred because it
tried to access plane-crtc object to call win_disable callback of FIMD
driver before mode_set callback is called: plane-crtc would be set by
mode_set callback so if it has no pair of encoder and crtc then the
plane can never point a crtc object created by FIMD driver.

Thanks,
Inki Dae

 
 [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] [c0015db4] (unwind_backtrace) from [c00121cc] 
 (show_stack+0x20/0x24)
 [1.706385] [c00121cc] (show_stack) from [c0528230] 
 (dump_stack+0x78/0xc4)
 [1.713588] [c0528230] (dump_stack) from [c02f72ec] 
 (exynos_disable_plane+0x2c/0x60)
 [1.721660] [c02f72ec] (exynos_disable_plane) from [c02f733c] 
 (exynos_plane_destroy+0x1c/0x30)
 [1.730605] [c02f733c] (exynos_plane_destroy) from [c02e37c4] 
 (drm_mode_config_cleanup+0x168/0x20c)
 [1.739982] [c02e37c4] (drm_mode_config_cleanup) from [c02f3d18] 
 (exynos_drm_load+0xac/0x12c)
 [1.748832] [c02f3d18] (exynos_drm_load) from [c02dc074] 
 (drm_dev_register+0xb0/0x110)
 [1.757075] [c02dc074] (drm_dev_register) from [c02ddc88] 
 (drm_platform_init+0x50/0xe0)
 [1.765405] [c02ddc88] (drm_platform_init) from [c02f3a08] 
 (exynos_drm_bind+0x20/0x28)
 [1.773655] [c02f3a08] (exynos_drm_bind) from [c02fe664] 
 (try_to_bring_up_master.part.1+0xd8/0x114)
 [1.783027] [c02fe664] (try_to_bring_up_master.part.1) from [c02fe754] 
 (component_master_add_with_match+0xb4/0x134)
 [1.793792] [c02fe754] (component_master_add_with_match) from 
 [c02f3e94] (exynos_drm_platform_probe+0xfc/0x124)
 [1.804207] [c02f3e94] (exynos_drm_platform_probe) from [c0304a44] 
 (platform_drv_probe+0x58/0xb4)
 [1.813411] [c0304a44] (platform_drv_probe) from [c0302fa8] 
 (driver_probe_device+0x11c/0x23c)
 [1.822261] [c0302fa8] (driver_probe_device) from [c0303164] 
 (__driver_attach+0x9c/0xa0)
 [1.830679] [c0303164] (__driver_attach) from [c03014a0] 
 (bus_for_each_dev+0x64/0x98)
 [1.838838] [c03014a0] (bus_for_each_dev) from [c0302a4c] 
 (driver_attach+0x2c/0x30)
 [1.846824] [c0302a4c] (driver_attach) from [c030269c] 
 (bus_add_driver+0xe8/0x1e4)
 [1.854722] [c030269c] (bus_add_driver) from [c0303ad8] 
 (driver_register+0x88/0x104)
 [1.862794] [c0303ad8] (driver_register) from [c03048ac] 
 (__platform_driver_register+0x58/0x6c)
 [1.871827] [c03048ac] (__platform_driver_register) from [c02f3f84] 
 (exynos_drm_init+0xc8/0x124)
 [1.880936] [c02f3f84] (exynos_drm_init) from [c00089f4] 
 (do_one_initcall+0x90/0x1e0)
 [1.889096] [c00089f4] (do_one_initcall) from [c08b2e24] 
 (kernel_init_freeable+0x114/0x1e0)
 [1.897779] [c08b2e24] (kernel_init_freeable) from [c05235ac] 
 (kernel_init+0x18/0xfc)
 [1.905934] [c05235ac] (kernel_init) from [c000efa0] 
 (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
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] ARM: exynos_defconfig: Disable IOMMU support

[Inki Dae]

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/j