Re: [PATCH v2 4/7] media: vb2-dma-contig: add helper for setting dma max seg size

[Laurent Pinchart]

Hi Marek,

On Monday 14 December 2015 10:20:22 Marek Szyprowski wrote:
> On 2015-12-13 20:57, Laurent Pinchart wrote:
> > On Wednesday 09 December 2015 14:58:19 Marek Szyprowski wrote:
> >> Add a helper function for device drivers to set DMA's max_seg_size.
> >> Setting it to largest possible value lets DMA-mapping API always create
> >> contiguous mappings in DMA address space. This is essential for all
> >> devices, which use dma-contig videobuf2 memory allocator and shared
> >> buffers.
> >> 
> >> Signed-off-by: Marek Szyprowski 
> >> ---
> >> 
> >>   drivers/media/v4l2-core/videobuf2-dma-contig.c | 15 +++
> >>   include/media/videobuf2-dma-contig.h   |  1 +
> >>   2 files changed, 16 insertions(+)
> >> 
> >> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >> b/drivers/media/v4l2-core/videobuf2-dma-contig.c index c331272..628518d
> >> 100644
> >> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> >> @@ -742,6 +742,21 @@ void vb2_dma_contig_cleanup_ctx(void *alloc_ctx)
> >> 
> >>   }
> >>   EXPORT_SYMBOL_GPL(vb2_dma_contig_cleanup_ctx);
> >> 
> >> +int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int
> >> size)
> >> +{
> >> +  if (!dev->dma_parms) {
> > 
> > When can this function be called with dev->dma_parms not NULL ?
> 
> When one loads a module with multimedia driver (which calls this
> function), then unloads and loads it again. It is rather safe to have this
> check.

Don't you have a much bigger problem in that case ? When you unload the module 
the device will be unbound from the driver, causing the memory allocated by 
devm_kzalloc to be freed. dev->dma_parms will then point to freed memory, 
which will get reused by all subsequent calls to dma_get_max_seg_size(), 
dma_get_max_seg_size() & co (including the ones in this function).

> >> +  dev->dma_parms = devm_kzalloc(dev, sizeof(dev->dma_parms),
> >> +GFP_KERNEL);
> >> +  if (!dev->dma_parms)
> >> +  return -ENOMEM;
> >> +  }
> >> +  if (dma_get_max_seg_size(dev) < size)
> >> +  return dma_set_max_seg_size(dev, size);
> >> +
> >> +  return 0;
> >> +}
> >> +EXPORT_SYMBOL_GPL(vb2_dma_contig_set_max_seg_size);
> >> +
> >>   MODULE_DESCRIPTION("DMA-contig memory handling routines for
> >>   videobuf2");
> >>   MODULE_AUTHOR("Pawel Osciak ");
> >>   MODULE_LICENSE("GPL");
> >> diff --git a/include/media/videobuf2-dma-contig.h
> >> b/include/media/videobuf2-dma-contig.h index c33dfa6..0e6ba64 100644
> >> --- a/include/media/videobuf2-dma-contig.h
> >> +++ b/include/media/videobuf2-dma-contig.h
> >> @@ -26,6 +26,7 @@ vb2_dma_contig_plane_dma_addr(struct vb2_buffer *vb,
> >> unsigned int plane_no)
> >>  void *vb2_dma_contig_init_ctx(struct device *dev);
> >>  void vb2_dma_contig_cleanup_ctx(void *alloc_ctx);
> >> +int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int
> >> size);
> >>  extern const struct vb2_mem_ops vb2_dma_contig_memops;

-- 
Regards,

Laurent Pinchart

--
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 v2 0/7] Exynos: MFC driver: reserved memory cleanup and IOMMU support

[Laurent Pinchart]

Hi Marek,

Thank you for the patches.

On Wednesday 09 December 2015 14:58:15 Marek Szyprowski wrote:
> Hello,
> 
> This patchset finally perform cleanup of custom code in s5p-mfc codec
> driver. The first part is removal of custom, driver specific code for
> intializing and handling of reserved memory. Instead, a generic code for
> reserved memory regions is used.

Should you update the reserved memory bindings documentation 
(Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) to 
document usage of the memory-region-names property ?

> Then, once it is done, the proper setup
> of DMA parameters (max segment size) is applied for all multimedia
> devices found on Exynos SoCs to let them properly handle shared buffers
> mapped into contiguous DMA address space. The last patch adds support
> for IOMMU to MFC driver. Some additional code is needed because of
> specific requirements of MFC device firmware (see patch 7 for more
> details). When no IOMMU is available, the code fallbacks to generic
> reserved memory regions.
> 
> After applying this patchset, MFC device works correctly when IOMMU is
> either enabled or disabled.
> 
> Patches have been tested on top of linux-next from 20151207. I would
> prefer to merge patches 1-2 via Samsung tree and patches 3-7 via media
> tree (there are no compile-time dependencies between patches 1-2 and
> 3-7). Patches have been tested on Odroid U3 (Exynos 4412 based) and
> Odroid XU3 (Exynos 5422 based) boards.
> 
> Best regards
> Marek Szyprowski
> Samsung R&D Institute Poland
> 
> 
> Changelog:
> v2:
> - reworked of_reserved_mem_init* functions on request from Rob Herring,
>   added separate index and name based selection of reserved region
> - adapted for of_reserved_mem_init* related changes
> 
> v1: https://www.mail-archive.com/linux-media@vger.kernel.org/msg94100.html
> - initial version of another approach for this problem, rewrote driver code
>   for new reserved memory bindings, which finally have been merged some
>   time ago
> 
> v0:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-August/189259.ht
> ml - old patchset solving the same problem, abandoned due to other tasks and
> long time of merging reserved memory bindings and support code for it
> 
> Patch summary:
> 
> Marek Szyprowski (7):
>   ARM: Exynos: convert MFC device to generic reserved memory bindings
>   ARM: dts: exynos4412-odroid*: enable MFC device
>   of: reserved_mem: add support for named reserved mem nodes
>   media: vb2-dma-contig: add helper for setting dma max seg size
>   media: set proper max seg size for devices on Exynos SoCs
>   media: s5p-mfc: replace custom reserved memory init code with generic
> one
>   media: s5p-mfc: add iommu support
> 
>  .../devicetree/bindings/media/s5p-mfc.txt  |  16 +--
>  arch/arm/boot/dts/exynos4210-origen.dts|  22 ++-
>  arch/arm/boot/dts/exynos4210-smdkv310.dts  |  22 ++-
>  arch/arm/boot/dts/exynos4412-odroid-common.dtsi|  24 
>  arch/arm/boot/dts/exynos4412-origen.dts|  22 ++-
>  arch/arm/boot/dts/exynos4412-smdk4412.dts  |  22 ++-
>  arch/arm/boot/dts/exynos5250-arndale.dts   |  22 ++-
>  arch/arm/boot/dts/exynos5250-smdk5250.dts  |  22 ++-
>  arch/arm/boot/dts/exynos5250-spring.dts|  22 ++-
>  arch/arm/boot/dts/exynos5420-arndale-octa.dts  |  22 ++-
>  arch/arm/boot/dts/exynos5420-smdk5420.dts  |  22 ++-
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi |  22 ++-
>  arch/arm/mach-exynos/Makefile  |   2 -
>  arch/arm/mach-exynos/exynos.c  |  19 ---
>  arch/arm/mach-exynos/mfc.h |  16 ---
>  arch/arm/mach-exynos/s5p-dev-mfc.c |  94 -
>  drivers/media/platform/exynos-gsc/gsc-core.c   |   1 +
>  drivers/media/platform/exynos4-is/fimc-core.c  |   1 +
>  drivers/media/platform/exynos4-is/fimc-is.c|   1 +
>  drivers/media/platform/exynos4-is/fimc-lite.c  |   1 +
>  drivers/media/platform/s5p-g2d/g2d.c   |   1 +
>  drivers/media/platform/s5p-jpeg/jpeg-core.c|   1 +
>  drivers/media/platform/s5p-mfc/s5p_mfc.c   | 153 ++
>  drivers/media/platform/s5p-mfc/s5p_mfc_iommu.h |  79 +++
>  drivers/media/platform/s5p-tv/mixer_video.c|   1 +
>  drivers/media/v4l2-core/videobuf2-dma-contig.c |  15 ++
>  drivers/of/of_reserved_mem.c   | 104 +++---
>  include/linux/of_reserved_mem.h|  31 -
>  include/media/videobuf2-dma-contig.h   |   1 +
>  29 files changed, 533 insertions(+), 248 deletions(-)
>  delete mode 100644 arch/arm/mach-

Re: [PATCH v2 4/7] media: vb2-dma-contig: add helper for setting dma max seg size

[Laurent Pinchart]

Hi Marek,

Thank you for the patch.

On Wednesday 09 December 2015 14:58:19 Marek Szyprowski wrote:
> Add a helper function for device drivers to set DMA's max_seg_size.
> Setting it to largest possible value lets DMA-mapping API always create
> contiguous mappings in DMA address space. This is essential for all
> devices, which use dma-contig videobuf2 memory allocator and shared
> buffers.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/media/v4l2-core/videobuf2-dma-contig.c | 15 +++
>  include/media/videobuf2-dma-contig.h   |  1 +
>  2 files changed, 16 insertions(+)
> 
> diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> b/drivers/media/v4l2-core/videobuf2-dma-contig.c index c331272..628518d
> 100644
> --- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
> +++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
> @@ -742,6 +742,21 @@ void vb2_dma_contig_cleanup_ctx(void *alloc_ctx)
>  }
>  EXPORT_SYMBOL_GPL(vb2_dma_contig_cleanup_ctx);
> 
> +int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size)
> +{
> + if (!dev->dma_parms) {

When can this function be called with dev->dma_parms not NULL ?

> + dev->dma_parms = devm_kzalloc(dev, sizeof(dev->dma_parms),
> +   GFP_KERNEL);
> + if (!dev->dma_parms)
> + return -ENOMEM;
> + }
> + if (dma_get_max_seg_size(dev) < size)
> + return dma_set_max_seg_size(dev, size);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(vb2_dma_contig_set_max_seg_size);
> +
>  MODULE_DESCRIPTION("DMA-contig memory handling routines for videobuf2");
>  MODULE_AUTHOR("Pawel Osciak ");
>  MODULE_LICENSE("GPL");
> diff --git a/include/media/videobuf2-dma-contig.h
> b/include/media/videobuf2-dma-contig.h index c33dfa6..0e6ba64 100644
> --- a/include/media/videobuf2-dma-contig.h
> +++ b/include/media/videobuf2-dma-contig.h
> @@ -26,6 +26,7 @@ vb2_dma_contig_plane_dma_addr(struct vb2_buffer *vb,
> unsigned int plane_no)
> 
>  void *vb2_dma_contig_init_ctx(struct device *dev);
>  void vb2_dma_contig_cleanup_ctx(void *alloc_ctx);
> +int vb2_dma_contig_set_max_seg_size(struct device *dev, unsigned int size);
> 
>  extern const struct vb2_mem_ops vb2_dma_contig_memops;

-- 
Regards,

Laurent Pinchart

--
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 v8 32/55] [media] media: use macros to check for V4L2 subdev entities

[Laurent Pinchart]

ia_entity_v4l2_subdev(pad->entity))
>   break;
> 
>   entity = 
> to_vsp1_entity(media_entity_to_v4l2_subdev(pad->entity));
> diff --git a/drivers/media/platform/xilinx/xilinx-dma.c
> b/drivers/media/platform/xilinx/xilinx-dma.c index
> 88cd789cdaf7..8e14841bf445 100644
> --- a/drivers/media/platform/xilinx/xilinx-dma.c
> +++ b/drivers/media/platform/xilinx/xilinx-dma.c
> @@ -49,8 +49,7 @@ xvip_dma_remote_subdev(struct media_pad *local, u32 *pad)
>   struct media_pad *remote;
> 
>   remote = media_entity_remote_pad(local);
> - if (remote == NULL ||
> - media_entity_type(remote->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> + if (!remote || !is_media_entity_v4l2_subdev(remote->entity))
>   return NULL;
> 
>   if (pad)
> @@ -113,8 +112,7 @@ static int xvip_pipeline_start_stop(struct xvip_pipeline
> *pipe, bool start) break;
> 
>   pad = media_entity_remote_pad(pad);
> - if (pad == NULL ||
> - media_entity_type(pad->entity) != MEDIA_ENT_T_V4L2_SUBDEV)
> + if (!pad || !is_media_entity_v4l2_subdev(pad->entity))
>   break;
> 
>   entity = pad->entity;
> diff --git a/drivers/media/v4l2-core/v4l2-subdev.c
> b/drivers/media/v4l2-core/v4l2-subdev.c index e6e1115d8215..60da43772de9
> 100644
> --- a/drivers/media/v4l2-core/v4l2-subdev.c
> +++ b/drivers/media/v4l2-core/v4l2-subdev.c
> @@ -526,7 +526,7 @@ static int
>  v4l2_subdev_link_validate_get_format(struct media_pad *pad,
>struct v4l2_subdev_format *fmt)
>  {
> - if (media_entity_type(pad->entity) == MEDIA_ENT_T_V4L2_SUBDEV) {
> + if (is_media_entity_v4l2_subdev(pad->entity)) {
>   struct v4l2_subdev *sd =
>   media_entity_to_v4l2_subdev(pad->entity);
> 
> diff --git a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> b/drivers/staging/media/davinci_vpfe/vpfe_video.c index
> 92573fa852a9..16763e0831f2 100644
> --- a/drivers/staging/media/davinci_vpfe/vpfe_video.c
> +++ b/drivers/staging/media/davinci_vpfe/vpfe_video.c
> @@ -148,7 +148,7 @@ static void vpfe_prepare_pipeline(struct
> vpfe_video_device *video) while ((entity =
> media_entity_graph_walk_next(&graph))) {
>   if (entity == &video->video_dev.entity)
>   continue;
> - if (media_entity_type(entity) != MEDIA_ENT_T_DEVNODE)
> + if ((!is_media_entity_v4l2_io(remote->entity))
>   continue;
>   far_end = to_vpfe_video(media_entity_to_video_device(entity));
>   if (far_end->type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
> @@ -293,7 +293,7 @@ static int vpfe_pipeline_enable(struct vpfe_pipeline
> *pipe) media_entity_graph_walk_start(&graph, entity);
>   while ((entity = media_entity_graph_walk_next(&graph))) {
> 
> - if (media_entity_type(entity) == MEDIA_ENT_T_DEVNODE)
> + if !is_media_entity_v4l2_subdev(entity))

With these two chunks fixed,

Acked-by: Laurent Pinchart 

I'm wondering, however, why you replace some occurrences of == 
MEDIA_ENT_T_DEVNODE with !is_media_entity_v4l2_subdev and some other with 
is_media_entity_v4l2_io.

>   continue;
>   subdev = media_entity_to_v4l2_subdev(entity);
>   ret = v4l2_subdev_call(subdev, video, s_stream, 1);
> @@ -334,7 +334,7 @@ static int vpfe_pipeline_disable(struct vpfe_pipeline
> *pipe)
> 
>   while ((entity = media_entity_graph_walk_next(&graph))) {
> 
> - if (media_entity_type(entity) == MEDIA_ENT_T_DEVNODE)
> + if (!is_media_entity_v4l2_subdev(entity))
>   continue;
>   subdev = media_entity_to_v4l2_subdev(entity);
>   ret = v4l2_subdev_call(subdev, video, s_stream, 0);
> diff --git a/drivers/staging/media/omap4iss/iss.c
> b/drivers/staging/media/omap4iss/iss.c index 40591963b42b..44b88ff3ba83
> 100644
> --- a/drivers/staging/media/omap4iss/iss.c
> +++ b/drivers/staging/media/omap4iss/iss.c
> @@ -397,7 +397,7 @@ static int iss_pipeline_pm_use_count(struct media_entity
> *entity) media_entity_graph_walk_start(&graph, entity);
> 
>   while ((entity = media_entity_graph_walk_next(&graph))) {
> - if (media_entity_type(entity) == MEDIA_ENT_T_DEVNODE)
> + if (is_media_entity_v4l2_io(entity))
>   use += entity->use_count;
>   }
> 
> @@ -419,7 +419,7 @@ static int iss_pipeline_pm_power_one(struct media_entity
> *entity, int change) {
>   struct v4l2_subdev *subdev;
> 
> - subdev = media_entity_type(en

Re: [Y2038] [PATCH v2 9/9] [media] omap3isp: support 64-bit version of omap3isp_stat_data

[Laurent Pinchart]

Hi Arnd,

On Monday 09 November 2015 21:30:41 Arnd Bergmann wrote:
> On Monday 09 November 2015 22:09:26 Laurent Pinchart wrote:
> > On Thursday 17 September 2015 23:19:40 Arnd Bergmann wrote:
> > > C libraries with 64-bit time_t use an incompatible format for
> > > struct omap3isp_stat_data. This changes the kernel code to
> > > support either version, by moving over the normal handling
> > > to the 64-bit variant, and adding compatiblity code to handle
> > > the old binary format with the existing ioctl command code.
> > > 
> > > Fortunately, the command code includes the size of the structure,
> > > so the difference gets handled automatically.
> > 
> > We plan to design a new interface to handle statistics in V4L2. That API
> > should support proper 64-bit timestamps out of the box, and will be
> > implemented by the OMAP3 ISP driver. Userspace should then move to it. I
> > wonder if it's worth it to fix the existing VIDIOC_OMAP3ISP_STAT_REQ ioctl
> > given that I expect it to have a handful of users at most.
> 
> We still need to do something to the driver. The alternative would
> be to make the existing ioctl command optional at kernel compile-time
> so we can still build the driver once we remove the 'struct timeval'
> definition. That patch would add slightly less complexity here
> but also lose functionality.
> 
> As my patch here depends on the struct v4l2_timeval I introduced in
> an earlier patch of the series, we will have to change it anyways,
> but I'd prefer to keep the basic idea. Let's get back to this one
> after the v4l_buffer replacement work is done.

Fine with me. I'll mark the patch as "Obsoleted" in patchwork in the meantime.

-- 
Regards,

Laurent Pinchart

--
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 v2 9/9] [media] omap3isp: support 64-bit version of omap3isp_stat_data

[Laurent Pinchart]

v_usec = data64.ts.tv_usec;
> + memcpy(&data->buf, &data64.buf, sizeof(*data) - sizeof(data->ts));
> +
> + return ret;
> +}
> +
>  /*
>   * omap3isp_stat_config - Receives new statistic engine configuration.
>   * @new_conf: Pointer to config structure.
> diff --git a/drivers/media/platform/omap3isp/ispstat.h
> b/drivers/media/platform/omap3isp/ispstat.h index
> 7b4f136567a3..b19ea6c8f733 100644
> --- a/drivers/media/platform/omap3isp/ispstat.h
> +++ b/drivers/media/platform/omap3isp/ispstat.h
> @@ -130,6 +130,8 @@ struct ispstat_generic_config {
>  int omap3isp_stat_config(struct ispstat *stat, void *new_conf);
>  int omap3isp_stat_request_statistics(struct ispstat *stat,
>struct omap3isp_stat_data *data);
> +int omap3isp_stat_request_statistics_time32(struct ispstat *stat,
> +  struct omap3isp_stat_data_time32 *data);
>  int omap3isp_stat_init(struct ispstat *stat, const char *name,
>  const struct v4l2_subdev_ops *sd_ops);
>  void omap3isp_stat_cleanup(struct ispstat *stat);
> diff --git a/include/uapi/linux/omap3isp.h b/include/uapi/linux/omap3isp.h
> index c090cf9249bb..4bff66aefca5 100644
> --- a/include/uapi/linux/omap3isp.h
> +++ b/include/uapi/linux/omap3isp.h
> @@ -54,6 +54,8 @@
>   _IOWR('V', BASE_VIDIOC_PRIVATE + 5, struct omap3isp_h3a_af_config)
>  #define VIDIOC_OMAP3ISP_STAT_REQ \
>   _IOWR('V', BASE_VIDIOC_PRIVATE + 6, struct omap3isp_stat_data)
> +#define VIDIOC_OMAP3ISP_STAT_REQ_TIME32 \
> + _IOWR('V', BASE_VIDIOC_PRIVATE + 6, struct omap3isp_stat_data_time32)
>  #define VIDIOC_OMAP3ISP_STAT_EN \
>   _IOWR('V', BASE_VIDIOC_PRIVATE + 7, unsigned long)
> 
> @@ -164,7 +166,11 @@ struct omap3isp_h3a_aewb_config {
>   * @config_counter: Number of the configuration associated with the data.
>   */
>  struct omap3isp_stat_data {
> +#ifdef __KERNEL__
> + struct v4l2_timeval ts;
> +#else
>   struct timeval ts;
> +#endif
>   void __user *buf;
>   __u32 buf_size;
>   __u16 frame_number;
> @@ -172,6 +178,19 @@ struct omap3isp_stat_data {
>   __u16 config_counter;
>  };
> 
> +#ifdef __KERNEL__
> +struct omap3isp_stat_data_time32 {
> + struct {
> + __s32   tv_sec;
> + __s32   tv_usec;
> + } ts;
> + __u32 buf;
> + __u32 buf_size;
> + __u16 frame_number;
> + __u16 cur_frame;
> + __u16 config_counter;
> +};
> +#endif
> 
>  /* Histogram related structs */

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity

[Laurent Pinchart]

Hi Shawn,

On Tuesday 13 October 2015 22:09:46 Shawn Guo wrote:
> On Tue, Oct 13, 2015 at 12:12:29AM +0300, Laurent Pinchart wrote:
> > Laurent Pinchart (37):
> ...
> 
> >   ARM: imx6sx-sdb: Fix typo in regulator enable GPIO property
> 
> ...
> 
> >   ARM: dts: imx6qdl-tx6: Fix regulator enable GPIO polarity
> 
> ...
> 
> >   ARM: dts: imx23-evk: Fix regulator enable GPIO polarity
> >   ARM: dts: imx23-stmp378x_devb: Fix regulator enable GPIO polarity
> >   ARM: dts: imx25-pdk: Fix regulator enable GPIO polarity
> >   ARM: dts: imx28-cfa10036: Fix regulator enable GPIO polarity
> >   ARM: dts: imx28-evk: Fix regulator enable GPIO polarity
> >   ARM: dts: imx28-m28cu3: Fix regulator enable GPIO polarity
> >   ARM: dts: imx28-m28evk: Fix regulator enable GPIO polarity
> >   ARM: dts: imx28-sps1: Fix regulator enable GPIO polarity
> >   ARM: dts: imx28-tx28: Fix regulator enable GPIO polarity
> >   ARM: dts: imx53-m53evk: Fix regulator enable GPIO polarity
> >   ARM: dts: imx53-mba53: Fix regulator enable GPIO polarity
> >   ARM: dts: imx53-tx53: Fix regulator enable GPIO polarity
> >   ARM: dts: imx6q-dmo-edmqmx6: Fix regulator enable GPIO polarity
> 
> Applied these 15 patches, thanks.

There's ongoing discussions regarding whether this is the right thing to do. 
Please see http://www.spinics.net/lists/arm-kernel/msg451724.html. It's thus a 
bit early to apply the patches at this point I'm afraid.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity

[Laurent Pinchart]

Hi Javier,

On Tuesday 13 October 2015 00:19:20 Javier Martinez Canillas wrote:
> On 10/12/2015 11:46 PM, Tony Lindgren wrote:
> > * Laurent Pinchart  [151012 14:17]:
> >> Hello,
> >> 
> >> While working on regulators, GPIOs and DT I noticed that many of our DT
> >> source files incorrectly describe fixed regulators. The common error
> >> patterns are
> >> 
> >> - Usage of the undefined (and never parsed) enable-active-low property
> >> - Usage of the enable-active-high property without specifying an enable
> >>   GPIO
> >> - Typos in the enabl GPIO property name (gpios instead of gpio)
> >> - Mismatch between the enable-active-high property (or the lack thereof)
> >>   and the enable GPIO flags
> >> 
> >> This patch series fixes those issues in all the DT sources after locating
> >> the errors using the following script.
> >> 
> >> -
> >> !/bin/sh
> >> 
> >> echo $1
> >> cat $1 | awk '
> >> BEGIN {
> >>open_drain = 0;
> >>active_high = 0;
> >>gpio = 0;
> >>flags = 0;
> >> }
> >> 
> >> match($0, /([a-zA-Z0-9@_-]*) {/, ary) {
> >>name = ary[1];
> >> }
> >> 
> >> /compatible.*"regulator-fixed"/ {
> >>found = 1;
> >> }
> >> 
> >> /enable-active-high/ {
> >>active_high = 1;
> >> }
> >> 
> >> /gpio-open-drain/ {
> >>open_drain = 1;
> >> }
> >> 
> >> match($0, /gpio += <.* ([^ ]*)>/, ary) {
> >>gpio = 1;
> >>flags = ary[1];
> >>if (flags == 0)
> >>flags = "GPIO_ACTIVE_HIGH";
> >> }
> >> 
> >> /}/ {
> >>if (found) {
> >>if (gpio) {
> >>print "\t" name ": active high " active_high " " flags 
> >> " open 
drain "
> >>open_drain;
> >>if ((active_high && flags == "GPIO_ACTIVE_LOW") ||
> >>(!active_high && flags == "GPIO_ACTIVE_HIGH"))
> >>print "WARNING: enable-active-high and flags do 
> >> not 
match"
> >>} else {
> >>if (active_high)
> >>print "WARNING: active high without GPIO"
> >>if (open_drain)
> >>print "WARNING: open drain without GPIO"
> >>}
> >>}
> >>
> >>gpio = 0;
> >>found = 0;
> >>active_high = 0;
> >>open_drain = 0;
> >>flags = 0;
> >> }
> >> '
> >> -
> >> 
> >> All patches except for the ones touching omap3-beagle-xm and
> >> omap3-overo-base are untested as I lack test hardware.
> >> 
> >> As there's no dependency between the patches touching different source
> >> files the appropriate maintainers could take their share of the patches
> >> in their tree. Alternatively I could send a single pull request after
> >> collecting all acks but that might be more complex.
> > 
> > Nice clean-up. For omaps, there's an earlier patch posted by
> > Javier Martinez Canillas  as "[PATCH] ARM: dts:
> > Use defined GPIO constants in flags cell for OMAP2+ boards". Can you guys
> > do some cross checking and let me know which combination I should appluy
> > for omaps?
>
> Since Laurent's changes for OMAP are part of a bigger series and my patch
> was only for OMAP, probably makes sense for you to pick his patches and I
> can re-spin mine on top of that.
> 
> BTW, I posted as a single patch since the changes were trivial but maybe
> that made handling these conflicts harder and I should split the changes
> instead, since I'll resend anyways.
> 
> What do you prefer? a patch per SoC family (i.e: OMAP{2,3,4,5}) or patch
> per board DTS?

My series will likely miss the next merge window as more discussion is needed. 
I'll thus respin the patches on top of yours, please proceed without caring 
about this.

-- 
Regards,

Laurent Pinchart

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

[PATCH 00/37] ARM: dts: Fix fixed regulators enable GPIO polarity

[Laurent Pinchart]

Hello,

While working on regulators, GPIOs and DT I noticed that many of our DT source
files incorrectly describe fixed regulators. The common error patterns are

- Usage of the undefined (and never parsed) enable-active-low property
- Usage of the enable-active-high property without specifying an enable GPIO
- Typos in the enabl GPIO property name (gpios instead of gpio)
- Mismatch between the enable-active-high property (or the lack thereof) and
  the enable GPIO flags

This patch series fixes those issues in all the DT sources after locating the
errors using the following script.

--
#!/bin/sh

echo $1
cat $1 | awk '
BEGIN {
open_drain = 0;
active_high = 0;
gpio = 0;
flags = 0;
}

match($0, /([a-zA-Z0-9@_-]*) {/, ary) {
name = ary[1];
}

/compatible.*"regulator-fixed"/ {
found = 1;
}

/enable-active-high/ {
active_high = 1;
}

/gpio-open-drain/ {
open_drain = 1;
}

match($0, /gpio += <.* ([^ ]*)>/, ary) {
gpio = 1;
flags = ary[1];
if (flags == 0)
flags = "GPIO_ACTIVE_HIGH";
}

/}/ {
if (found) {
if (gpio) {
print "\t" name ": active high " active_high " " flags 
" open drain " open_drain;
if ((active_high && flags == "GPIO_ACTIVE_LOW") ||
(!active_high && flags == "GPIO_ACTIVE_HIGH"))
print "WARNING: enable-active-high and flags do 
not match"
} else {
if (active_high)
print "WARNING: active high without GPIO"
if (open_drain)
print "WARNING: open drain without GPIO"
}
}

gpio = 0;
found = 0;
active_high = 0;
open_drain = 0;
flags = 0;
}
'
--

All patches except for the ones touching omap3-beagle-xm and omap3-overo-base
are untested as I lack test hardware.

As there's no dependency between the patches touching different source files
the appropriate maintainers could take their share of the patches in their
tree. Alternatively I could send a single pull request after collecting all
acks but that might be more complex.

Cc: devicet...@vger.kernel.org
Cc: linux-o...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: linux-te...@vger.kernel.org
Cc: linux-g...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Benoit Cousson 
Cc: Tony Lindgren 
Cc: Jason Cooper 
Cc: Andrew Lunn 
Cc: Gregory Clement 
Cc: Sebastian Hesselbarth 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
Cc: Shawn Guo 
Cc: Sascha Hauer 
Cc: Stephen Warren 
Cc: Thierry Reding 
Cc: Alexandre Courbot 
Cc: Liam Girdwood 
Cc: Mark Brown 
Cc: Linus Walleij 

Laurent Pinchart (37):
  ARM: dts: am437x-gp-evm: Remove unneeded regulator property
  ARM: dts: am43xx-epos-evm: Remove unneeded regulator property
  ARM: mvebu: Armada 388 GP: Remove unneeded regulator property
  ARM: imx6sx-sdb: Fix typo in regulator enable GPIO property
  ARM: dts: s5pv210-aquila: Fix typo in regulator enable GPIO property
  ARM: dts: s5pv210-goni: Fix typo in regulator enable GPIO property
  ARM: dts: omap3-evm: Remove invalid enable-active-low regulator
property
  ARM: dts: omap3-sb-t35: Remove invalid enable-active-low regulator
property
  ARM: dts: omap3-tao3530: Remove invalid enable-active-low regulator
property
  ARM: dts: imx6qdl-tx6: Fix regulator enable GPIO polarity
  ARM: dts: dove-cm-a510: Fix regulator enable GPIO polarity
  ARM: dts: dove-sbc-a510: Fix regulator enable GPIO polarity
  ARM: dts: exynos5250-arndale: Fix regulator enable GPIO polarity
  ARM: dts: imx23-evk: Fix regulator enable GPIO polarity
  ARM: dts: imx23-stmp378x_devb: Fix regulator enable GPIO polarity
  ARM: dts: imx25-pdk: Fix regulator enable GPIO polarity
  ARM: dts: imx28-cfa10036: Fix regulator enable GPIO polarity
  ARM: dts: imx28-evk: Fix regulator enable GPIO polarity
  ARM: dts: imx28-m28cu3: Fix regulator enable GPIO polarity
  ARM: dts: imx28-m28evk: Fix regulator enable GPIO polarity
  ARM: dts: imx28-sps1: Fix regulator enable GPIO polarity
  ARM: dts: imx28-tx28: Fix regulator enable GPIO polarity
  ARM: dts: imx53-m53evk: Fix regulator enable GPIO polarity
  ARM: dts: imx53-mba53: Fix regulator enable GPIO polarity
  ARM: dts: imx53-tx53: Fix regulator enable GPIO polarity
  ARM: dts: imx6q-dmo-edmqmx6: Fix regulator enable GPIO polarity
  ARM: dts: kirkwood-blackarmor-nas220: Fix regulator enable GPIO
polarity
  ARM: dts: omap4-duovero: Fix regulator enable GPIO polarity
  ARM: dts: kirkwood-nsa3x0-common: Fix regulator enable GPIO pola

[PATCH 06/37] ARM: dts: s5pv210-goni: Fix typo in regulator enable GPIO property

[Laurent Pinchart]

The property name should be "gpio", not "gpios". Fix it.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/s5pv210-goni.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Cc: linux-samsung-soc@vger.kernel.org
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 

diff --git a/arch/arm/boot/dts/s5pv210-goni.dts 
b/arch/arm/boot/dts/s5pv210-goni.dts
index a3d4643b202e..3b76eeeb8410 100644
--- a/arch/arm/boot/dts/s5pv210-goni.dts
+++ b/arch/arm/boot/dts/s5pv210-goni.dts
@@ -47,7 +47,7 @@
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
reg = <0>;
-   gpios = <&mp05 4 0>;
+   gpio = <&mp05 4 0>;
enable-active-high;
};
 
@@ -73,7 +73,7 @@
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
reg = <3>;
-   gpios = <&gpj1 3 0>;
+   gpio = <&gpj1 3 0>;
enable-active-high;
};
};
-- 
2.4.9

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

[PATCH 05/37] ARM: dts: s5pv210-aquila: Fix typo in regulator enable GPIO property

[Laurent Pinchart]

The property name should be "gpio", not "gpios". Fix it.

Signed-off-by: Laurent Pinchart 
---
 arch/arm/boot/dts/s5pv210-aquila.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Cc: linux-samsung-soc@vger.kernel.org
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 

diff --git a/arch/arm/boot/dts/s5pv210-aquila.dts 
b/arch/arm/boot/dts/s5pv210-aquila.dts
index f00cea7aca2f..aa64faa72970 100644
--- a/arch/arm/boot/dts/s5pv210-aquila.dts
+++ b/arch/arm/boot/dts/s5pv210-aquila.dts
@@ -46,7 +46,7 @@
regulator-name = "V_TF_2.8V";
regulator-min-microvolt = <280>;
regulator-max-microvolt = <280>;
-   gpios = <&mp05 4 0>;
+   gpio = <&mp05 4 0>;
enable-active-high;
};
 
-- 
2.4.9

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

Re: [PATCH v4 1/6] media: get rid of unused "extra_links" param on media_entity_init()

[Laurent Pinchart]

Hi Mauro,

Thank you for the patch.

On Friday 14 August 2015 11:56:38 Mauro Carvalho Chehab wrote:
> Currently, media_entity_init() creates an array with the links,
> allocated at init time. It provides a parameter (extra_links)
> that would allocate more links than the current needs, but this
> is not used by any driver.
> 
> As we want to be able to do dynamic link allocation/removal,
> we'll need to change the implementation of the links. So,
> before doing that, let's first remove that extra unused
> parameter, in order to cleanup the interface first.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> Acked-by: Sakari Ailus 
> 
> diff --git a/Documentation/media-framework.txt
> b/Documentation/media-framework.txt index f552a75c0e70..2cc6019f7147 100644
> --- a/Documentation/media-framework.txt
> +++ b/Documentation/media-framework.txt
> @@ -104,7 +104,7 @@ although drivers can allocate entities directly.
>  Drivers initialize entities by calling
> 
>   media_entity_init(struct media_entity *entity, u16 num_pads,
> -   struct media_pad *pads, u16 extra_links);
> +   struct media_pad *pads);
> 
>  The media_entity name, type, flags, revision and group_id fields can be
>  initialized before or after calling media_entity_init. Entities embedded in

The extra_links parameter is documented later on in this file. Could you 
replace the paragraph

"Unlike the number of pads, the total number of links isn't always known in
advance by the entity driver. As an initial estimate, media_entity_init
pre-allocates a number of links equal to the number of pads plus an optional
number of extra links. The links array will be reallocated if it grows beyond
the initial estimate."

with

"Unlike the number of pads, the total number of links isn't always known in
advance by the entity driver. As an initial estimate, media_entity_init
pre-allocates a number of links equal to the number of pads. The links array 
will be reallocated if it grows beyond the initial estimate."

?

[snip]

> diff --git a/drivers/media/media-entity.c b/drivers/media/media-entity.c
> index 4d8e01c7b1b2..78440c7aad94 100644
> --- a/drivers/media/media-entity.c
> +++ b/drivers/media/media-entity.c
> @@ -30,7 +30,6 @@
>   * media_entity_init - Initialize a media entity
>   *
>   * @num_pads: Total number of sink and source pads.
> - * @extra_links: Initial estimate of the number of extra links.
>   * @pads: Array of 'num_pads' pads.
>   *
>   * The total number of pads is an intrinsic property of entities known by
> the

Similarly here, I would rewrite the documentation as

 * The total number of pads is an intrinsic property of entities known by the
 * entity driver, while the total number of links depends on hardware design
 * and is an extrinsic property unknown to the entity driver. However, in most
 * use cases the number of links can safely be assumed to be equal to or
 * larger than the number of pads.
 *
 * For those reasons the links array can be preallocated based on the number
 * of pads and will be reallocated later if extra links need to be created.
 *
 * This function allocates a links array with enough space to hold at least
 * 'num_pads' elements. The media_entity::max_links field will be set to the
 * number of allocated elements.

With that fixed,

Acked-by: Laurent Pinchart 

And feel free to merge this patch for v4.3 independently of the rest.

> @@ -52,10 +51,10 @@
>   */
>  int
>  media_entity_init(struct media_entity *entity, u16 num_pads,
> -   struct media_pad *pads, u16 extra_links)
> +   struct media_pad *pads)
>  {
>   struct media_link *links;
> -     unsigned int max_links = num_pads + extra_links;
> + unsigned int max_links = num_pads;
>   unsigned int i;
> 
>   links = kzalloc(max_links * sizeof(links[0]), GFP_KERNEL);

-- 
Regards,

Laurent Pinchart

--
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 v7 03/25] iommu: Init iommu-groups support earlier, in core_initcall

[Laurent Pinchart]

Hi Marek,

Thank you for the patch.

On Tuesday 19 May 2015 15:20:23 Marek Szyprowski wrote:
> iommu_group_alloc might be called very early in case of iommu controllers
> activated from of_iommu, so ensure that this part of subsystem is ready
> when devices are being populated from device-tree (core_initcall seems to
> be okay for this case).
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/iommu/iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> index d4f527e56679..37a6aa8f318b 100644
> --- a/drivers/iommu/iommu.c
> +++ b/drivers/iommu/iommu.c
> @@ -1207,7 +1207,7 @@ static int __init iommu_init(void)
> 
>   return 0;
>  }
> -arch_initcall(iommu_init);
> +core_initcall(iommu_init);

I'll let Joerg comment on this, but this initcall ordering dance always makes 
me feel that something isn't quite right. Have you had a chance to look at the 
patch series I posted about a week ago to implement IOMMU probe deferral 
support ?

>  int iommu_domain_get_attr(struct iommu_domain *domain,
>     enum iommu_attr attr, void *data)

-- 
Regards,

Laurent Pinchart

--
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 v6 10/25] iommu: exynos: remove useless device_add/remove callbacks

[Laurent Pinchart]

Hi Joerg,

On Monday 18 May 2015 19:04:30 Joerg Roedel wrote:
> On Mon, May 18, 2015 at 02:09:14PM +0200, Marek Szyprowski wrote:
> > > Hmm, will this remove support for iommu-groups in the exynos driver? I
> > > am still working on the default-domain patch-set which makes iommu-group
> > > support mandatory for iommu-drivers.
> > 
> > I you wish, I can leave this code. iommu-groups were not used at all
> > on Exynos, so I thought that there is no point keeping useless code.
> 
> Yes, please keep the iommu-goups support, it will be required at some
> point.

I think the concept of iommu groups isn't very well understood, hence the 
little love it receives from developers who conclude it's useless. I can't 
blame anyone, I don't do any better. Could I convince you to include 
documentation in your next patch series that touches iommu groups ?

Could you please have a look at my "[RFC/PATCH 0/9] IOMMU probe deferral 
support" patch series in the context of iommu groups ? The series pretty much 
drops groups support from the ipmmu-vmsa driver, not because of a real desire 
to do so, but because I wasn't sure how to keep them. Tips would be 
appreciated.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v5 11/18] iommu: exynos: remove useless device_add/remove callbacks

[Laurent Pinchart]

Hi Joerg,

On Monday 26 January 2015 12:00:59 Joerg Roedel wrote:
> Hi Laurent,
> 
> On Sun, Jan 25, 2015 at 05:38:22PM +0200, Laurent Pinchart wrote:
> > IOMMU groups still seem a bit unclear to me. Will Deacon has nicely
> > explained what they represent in
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/310816
> > .html. The IOMMU core doesn't make groups
> > mandatory, but requires them in some code paths.
> > 
> > For example the coldplug device add function add_iommu_group() called for
> > all devices already registered when bus_set_iommu() is called will try to
> > warn of devices added multiple times with a WARN_ON(dev->iommu_group).
> > Another example is the iommu_bus_notifier() function which will call the
> > remove_device() operation only when dev->iommu_group isn't NULL.
> > 
> > I'm thus unsure whether groups should be made mandatory, or whether the
> > IOMMU core should be fixed to make them really optional (or, third
> > option, whether there's something I haven't understood properly).
> 
> My plan is to make IOMMU groups mandatory. I am currently preparing and
> RFC patch-set to introduce default-domains (which will be per group). So
> when all IOMMU drivers are converted to make use of default domains the
> iommu groups will be mandatory.

Could the default domain policy be configured by the IOMMU driver ? The ipmmu-
vmsa driver supports four domains only, and serves up to 32 masters, with one 
group per master. A default of one domain per group wouldn't be usable.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v5 11/18] iommu: exynos: remove useless device_add/remove callbacks

[Laurent Pinchart]

Hi Marek,

Thank you for the patch.

On Friday 23 January 2015 16:51:21 Marek Szyprowski wrote:
> The driver doesn't need to do anything important in device add/remove
> callbacks, because initialization will be done from device-tree specific
> callbacks added later. IOMMU groups created by current code were never
> used.

IOMMU groups still seem a bit unclear to me. Will Deacon has nicely explained 
what they represent in 
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/310816.html.
 The IOMMU core doesn't make groups 
mandatory, but requires them in some code paths.

For example the coldplug device add function add_iommu_group() called for all 
devices already registered when bus_set_iommu() is called will try to warn of 
devices added multiple times with a WARN_ON(dev->iommu_group). Another example 
is the iommu_bus_notifier() function which will call the remove_device() 
operation only when dev->iommu_group isn't NULL.

I'm thus unsure whether groups should be made mandatory, or whether the IOMMU 
core should be fixed to make them really optional (or, third option, whether 
there's something I haven't understood properly).

> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/iommu/exynos-iommu.c | 28 
>  1 file changed, 28 deletions(-)
> 
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index e62cb96..e40e699 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -1055,32 +1055,6 @@ static phys_addr_t exynos_iommu_iova_to_phys(struct
> iommu_domain *domain, return phys;
>  }
> 
> -static int exynos_iommu_add_device(struct device *dev)
> -{
> - struct iommu_group *group;
> - int ret;
> -
> - group = iommu_group_get(dev);
> -
> - if (!group) {
> - group = iommu_group_alloc();
> - if (IS_ERR(group)) {
> - dev_err(dev, "Failed to allocate IOMMU group\n");
> - return PTR_ERR(group);
> - }
> - }
> -
> - ret = iommu_group_add_device(group, dev);
> - iommu_group_put(group);
> -
> - return ret;
> -}
> -
> -static void exynos_iommu_remove_device(struct device *dev)
> -{
> - iommu_group_remove_device(dev);
> -}
> -
>  static const struct iommu_ops exynos_iommu_ops = {
>   .domain_init = exynos_iommu_domain_init,
>   .domain_destroy = exynos_iommu_domain_destroy,
> @@ -1090,8 +1064,6 @@ static const struct iommu_ops exynos_iommu_ops = {
>   .unmap = exynos_iommu_unmap,
>   .map_sg = default_iommu_map_sg,
>   .iova_to_phys = exynos_iommu_iova_to_phys,
> - .add_device = exynos_iommu_add_device,
> - .remove_device = exynos_iommu_remove_device,
>   .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
>  };

-- 
Regards,

Laurent Pinchart

--
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 V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Laurent Pinchart]

Hi,

On Monday 19 January 2015 18:05:07 Javier Martinez Canillas wrote:
> On 01/19/2015 05:30 PM, Thierry Reding wrote:
> >> I know you probably are very busy but it would be great if you can take a
> >> look to this series to avoid another kernel release to be missed since
> >> we are already at v3.19-rc5.
> >> 
> >> Only this version was posted 2 months ago and the first version of the
> >> series was sent on May, 2014 so it has been on the list for almost a
> >> year now...
> >> 
> >> Tomi and Laurent had already agreed with the DT binging so I think that
> >> we can already merge these and if there are any remaining issues, those
> >> can be fixed during the 3.20 -rc cycle.
> > 
> > I see only a single Tested-by on this series and that seems to be with a
> > bunch of out-of-tree patches applied on top. Does this now actually work
> > applied on top of upstream? Also it seems like many people actually want
> > this to get merged but there's been no Reviewed-bys and only a single
> > Tested-by? Is that as good as it's going to get?
> 
> Good point, I provided some feedback on an early version of the series but
> I'm not an DRM expert so I couldn't review it in detail to provide my
> Reviewed-by.
> 
> I did provide my Tested-by a long time ago though but looking at the patches
> it seems those were dropped so here goes again:
> 
> For the whole series on an Exynos5420 Peach Pit and an Exynos5250 Snow
> Chromebooks:
> 
> Tested-by: Javier Martinez Canillas 
> 
> > Also I think the last update was that Ajay was going to resend this
> > based on v3.19-rc1 or something. Is that still going to happen?
> > Otherwise I can probably try to apply as-is, but not sure how well it
> > will.
> 
> Ajay,
> 
> Are you going to rebase and resend this series with all the provided tags?
> Gustavo and I have a rebased branch on top of 3.19-rc5 and one of us can
> post your series if you are not planning to do it.
> 
> Laurent and Tomi,
> 
> You said that you are OK with the DT bindings now, does that count as an
> Acked-by or Reviewed-by for you at least for the DT bindings changes in the
> series?

It counts as an Acked-by for the DT bindings.

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v4 17/18] iommu: exynos: init from dt-specific callback instead of initcall

[Laurent Pinchart]

Hi Will,

On Monday 19 January 2015 11:33:31 Will Deacon wrote:
> On Mon, Jan 19, 2015 at 01:11:07AM +0000, Laurent Pinchart wrote:
> > On Friday 16 January 2015 10:13:11 Marek Szyprowski wrote:
> >> This patch introduces IOMMU_OF_DECLARE-based initialization to the
> >> driver, which replaces subsys_initcall-based procedure.
> >> exynos_iommu_of_setup ensures that each sysmmu controller is probed
> >> before its master device.
> 
> [...]
> 
> >> +static int __init exynos_iommu_of_setup(struct device_node *np)
> >> +{
> >> +  struct platform_device *pdev;
> >> +
> >> +  if (!init_done)
> >> +  exynos_iommu_init();
> >> +
> >> +  pdev = of_platform_device_create(np, NULL,
> >> platform_bus_type.dev_root);
> >> +  if (IS_ERR(pdev))
> >> +  return PTR_ERR(pdev);
> > 
> > This feels like a hack to me. What happens here is that you're using the
> > IOMMU_OF_DECLARE mechanism to make sure that the iommu platform device
> > will be created and registered before the normal OF bus populate
> > mechanism kicks in, thus ensuring that the iommu gets probed before other
> > devices. In practice this is pretty similar to using different init
> > levels, which is what Will's patch set was trying to avoid in the first
> > place. Creating a new kind of init levels mechanism doesn't sound very
> > good to me.
> > 
> > The existing exynos-iommu driver is based on classic instantiation of a
> > platform device from DT, using the normal device probing mechanism. As
> > such it relies on the availability of a struct device for various helper
> > functions. I thus understand why you want a struct device being
> > registered for the iommu, instead of initializing the device right from
> > the exynos_iommu_of_setup() function without a corresponding struct
> > device being registered.
> > 
> > This leads me to question whether we should really introduce
> > IOMMU_OF_DECLARE. Using regular deferred probing seems more and more like
> > a better solution to me.
> 
> We seem to be going round and round on this argument. I said before that
> I'm not against changing this [1], but somebody would need to propose
> patches, which hasn't happened in recent history.
> 
> Arnd also makes some good arguments against using probing [2], which would
> need further discussion.
> 
> Basically, it looks like there are two sides to this argument and I don't
> see anything changing without patch proposals. The only thing that the
> current discussions seem to be achieving is blocking people like Marek,
> who are trying to make use of what we have in mainline today!

To be perfectly clear, I won't block patches here without submitting a 
counterproposal (unless there's something fundamentally wrong of course). I 
still believe the deferred probe approach should be given at least a try, but 
as I don't have time to implement that myself now, I won't try to block 
anything.

> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/310783.
> html
> [2]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/310992.
> html

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v4 17/18] iommu: exynos: init from dt-specific callback instead of initcall

[Laurent Pinchart]

Hi Marek,

Thank you for the patch.

On Friday 16 January 2015 10:13:11 Marek Szyprowski wrote:
> This patch introduces IOMMU_OF_DECLARE-based initialization to the
> driver, which replaces subsys_initcall-based procedure.
> exynos_iommu_of_setup ensures that each sysmmu controller is probed
> before its master device.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/iommu/exynos-iommu.c | 28 +++-
>  1 file changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index c53cc8f61176..ea2659159e63 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c
> @@ -13,16 +13,21 @@
>  #endif
> 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  #include 
>  #include 
>  #include 
> 
>  #include 
> +#include 
>  #include 
> 
>  typedef u32 sysmmu_iova_t;
> @@ -1084,6 +1089,8 @@ static const struct iommu_ops exynos_iommu_ops = {
>   .pgsize_bitmap = SECT_SIZE | LPAGE_SIZE | SPAGE_SIZE,
>  };
> 
> +static int init_done;
> +
>  static int __init exynos_iommu_init(void)
>  {
>   int ret;
> @@ -1116,6 +1123,8 @@ static int __init exynos_iommu_init(void)
>   goto err_set_iommu;
>   }
> 
> + init_done = true;
> +
>   return 0;
>  err_set_iommu:
>   kmem_cache_free(lv2table_kmem_cache, zero_lv2_table);
> @@ -1125,4 +1134,21 @@ err_reg_driver:
>   kmem_cache_destroy(lv2table_kmem_cache);
>   return ret;
>  }
> -subsys_initcall(exynos_iommu_init);
> +
> +static int __init exynos_iommu_of_setup(struct device_node *np)
> +{
> + struct platform_device *pdev;
> +
> + if (!init_done)
> + exynos_iommu_init();
> +
> + pdev = of_platform_device_create(np, NULL, platform_bus_type.dev_root);
> + if (IS_ERR(pdev))
> + return PTR_ERR(pdev);

This feels like a hack to me. What happens here is that you're using the 
IOMMU_OF_DECLARE mechanism to make sure that the iommu platform device will be 
created and registered before the normal OF bus populate mechanism kicks in, 
thus ensuring that the iommu gets probed before other devices. In practice 
this is pretty similar to using different init levels, which is what Will's 
patch set was trying to avoid in the first place. Creating a new kind of init 
levels mechanism doesn't sound very good to me.

The existing exynos-iommu driver is based on classic instantiation of a 
platform device from DT, using the normal device probing mechanism. As such it 
relies on the availability of a struct device for various helper functions. I 
thus understand why you want a struct device being registered for the iommu, 
instead of initializing the device right from the exynos_iommu_of_setup() 
function without a corresponding struct device being registered.

This leads me to question whether we should really introduce IOMMU_OF_DECLARE. 
Using regular deferred probing seems more and more like a better solution to 
me.

> + of_iommu_set_ops(np, &exynos_iommu_ops);
> + return 0;
> +}
> +
> +IOMMU_OF_DECLARE(exynos_iommu_of, "samsung,exynos-sysmmu",
> +  exynos_iommu_of_setup);

-- 
Regards,

Laurent Pinchart
--
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: [Linaro-mm-sig] [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall

[Laurent Pinchart]

Hi Arnd,

On Wednesday 17 December 2014 16:56:53 Arnd Bergmann wrote:
> On Wednesday 17 December 2014 15:53:25 Lucas Stach wrote:
> > Am Mittwoch, den 17.12.2014, 15:27 +0100 schrieb Arnd Bergmann:
> >> On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
> >>> If we forbid the IOMMU driver from being compiled as a module can't we
> >>> just rely on deferred probing ? The bus master driver will just be
> >>> reprobed after the IOMMU gets probed, like for other devices.
> >>> 
> >>> This could fail in case the IOMMU device permanently fails to probe.
> >>> There would be something very wrong in the system in that case,
> >>> Enabling the bus masters totally transparently without IOMMU support
> >>> could not be such a good idea.
> >> 
> >> I believe in the majority of cases today, the IOMMU is entirely
> >> optional. There are valid reasons for not including the IOMMU driver in
> >> the kernel, e.g. when you know that all the machines with that driver
> >> can DMA to all of their RAM and you want to avoid the overhead of IOTLB
> >> misses.
> > 
> > This is similar to the problems we discussed with the componentized
> > device framework and in the end everybody agreed on a simple rule:
> > if the device node is enabled in the DT there must be a driver bound to
> > it before other devices depending on this node can be probed.
> > 
> > If we apply the same logic to the IOMMU situation we get two
> > possibilities to allow bypassing the IOMMU:
> > 1. completely disable the IOMMU node in the DT
> > 2. leave node enabled in DT, but add a bypass property
> > 
> > Obviously the second option still requires to have the IOMMU driver
> > available, but is more flexible. Right now everything depends on the
> > IOMMU being in passthrough mode at reset with no driver bound. If a
> > device comes around where this isn't the case thing will break with the
> > current assumptions or the first option.
> > 
> > Having the IOMMU node enabled in DT with no driver available to the
> > kernel seems like an invalid configuration which should be expected to
> > break. Exactly the same thing as with componentized devices...
> 
> One differences here is that for the IOMMU, we should generally be able
> to fall back to swiotlb

Or to nothing at all if the device can DMA to the allocated memory directly.

> (currently only on ARM64, not ARM32, until someone adds support). I can see
> your point regarding machines that have a mandatory IOMMU with no fallback
> when there is no driver, but we can support them by making the iommu driver
> selected through Kconfig for that platform, while still allowing other
> platforms to work with drivers left out of the kernel.

The question is how to tell the kernel not to wait for an IOMMU that will 
never be there. Would a kernel command line argument be an acceptable solution 
or do we need something more automatic ?

-- 
Regards,

Laurent Pinchart

--
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: [Linaro-mm-sig] [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall

[Laurent Pinchart]

Hi Arnd,

On Wednesday 17 December 2014 22:58:47 Arnd Bergmann wrote:
> On Wednesday 17 December 2014 18:02:51 Laurent Pinchart wrote:
> > On Wednesday 17 December 2014 16:41:33 Arnd Bergmann wrote:
> >> On Wednesday 17 December 2014 16:39:02 Laurent Pinchart wrote:
> >>> On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote:
> >>>> On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
> >>>>> If we forbid the IOMMU driver from being compiled as a module
> >>>>> can't we just rely on deferred probing ? The bus master driver
> >>>>> will just be reprobed after the IOMMU gets probed, like for other
> >>>>> devices.
> >>>>> 
> >>>>> This could fail in case the IOMMU device permanently fails to
> >>>>> probe. There would be something very wrong in the system in that
> >>>>> case, Enabling the bus masters totally transparently without IOMMU
> >>>>> support could not be such a good idea.
> >>>> 
> >>>> I believe in the majority of cases today, the IOMMU is entirely
> >>>> optional. There are valid reasons for not including the IOMMU driver
> >>>> in the kernel, e.g. when you know that all the machines with that
> >>>> driver can DMA to all of their RAM and you want to avoid the
> >>>> overhead of IOTLB misses.
> >>> 
> >>> Should that really be controlled by compiling the IOMMU driver out,
> >>> wouldn't it be better to disable the IOMMU devices in DT in that case
> >>> ?
> >> 
> >> It's a policy decision that should only depend on the user. Modifying
> >> the DT is wrong here IMHO because the device is still connected to the
> >> IOMMU in hardware and we should correctly represent that.
> > 
> > I was thinking about setting status = "disabled" on the IOMMU nodes, not
> > removing the IOMMU references in the bus master nodes.
> 
> But that still requires a modification of the DT. The hardware is the
> same, so I don't see why we should update the dtb based on kernel
> configuration.

It wouldn't be the first time we encode configuration information in DT, but I 
agree it's not an optimal solution. Setting iommu=off on the kernel command 
line is better, and should be easy to implement.

-- 
Regards,

Laurent Pinchart

--
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: [Linaro-mm-sig] [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall

[Laurent Pinchart]

Hi Arnd,

On Wednesday 17 December 2014 16:41:33 Arnd Bergmann wrote:
> On Wednesday 17 December 2014 16:39:02 Laurent Pinchart wrote:
> > On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote:
> > > On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
> > > > If we forbid the IOMMU driver from being compiled as a module can't we
> > > > just rely on deferred probing ? The bus master driver will just be
> > > > reprobed after the IOMMU gets probed, like for other devices.
> > > > 
> > > > This could fail in case the IOMMU device permanently fails to probe.
> > > > There
> > > > would be something very wrong in the system in that case, Enabling the
> > > > bus
> > > > masters totally transparently without IOMMU support could not be such
> > > > a
> > > > good idea.
> > > 
> > > I believe in the majority of cases today, the IOMMU is entirely
> > > optional.
> > > There are valid reasons for not including the IOMMU driver in the
> > > kernel,
> > > e.g. when you know that all the machines with that driver can DMA to
> > > all of their RAM and you want to avoid the overhead of IOTLB misses.
> > 
> > Should that really be controlled by compiling the IOMMU driver out,
> > wouldn't it be better to disable the IOMMU devices in DT in that case ?
> 
> It's a policy decision that should only depend on the user. Modifying the
> DT is wrong here IMHO because the device is still connected to the IOMMU
> in hardware and we should correctly represent that.

I was thinking about setting status = "disabled" on the IOMMU nodes, not 
removing the IOMMU references in the bus master nodes.

> You can normally set 'iommu=off' or 'iommu=force' on the command line
> to force it on or off rather than letting the IOMMU driver decide whether
> the device turns it on. Not enabling the IOMMU at all should really just
> behave the same way as 'iommu=off', anything else would be very confusing.

Setting iommu=off sounds fine to me. The IOMMU core would then return a "no 
IOMMU present" error instead of -EPROBE_DEFER, and probing of the bus masters 
would continue without IOMMU support.

-- 
Regards,

Laurent Pinchart

--
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: [Linaro-mm-sig] [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall

[Laurent Pinchart]

Hi Arnd,

On Wednesday 17 December 2014 15:27:36 Arnd Bergmann wrote:
> On Wednesday 17 December 2014 01:24:42 Laurent Pinchart wrote:
> > If we forbid the IOMMU driver from being compiled as a module can't we
> > just rely on deferred probing ? The bus master driver will just be
> > reprobed after the IOMMU gets probed, like for other devices.
> > 
> > This could fail in case the IOMMU device permanently fails to probe. There
> > would be something very wrong in the system in that case, Enabling the bus
> > masters totally transparently without IOMMU support could not be such a
> > good idea.
> 
> I believe in the majority of cases today, the IOMMU is entirely optional.
> There are valid reasons for not including the IOMMU driver in the kernel,
> e.g. when you know that all the machines with that driver can DMA to
> all of their RAM and you want to avoid the overhead of IOTLB misses.

Should that really be controlled by compiling the IOMMU driver out, wouldn't 
it be better to disable the IOMMU devices in DT in that case ?

-- 
Regards,

Laurent Pinchart

--
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 V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Laurent Pinchart]

Hi Javier,

On Wednesday 17 December 2014 10:31:41 Javier Martinez Canillas wrote:
> On 12/16/2014 12:37 AM, Laurent Pinchart wrote:
> > Hi Javier,
> > 
> >> Tomi and Laurent,
> >> 
> >> You asked Ajay to change his series to use the video port and enpoints DT
> >> bindings instead of phandles, could you please review his latest version?
> >> 
> >> I guess is now too late for 3.19 since we are in the middle of the merge
> >> window but it would be great if this series can at least made it to 3.20.
> > 
> > I don't have time to review the series in details right now, but I'm happy
> > with the DT bindings, and have no big issue with the rest of the patches.
> > I
> > don't really like the of_drm_find_bridge() concept introduced in 03/14 but
> > I won't nack it given lack of time to implement an alternative proposal.
> > It's an internal API, it can always be reworked later anyway.
> 
> Thanks a lot for taking the time to look at the DT bindings,

You're welcome. Sorry for the long delay.

> then I guess that the series are finally ready to be merged?

>From my point of view, yes.

> Ajay's series don't apply cleanly anymore because it has been a while since
> he posted it but he can rebase on top of 3.19-rc1 once it is released and
> re-resend.

-- 
Regards,

Laurent Pinchart

--
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: [Linaro-mm-sig] [PATCH v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall

[Laurent Pinchart]

Hi Arnd,

On Tuesday 16 December 2014 13:10:59 Arnd Bergmann wrote:
> On Tuesday 16 December 2014 14:07:11 Laurent Pinchart wrote:
> > On Tuesday 16 December 2014 12:40:28 Arnd Bergmann wrote:
> > > On Monday 15 December 2014 18:13:23 Will Deacon wrote:
> > > >>>> IOMMUs are not as low-level as system interrupt controllers or
> > > >>>> system clocks. I'm beginning to agree with Thierry that they should
> > > >>>> be treated as normal platform devices as they're not required
> > > >>>> earlier than probe time of their bus master devices.
> > > >>> 
> > > >>> Well, I think you'd have to propose patches for discussion since I'm
> > > >>> certainly not wed to the current approach; I just want something
> > > >>> that allows of_{dma,iommu}_configure to run with the information it
> > > >>> needs.
> > > >> 
> > > >> Do we need of_dma_configure() to run when the device is created, or
> > > >> could we postpone it to just before probe time ?
> > > > 
> > > > I'm not sure I can answer that one... Arnd?
> > > 
> > > I believe we could postpone it to probe time, but I'd rather not.
> > > The way I see the arguments in favor, we have mainly cosmetic arguments:
> > > 
> > > - Doing it at probe time would eliminate the ugly section magic hack
> > > - iommu drivers could be implemented as loadable modules with platform
> > >   drivers, for consistency with most other drivers
> > 
> > The main argument, from my point of view, is that handling IOMMUs are
> > normal platform devices allow using all the kernel infrastructure that
> > depends on a struct device. The dev_* print helpers are nice to have, but
> > what would make a big difference is the ability to use runtime PM.
> 
> Right, I agree that would be nice.
> 
> > > On the other hand, I see:
> > > 
> > > - DMA configuration is traditionally done at device creation time, and
> > >   changing that is more likely to introduce bugs than leaving it
> > >   where it is.
> > > 
> > > - On a lot of machines, the IOMMU is optional, and the probe function
> > >   cannot know the difference between an IOMMU driver that is left out
> > >   of the kernel and one that will be initialized later, using a fixed
> > >   entry point for initializing the IOMMU makes the behavior consistent
> > 
> > I'm not advocating for IOMMU support being built as a loadable module. It
> > might be nice from a development point of view, but that's about it.
> 
> We'd still have to deal with deferred probing, or with ordering the iommu
> initcalls before the dma master initcalls in some other way, so the
> problem is not that different from loadable modules. Do you have an idea
> for how to solve that?

If we forbid the IOMMU driver from being compiled as a module can't we just 
rely on deferred probing ? The bus master driver will just be reprobed after 
the IOMMU gets probed, like for other devices.

This could fail in case the IOMMU device permanently fails to probe. There 
would be something very wrong in the system in that case, Enabling the bus 
masters totally transparently without IOMMU support could not be such a good 
idea.

-- 
Regards,

Laurent Pinchart

--
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 v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall

[Laurent Pinchart]

Hi Arnd,

On Tuesday 16 December 2014 12:40:28 Arnd Bergmann wrote:
> On Monday 15 December 2014 18:13:23 Will Deacon wrote:
> >>>> IOMMUs are not as low-level as system interrupt controllers or
> >>>> system clocks. I'm beginning to agree with Thierry that they should
> >>>> be treated as normal platform devices as they're not required
> >>>> earlier than probe time of their bus master devices.
> >>> 
> >>> Well, I think you'd have to propose patches for discussion since I'm
> >>> certainly not wed to the current approach; I just want something that
> >>> allows of_{dma,iommu}_configure to run with the information it needs.
> >> 
> >> Do we need of_dma_configure() to run when the device is created, or
> >> could we postpone it to just before probe time ?
> > 
> > I'm not sure I can answer that one... Arnd?
> 
> I believe we could postpone it to probe time, but I'd rather not.
> The way I see the arguments in favor, we have mainly cosmetic arguments:
> 
> - Doing it at probe time would eliminate the ugly section magic hack
> - iommu drivers could be implemented as loadable modules with platform
>   drivers, for consistency with most other drivers

The main argument, from my point of view, is that handling IOMMUs are normal 
platform devices allow using all the kernel infrastructure that depends on a 
struct device. The dev_* print helpers are nice to have, but what would make a 
big difference is the ability to use runtime PM.

> On the other hand, I see:
> 
> - DMA configuration is traditionally done at device creation time, and
>   changing that is more likely to introduce bugs than leaving it
>   where it is.
> - On a lot of machines, the IOMMU is optional, and the probe function
>   cannot know the difference between an IOMMU driver that is left out
>   of the kernel and one that will be initialized later, using a fixed
>   entry point for initializing the IOMMU makes the behavior consistent

I'm not advocating for IOMMU support being built as a loadable module. It 
might be nice from a development point of view, but that's about it.

> There is a third option in theory, which is to only enable the IOMMU
> as part of dma_set_mask(). I've done that in the past on powerpc, but
> the new approach seems cleaner.

-- 
Regards,

Laurent Pinchart

--
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 V8 00/14] drm/exynos: few patches to enhance bridge chip support

[Laurent Pinchart]

Hi Javier,

On Friday 12 December 2014 10:51:50 Javier Martinez Canillas wrote:
> Hello,
> 
> On 11/18/2014 07:20 AM, Ajay kumar wrote:
> > On Sat, Nov 15, 2014 at 3:24 PM, Ajay Kumar wrote:
> >> This series is based on master branch of Linus tree at:
> >> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> 
> This series has been in the mailing lists for months and have been tested
> by many people. What else is missing before it can be merged?
> 
> It would be great to have proper display support on platforms that have a
> eDP to LVDS bridge chip (e.g: Snow, Peach Pit and Spring Chromebooks) and
> everything is in place but this series which had been missing many kernel
> releases already.
> 
> >> Changes since V7:
> >> -- Address comments from Tomi and Laurent:
> >> -- Use videoports and endpoints to represent the
> >> connection between
> >> 
> >>encoder, bridge and the panel, instead of using
> >>phandles.
> >> 
> >> -- Address comments from Daniel:
> >> -- Make the patch description more descriptive.
> >> -- remove device pointer from drm_bridge, and just use
> >> 
> >>device_node instead.
> >> 
> >> -- don't pass encoder pointer to bridge_attach.
> >> 
> >> -- Address comments from Sean Paul:
> >> -- Remove bridge from mode_config, and pull out
> >> drm_bridge
> >> 
> >>functions from drm_crtc.c to drm_bridge.c
> 
> Tomi and Laurent,
> 
> You asked Ajay to change his series to use the video port and enpoints DT
> bindings instead of phandles, could you please review his latest version?
> 
> I guess is now too late for 3.19 since we are in the middle of the merge
> window but it would be great if this series can at least made it to 3.20.

I don't have time to review the series in details right now, but I'm happy 
with the DT bindings, and have no big issue with the rest of the patches. I 
don't really like the of_drm_find_bridge() concept introduced in 03/14 but I 
won't nack it given lack of time to implement an alternative proposal. It's an 
internal API, it can always be reworked later anyway.

-- 
Regards,

Laurent Pinchart

--
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 v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall

[Laurent Pinchart]

On Monday 15 December 2014 18:13:23 Will Deacon wrote:
> On Mon, Dec 15, 2014 at 05:53:48PM +0000, Laurent Pinchart wrote:
> > Hi Will,
> 
> Hello again :)
> 
> > On Monday 15 December 2014 17:43:02 Will Deacon wrote:
> > > On Mon, Dec 15, 2014 at 05:27:30PM +, Laurent Pinchart wrote:
> > > > On Monday 15 December 2014 17:17:00 Will Deacon wrote:
> > > > > Creating the platform device manually for the IOMMU is indeed
> > > > > grotty, but I don't really understand why it's needed. Interrupt
> > > > > controllers, for example, seem to get by without one.
> > > > 
> > > > There's several reasons, one of the most compelling ones I can think
> > > > of at the moment is runtime PM. IRQ controllers close to the CPU use
> > > > CPU PM notifiers instead. Note that IRQ controllers that are further
> > > > away from the CPU (such as GPIO-based IRQ controllers) are real
> > > > platform devices and use runtime PM.
> > > 
> > > Ok, that's a good point, but the IOMMU will still probe later anyway,
> > > right?
> >
> > That depends on the driver implementation, using OF node match an IOMMU
> > driver doesn't have to register a struct driver. Assuming we require
> > IOMMU drivers to register a struct driver, a platform device should then
> > be probed at a later time.
> > 
> > However, if we wait until the IOMMU gets probed to initialize runtime PM
> > and make it functional, we'll be back in square one if the IOMMU gets
> > probed after the bus master, as the bus master could start issuing bus
> > requests at probe time with the IOMMU not powered yet.
> 
> True, but couldn't the early init code do enough to get the thing
> functional? That said, I'm showing my ignorance here as I'm not familiar
> with the PM code (and the software models I have for the SMMU clearly don't
> implement anything in this regard).

We're reaching the limits of my knowledge as well. If the IOMMU is in a power 
domain different than the bus masters the driver would at least need to ensure 
that the power domain is turned on, which might be a bit hackish without 
runtime PM.

> > > > IOMMUs are not as low-level as system interrupt controllers or system
> > > > clocks. I'm beginning to agree with Thierry that they should be
> > > > treated as normal platform devices as they're not required earlier
> > > > than probe time of their bus master devices.
> > > 
> > > Well, I think you'd have to propose patches for discussion since I'm
> > > certainly not wed to the current approach; I just want something that
> > > allows of_{dma,iommu}_configure to run with the information it needs.
> > 
> > Do we need of_dma_configure() to run when the device is created, or could
> > we postpone it to just before probe time ?
> 
> I'm not sure I can answer that one... Arnd?

-- 
Regards,

Laurent Pinchart

--
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 v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall

[Laurent Pinchart]

Hi Will,

On Monday 15 December 2014 17:43:02 Will Deacon wrote:
> On Mon, Dec 15, 2014 at 05:27:30PM +0000, Laurent Pinchart wrote:
> > On Monday 15 December 2014 17:17:00 Will Deacon wrote:
> > > On Sun, Dec 14, 2014 at 12:45:36PM +, Laurent Pinchart wrote:
> > > > On Wednesday 19 November 2014 12:15:47 Marek Szyprowski wrote:
> > > > > +static int __init exynos_iommu_of_setup(struct device_node *np)
> > > > > +{
> > > > > + struct platform_device *pdev;
> > > > > +
> > > > > + if (!init_done)
> > > > > + exynos_iommu_init();
> > > > > +
> > > > > + pdev = of_platform_device_create(np, NULL,
> > > > > platform_bus_type.dev_root);
> > > > > + if (IS_ERR(pdev))
> > > > > + return PTR_ERR(pdev);
> > > > 
> > > > If we end up having to create the IOMMU platform devices from within
> > > > the drivers, the introduction of IOMMU_OF_DECLARE starts to feel like
> > > > a workaround to me. I wonder whether it wouldn't then be better to let
> > > > the driver core instantiate the IOMMU platform device from DT as for
> > > > all other devices, and use device notifiers to defer probe of the bus
> > > > masters until the required IOMMU(s) are registered.
> > > > 
> > > > Will, what's your opinion on that ?
> > > 
> > > Creating the platform device manually for the IOMMU is indeed grotty,
> > > but I don't really understand why it's needed. Interrupt controllers,
> > > for example, seem to get by without one.
> > 
> > There's several reasons, one of the most compelling ones I can think of at
> > the moment is runtime PM. IRQ controllers close to the CPU use CPU PM
> > notifiers instead. Note that IRQ controllers that are further away from
> > the CPU (such as GPIO-based IRQ controllers) are real platform devices
> > and use runtime PM.
>
> Ok, that's a good point, but the IOMMU will still probe later anyway, right?

That depends on the driver implementation, using OF node match an IOMMU driver 
doesn't have to register a struct driver. Assuming we require IOMMU drivers to 
register a struct driver, a platform device should then be probed at a later 
time.

However, if we wait until the IOMMU gets probed to initialize runtime PM and 
make it functional, we'll be back in square one if the IOMMU gets probed after 
the bus master, as the bus master could start issuing bus requests at probe 
time with the IOMMU not powered yet.

> > IOMMUs are not as low-level as system interrupt controllers or system
> > clocks. I'm beginning to agree with Thierry that they should be treated
> > as normal platform devices as they're not required earlier than probe
> > time of their bus master devices.
> 
> Well, I think you'd have to propose patches for discussion since I'm
> certainly not wed to the current approach; I just want something that
> allows of_{dma,iommu}_configure to run with the information it needs.

Do we need of_dma_configure() to run when the device is created, or could we 
postpone it to just before probe time ?

> The usual answer is `we should model buses properly', but that's really
> not practical afaict.

-- 
Regards,

Laurent Pinchart

--
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 v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall

[Laurent Pinchart]

Hi Will,

On Monday 15 December 2014 17:17:00 Will Deacon wrote:
> On Sun, Dec 14, 2014 at 12:45:36PM +0000, Laurent Pinchart wrote:
> > On Wednesday 19 November 2014 12:15:47 Marek Szyprowski wrote:
> > > This patch introduces IOMMU_OF_DECLARE-based initialization to the
> > > driver, which replaces subsys_initcall-based procedure.
> > > exynos_iommu_of_setup ensures that each sysmmu controller is probed
> > > before its master device.
> > > 
> > > Signed-off-by: Marek Szyprowski 
> > > ---
> > > 
> > >  drivers/iommu/exynos-iommu.c | 28 +++-
> > >  1 file changed, 27 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> > > index cd28dc09db39..88f9afe641a0 100644
> > > --- a/drivers/iommu/exynos-iommu.c
> > > +++ b/drivers/iommu/exynos-iommu.c
> > 
> > [snip]
> > 
> > > @@ -1125,4 +1134,21 @@ err_reg_driver:
> > >   kmem_cache_destroy(lv2table_kmem_cache);
> > >   return ret;
> > >  
> > >  }
> > > 
> > > -subsys_initcall(exynos_iommu_init);
> > > +
> > > +static int __init exynos_iommu_of_setup(struct device_node *np)
> > > +{
> > > + struct platform_device *pdev;
> > > +
> > > + if (!init_done)
> > > + exynos_iommu_init();
> > > +
> > > + pdev = of_platform_device_create(np, NULL,
> > > platform_bus_type.dev_root);
> > > + if (IS_ERR(pdev))
> > > + return PTR_ERR(pdev);
> > 
> > If we end up having to create the IOMMU platform devices from within the
> > drivers, the introduction of IOMMU_OF_DECLARE starts to feel like a
> > workaround to me. I wonder whether it wouldn't then be better to let the
> > driver core instantiate the IOMMU platform device from DT as for all
> > other devices, and use device notifiers to defer probe of the bus masters
> > until the required IOMMU(s) are registered.
> > 
> > Will, what's your opinion on that ?
> 
> Creating the platform device manually for the IOMMU is indeed grotty, but I
> don't really understand why it's needed. Interrupt controllers, for example,
> seem to get by without one.

There's several reasons, one of the most compelling ones I can think of at the 
moment is runtime PM. IRQ controllers close to the CPU use CPU PM notifiers 
instead. Note that IRQ controllers that are further away from the CPU (such as 
GPIO-based IRQ controllers) are real platform devices and use runtime PM.

IOMMUs are not as low-level as system interrupt controllers or system clocks. 
I'm beginning to agree with Thierry that they should be treated as normal 
platform devices as they're not required earlier than probe time of their bus 
master devices.

-- 
Regards,

Laurent Pinchart

--
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 v3 18/19] iommu: exynos: init from dt-specific callback instead of initcall

[Laurent Pinchart]

Hi Marek,

Thank you for the patch.

On Wednesday 19 November 2014 12:15:47 Marek Szyprowski wrote:
> This patch introduces IOMMU_OF_DECLARE-based initialization to the
> driver, which replaces subsys_initcall-based procedure.
> exynos_iommu_of_setup ensures that each sysmmu controller is probed
> before its master device.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/iommu/exynos-iommu.c | 28 +++-
>  1 file changed, 27 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
> index cd28dc09db39..88f9afe641a0 100644
> --- a/drivers/iommu/exynos-iommu.c
> +++ b/drivers/iommu/exynos-iommu.c

[snip]

> @@ -1125,4 +1134,21 @@ err_reg_driver:
>   kmem_cache_destroy(lv2table_kmem_cache);
>   return ret;
>  }
> -subsys_initcall(exynos_iommu_init);
> +
> +static int __init exynos_iommu_of_setup(struct device_node *np)
> +{
> + struct platform_device *pdev;
> +
> + if (!init_done)
> + exynos_iommu_init();
> +
> + pdev = of_platform_device_create(np, NULL, platform_bus_type.dev_root);
> + if (IS_ERR(pdev))
> + return PTR_ERR(pdev);

If we end up having to create the IOMMU platform devices from within the 
drivers, the introduction of IOMMU_OF_DECLARE starts to feel like a workaround 
to me. I wonder whether it wouldn't then be better to let the driver core 
instantiate the IOMMU platform device from DT as for all other devices, and 
use device notifiers to defer probe of the bus masters until the required 
IOMMU(s) are registered.

Will, what's your opinion on that ?

> +
> + of_iommu_set_ops(np, &exynos_iommu_ops);
> + return 0;
> +}
> +
> +IOMMU_OF_DECLARE(exynos_iommu_of, "samsung,exynos-sysmmu",
> +  exynos_iommu_of_setup);

-- 
Regards,

Laurent Pinchart

--
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Laurent Pinchart]

Hi Ajay,

On Friday 10 October 2014 18:33:05 Ajay kumar wrote:
> On Wed, Oct 8, 2014 at 12:39 PM, Thierry Reding wrote:
> > On Tue, Oct 07, 2014 at 05:49:24PM +0300, Laurent Pinchart wrote:
> >> On Tuesday 07 October 2014 16:06:55 Ajay kumar wrote:
> >> > On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen wrote:
> >> > > On 20/09/14 14:22, Ajay kumar wrote:
> >> > >> Well, I am okay with using video ports to describe the relationship
> >> > >> between the encoder, bridge and the panel.
> >> > >> But, its just that I need to make use of 2 functions when phandle
> >> > >> does it using just one function ;)
> >> > >> -panel_node = of_parse_phandle(dev->of_node, "panel", 0)
> >> > >> +   endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
> >> > >> +   if (!endpoint)
> >> > >> +   return -EPROBE_DEFER;
> >> > >> +
> >> > >> +   panel_node = of_graph_get_remote_port_parent(endpoint);
> >> > >> +   if (!panel_node)
> >> > >> +   return -EPROBE_DEFER;
> >> > >> 
> >> > >> 
> >> > >> If nobody else has objections over using of_graph functions instead
> >> > >> of phandles, I can respin this patchset by making use of video
> >> > >> ports.
> >> > > 
> >> > > The discussion did digress somewhat.
> >> > > 
> >> > > As a clarification, I'm in no way nack'ing this series because it
> >> > > doesn't use the graphs for video connections. I don't see the simple
> >> > > phandle bindings used here as broken as such.
> >> > 
> >> > Well, I am okay with any approach you guys decide on. I desperately
> >> > want this to get this in since it has been floating around for quite
> >> > sometime. The more we drag this, the more rework for me since the
> >> > number of platforms using bridge support is increasing daily!
> >> 
> >> I won't nack this patch either. I'm however concerned that we'll run
> >> straight into the wall if we don't come up with an agreement on a
> >> standard way to describe connections in DT for display devices, which is
> >> why I would prefer the ps8622 bindings to use OF graph to describe
> >> connections.
> > 
> > I think there's not really an easy way out here. It's pretty bold trying
> > to come up with a common way to describe bridges when we have only a
> > single one (and a single use-case at that). The worst that can happen is
> > that we need to change the binding at some point, in which case we may
> > have to special-case early drivers, but I really don't think that's as
> > much of an issue as everybody seems to think.
> > 
> > This series has been floating around for months because we're being
> > overly prudent to accept a binding that /may/ turn out to not be generic
> > enough.
> 
> Right. It would be great if you guys come to agreement ASAP!

I don't think we'll agree any time soon, so I believe it's up to you to decide 
which option is best based on all arguments that have been presented.

If you ask me, of course, OF graph is best :-)

-- 
Regards,

Laurent Pinchart

--
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Laurent Pinchart]

Hi Tomi,

On Tuesday 07 October 2014 11:25:56 Tomi Valkeinen wrote:
> On 07/10/14 10:23, Laurent Pinchart wrote:
> >> You mean the bridge driver would somehow take a peek into panel1 and
> >> panel2 nodes, looking for bridge specific properties? Sounds somewhat
> >> fragile to me... How would the bridge driver know a property is for the
> >> bridge?
> > 
> > No, I mean the bridge driver should call the API provided by the panel
> > objects to get information about the panels, and compute its
> > configuration parameters from those. I'm not sure if that's possible
> > though, it depends on whether the bridge parameters can be computed from
> > information provided by the panel.
>
> Right. My example tried to show a case where they can't be queried. The
> board or the wiring causes signal degradation, which can be fixed by
> increasing the bridge output voltage slightly.
> 
> So it has nothing really to do with the panel, but the board.
> 
> I fully admit that it is a purely theoretical case, and I don't have any
> real use cases in mind right now.

Still, I agree with you that we might need to configure the bridge differently 
depending on the selected output with parameters that are not specific to the 
bridge.

There's two use cases I can think of. In the first one the panels are 
connected directly to the bridge. The bridge should have two links from its 
output port, one to each panel. If we use the OF graph bindings then the 
bridge output port node would have two endpoint nodes, and configuration 
parameters can be stored in the endpoint nodes.

In the second use case another element would be present between the bridge and 
the two panels. In that case there would be a single link between the bridge 
and that other element. If the bridge needs to be configured differently 
depending on the selected panel using parameters that can't be queried from 
the panels, then we'll have a problem. I'm not sure whether this use case has 
practical applications as board-related parameters seem to me that they 
pertain to physical links.

-- 
Regards,

Laurent Pinchart

--
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Laurent Pinchart]

Hi Ajay,

On Tuesday 07 October 2014 16:06:55 Ajay kumar wrote:
> On Tue, Oct 7, 2014 at 4:00 PM, Tomi Valkeinen wrote:
> > On 20/09/14 14:22, Ajay kumar wrote:
> >> Well, I am okay with using video ports to describe the relationship
> >> between the encoder, bridge and the panel.
> >> But, its just that I need to make use of 2 functions when phandle
> >> does it using just one function ;)
> >> -panel_node = of_parse_phandle(dev->of_node, "panel", 0)
> >> +   endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
> >> +   if (!endpoint)
> >> +   return -EPROBE_DEFER;
> >> +
> >> +   panel_node = of_graph_get_remote_port_parent(endpoint);
> >> +   if (!panel_node)
> >> +   return -EPROBE_DEFER;
> >> 
> >> 
> >> If nobody else has objections over using of_graph functions instead
> >> of phandles, I can respin this patchset by making use of video ports.
> > 
> > The discussion did digress somewhat.
> > 
> > As a clarification, I'm in no way nack'ing this series because it
> > doesn't use the graphs for video connections. I don't see the simple
> > phandle bindings used here as broken as such.
> 
> Well, I am okay with any approach you guys decide on. I desperately want
> this to get this in since it has been floating around for quite sometime.
> The more we drag this, the more rework for me since the number of platforms
> using bridge support is increasing daily!

I won't nack this patch either. I'm however concerned that we'll run straight 
into the wall if we don't come up with an agreement on a standard way to 
describe connections in DT for display devices, which is why I would prefer 
the ps8622 bindings to use OF graph to describe connections.

-- 
Regards,

Laurent Pinchart

--
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Laurent Pinchart]

Hi Tomi,

On Tuesday 07 October 2014 10:06:10 Tomi Valkeinen wrote:
> On 06/10/14 17:40, Laurent Pinchart wrote:
> >> But seriously speaking, I was thinking about this. I'd really like to
> >> have a generic video-mux node, that would still somehow allow us to have
> >> device specific configurations for the video sources and sinks (which
> >> the endpoints provide us), without endpoints.
> >> 
> >> The reason endpoints don't feel right in this case is that it makes
> >> sense that the mux has a single input and two outputs, but with
> >> endpoints we need two endpoints from the bridge (which is still ok), but
> >> we also need two endpoitns in the mux's input side, which doesn't feel
> >> right.
> >> 
> >> I came up with the following. It's quite ugly, though. I hope someone
> >> has ideas how it could be done in a neater way:
> >> 
> >> bridge1234 {
> >> 
> >>bridge1234-cfg1: config1 {
> >>
> >>high-voltage;
> >>
> >>};
> >>
> >>bridge1234-cfg2: config2 {
> >>
> >>low-voltage;
> >>
> >>};
> >>
> >>output = <&mux>;
> >> 
> >> };
> >> 
> >> mux: video-gpio-mux {
> >> 
> >>gpio = <123>;
> >>
> >>outputs = <&panel1 &panel2>;
> >>input-configs = <&bridge1234-cfg1 &bridge1234-cfg2>;
> >> 
> >> };
> >> 
> >> panel1: panel-foo {
> >> 
> >> };
> >> 
> >> panel2: panel-foo {
> >> 
> >> };
> >> 
> >> So the bridge node has configuration sets. These might be compared to
> >> pinmux nodes. And the mux has a list of input-configs. When panel1 is to
> >> be enabled, "bridge1234-cfg1" config becomes active, and the bridge is
> >> given this configuration.
> >> 
> >> I have to say the endpoint system feels cleaner than the above, but
> >> perhaps it's possible to improve the method above somehow.
> > 
> > Isn't it possible for the bridge to compute its configuration at runtime
> > by querying properties of the downstream video entities ? That would solve
> > the problem neatly.
> 
> You mean the bridge driver would somehow take a peek into panel1 and
> panel2 nodes, looking for bridge specific properties? Sounds somewhat
> fragile to me... How would the bridge driver know a property is for the
> bridge?

No, I mean the bridge driver should call the API provided by the panel objects 
to get information about the panels, and compute its configuration parameters 
from those. I'm not sure if that's possible though, it depends on whether the 
bridge parameters can be computed from information provided by the panel.

-- 
Regards,

Laurent Pinchart

--
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Laurent Pinchart]

Hi Tomi,

On Wednesday 24 September 2014 11:42:06 Tomi Valkeinen wrote:
> On 23/09/14 17:45, Thierry Reding wrote:
> > On Tue, Sep 23, 2014 at 02:31:35PM +0300, Tomi Valkeinen wrote:
> >> On 23/09/14 12:39, Thierry Reding wrote:
> >>> My point is that if you use plain phandles you usually have the
> >>> meta-data already. Referring to the above example, bridge0 knows that it
> >>> should look for a bridge with phandle &bridge1, whereas bridge1 knows
> >>> that the device it is connected to is a panel.
> >> 
> >> The bridge should not care what kind of device is there on the other
> >> end. The bridge just has an output, going to another video component.
> > 
> > You'll need to know at some point that one of the devices in a panel,
> > otherwise you can't treat it like a panel.
> 
> The bridge doesn't need to treat it like a panel. Someone else might,
> though. But the panel driver knows it is a panel, and can thus register
> needed services, or mark itself as a panel.
> 
> >>>> Well, I can't say about this particular bridge, but afaik you can
> >>>> connect a parallel RGB signal to multiple panels just like that,
> >>>> without any muxing.
> >>> 
> >>> Right, but in that case you're not reconfiguring the signal in any way
> >>> for each of the panels. You send one single signal to all of them. For
> >> 
> >> Yes, that's one use case, cloning. But I was not talking about that.
> >> 
> >>> all intents and purposes there is only one panel. Well, I guess you
> >>> could have separate backlights for the panels. In that case though it
> >>> seems better to represent it at least as a virtual mux or bridge, or
> >>> perhaps a "mux panel".
> >> 
> >> I was talking about the case where you have two totally different
> >> devices, let's say panels, connected to the same output. One could take
> >> a 16-bit parallel RGB signal, the other 24-bit. Only one of them can  be
> >> enabled at a time (from HW perspective both can be enabled at the same
> >> time, but then the other one shows garbage).
> > 
> > So we're essentially back to a mux, albeit maybe a virtual one.
> 
> Yes. Are you suggesting to model virtual hardware in .dts? I got the
> impression that you wanted to model only the real hardware in .dts =).
> 
> But seriously speaking, I was thinking about this. I'd really like to
> have a generic video-mux node, that would still somehow allow us to have
> device specific configurations for the video sources and sinks (which
> the endpoints provide us), without endpoints.
> 
> The reason endpoints don't feel right in this case is that it makes
> sense that the mux has a single input and two outputs, but with
> endpoints we need two endpoints from the bridge (which is still ok), but
> we also need two endpoitns in the mux's input side, which doesn't feel
> right.
> 
> I came up with the following. It's quite ugly, though. I hope someone
> has ideas how it could be done in a neater way:
> 
> bridge1234 {
>   bridge1234-cfg1: config1 {
>   high-voltage;
>   };
> 
>   bridge1234-cfg2: config2 {
>   low-voltage;
>   };
> 
>   output = <&mux>;
> };
> 
> mux: video-gpio-mux {
>   gpio = <123>;
> 
>   outputs = <&panel1 &panel2>;
>   input-configs = <&bridge1234-cfg1 &bridge1234-cfg2>;
> };
> 
> panel1: panel-foo {
> 
> };
> 
> panel2: panel-foo {
> 
> };
> 
> So the bridge node has configuration sets. These might be compared to
> pinmux nodes. And the mux has a list of input-configs. When panel1 is to
> be enabled, "bridge1234-cfg1" config becomes active, and the bridge is
> given this configuration.
> 
> I have to say the endpoint system feels cleaner than the above, but
> perhaps it's possible to improve the method above somehow.

Isn't it possible for the bridge to compute its configuration at runtime by 
querying properties of the downstream video entities ? That would solve the 
problem neatly.

-- 
Regards,

Laurent Pinchart

--
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Laurent Pinchart]

Hi Thierry,

On Tuesday 23 September 2014 16:49:38 Thierry Reding wrote:
> On Tue, Sep 23, 2014 at 02:52:24PM +0300, Laurent Pinchart wrote:
> > On Tuesday 23 September 2014 13:47:40 Andrzej Hajda wrote:
> >> On 09/23/2014 01:23 PM, Laurent Pinchart wrote:
> [...]
> 
> >>> This becomes an issue even on Linux when considering video-related
> >>> devices that can be part of either a capture pipeline or a display
> >>> pipeline. If the link always goes in the data flow direction, then it
> >>> will be easy to locate the downstream device (bridge or panel) from
> >>> the display controller driver, but it would be much more difficult to
> >>> locate the same device from a camera driver as all of a sudden the
> >>> device would become an upstream device.
> >> 
> >> Why?
> >> 
> >> If you have graph:
> >> sensor --> camera
> >> 
> >> Then camera register itself in some framework as a destination device
> >> and sensor looks in this framework for the device identified by remote
> >> endpoint. Then sensor tells camera it is connected to it and voila.
> > 
> > Except that both kernelspace and userspace deal with cameras the other way
> > around, the master device is the camera receiver, not the camera sensor.
> > DRM is architected the same way, with the component that performs DMA
> > operations being the master device.
> 
> I don't see what's wrong with having the camera reference the sensor by
> phandle instead. That's much more natural in my opinion.

The problem, as explained by Tomi in a more recent e-mail (let's thus discuss 
the issue there) is that making the phandles pointing outwards from the CPU 
point of view stops working when the same chip or IP core can be used in both 
a camera and a display pipeline (and we have real use cases for that), or when 
the CPU isn't involved at all in the pipeline.

-- 
Regards,

Laurent Pinchart

--
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Laurent Pinchart]

of
> > supplementing missing information that can't be probed if hardware is
> > too stupid. I guess that's one of the primary reasons for structuring it
> > the way we do, from the CPU point of view, because it allows the CPU to
> > probe via the device tree.
> > 
> > Probing is always done downstream, so you'd start by looking at some
> > type of bus interface and query it for what devices are present on the
> > bus. Take for example PCI: the CPU only needs to know how to access the
> > host bridge and will then probe devices behind each of the ports on that
> > bridge. Some of those devices will be bridges, too, so it will continue
> > to probe down the hierarchy.
> > 
> > Without DT you don't have a means to know that there was a panel before
> > you've actually gone and probed your whole hierarchy and found a GPU
> > with some sort of output that a panel can be connected to. I think it
> > makes a lot of sense to describe things in the same way in DT.
> 
> Maybe I don't quite follow, but it sounds to be you are mixing control
> and data. For control, all you say is true. The CPU probes the devices
> on control busses, either with the aid of HW or the aid of DT, going
> downstream.
> 
> But the data paths are a different matter. The CPU/SoC may not even be
> involved in the whole data path. You could have a sensor on the board
> directly connected to a panel. Both are controlled by the CPU, but the
> data path goes from the sensor to the panel (or vice versa). There's no
> way the data paths can be "CPU centric" in that case.
> 
> Also, a difference with the data paths compared to control paths is that
> they are not strictly needed for operation. An encoder can generate an
> output without enabling its input (test pattern or maybe blank screen,
> or maybe a screen with company logo). Or an encoder with two inputs
> might only get the second input when the user requests a very high res
> mode. So it is possible that the data paths are lazily initialized.
> 
> You do know that there is a panel right after the device is probed
> according to its control bus. It doesn't mean that the data paths are
> there yet. In some cases the user space needs to reconfigure the data
> paths before a panel has an input and can be used to show an image from
> the SoC's display subsystem.
> 
> The point here being that the data path bindings don't really relate to
> the probing part. You can probe no matter which way the data path
> bindings go, and no matter if there actually exists (yet) a probed
> device on the other end of a data path phandle.
> 
> While I think having video data connections in DT either way, downstream
> or upstream, would work, it has felt most natural for me to have the
> phandles from video sinks to video sources.
> 
> The reason for that is that I think the video sink has to be in control
> of its source. It's the sink that tells the source to start or stop or
> reconfigure. So I have had need to get the video source from a video
> sink, but I have never had the need to get the video sinks from video
> sources.

We could decide to model all data connections are phandles that go in the data 
flow direction (source to sink), opposite to the data flow direction (sink to 
source), or in both directions. The problem with the sink to source direction 
is that it raises the complexity of implementations for display drivers, as 
the master driver that will bind all the components together will have a hard 
time locating the components in DT if all the components point towards it. 
Modeling the connections in the source to sink direction only would create the 
exact same problem for video capture (camera) devices. That's why I believe 
that bidirectional connections would be a better choice.

-- 
Regards,

Laurent Pinchart

--
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Laurent Pinchart]

On Tuesday 23 September 2014 13:47:40 Andrzej Hajda wrote:
> On 09/23/2014 01:23 PM, Laurent Pinchart wrote:
> > On Tuesday 23 September 2014 13:18:30 Andrzej Hajda wrote:
> >> On 09/23/2014 01:10 PM, Laurent Pinchart wrote:
> >>> On Tuesday 23 September 2014 12:02:45 Andrzej Hajda wrote:
> >>>> On 09/23/2014 11:30 AM, Tomi Valkeinen wrote:
> >>>>> On 23/09/14 09:21, Thierry Reding wrote:
> >>>>>>> Well, I can write almost any kind of bindings, and then evidently my
> >>>>>>> device would work. For me, on my board.
> >>>>>> 
> >>>>>> Well, that's the whole problem with DT. For many devices we only have
> >>>>>> a single setup to test against. And even when we have several they
> >>>>>> often are derived from each other. But the alternative would be to
> >>>>>> defer (possibly indefinitely) merging support for a device until a
> >>>>>> second, wildly different setup shows up. That's completely
> >>>>>> unreasonable and we need to start somewhere.
> >>>>> 
> >>>>> Yes, but in this case we know of existing boards that have complex
> >>>>> setups. It's not theoretical.
> >>>>> 
> >>>>> I'm not saying we should stop everything until we have a 100% solution
> >>>>> for the rare complex cases. But we should keep them in mind and, when
> >>>>> possible, solve problems in a way that will work for the complex cases
> >>>>> also.
> >>>>> 
> >>>>>>> I guess non-video devices haven't had need for those. I have had
> >>>>>>> lots of boards with video setup that cannot be represented with
> >>>>>>> simple phandles. I'm not sure if I have just been unlucky or what,
> >>>>>>> but my understand is that other people have encountered such boards
> >>>>>>> also. Usually the problems encountered there have been circumvented
> >>>>>>> with some hacky video driver for that specific board, or maybe a
> >>>>>>> static configuration handled by the boot loader.
> >>>>>> 
> >>>>>> I have yet to encounter such a setup. Can you point me at a DTS for
> >>>>>> one such setup? I do remember a couple of hypothetical cases being
> >>>>>> discussed at one time or another, but I haven't seen any actual DTS
> >>>>>> content where this was needed.
> >>>>> 
> >>>>> No, I can't point to them as they are not in the mainline (at least
> >>>>> the ones I've been working on), for obvious reasons.
> >>>>> 
> >>>>> With a quick glance, I have the following devices in my cabinet that
> >>>>> have more complex setups: OMAP 4430 SDP, BeagleBoneBlack + LCD, AM43xx
> >>>>> EVM. Many Nokia devices used to have such setups, usually so that the
> >>>>> LCD and tv-out were connected to the same video source.
> >>>>> 
> >>>>>>> Do we have a standard way of representing the video pipeline with
> >>>>>>> simple phandles? Or does everyone just do their own version? If
> >>>>>>> there's no standard way, it sounds it'll be a mess to support in the
> >>>>>>> future.
> >>>>>> 
> >>>>>> It doesn't matter all that much whether the representation is
> >>>>>> standard.
> >>>>> 
> >>>>> Again, I disagree.
> >>>>> 
> >>>>>> phandles should simply point to the next element in the pipeline and
> >>>>>> the OS abstractions should be good enough to handle the details about
> >>>>>> how to chain the elements.
> >>>>> 
> >>>>> I, on the other hand, would rather see the links the other way around.
> >>>>> Panel having a link to the video source, etc.
> >>>>> 
> >>>>> The video graphs have two-way links, which of course is the safest
> >>>>> options, but also more verbose and redundant.
> >>>>> 
> >>>>> When this was discussed earlier, it was unclear which way the links
> >>>>> should be. It's true that only links to one direction are strictly
>

DT property to selectively disable device features (was [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties)

[Laurent Pinchart]

Hi Thierry,

On Tuesday 23 September 2014 07:55:34 Thierry Reding wrote:
> On Tue, Sep 23, 2014 at 03:00:37AM +0300, Laurent Pinchart wrote:
> > On Monday 22 September 2014 13:35:15 Thierry Reding wrote:
> >> On Mon, Sep 22, 2014 at 04:53:22PM +0530, Ajay kumar wrote:
> >>> On Mon, Sep 22, 2014 at 4:11 PM, Thierry Reding wrote:
> >>>> On Mon, Sep 22, 2014 at 02:01:38PM +0530, Ajay kumar wrote:

[snip]

> >>>> I think you misunderstood what I said, or maybe I didn't explain
> >>>> clearly what I meant. If the PS8622 provides a backlight there's
> >>>> nothing wrong with always exposing it. The bridge itself isn't going
> >>>> to be using the backlight anyway. Rather the panel itself should be
> >>>> using the backlight device exposed by PS8622 or some separate
> >>>> backlight device.
> >>>> 
> >>>> To illustrate by an example:
> >>>> ps8622: ... {
> >>>> compatible = "parade,ps8622";
> >>>> ...
> >>>> };
> >>>> 
> >>>> panel {
> >>>> ...
> >>>> backlight = <&ps8622>;
> >>>> ...
> >>>> };
> >>> 
> >>> No, if ps8622 backlight control is used, we need not specify the
> >>> backlight phandle for the panel driver. Somehow, ps8622 internal
> >>> circuitry keeps the bootup glitch free :)
> >>> Backlight control and panel controls can be separate then.
> >> 
> >> But they shouldn't. Your panel driver should always be the one to
> >> control backlight. How else is the bridge supposed to know when to turn
> >> backlight on or off?
> >> 
> >>>> What you did in v6 of this series was look up a backlight device and
> >>>> then not use it. That seemed unnecessary. Looking at v6 again the
> >>>> reason for getting a phandle to the backlight was so that the device
> >>>> itself did not expose its own backlight controlling circuitry if an
> >>>> external one was being used. But since the bridge has no business
> >>>> controlling the backlight, having the backlight phandle in the
> >>>> bridge is not correct.
> >>>> 
> >>>> So I think what you could do in the driver instead is always expose
> >>>> the backlight device. If the panel used a different backlight, the
> >>>> PS8622's internal on simply wouldn't be accessed. It would still be
> >>>> possible to control the backlight in sysfs, but that shouldn't be a
> >>>> problem (only root can access it)
> >>> 
> >>> That would be like simple exposing a feature which cannot be used
> >>> by the user, ideally which "should not be" used by the user.
> >> 
> >> And it won't be used unless they access the sysfs files directly. There
> >> are a lot of cases where we expose functionality that cannot be
> >> meaningfully used by the user. For example, a GPIO may not be routed to
> >> anything on a board, yet we don't explicitly hide any specific GPIOs
> >> from users.
> >> 
> >>>> That said, I have no strong objections to the boolean property if
> >>>> you feel like it's really necessary.
> >>> 
> >>> Won't you think having a boolean property for an optional
> >>> feature of the device, is better than all these?
> >> 
> >> Like I said, I'm indifferent on the matter. I don't think it's necessary
> >> to hide the backlight device, but if you want to, please feel free to do
> >> so.
> > 
> > DT typically use
> > 
> > status = "disabled"
> > 
> > to disable devices. In this case we don't want to disable the ps8622
> > completely, but just one of its functions. Maybe a "backlight-status"
> > property could be used for that ? If that's considered too verbose, I
> > would be fine with a "disable-" boolean property too.
> 
> Another alternative would be to make the backlight a subnode:
> 
>   ps8622: bridge@... {
>   compatible = "parade,ps8622";
>   ...
> 
>   backlight {
>   ...
>   status = "disabled";
>   ...
>   };
>   };

I've thought about that as well. I feel it's getting a bit complex for little 
added benefit, but I don't have a very strong opinion.

Devices that expose several functions are not the odd case, and the need to 
selectively mark some of them as disabled in DT seems pretty common to me. I 
wonder if we should try to decide on standard bindings for that. To recap the 
proposals, we could have

- a boolean "disable-" property
- a text "-status" property
- a "" subnode with a "status" text property

Anything else ?

-- 
Regards,

Laurent Pinchart

--
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Laurent Pinchart]

Hi Thierry,

On Tuesday 23 September 2014 12:10:33 Thierry Reding wrote:
> On Tue, Sep 23, 2014 at 11:43:47AM +0200, Andrzej Hajda wrote:
> > On 09/23/2014 10:35 AM, Thierry Reding wrote:
> [...]
> 
> > > But I agree that it would be nice to unify bridges and encoders more. It
> > > should be possible to make encoder always a bridge (or perhaps even
> > > replace encoders with bridges altogether). Then once you're out of the
> > > DRM device everything would be a bridge until you get to a panel.
> > 
> > I agree that some sort of unification of bridges, (slave) encoders is a
> > good thing, this way we stay only with bridges and panels as receivers.> 
> > But we will still have to deal with the code like:
> >
> > if (on the other end of the link is panel)
> > do panel framework specific things
> > else
> > do bridge framework specific things
> > 
> > The code in both branches usually does similar things but due to framework
> > differences it is difficult to merge.
> 
> That's because they are inherently different entities. You can perform
> operations on a panel that don't make sense for a bridge and vice-versa.

But a subset of the operations are common, so it's annoying to have to 
explicitly deal with both objects in code that only cares about the common 
subset of operations.

> > Ideally it would be best to get rid of such constructs. For example by
> > trying to make frameworks per interface type exposed by device (eg.
> > video_sink) and not by device type (drm_bridge, drm_panel).
> 
> But then you loose all information about the real type of device. Or you
> have to create a common base class. And then you're still back to dealing
> with the two specific cases in many places, so the gain seems rather
> minimal.

We would need to experiment with the concept, but a single abstract class 
works surprisingly well in V4L. Devices as diverse as camera sensors, HDMI 
receivers or video scalers expose a single API, and drivers for the logical 
capture devices (roughly equivalent to the DRM display controller drivers) 
turned out not to need much knowledge about what the connected devices really 
are in order to use them. This was implemented with a superset of operations, 
with many of them being optional to implement for component drivers. Of course 
knowing the exact type of a component can still be sometimes useful, but that 
would be pretty easy to implement through a query operation exposed by the 
components.

We're digressing here, but my point is that the encoder/bridge merge that we 
seem to agree about should, in my opinion, be followed by a merge with panels. 
I am, however, more interested at this point by the encoder/bridge merge, as 
having two separate frameworks there is the biggest pain point for my use 
cases.

-- 
Regards,

Laurent Pinchart

--
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Laurent Pinchart]

On Tuesday 23 September 2014 13:18:30 Andrzej Hajda wrote:
> On 09/23/2014 01:10 PM, Laurent Pinchart wrote:
> > On Tuesday 23 September 2014 12:02:45 Andrzej Hajda wrote:
> >> On 09/23/2014 11:30 AM, Tomi Valkeinen wrote:
> >>> On 23/09/14 09:21, Thierry Reding wrote:
> >>>>> Well, I can write almost any kind of bindings, and then evidently my
> >>>>> device would work. For me, on my board.
> >>>> 
> >>>> Well, that's the whole problem with DT. For many devices we only have a
> >>>> single setup to test against. And even when we have several they often
> >>>> are derived from each other. But the alternative would be to defer
> >>>> (possibly indefinitely) merging support for a device until a second,
> >>>> wildly different setup shows up. That's completely unreasonable and we
> >>>> need to start somewhere.
> >>> 
> >>> Yes, but in this case we know of existing boards that have complex
> >>> setups. It's not theoretical.
> >>> 
> >>> I'm not saying we should stop everything until we have a 100% solution
> >>> for the rare complex cases. But we should keep them in mind and, when
> >>> possible, solve problems in a way that will work for the complex cases
> >>> also.
> >>> 
> >>>>> I guess non-video devices haven't had need for those. I have had lots
> >>>>> of boards with video setup that cannot be represented with simple
> >>>>> phandles. I'm not sure if I have just been unlucky or what, but my
> >>>>> understand is that other people have encountered such boards also.
> >>>>> Usually the problems encountered there have been circumvented with
> >>>>> some hacky video driver for that specific board, or maybe a static
> >>>>> configuration handled by the boot loader.
> >>>> 
> >>>> I have yet to encounter such a setup. Can you point me at a DTS for one
> >>>> such setup? I do remember a couple of hypothetical cases being
> >>>> discussed at one time or another, but I haven't seen any actual DTS
> >>>> content where this was needed.
> >>> 
> >>> No, I can't point to them as they are not in the mainline (at least the
> >>> ones I've been working on), for obvious reasons.
> >>> 
> >>> With a quick glance, I have the following devices in my cabinet that
> >>> have more complex setups: OMAP 4430 SDP, BeagleBoneBlack + LCD, AM43xx
> >>> EVM. Many Nokia devices used to have such setups, usually so that the
> >>> LCD and tv-out were connected to the same video source.
> >>> 
> >>>>> Do we have a standard way of representing the video pipeline with
> >>>>> simple phandles? Or does everyone just do their own version? If
> >>>>> there's no standard way, it sounds it'll be a mess to support in the
> >>>>> future.
> >>>> 
> >>>> It doesn't matter all that much whether the representation is standard.
> >>> 
> >>> Again, I disagree.
> >>> 
> >>>> phandles should simply point to the next element in the pipeline and
> >>>> the OS abstractions should be good enough to handle the details about
> >>>> how to chain the elements.
> >>> 
> >>> I, on the other hand, would rather see the links the other way around.
> >>> Panel having a link to the video source, etc.
> >>> 
> >>> The video graphs have two-way links, which of course is the safest
> >>> options, but also more verbose and redundant.
> >>> 
> >>> When this was discussed earlier, it was unclear which way the links
> >>> should be. It's true that only links to one direction are strictly
> >>> needed, but the question raised was that if in the drivers we end up
> >>> always going the links the other way, the performance penalty may be
> >>> somewhat big. (If I recall right).
> >> 
> >> I do not see why performance may drop significantly?
> >> If the link is one-way it should probably work as below:
> >> - the destination registers itself in some framework,
> >> - the source looks for the destination in this framework using phandle,
> >> - the source starts to communicate with the destination - since now full
> >> two way link can be established dyn

Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Laurent Pinchart]

On Tuesday 23 September 2014 11:53:15 Thierry Reding wrote:
> On Tue, Sep 23, 2014 at 12:30:20PM +0300, Tomi Valkeinen wrote:
> > On 23/09/14 09:21, Thierry Reding wrote:
> > >> Well, I can write almost any kind of bindings, and then evidently my
> > >> device would work. For me, on my board.
> > > 
> > > Well, that's the whole problem with DT. For many devices we only have a
> > > single setup to test against. And even when we have several they often
> > > are derived from each other. But the alternative would be to defer
> > > (possibly indefinitely) merging support for a device until a second,
> > > wildly different setup shows up. That's completely unreasonable and we
> > > need to start somewhere.
> > 
> > Yes, but in this case we know of existing boards that have complex
> > setups. It's not theoretical.
> 
> Complex setups involving /this particular/ bridge and binding are
> theoretical at this point, however.
> 
> > > phandles should simply point to the next element in the pipeline and the
> > > OS abstractions should be good enough to handle the details about how to
> > > chain the elements.
> > 
> > I, on the other hand, would rather see the links the other way around.
> > Panel having a link to the video source, etc.
> 
> Why? It seems much more natural to describe this using the natural flow
> of data. The device furthest away from the CPU should be the target of
> the phandle. That way the DT can be used to trace the flow of data down
> the pipeline.
> 
> > The video graphs have two-way links, which of course is the safest
> > options, but also more verbose and redundant.
> 
> Right. If we take that line of thinking to the extreme we end up listing
> individual registers in DT so that we can safely assume that we can
> control all possible aspects of the device.

And the other extreme would be to have a single DT node for the logical video 
device with all information pertaining to it stored in C code. Extremes are 
never good, we need to find a reasonable middle-ground here. I believe OF 
graph fulfills that requirement, it might be slightly more verbose than a 
single phandle, but it's also much more versatile. 

> Like I said, this seems to be the latest response to DT ABI stability
> requirement. Add as much data to a DT node as possible so that it has
> higher chances of being complete. The result is often overly complex DT
> content that doesn't add any real value.
> 
> > When this was discussed earlier, it was unclear which way the links
> > should be. It's true that only links to one direction are strictly
> > needed, but the question raised was that if in the drivers we end up
> > always going the links the other way, the performance penalty may be
> > somewhat big. (If I recall right).
> 
> I doubt that graphs will become so complex that walking it would become
> a performance bottleneck. In fact if we're constantly walking the graph
> we're already doing something wrong. It should only be necessary when
> the pipeline configuration changes, which should hopefully not be very
> often (i.e. not several times per second).

-- 
Regards,

Laurent Pinchart

--
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 V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Laurent Pinchart]

On Tuesday 23 September 2014 12:02:45 Andrzej Hajda wrote:
> On 09/23/2014 11:30 AM, Tomi Valkeinen wrote:
> > On 23/09/14 09:21, Thierry Reding wrote:
> >>> Well, I can write almost any kind of bindings, and then evidently my
> >>> device would work. For me, on my board.
> >> 
> >> Well, that's the whole problem with DT. For many devices we only have a
> >> single setup to test against. And even when we have several they often
> >> are derived from each other. But the alternative would be to defer
> >> (possibly indefinitely) merging support for a device until a second,
> >> wildly different setup shows up. That's completely unreasonable and we
> >> need to start somewhere.
> > 
> > Yes, but in this case we know of existing boards that have complex
> > setups. It's not theoretical.
> > 
> > I'm not saying we should stop everything until we have a 100% solution
> > for the rare complex cases. But we should keep them in mind and, when
> > possible, solve problems in a way that will work for the complex cases
> > also.> 
> >>> I guess non-video devices haven't had need for those. I have had lots of
> >>> boards with video setup that cannot be represented with simple phandles.
> >>> I'm not sure if I have just been unlucky or what, but my understand is
> >>> that other people have encountered such boards also. Usually the
> >>> problems encountered there have been circumvented with some hacky video
> >>> driver for that specific board, or maybe a static configuration handled
> >>> by the boot loader.
> >> 
> >> I have yet to encounter such a setup. Can you point me at a DTS for one
> >> such setup? I do remember a couple of hypothetical cases being discussed
> >> at one time or another, but I haven't seen any actual DTS content where
> >> this was needed.
> > 
> > No, I can't point to them as they are not in the mainline (at least the
> > ones I've been working on), for obvious reasons.
> > 
> > With a quick glance, I have the following devices in my cabinet that
> > have more complex setups: OMAP 4430 SDP, BeagleBoneBlack + LCD, AM43xx
> > EVM. Many Nokia devices used to have such setups, usually so that the
> > LCD and tv-out were connected to the same video source.
> > 
> >>> Do we have a standard way of representing the video pipeline with simple
> >>> phandles? Or does everyone just do their own version? If there's no
> >>> standard way, it sounds it'll be a mess to support in the future.
> >> 
> >> It doesn't matter all that much whether the representation is standard.
> > 
> > Again, I disagree.
> > 
> >> phandles should simply point to the next element in the pipeline and the
> >> OS abstractions should be good enough to handle the details about how to
> >> chain the elements.
> > 
> > I, on the other hand, would rather see the links the other way around.
> > Panel having a link to the video source, etc.
> > 
> > The video graphs have two-way links, which of course is the safest
> > options, but also more verbose and redundant.
> > 
> > When this was discussed earlier, it was unclear which way the links
> > should be. It's true that only links to one direction are strictly
> > needed, but the question raised was that if in the drivers we end up
> > always going the links the other way, the performance penalty may be
> > somewhat big. (If I recall right).
> 
> I do not see why performance may drop significantly?
> If the link is one-way it should probably work as below:
> - the destination registers itself in some framework,
> - the source looks for the destination in this framework using phandle,
> - the source starts to communicate with the destination - since now full
> two way link can be established dynamically.
> 
> Where do you see here big performance penalty?

The performance-related problems arise when you need to locate the remote 
device in the direction opposite to the phandle link direction. Traversing a 
link forward just involves a phandle lookup, but traversing it backwards isn't 
possible the same way.

-- 
Regards,

Laurent Pinchart

--
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 V6 6/8] drm/bridge: Modify drm_bridge core to support driver model

[Laurent Pinchart]

Hi Thierry,

On Monday 22 September 2014 09:40:38 Thierry Reding wrote:
> On Wed, Sep 17, 2014 at 12:27:13PM +0300, Laurent Pinchart wrote:
> > On Wednesday 17 September 2014 14:37:30 Ajay kumar wrote:
> > > On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart wrote:
> > > > Hi Ajay,
> > > > 
> > > > Thank you for the patch.
> > > > 
> > > > I think we're moving in the right direction, but we're not there yet.
> > > > 
> > > > On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
> > > >> This patch tries to seperate drm_bridge implementation
> > > >> into 2 parts, a drm part and a non_drm part.
> > > >> 
> > > >> A set of helper functions are defined in this patch to make
> > > >> bridge driver probe independent of the drm flow.
> > > >> 
> > > >> The bridge devices register themselves on a lookup table
> > > >> when they get probed by calling "drm_bridge_add_for_lookup".
> > > >> 
> > > >> The parent encoder driver waits till the bridge is available in the
> > > >> lookup table(by calling "of_drm_find_bridge") and then continues with
> > > >> its initialization.
> > > > 
> > > > Before the introduction of the component framework I would have said
> > > > this is the way to go. Now, I think bridges should register themselves
> > > > as components, and the DRM master driver should use the component
> > > > framework to get a reference to the bridges it needs.
> > > 
> > > Well, I have modified the bridge framework exactly the way Thierry
> > > wanted it to be, I mean the same way the current panel framework is.
> > > And, I don't think there is a problem with that.
> > > What problem are you facing with current bridge implementation?
> > > What is the advantage of using the component framework to register
> > > bridges?
> > 
> > There are several advantages.
> > 
> > - The component framework has been designed with this exact problem in
> > mind, piecing multiple components into a display device.
> 
> No. Component framework was designed with multi-device drivers in mind.
> That is, drivers that need to combine two or more platform devices into
> a single logical device. Typically that includes display controllers and
> encoders (in various looks) for DRM.

I disagree. AFAIK the component framework was designed to easily combine 
multiple devices into a single logical device, regardless of which bus each 
device is connected to. That's what makes the component framework useful : it 
allows master drivers to build logical devices from heterogeneous components 
without having to use one API per bus and/or component type. If the only goal 
had been to combine platform devices on an SoC, simpler device-specific 
solutions would likely have been used instead.

> Panels and bridges are in my opinion different because they are outside
> of the DRM driver. They aren't part of the device complex that an SoC
> provides. They represent hardware that is external to the SoC and the
> DRM driver and can be shared across SoCs.

They represent hardware external to the SoC, but internal to the logical DRM 
device.

> Forcing panels and bridges to register as components will require all
> drivers to implement master/component support solely for accessing this
> external hardware.
> 
> What you're suggesting is like saying that clocks or regulators should
> register as components so that their users can get them that way. In
> fact by that argument everything that's referenced by phandle would need
> to register as component (PHYs, LEDs, GPIOs, I2C controllers, ...).

No, that's very different. The device you list are clearly external resources, 
while the bridges and panels are components part of a logical display device.

> > This patch set introduces yet another framework, without any compelling
> > reason as far as I can see. Today DRM drivers already need to use three
> > different frameworks (component, I2C slave encoder and panel), and we're
> > adding a fourth oneto make the mess even messier.
> 
> Panel and bridge aren't really frameworks. Rather they are a simple
> registry to allow drivers to register panels and bridges and display
> drivers to look them up.

Regardless of how you call them, we have three interfaces.

> > This is really a headlong rush, we need to stop and fix the  design
> > mistakes.
>
> Can you point out specific design mistakes? I don't see any, but I'm
> obviously biased.

The slave e

Re: [PATCH V7 11/12] Documentation: bridge: Add documentation for ps8622 DT properties

[Laurent Pinchart]

gt; > >> This was discussed before, and you suggested to use the boolean
> > >> property, refer to this link:
> > >> http://lists.freedesktop.org/archives/dri-devel/2014-July/065048.html
> > > 
> > > I think you misunderstood what I said, or maybe I didn't explain clearly
> > > what I meant. If the PS8622 provides a backlight there's nothing wrong
> > > with always exposing it. The bridge itself isn't going to be using the
> > > backlight anyway. Rather the panel itself should be using the backlight
> > > device exposed by PS8622 or some separate backlight device.
> > > 
> > > To illustrate by an example:
> > > ps8622: ... {
> > > 
> > > compatible = "parade,ps8622";
> > > ...
> > > 
> > > };
> > > 
> > > panel {
> > > 
> > > ...
> > > backlight = <&ps8622>;
> > > ...
> > > 
> > > };
> > 
> > No, if ps8622 backlight control is used, we need not specify the backlight
> > phandle for the panel driver. Somehow, ps8622 internal circuitry keeps
> > the bootup glitch free :)
> > Backlight control and panel controls can be separate then.
> 
> But they shouldn't. Your panel driver should always be the one to
> control backlight. How else is the bridge supposed to know when to turn
> backlight on or off?
> 
> > > What you did in v6 of this series was look up a backlight device and
> > > then not use it. That seemed unnecessary. Looking at v6 again the reason
> > > for getting a phandle to the backlight was so that the device itself did
> > > not expose its own backlight controlling circuitry if an external one
> > > was being used. But since the bridge has no business controlling the
> > > backlight, having the backlight phandle in the bridge is not correct.
> > > 
> > > So I think what you could do in the driver instead is always expose the
> > > backlight device. If the panel used a different backlight, the PS8622's
> > > internal on simply wouldn't be accessed. It would still be possible to
> > > control the backlight in sysfs, but that shouldn't be a problem (only
> > > root can access it)
> > 
> > That would be like simple exposing a feature which cannot be used
> > by the user, ideally which "should not be" used by the user.
> 
> And it won't be used unless they access the sysfs files directly. There
> are a lot of cases where we expose functionality that cannot be
> meaningfully used by the user. For example, a GPIO may not be routed to
> anything on a board, yet we don't explicitly hide any specific GPIOs
> from users.
> 
> > > That said, I have no strong objections to the boolean property if you
> > > feel like it's really necessary.
> > 
> > Won't you think having a boolean property for an optional
> > feature of the device, is better than all these?
> 
> Like I said, I'm indifferent on the matter. I don't think it's necessary
> to hide the backlight device, but if you want to, please feel free to do
> so.

DT typically use

status = "disabled"

to disable devices. In this case we don't want to disable the ps8622 
completely, but just one of its functions. Maybe a "backlight-status" property 
could be used for that ? If that's considered too verbose, I would be fine 
with a "disable-" boolean property too.

> Another alternative would be not to expose it at all and not have the
> boolean property since you don't seem to have a way to test it in the
> first place (or at least there's no device support upstream where it's
> needed).

-- 
Regards,

Laurent Pinchart


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Laurent Pinchart]

Hi Ajay,

On Wednesday 17 September 2014 15:43:04 Ajay kumar wrote:
> Hi Laurent,
> 
> Please find the latest series here:
> http://www.spinics.net/lists/dri-devel/msg66740.html

Thank you. My comment was meant to be general though, not just for your patch 
series.

> On Wed, Sep 17, 2014 at 3:23 PM, Laurent Pinchart wrote:
> > On Wednesday 30 July 2014 11:40:54 Thierry Reding wrote:

[snip]

> >> One other thing: how does the bridge know which mode to drive? I suspect
> >> that it can drive more than one mode? Can it freely be configured or
> >> does it have a predefined set of modes? If the latter, then according to
> >> what you said above there needs to be a way to configure the bridge (via
> >> DT?) so that it reports the mode matching the panel. I wonder if that
> >> should be handled completely in code, so that for example a bridge has a
> >> panel attached it can use the panel's .get_modes() and select a matching
> >> mode among the set that it supports.
> > 
> > Yes, pretty please :-) I don't think it would be a good idea to duplicate
> > mode information in the bridge DT node, as that's not a property of the
> > bridge. Querying the mode at runtime is in my opinion a much better
> > option, and would also allow switching between different modes at runtime
> > when that makes sense.
> > 
> > Now, I'm not sure whether it should be the bridge driver querying the
> > panel driver directly, or the display controller driver doing it and then
> > configuring the bridge accordingly. The latter seems more generic to me
> > and doesn't rely on the assumption that the bridge output will always be
> > directly connected to a panel.

-- 
Regards,

Laurent Pinchart

--
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 V6 0/8] drm/exynos: few patches to enhance bridge chip support

[Laurent Pinchart]

Hi Thierry,

On Wednesday 30 July 2014 11:40:54 Thierry Reding wrote:
> On Wed, Jul 30, 2014 at 11:54:00AM +0530, Ajay kumar wrote:
> > On Tue, Jul 29, 2014 at 5:17 PM, Thierry Reding wrote:
> > > On Tue, Jul 29, 2014 at 01:42:09PM +0200, Andreas Färber wrote:
> > >> Am 29.07.2014 13:36, schrieb Thierry Reding:
> > >> > On Tue, Jul 29, 2014 at 01:21:48PM +0200, Andreas Färber wrote:
> > >> >> Am 28.07.2014 08:13, schrieb Ajay kumar:
> > >> >>> On 7/27/14, Andreas Färber  wrote:
> > >> >>>> Am 25.07.2014 21:22, schrieb Ajay Kumar:
> > >> >>>>> This series is based on exynos-drm-next branch of Inki Dae's tree
> > >> >>>>> at:
> > >> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.
> > >> >>>>> git
> > >> >>>>> 
> > >> >>>>> I have tested this after adding few DT changes for
> > >> >>>>> exynos5250-snow,
> > >> >>>>> exynos5420-peach-pit and exynos5800-peach-pi boards.
> > >> >>>> 
> > >> >>>> I'm trying to test this with a modified exynos5250-spring DT
> > >> 
> > >> [...]
> > >> 
> > >> >> Unfortunately the most I got on Spring with attached DT was a blank
> > >> >> screen with a white horizontal line in the middle.
> > >> >> 
> > >> >> Do I need to specify a specific panel model for Spring?
> > >> 
> > >> [...]
> > >> 
> > >> >> From 9172a26a8f0d0f0d170bd27e1c150ad204d8086a Mon Sep 17 00:00:00
> > >> >> 2001
> > >> >> From: =?UTF-8?q?Andreas=20F=C3=A4rber?= 
> > >> >> Date: Sun, 27 Jul 2014 21:58:06 +0200
> > >> >> Subject: [PATCH] ARM: dts: exynos5250: Add eDP/LVDS bridge to Spring
> > >> >> MIME-Version: 1.0
> > >> >> Content-Type: text/plain; charset=UTF-8
> > >> >> Content-Transfer-Encoding: 8bit
> > >> >> 
> > >> >> Signed-off-by: Ajay Kumar 
> > >> >> [AF: Redone for v6]
> > >> >> Signed-off-by: Andreas F??rber 
> > >> >> ---
> > >> >> 
> > >> >>  arch/arm/boot/dts/exynos5250-spring.dts | 32 +-
> > >> >>  1 file changed, 31 insertions(+), 1 deletion(-)
> > >> >> 
> > >> >> diff --git a/arch/arm/boot/dts/exynos5250-spring.dts
> > >> >> b/arch/arm/boot/dts/exynos5250-spring.dts index
> > >> >> 687dfab86bc8..517b1ff2bfdf 100644
> > >> >> --- a/arch/arm/boot/dts/exynos5250-spring.dts
> > >> >> +++ b/arch/arm/boot/dts/exynos5250-spring.dts
> > >> >> @@ -64,10 +64,14 @@
> > >> >>vdd_pll-supply = <&s5m_ldo8_reg>;
> > >> >>};
> > >> >> 
> > >> >> +  panel: panel {
> > >> >> +  compatible = "simple-panel";
> > >> >> +  };
> > >> > 
> > >> > You can't do this. "simple-panel" isn't a valid panel model. It
> > >> > should probably be removed from the platform_of_match table in the
> > >> > driver.
> > >> 
> > >> Okay, that means the Snow DT is wrong, too:
> > >> https://patchwork.kernel.org/patch/4625441/
> > >> 
> > >> And the others specify it as fallback:
> > >> https://patchwork.kernel.org/patch/4625461/
> > >> https://patchwork.kernel.org/patch/4625451/
> > > 
> > > A quick grep shows that many (all?) devices that use DRM panels provide
> > > simple-panel as fallback. That's probably fine as long as they also do
> > > provide the specific model. But given that simple-panel does not have a
> > > mode or physical size, I don't think even that makes sense.
> > 
> > On snow, the bridge chip provides the display mode instead of the panel.
> > That is why display was working for me.
> 
> Okay, I suppose under some circumstances that might make sense. Although
> it's still always the panel that dictates the display timings, so the
> panel node needs to have a panel model specific compatible value with a
> matching entry in the panel-simple driver so that it can even be used in
> setups without a bridge.
> 
> One other thing: how does t

Re: [PATCH V6 6/8] drm/bridge: Modify drm_bridge core to support driver model

[Laurent Pinchart]

Hi Ajay,

On Wednesday 17 September 2014 14:37:30 Ajay kumar wrote:
> On Mon, Sep 15, 2014 at 11:07 PM, Laurent Pinchart wrote:
> > Hi Ajay,
> > 
> > Thank you for the patch.
> > 
> > I think we're moving in the right direction, but we're not there yet.
> > 
> > On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
> >> This patch tries to seperate drm_bridge implementation
> >> into 2 parts, a drm part and a non_drm part.
> >> 
> >> A set of helper functions are defined in this patch to make
> >> bridge driver probe independent of the drm flow.
> >> 
> >> The bridge devices register themselves on a lookup table
> >> when they get probed by calling "drm_bridge_add_for_lookup".
> >> 
> >> The parent encoder driver waits till the bridge is available in the
> >> lookup table(by calling "of_drm_find_bridge") and then continues with
> >> its initialization.
> > 
> > Before the introduction of the component framework I would have said this
> > is the way to go. Now, I think bridges should register themselves as
> > components, and the DRM master driver should use the component framework
> > to get a reference to the bridges it needs.
> 
> Well, I have modified the bridge framework exactly the way Thierry wanted it
> to be, I mean the same way the current panel framework is.
> And, I don't think there is a problem with that.
> What problem are you facing with current bridge implementation?
> What is the advantage of using the component framework to register bridges?

There are several advantages.

- The component framework has been designed with this exact problem in mind, 
piecing multiple components into a display device. This patch set introduces 
yet another framework, without any compelling reason as far as I can see. 
Today DRM drivers already need to use three different frameworks (component, 
I2C slave encoder and panel), and we're adding a fourth one to make the mess 
even messier. This is really a headlong rush, we need to stop and fix the 
design mistakes.

- The component framework solves the probe ordering problem. Bridges can use 
deferred probing, but when a bridge requires a resources (such as a clock for 
instance) provided by the display controller, this will break.

> >> The encoder driver should call "drm_bridge_attach_encoder" to pass on
> >> the drm_device and the encoder pointers to the bridge object.
> >> 
> >> Now that the drm_device pointer is available, the encoder then calls
> >> "bridge->funcs->post_encoder_init" to allow the bridge to continue
> >> registering itself with the drm core.
> > 
> > This is what really bothers me with DRM bridge.
> > 
> > The framework assumes that a bridge will always bridge an encoder and a
> > connector. Beside lacking support for chained bridges, this creates an
> > artificial split between bridges and encoders by modeling the same
> > components using drm_encoder or drm_bridge depending on their position in
> > the video output pipeline.
> > 
> > I would like to see drm_bridge becoming more self-centric, removing the
> > awareness of the upstream encoder and downstream connector. I'll give this
> > a try, but it will conflict with this patch, so I'd like to share
> > opinions and coordinate efforts sooner than later if possible.
> 
> I am not really able to understand how you want "drm_bridge" to be.
> As of now, there are many platforms using drm_bridge and they don't
> have a problem with current implementation.
> Regarding chained bridges: Can't you add this once my patchset is merged?
> As an additional feature?

Yes, as I mentioned in another e-mail this can be fixed later. I want to start 
discussing it though.

> To be honest, I have spent quite sometime for working on this patchset.
> All I started with was to add drm_panel support to drm_bridge.
> When I sent the first patchset for that, Daniel, Rob and Thierry raised a
> concern that current bridge framework itself is not proper and hence
> they asked me to fix that first. And we have reached till here based on
> their comments only.
> 
> Without this patchset, you cannot bring an X server
> based display on snow and peach_pit. Also, day by day the number of
> platforms using drm_bridge is increasing.

That's exactly why I'd like to use the component framework now, as the 
conversion will become more complex as time goes by.

> And, I don't really see a problem with the current approach(which is exactly
> the same way panel framework is). And, I am no decision maker here. I would
> expect the top guys to comment!

-- 
Regards,

Laurent Pinchart

--
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 V7 00/12] drm/exynos: few patches to enhance bridge chip support

[Laurent Pinchart]

Hi Javier,

On Tuesday 16 September 2014 14:44:02 Javier Martinez Canillas wrote:
> [adding Laurent Pinchart to cc who had concerns with a previous
> version of this patch-set]

Thank you, I've indeed missed v7.

> On Wed, Aug 27, 2014 at 4:29 PM, Ajay Kumar wrote:
> > This series is based on master branch of Linus tree at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > 
> > I have tested this after adding few DT changes for exynos5250-snow and
> > exynos5420-peach-pit boards.
> > 
> > The V4 series of this particular patchset was also tested by:
> > Rahul Sharma 
> > Javier Martinez Canillas 
> > 
> > Changes since V2:
> > -- Address comments from Jingoo Han for ps8622 driver
> > -- Address comments from Daniel, Rob and Thierry regarding
> >bridge chaining
> > -- Address comments from Thierry regarding the names for
> >new drm_panel functions
> > 
> > Changes since V3:
> > -- Remove hotplug based initialization of exynos_dp
> > -- Make exynos_dp work directly with drm_panel, remove
> >dependency on panel_binder
> > -- Minor cleanups in panel_binder and panel_lvds driver
> > 
> > Changes since V4:
> > -- Use gpiod interface for panel-lvds and ps8622 drivers.
> > -- Address comments from Javier.
> > -- Fix compilation issues when PANEL_BINDER is selected as module.
> > -- Split Documentation patches from driver patches.
> > -- Rebase on top of the tree.
> > 
> > Changes since V5:
> > -- Modify bridge drivers to support driver model.
> > -- Drop the concept of bridge chain(sincle there are no 2 real
> > bridges)
> >Hence drop bridge-panel_binder layer.
> > -- Drop panel-lvds driver and accomodate the required changes in
> >panel-simple driver.
> > -- Use gpiod interface in ptn3460 driver.
> > -- Address all comments by Thierry Reding for V5 series.
> > -- Address comments from Sean Paul for exynos_dp_commit issue.
> > 
> > Changes since V6:
> > -- Panel patches were seperated and they are merged already.
> > -- Fix few issues with ptn3460, before modifying the bridge core.
> > -- Modify drm_bridge as per Thierry's comments for V6 series.
> > -- Add drm_bridge changes minimally without breaking existing
> > code.
> > -- Add new features for ptn3460, step-by-step.
> > -- Address comments from Thierry and Andreas for ptn3460 and
> > ps8622.
> > -- Split documentation patches from driver patches.
> 
> I've tested your series on an Exynos5420 Peach Pit and an Exynos5250
> Snow Chromebooks and display worked for me on both machines.
> 
> I also needed "[PATCH] drm/panel: simple: Add AUO B116XW03 panel
> support" [0] which does not apply cleanly on linux-next so you may
> want to do a re-spin for that patch.
> 
> For Snow I also had to disable CONFIG_FB_SIMPLE, otherwise I just saw
> a blink on boot and only the backlight remained turned on (no display
> output). I don't know if that is expected since IIUC it should be
> possible to do a transition from simplefb to a DRM/KMS driver. I don't
> have a serial console hooked on this machine so I couldn't debug it
> further, sorry.
> 
> Also, I saw that Laurent mentioned some concerns today about the
> previous version (v6) of your series [1]. I guess he missed this v7
> although AFAIU there was no fundamental change on this one so his
> concerns remains? I was really hoping that this could make it to 3.18
> since display support is one of the last major functionalities that is
> missing on these machines.

My main concern as far as merging this patch set goes is why we can't use the 
component framework instead of introducing yet another new subsystem-specific 
component registration framework. My other concerns could be addressed as 
follow-up patches (but I'd like to start discussing them now).

> [0]: http://patchwork.ozlabs.org/patch/384744/
> [1]: http://www.spinics.net/lists/linux-samsung-soc/msg36791.html

-- 
Regards,

Laurent Pinchart

--
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 V6 6/8] drm/bridge: Modify drm_bridge core to support driver model

[Laurent Pinchart]

Hi Ajay,

Thank you for the patch.

I think we're moving in the right direction, but we're not there yet.

On Saturday 26 July 2014 00:52:08 Ajay Kumar wrote:
> This patch tries to seperate drm_bridge implementation
> into 2 parts, a drm part and a non_drm part.
> 
> A set of helper functions are defined in this patch to make
> bridge driver probe independent of the drm flow.
> 
> The bridge devices register themselves on a lookup table
> when they get probed by calling "drm_bridge_add_for_lookup".
> 
> The parent encoder driver waits till the bridge is available in the
> lookup table(by calling "of_drm_find_bridge") and then continues with
> its initialization.

Before the introduction of the component framework I would have said this is 
the way to go. Now, I think bridges should register themselves as components, 
and the DRM master driver should use the component framework to get a 
reference to the bridges it needs.

> The encoder driver should call "drm_bridge_attach_encoder" to pass on
> the drm_device and the encoder pointers to the bridge object.
> 
> Now that the drm_device pointer is available, the encoder then calls
> "bridge->funcs->post_encoder_init" to allow the bridge to continue
> registering itself with the drm core.

This is what really bothers me with DRM bridge.

The framework assumes that a bridge will always bridge an encoder and a 
connector. Beside lacking support for chained bridges, this creates an 
artificial split between bridges and encoders by modeling the same components 
using drm_encoder or drm_bridge depending on their position in the video 
output pipeline.

I would like to see drm_bridge becoming more self-centric, removing the 
awareness of the upstream encoder and downstream connector. I'll give this a 
try, but it will conflict with this patch, so I'd like to share opinions and 
coordinate efforts sooner than later if possible.

> Also, non driver model based ptn3460 driver is removed in this patch.
> 
> Signed-off-by: Ajay Kumar 
> ---
>  .../devicetree/bindings/drm/bridge/ptn3460.txt |   27 --
>  drivers/gpu/drm/Makefile   |1 +
>  drivers/gpu/drm/bridge/Kconfig |   12 +-
>  drivers/gpu/drm/bridge/Makefile|2 -
>  drivers/gpu/drm/bridge/ptn3460.c   |  343 -
>  drivers/gpu/drm/drm_bridge.c   |   89 +
>  drivers/gpu/drm/drm_crtc.c |9 +-
>  drivers/gpu/drm/exynos/Kconfig |3 +-
>  drivers/gpu/drm/exynos/exynos_dp_core.c|   57 ++--
>  drivers/gpu/drm/exynos/exynos_dp_core.h|1 +
>  drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |3 +-
>  include/drm/bridge/ptn3460.h   |   37 ---
>  include/drm/drm_crtc.h |   16 +-
>  13 files changed, 147 insertions(+), 453 deletions(-)
>  delete mode 100644 Documentation/devicetree/bindings/drm/bridge/ptn3460.txt
>  delete mode 100644 drivers/gpu/drm/bridge/ptn3460.c
>  create mode 100644 drivers/gpu/drm/drm_bridge.c
>  delete mode 100644 include/drm/bridge/ptn3460.h

-- 
Regards,

Laurent Pinchart

--
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 04/29] drivers: base: add notifier for failed driver bind

[Laurent Pinchart]

Hi Marek,

Thank you for the patch.

On Tuesday 05 August 2014 12:47:32 Marek Szyprowski wrote:
> This patch adds support for getting a notify for failed device driver
> bind, so all the items done in BUS_NOTIFY_BIND_DRIVER event can be
> cleaned if the driver fails to bind.
> 
> Signed-off-by: Marek Szyprowski 
> ---
>  drivers/base/dd.c  | 10 +++---
>  include/linux/device.h |  4 +++-
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index e4ffbcf..541a41f 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -237,10 +237,14 @@ static int driver_sysfs_add(struct device *dev)
>   return ret;
>  }
> 
> -static void driver_sysfs_remove(struct device *dev)
> +static void driver_sysfs_remove(struct device *dev, int failed)
>  {
>   struct device_driver *drv = dev->driver;
> 
> + if (failed && dev->bus)
> + blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
> +  BUS_NOTIFY_DRVBIND_FAILED, dev);

This might be a stupid question, but as you only call driver_sysfs_remove with 
failed set to true in a single location (in the failure path of really_probe), 
how about moving the blocking_notifier_call_chain to that location ? The code 
seems to be a bit out of place here.

> +
>   if (drv) {
>   sysfs_remove_link(&drv->p->kobj, kobject_name(&dev->kobj));
>   sysfs_remove_link(&dev->kobj, "driver");
> @@ -316,7 +320,7 @@ static int really_probe(struct device *dev, struct
> device_driver *drv)
> 
>  probe_failed:
>   devres_release_all(dev);
> - driver_sysfs_remove(dev);
> + driver_sysfs_remove(dev, true);
>   dev->driver = NULL;
>   dev_set_drvdata(dev, NULL);
> 
> @@ -509,7 +513,7 @@ static void __device_release_driver(struct device *dev)
>   if (drv) {
>   pm_runtime_get_sync(dev);
> 
> - driver_sysfs_remove(dev);
> + driver_sysfs_remove(dev, false);
> 
>   if (dev->bus)
>   blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
> diff --git a/include/linux/device.h b/include/linux/device.h
> index b387710..92daded 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -176,7 +176,7 @@ extern int bus_register_notifier(struct bus_type *bus,
>  extern int bus_unregister_notifier(struct bus_type *bus,
>  struct notifier_block *nb);
> 
> -/* All 4 notifers below get called with the target struct device *
> +/* All 7 notifers below get called with the target struct device *
>   * as an argument. Note that those functions are likely to be called
>   * with the device lock held in the core, so be careful.
>   */
> @@ -189,6 +189,8 @@ extern int bus_unregister_notifier(struct bus_type *bus,
> unbound */
>  #define BUS_NOTIFY_UNBOUND_DRIVER0x0006 /* driver is unbound
> from the device */
> +#define BUS_NOTIFY_DRVBIND_FAILED0x0007 /* driver failed to bind
> +   to device */
> 
>  extern struct kset *bus_get_kset(struct bus_type *bus);
>  extern struct klist *bus_get_device_klist(struct bus_type *bus);

-- 
Regards,

Laurent Pinchart

--
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 v3 1/2] [media] v4l: Add source change event

[Laurent Pinchart]

subscribe(struct v4l2_fh *fh,
> + const struct v4l2_event_subscription *sub)
> +{
> + if (sub->type == V4L2_EVENT_SOURCE_CHANGE)
> + return v4l2_event_subscribe(fh, sub, 0, &v4l2_event_src_ch_ops);
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL_GPL(v4l2_src_change_event_subscribe);
> +
> +int v4l2_src_change_event_subdev_subscribe(struct v4l2_subdev *sd,
> + struct v4l2_fh *fh, struct v4l2_event_subscription *sub)
> +{
> + return v4l2_src_change_event_subscribe(fh, sub);
> +}
> +EXPORT_SYMBOL_GPL(v4l2_src_change_event_subdev_subscribe);
> diff --git a/include/media/v4l2-event.h b/include/media/v4l2-event.h
> index be05d01..1ab9045 100644
> --- a/include/media/v4l2-event.h
> +++ b/include/media/v4l2-event.h
> @@ -132,4 +132,8 @@ int v4l2_event_unsubscribe(struct v4l2_fh *fh,
>  void v4l2_event_unsubscribe_all(struct v4l2_fh *fh);
>  int v4l2_event_subdev_unsubscribe(struct v4l2_subdev *sd, struct v4l2_fh
> *fh, struct v4l2_event_subscription *sub);
> +int v4l2_src_change_event_subscribe(struct v4l2_fh *fh,
> + const struct v4l2_event_subscription *sub);
> +int v4l2_src_change_event_subdev_subscribe(struct v4l2_subdev *sd,
> + struct v4l2_fh *fh, struct v4l2_event_subscription *sub);
>  #endif /* V4L2_EVENT_H */
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index ea468ee..b923d91 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -1765,6 +1765,7 @@ struct v4l2_streamparm {
>  #define V4L2_EVENT_EOS   2
>  #define V4L2_EVENT_CTRL  3
>  #define V4L2_EVENT_FRAME_SYNC4
> +#define V4L2_EVENT_SOURCE_CHANGE 5

My last concern is about the event name (and the name of the related 
structure). Either this event applies to inputs only, in which case the 
documentation shouldn't mention the output number as it does above, or the 
event applies to both inputs and outputs, in which case the name "source" is 
too restrictive. I'd be tempted to go for the second option, even though I 
have less use cases in mind on the output side.

>  #define V4L2_EVENT_PRIVATE_START 0x0800
> 
>  /* Payload for V4L2_EVENT_VSYNC */
> @@ -1796,12 +1797,19 @@ struct v4l2_event_frame_sync {
>   __u32 frame_sequence;
>  };
> 
> +#define V4L2_EVENT_SRC_CH_RESOLUTION (1 << 0)
> +
> +struct v4l2_event_src_change {
> + __u32 changes;
> +};
> +
>  struct v4l2_event {
>   __u32   type;
>   union {
>   struct v4l2_event_vsync vsync;
>   struct v4l2_event_ctrl  ctrl;
>   struct v4l2_event_frame_syncframe_sync;
> + struct v4l2_event_src_changesrc_change;
>   __u8data[64];
>   } u;
>   __u32   pending;

-- 
Regards,

Laurent Pinchart

--
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 v3 PATCH v6 11/16] ARM: dts: s6e3fa0: add DT bindings

[Laurent Pinchart]

On Wednesday 07 May 2014 10:05:46 YoungJun Cho wrote:
> Hi Andrzej
> 
> Thank you for comments.
> 
> On 05/05/2014 07:35 PM, Andrzej Hajda wrote:
> > On 04/27/2014 03:50 AM, YoungJun Cho wrote:
> >> This patch adds DT bindings for s6e3fa0 panel.
> >> The bindings describes panel resources, display timings and cpu mode
> >> timings.
> >> 
> >> Changelog v2:
> >> - Adds unit address (commented by Sachin Kamat)
> >> Changelog v3:
> >> - Removes optional delay, size properties (commented by Laurent Pinchart)
> >> - Adds OLED detection, TE gpio properties
> >> Changelog v4:
> >> - Moves CPU timings relevant properties from FIMD DT
> >> 
> >>(commeted by Laurent Pinchart, Andrzej Hajda)
> >> 
> >> Changelog v5:
> >> - Fixes gpio property names (commented by Andrzej Hajda)
> >> Changelog v6:
> >> - Renames CPU timings to CPU mode timings
> >> - Modifies CPU mode timings internal properties relevant things
> >> 
> >>(commeted by Laurent Pinchart, Andrzej Hajda)
> >> 
> >> Signed-off-by: YoungJun Cho 
> >> Acked-by: Inki Dae 
> >> Acked-by: Kyungmin Park 
> >> ---
> >> 
> >>   .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   68
> >>    1 file changed, 68 insertions(+)
> >>   create mode 100644
> >>   Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt>> 
> >> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> >> b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
> >> mode 100644
> >> index 000..9f06645
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> >> @@ -0,0 +1,68 @@
> >> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
> >> +
> >> +Required properties:
> >> +  - compatible: "samsung,s6e3fa0"
> >> +  - reg: the virtual channel number of a DSI peripheral
> >> +  - vdd3-supply: core voltage supply
> >> +  - vci-supply: voltage supply for analog circuits
> >> +  - reset-gpios: a GPIO spec for the reset pin
> >> +  - det-gpios: a GPIO spec for the OLED detection pin
> >> +  - te-gpios: a GPIO spec for the TE pin
> >> +  - display-timings: timings for the connected panel as described by [1]
> > 
> > This still bothers me, it forces users to provide bunch of fake
> > properties (four porches, two syncs and clock-frequency) just because we
> > need to pass somehow pixel width and height. And do we really need pixel
> > dimension to be passed via DT? I guess it could be:
> > - hardcoded into the driver,
> > - derived from the panel id,
> > - maybe read from the panel, this is the best option I guess but I am
> > not sure if panel provides an API for this.
> 
> I have been trying to only use cpu-mode-timings without display-timings
> for next RFC v4.
> 
> As you mentioned, the only required things in display-timings are
> clock-frequency, hactive and vactive.
> I put them into cpu-mode-timings, but strictly speaking,
> cpu-mode-timings is not related with display timing, it is data
> transmission mode switch timing.
> And there is no interface for this in drm (display) mode yet.
> So I'm not sure what is the generic method to treat them.

If the sync-related properties are not used, they should not be specified. I 
don't really like bundling the timing-related properties with the bus timings 
though, I would rather make the sync-related properties optional in the 
display timing node.

However, I'm pretty sure that your panel does have horizontal and vertical 
blanking, and that information is needed in the display timings to compute the 
frame rate accurately. The porch and sync length properties might not be 
needed individually, but their total value is required.

> >> +  - cpu-mode-timings: CPU interface timings for the connected panel,
> >> +  and it contains following properties.
> >> +Required properties:
> >> +  - wr-active: clock cycles for the active period of CS enable
> >> in CPU +  interface.
> >> +Optional properties:
> >> +  - cs-setup: clock cycles for the active period of address
> >> signal
> >> +  enable until chip select is enable in CPU interface.
> >> +  If not specified, the default value(0) will be used.
> >> +  - wr-setup: clock cycles for the active period of CS signal
> >> enable +  until writ

Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[Laurent Pinchart]

Hi Thierry,

On Monday 28 April 2014 23:25:50 Thierry Reding wrote:
> On Mon, Apr 28, 2014 at 05:05:24PM +0200, Laurent Pinchart wrote:
> > On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
> > > On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
> > > > Hi YoungJun,
> > > > 
> > > > Thank you for the patch.
> > > > 
> > > > On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
> > > >> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel
> > > >> driver.
> > > >> 
> > > >> Changelog v2:
> > > >> - Declares delay, size properties in probe routine instead of DT
> > > >> Changelog v3:
> > > >> - Moves CPU timings relevant properties from FIMD DT
> > > >> 
> > > >>(commented by Laurent Pinchart, Andrzej Hajda)
> > > >> 
> > > >> Signed-off-by: YoungJun Cho 
> > > >> Acked-by: Inki Dae 
> > > >> Acked-by: Kyungmin Park 
> > > >> ---
> > > >> 
> > > >>   drivers/gpu/drm/panel/Kconfig |7 +
> > > >>   drivers/gpu/drm/panel/Makefile|1 +
> > > >>   drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 ++
> > > >>   3 files changed, 577 insertions(+)
> > > >>   create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
> > > > 
> > > > [snip]
> > > > 
> > > >> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
> > > >> b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
> > > >> index 000..1282678
> > > >> --- /dev/null
> > > >> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
> > > >> @@ -0,0 +1,569 @@
> > > > 
> > > > [snip]
> > > > 
> > > >> +static int s6e3fa0_get_modes(struct drm_panel *panel)
> > > >> +{
> > > >> +  struct drm_connector *connector = panel->connector;
> > > >> +  struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
> > > >> +  struct drm_display_mode *mode;
> > > >> +
> > > >> +  mode = drm_mode_create(connector->dev);
> > > >> +  if (!mode) {
> > > >> +  DRM_ERROR("failed to create a new display mode\n");
> > > >> +  return 0;
> > > >> +  }
> > > >> +
> > > >> +  drm_display_mode_from_videomode(&ctx->vm, mode);
> > > >> +  mode->width_mm = ctx->width_mm;
> > > >> +  mode->height_mm = ctx->height_mm;
> > > >> +  connector->display_info.width_mm = mode->width_mm;
> > > >> +  connector->display_info.height_mm = mode->height_mm;
> > > >> +
> > > >> +  mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> > > >> +  mode->private = (void *)&ctx->cpu_timings;
> > > > 
> > > > Wouldn't it make sense to create a new get_interface_params (or
> > > > similar)
> > > > operation for drm_panel to query interface configuration parameters
> > > > instead of shoving it in the mode private field ?
> > > 
> > > You mean "new get_interface_params operation" is different from
> > > get_modes() ?
> > > 
> > > Till now, struct drm_display_mode and most of mode relevant APIs are
> > > only for video interface.
> > > And CPU interface also needs video mode configurations.
> > > 
> > > I have a plan to implement the CPU interface relevant APIs like video
> > > mode ones, but I think they should be used under current DRM mode APIs
> > > like fill_modes, get_modes and so on.
> > > So after that implementation, this private field will be replaced by
> > > new ones.
> > > 
> > > Could you explain it in more detail?
> > 
> > The idea is that the interface parameters (RD/WR signals timings in this
> > case, but this could also include MIPI DSI lane configuration or any
> > other kind of physical interface parameters) are distinct from the video
> > modes.
> 
> We already have the lanes field in struct mipi_dsi_device.

Seems I've missed the addition of mipi_dsi_device to DRM.

> I think in general I'd prefer to not spread these parameters around too
> wildly. If this is a general requirement for DBI devices, perhaps what we
> need is struct mipi_dbi_device?

That could be done, but I'm not sure we should expose the nature of the panel 
device (i.e. "I'm a mipi_dsi_device") to the display controller. I would be 
worried about using container_of() on panel->dev to get a mipi_dsi_device 
pointer, as we would then need a strict guarantee that the panel->dev pointer 
is embedded directly in a mipi_dsi_device. This might be doable for DSI, but 
other kind of panels might be connected to different control busses (I'm 
thinking about I2C and SPI in particular) and still need to expose video 
interface parameters to the display controller driver.

-- 
Regards,

Laurent Pinchart


signature.asc
Description: This is a digitally signed message part.

Re: [PATCH] [media] s5p-mfc: Add IOMMU support

[Laurent Pinchart]

Hi Arun,

On Tuesday 22 April 2014 17:52:08 Arun Kumar K wrote:
> On Tue, Apr 22, 2014 at 5:23 PM, Laurent Pinchart wrote:
> > On Tuesday 22 April 2014 16:32:48 Arun Kumar K wrote:
> >> The patch adds IOMMU support for MFC driver.
> > 
> > I've been working on an IOMMU driver lately, which led me to think about
> > how drivers should be interfaced with IOMMUs. Runtime IOMMU handling is
> > performed by the DMA mapping API, but in many cases (including Exynos
> > platforms) the arm_iommu_create_mapping() and arm_iommu_attach_device()
> > functions still need to be called explicitly by drivers, which doesn't
> > seem a very good idea to me. Ideally IOMMU usage should be completely
> > transparent for bus master drivers, without requiring any driver
> > modification to use the IOMMU.
> > 
> > What would you think about improving the Exynos IOMMU driver to create the
> > mapping and attach the device instead of having to modify all bus master
> > drivers ? See the ipmmu_add_device() function in
> > http://www.spinics.net/lists/linux-sh/msg30488.html for a possible
> > implementation.
> 
> Yes that would be a better solution. But as far as I know, exynos platforms
> has few more complications where multiple IOMMUs are present for single IP.
> The exynos iommu work is still under progress and KyonHo Cho will have some
> inputs / comments on this. This seems to me a valid usecase which can be
> considered for exynos iommu also.

Thank you. Just to be clear, I don't see a reason to delay this patch until 
the Exynos IOMMU driver gets support for creating mappings and attaching 
devices, but it would be nice to see that happen as a cleanup in the not too 
distant future.

> >> Signed-off-by: Arun Kumar K 
> >> ---
> >> This patch is tested on IOMMU support series [1] posted
> >> by KyonHo Cho.
> >> [1] https://lkml.org/lkml/2014/3/14/9
> >> ---
> >> 
> >>  drivers/media/platform/s5p-mfc/s5p_mfc.c |   33
> >>  +++
> >>  1 file changed, 33 insertions(+)
> >> 
> >> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> >> b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 89356ae..1f248ba 100644
> >> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> >> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> >> @@ -32,11 +32,18 @@
> >> 
> >>  #include "s5p_mfc_opr.h"
> >>  #include "s5p_mfc_cmd.h"
> >>  #include "s5p_mfc_pm.h"
> >> 
> >> +#ifdef CONFIG_EXYNOS_IOMMU
> >> +#include 
> >> +#endif
> >> 
> >>  #define S5P_MFC_NAME "s5p-mfc"
> >>  #define S5P_MFC_DEC_NAME "s5p-mfc-dec"
> >>  #define S5P_MFC_ENC_NAME "s5p-mfc-enc"
> >> 
> >> +#ifdef CONFIG_EXYNOS_IOMMU
> >> +static struct dma_iommu_mapping *mapping;
> >> +#endif
> >> +
> >> 
> >>  int debug;
> >>  module_param(debug, int, S_IRUGO | S_IWUSR);
> >>  MODULE_PARM_DESC(debug, "Debug level - higher value produces more
> >>  verbose
> >> 
> >> messages"); @@ -1013,6 +1020,23 @@ static void *mfc_get_drv_data(struct
> >> platform_device *pdev);
> >> 
> >>  static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev *dev)
> >>  {
> >> 
> >> +#ifdef CONFIG_EXYNOS_IOMMU
> >> + struct device *mdev = &dev->plat_dev->dev;
> >> +
> >> + mapping = arm_iommu_create_mapping(&platform_bus_type, 0x2000,
> >> + SZ_256M);
> >> + if (mapping == NULL) {
> >> + mfc_err("IOMMU mapping failed\n");
> >> + return -EFAULT;
> >> + }
> >> + mdev->dma_parms = devm_kzalloc(&dev->plat_dev->dev,
> >> + sizeof(*mdev->dma_parms), GFP_KERNEL);
> >> + dma_set_max_seg_size(mdev, 0xu);
> >> + arm_iommu_attach_device(mdev, mapping);
> >> +
> >> + dev->mem_dev_l = dev->mem_dev_r = mdev;
> >> + return 0;
> >> +#else
> >> 
> >>   unsigned int mem_info[2] = { };
> >>   
> >>   dev->mem_dev_l = devm_kzalloc(&dev->plat_dev->dev,
> >> 
> >> @@ -1049,6 +1073,7 @@ static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev
> >> *dev) return -ENOMEM;
> >> 
> >>   }
> >>   return 0;
> >> 
> >> +#endif
> >> 
> >>  }
> >

Re: [RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[Laurent Pinchart]

Hi YoungJun,

On Tuesday 22 April 2014 10:24:39 YoungJun Cho wrote:
> On 04/22/2014 08:00 AM, Laurent Pinchart wrote:
> > Hi YoungJun,
> > 
> > Thank you for the patch.
> > 
> > On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
> >> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel
> >> driver.
> >> 
> >> Changelog v2:
> >> - Declares delay, size properties in probe routine instead of DT
> >> Changelog v3:
> >> - Moves CPU timings relevant properties from FIMD DT
> >> 
> >>(commented by Laurent Pinchart, Andrzej Hajda)
> >> 
> >> Signed-off-by: YoungJun Cho 
> >> Acked-by: Inki Dae 
> >> Acked-by: Kyungmin Park 
> >> ---
> >> 
> >>   drivers/gpu/drm/panel/Kconfig |7 +
> >>   drivers/gpu/drm/panel/Makefile|1 +
> >>   drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 ++
> >>   3 files changed, 577 insertions(+)
> >>   create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c
> > 
> > [snip]
> > 
> >> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
> >> b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
> >> index 000..1282678
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
> >> @@ -0,0 +1,569 @@
> > 
> > [snip]
> > 
> >> +static int s6e3fa0_get_modes(struct drm_panel *panel)
> >> +{
> >> +  struct drm_connector *connector = panel->connector;
> >> +  struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
> >> +  struct drm_display_mode *mode;
> >> +
> >> +  mode = drm_mode_create(connector->dev);
> >> +  if (!mode) {
> >> +  DRM_ERROR("failed to create a new display mode\n");
> >> +  return 0;
> >> +  }
> >> +
> >> +  drm_display_mode_from_videomode(&ctx->vm, mode);
> >> +  mode->width_mm = ctx->width_mm;
> >> +  mode->height_mm = ctx->height_mm;
> >> +  connector->display_info.width_mm = mode->width_mm;
> >> +  connector->display_info.height_mm = mode->height_mm;
> >> +
> >> +  mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> >> +  mode->private = (void *)&ctx->cpu_timings;
> > 
> > Wouldn't it make sense to create a new get_interface_params (or similar)
> > operation for drm_panel to query interface configuration parameters
> > instead of shoving it in the mode private field ?
> 
> You mean "new get_interface_params operation" is different from
> get_modes() ?
> 
> Till now, struct drm_display_mode and most of mode relevant APIs are
> only for video interface.
> And CPU interface also needs video mode configurations.
> 
> I have a plan to implement the CPU interface relevant APIs like video
> mode ones, but I think they should be used under current DRM mode APIs
> like fill_modes, get_modes and so on.
> So after that implementation, this private field will be replaced by
> new ones.
> 
> Could you explain it in more detail?

The idea is that the interface parameters (RD/WR signals timings in this case, 
but this could also include MIPI DSI lane configuration or any other kind of 
physical interface parameters) are distinct from the video modes.

Do you see a need to tie tie interface parameters with drm_display_mode ? Can 
they be mode-specific ? In any case I'd like not to use the private field of 
drm_display_mode. If we need to tie both information together then it should 
be done in a standard way.

-- 
Regards,

Laurent Pinchart

--
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 v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[Laurent Pinchart]

Hi Andrzej,

On Wednesday 23 April 2014 14:48:31 Andrzej Hajda wrote:
> On 04/23/2014 01:34 PM, Laurent Pinchart wrote:
> > On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
> >> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> >>> This patch adds DT bindings for s6e3fa0 panel.
> >>> The bindings describes panel resources, display timings and cpu timings.
> >>> 
> >>> Changelog v2:
> >>> - Adds unit address (commented by Sachin Kamat)
> >>> Changelog v3:
> >>> - Removes optional delay, size properties (commented by Laurent
> >>> Pinchart)
> >>> - Adds OLED detection, TE gpio properties
> >>> Changelog v4:
> >>> - Moves CPU timings relevant properties from FIMD DT
> >>> 
> >>>   (commeted by Laurent Pinchart, Andrzej Hajda)
> >>> 
> >>> Signed-off-by: YoungJun Cho 
> >>> Acked-by: Inki Dae 
> >>> Acked-by: Kyungmin Park 
> >>> ---
> >>> 
> >>>  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63
> >>>  +++
> >>> 
> >>> 1 file changed, 63 insertions(+)
> >>> 
> >>>  create mode 100644
> >>>  Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt>
> >>> 
> >>> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> >>> b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
> >>> mode 100644
> >>> index 000..9eeb38b
> >>> --- /dev/null
> >>> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> >>> @@ -0,0 +1,63 @@
> >>> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
> >>> +
> >>> +Required properties:
> >>> +  - compatible: "samsung,s6e3fa0"
> >>> +  - reg: the virtual channel number of a DSI peripheral
> >>> +  - vdd3-supply: core voltage supply
> >>> +  - vci-supply: voltage supply for analog circuits
> >>> +  - reset-gpio: a GPIO spec for the reset pin
> >>> +  - det-gpio: a GPIO spec for the OLED detection pin
> >>> +  - te-gpio: a GPIO spec for the TE pin
> >>> +  - display-timings: timings for the connected panel as described by
> >>> [1]
> >> 
> >> Which properties of display-timings are relevant for CPU mode?
> >> I guess width and height. Anything more?
> >> 
> >>> +  - cpu-timings: CPU interface timings for the connected panel, and it
> >>> contains
> >>> +following optional properties.
> >>> +  - cs-setup: clock cycles for the active period of address
> >>> signal
> >>> +enable until chip select is enable in CPU interface
> >>> +  - wr-setup: clock cycles for the active period of CS signal
> >>> enable
> >>> +until write signal is enable in CPU interface
> >>> +  - wr-act: clock cycles for the active period of CS enable in
> >>> CPU
> >>> +interface
> > 
> > What about calling this property wr-active ? I had called this wr-cycle in
> > a previous implementation, that could be an option as well.
> > 
> >>> +  - wr-hold: clock cycles for the active period of CS disable
> >>> until
> >>> +write signal is disable in CPU interface
> >> 
> >> cpu-timings name does not sound to be related to display.
> >> I wonder if it would not be better to merge cpu-timings into
> >> display-timings but this will require more discussion I guess.
> > 
> > The panel has a memory-like interface with chip select, read/write and
> > access strobe, address (1 bit) and data signals. The interface is defined
> > in the MIPI DBI specification (a quick search turned up
> > http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might
> > be direct PDF downloads available), even if some panels implement a
> > similar interface that predates MIPI DBI (with names such as i80 or
> > SYS-80 probably due to the similarities with the 8051 external bus).
> > 
> > The cpu-timings properties describe the read and write access timings for
> > those signals, unrelated to the display video timings. I thus believe that
> > they should be separate from the display timings. We will probably need to
> > add properties for the read signal as well, but that can be done later.
>
> cpu-timings suggests these timings are for CPU, but t

Re: [RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

[Laurent Pinchart]

Hi Andrzej,

On Wednesday 23 April 2014 11:02:21 Andrzej Hajda wrote:
> On 04/21/2014 02:28 PM, YoungJun Cho wrote:
> > This patch adds DT bindings for s6e3fa0 panel.
> > The bindings describes panel resources, display timings and cpu timings.
> > 
> > Changelog v2:
> > - Adds unit address (commented by Sachin Kamat)
> > Changelog v3:
> > - Removes optional delay, size properties (commented by Laurent Pinchart)
> > - Adds OLED detection, TE gpio properties
> > Changelog v4:
> > - Moves CPU timings relevant properties from FIMD DT
> > 
> >   (commeted by Laurent Pinchart, Andrzej Hajda)
> > 
> > Signed-off-by: YoungJun Cho 
> > Acked-by: Inki Dae 
> > Acked-by: Kyungmin Park 
> > ---
> > 
> >  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   63 +++
> > 1 file changed, 63 insertions(+)
> >  create mode 100644
> >  Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt> 
> > diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> > b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file
> > mode 100644
> > index 000..9eeb38b
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> > @@ -0,0 +1,63 @@
> > +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
> > +
> > +Required properties:
> > +  - compatible: "samsung,s6e3fa0"
> > +  - reg: the virtual channel number of a DSI peripheral
> > +  - vdd3-supply: core voltage supply
> > +  - vci-supply: voltage supply for analog circuits
> > +  - reset-gpio: a GPIO spec for the reset pin
> > +  - det-gpio: a GPIO spec for the OLED detection pin
> > +  - te-gpio: a GPIO spec for the TE pin
> > +  - display-timings: timings for the connected panel as described by [1]
> 
> Which properties of display-timings are relevant for CPU mode?
> I guess width and height. Anything more?
> 
> > +  - cpu-timings: CPU interface timings for the connected panel, and it
> > contains
> > +following optional properties.
> > +  - cs-setup: clock cycles for the active period of address
> > signal
> > +enable until chip select is enable in CPU interface
> > +  - wr-setup: clock cycles for the active period of CS signal
> > enable
> > +until write signal is enable in CPU interface
> > +  - wr-act: clock cycles for the active period of CS enable in
> > CPU
> > +interface

What about calling this property wr-active ? I had called this wr-cycle in a 
previous implementation, that could be an option as well.

> > +  - wr-hold: clock cycles for the active period of CS disable
> > until
> > +write signal is disable in CPU interface
> 
> cpu-timings name does not sound to be related to display.
> I wonder if it would not be better to merge cpu-timings into
> display-timings but this will require more discussion I guess.

The panel has a memory-like interface with chip select, read/write and access 
strobe, address (1 bit) and data signals. The interface is defined in the MIPI 
DBI specification (a quick search turned up 
http://www.scribd.com/doc/206899854/MIPI-DPI-Specification-v2, there might be 
direct PDF downloads available), even if some panels implement a similar 
interface that predates MIPI DBI (with names such as i80 or SYS-80 probably 
due to the similarities with the 8051 external bus).

The cpu-timings properties describe the read and write access timings for 
those signals, unrelated to the display video timings. I thus believe that 
they should be separate from the display timings. We will probably need to add 
properties for the read signal as well, but that can be done later.

> If you want to stay with separate node please consider to make it
> optional as whole node or make some properties required. Making node
> required with all sub-properties optional is weird.
> By the way I hope all timings properties are generic for CPU mode,
> if not they should be prefixed by vendor or model.

The timings description should be pretty generic I believe, especially given 
that the interface is standardized by the MIPI alliance. Could you have a 
quick look at the spec and share your opinion ?

> > +
> > +Optional properties:
> > +
> > +The device node can contain one 'port' child node with one child
> > +'endpoint' node, according to the bindings defined in [2]. This
> > +node should describe panel's video bus.
> > +
> > +[1]: Documentation/devicetree/bindings/video/display-timing.txt
> > +[2]: Documentation/devicetree/bindings/media/video-interface

Re: [PATCH] [media] s5p-mfc: Add IOMMU support

[Laurent Pinchart]

Hi Arun,

Thank you for the patch.

On Tuesday 22 April 2014 16:32:48 Arun Kumar K wrote:
> The patch adds IOMMU support for MFC driver.

I've been working on an IOMMU driver lately, which led me to think about how 
drivers should be interfaced with IOMMUs. Runtime IOMMU handling is performed 
by the DMA mapping API, but in many cases (including Exynos platforms) the 
arm_iommu_create_mapping() and arm_iommu_attach_device() functions still need 
to be called explicitly by drivers, which doesn't seem a very good idea to me. 
Ideally IOMMU usage should be completely transparent for bus master drivers, 
without requiring any driver modification to use the IOMMU.

What would you think about improving the Exynos IOMMU driver to create the 
mapping and attach the device instead of having to modify all bus master 
drivers ? See the ipmmu_add_device() function in 
http://www.spinics.net/lists/linux-sh/msg30488.html for a possible 
implementation.

> Signed-off-by: Arun Kumar K 
> ---
> This patch is tested on IOMMU support series [1] posted
> by KyonHo Cho.
> [1] https://lkml.org/lkml/2014/3/14/9
> ---
>  drivers/media/platform/s5p-mfc/s5p_mfc.c |   33 +++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> b/drivers/media/platform/s5p-mfc/s5p_mfc.c index 89356ae..1f248ba 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc.c
> @@ -32,11 +32,18 @@
>  #include "s5p_mfc_opr.h"
>  #include "s5p_mfc_cmd.h"
>  #include "s5p_mfc_pm.h"
> +#ifdef CONFIG_EXYNOS_IOMMU
> +#include 
> +#endif
> 
>  #define S5P_MFC_NAME "s5p-mfc"
>  #define S5P_MFC_DEC_NAME "s5p-mfc-dec"
>  #define S5P_MFC_ENC_NAME "s5p-mfc-enc"
> 
> +#ifdef CONFIG_EXYNOS_IOMMU
> +static struct dma_iommu_mapping *mapping;
> +#endif
> +
>  int debug;
>  module_param(debug, int, S_IRUGO | S_IWUSR);
>  MODULE_PARM_DESC(debug, "Debug level - higher value produces more verbose
> messages"); @@ -1013,6 +1020,23 @@ static void *mfc_get_drv_data(struct
> platform_device *pdev);
> 
>  static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev *dev)
>  {
> +#ifdef CONFIG_EXYNOS_IOMMU
> + struct device *mdev = &dev->plat_dev->dev;
> +
> + mapping = arm_iommu_create_mapping(&platform_bus_type, 0x2000,
> + SZ_256M);
> + if (mapping == NULL) {
> + mfc_err("IOMMU mapping failed\n");
> + return -EFAULT;
> + }
> + mdev->dma_parms = devm_kzalloc(&dev->plat_dev->dev,
> + sizeof(*mdev->dma_parms), GFP_KERNEL);
> + dma_set_max_seg_size(mdev, 0xu);
> + arm_iommu_attach_device(mdev, mapping);
> +
> + dev->mem_dev_l = dev->mem_dev_r = mdev;
> + return 0;
> +#else
>   unsigned int mem_info[2] = { };
> 
>   dev->mem_dev_l = devm_kzalloc(&dev->plat_dev->dev,
> @@ -1049,6 +1073,7 @@ static int s5p_mfc_alloc_memdevs(struct s5p_mfc_dev
> *dev) return -ENOMEM;
>   }
>   return 0;
> +#endif
>  }
> 
>  /* MFC probe function */
> @@ -1228,6 +1253,10 @@ err_mem_init_ctx_1:
>   vb2_dma_contig_cleanup_ctx(dev->alloc_ctx[0]);
>  err_res:
>   s5p_mfc_final_pm(dev);
> +#ifdef CONFIG_EXYNOS_IOMMU
> + if (mapping)
> + arm_iommu_release_mapping(mapping);
> +#endif
> 
>   pr_debug("%s-- with error\n", __func__);
>   return ret;
> @@ -1256,6 +1285,10 @@ static int s5p_mfc_remove(struct platform_device
> *pdev) put_device(dev->mem_dev_r);
>   }
> 
> +#ifdef CONFIG_EXYNOS_IOMMU
> + if (mapping)
> + arm_iommu_release_mapping(mapping);
> +#endif
>   s5p_mfc_final_pm(dev);
>   return 0;
>  }

-- 
Regards,

Laurent Pinchart

--
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 v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

[Laurent Pinchart]

Hi YoungJun,

Thank you for the patch.

On Monday 21 April 2014 21:28:37 YoungJun Cho wrote:
> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
> 
> Changelog v2:
> - Declares delay, size properties in probe routine instead of DT
> Changelog v3:
> - Moves CPU timings relevant properties from FIMD DT
>   (commented by Laurent Pinchart, Andrzej Hajda)
> 
> Signed-off-by: YoungJun Cho 
> Acked-by: Inki Dae 
> Acked-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/panel/Kconfig |7 +
>  drivers/gpu/drm/panel/Makefile|1 +
>  drivers/gpu/drm/panel/panel-s6e3fa0.c |  569 ++
>  3 files changed, 577 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-s6e3fa0.c

[snip]

> diff --git a/drivers/gpu/drm/panel/panel-s6e3fa0.c
> b/drivers/gpu/drm/panel/panel-s6e3fa0.c new file mode 100644
> index 000..1282678
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-s6e3fa0.c
> @@ -0,0 +1,569 @@

[snip]

> +static int s6e3fa0_get_modes(struct drm_panel *panel)
> +{
> + struct drm_connector *connector = panel->connector;
> + struct s6e3fa0 *ctx = panel_to_s6e3fa0(panel);
> + struct drm_display_mode *mode;
> +
> + mode = drm_mode_create(connector->dev);
> + if (!mode) {
> + DRM_ERROR("failed to create a new display mode\n");
> + return 0;
> + }
> +
> + drm_display_mode_from_videomode(&ctx->vm, mode);
> + mode->width_mm = ctx->width_mm;
> + mode->height_mm = ctx->height_mm;
> + connector->display_info.width_mm = mode->width_mm;
> + connector->display_info.height_mm = mode->height_mm;
> +
> + mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
> + mode->private = (void *)&ctx->cpu_timings;

Wouldn't it make sense to create a new get_interface_params (or similar) 
operation for drm_panel to query interface configuration parameters instead of 
shoving it in the mode private field ?

> + drm_mode_probed_add(connector, mode);
> +
> + return 1;
> +}

[snip]

-- 
Regards,

Laurent Pinchart

--
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 v2 PATCH v2 06/14] drm/exynos: support MIPI DSI command mode

[Laurent Pinchart]

Hi YoungJun,

Thank you for the patch.

On Monday 21 April 2014 21:28:33 YoungJun Cho wrote:
> This patch adds I80 interface for FIMD to support command mode panel.
> 
> For this, the below features are added:
> - Sets display interface mode relevant registers properly according to the
>   interface type from DT
> - Adds drm_panel_cpu_timings structure
>  . The command mode panel sets them as the private attributes in struct
>drm_display_mode and FIMD gets them by fimd_mode_set().
> - Adds TE interrupt handler
>   . FIMD driver should know TE signal from lcd panel to avoid tearing issue.
> - Adds trigger feature
>   . In case of command mode panel, FIMD should set trigger bit,
> so that image data has to be transferred to display bus or lcd panel.
> 
> Changelog v2:
> - Moves CPU timings relevant properties to panel DT
>   (commented by Laurent Pinchart, Andrzej Hajda)
> 
> Signed-off-by: YoungJun Cho 
> Acked-by: Inki Dae 
> Acked-by: Kyungmin Park 
> ---
>  drivers/gpu/drm/exynos/Kconfig   |1 +
>  drivers/gpu/drm/exynos/exynos_drm_crtc.c |   11 ++
>  drivers/gpu/drm/exynos/exynos_drm_crtc.h |2 +
>  drivers/gpu/drm/exynos/exynos_drm_drv.h  |2 +
>  drivers/gpu/drm/exynos/exynos_drm_dsi.c  |   13 ++
>  drivers/gpu/drm/exynos/exynos_drm_fimd.c |  280 ++-
>  include/drm/drm_mipi_dsi.h   |2 +
>  include/drm/drm_panel.h  |7 +

Could you please split the DRM core changes into two separate standalone 
patches (as they're unrelated to each other) ?

>  include/video/samsung_fimd.h         |3 +-
>  9 files changed, 277 insertions(+), 44 deletions(-)

[snip]

-- 
Regards,

Laurent Pinchart

--
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 PATCH 05/14] ARM: dts: samsung-fimd: add I80 specific properties

[Laurent Pinchart]

Hi YoungJun,

On Thursday 17 April 2014 14:33:37 YoungJun Cho wrote:
> On 04/17/2014 06:26 AM, Laurent Pinchart wrote:
> > On Tuesday 15 April 2014 14:47:33 YoungJun Cho wrote:
> >> In case of using CPU interface panel, the relevant registers should be
> >> set. So this patch adds relevant dt bindings.
> >> 
> >> Signed-off-by: YoungJun Cho 
> >> Signed-off-by: Inki Dae 
> >> Signed-off-by: Kyungmin Park 
> >> ---
> >> 
> >>   .../devicetree/bindings/video/samsung-fimd.txt |9 +
> >>   1 file changed, 9 insertions(+)
> >> 
> >> diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> >> b/Documentation/devicetree/bindings/video/samsung-fimd.txt index
> >> 2dad41b..924c2e1 100644
> >> --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> >> +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
> >> 
> >> @@ -44,6 +44,15 @@ Optional Properties:
> >>   - display-timings: timing settings for FIMD, as described in document
> >>   [1].
> >>   
> >>Can be used in case timings cannot be provided otherwise
> >>or to override timings provided by the panel.
> >> 
> >> +- samsung,sysreg-phandle: handle to syscon used to control the system
> 
> Oops... I have to change "samsung,sysreg-phandle" to "samsung,sysreg".
> 
> >> registers
> >> +- vidout-i80-ldi: boolean to support i80 interface instead of rgb one
> >> +- cs-setup: clock cycles for the active period of address signal enable
> >> until
> >> +  chip select is enable in i80 interface
> >> +- wr-setup: clock cycles for the active period of CS signal enable until
> >> +  write signal is enable in i80 interface
> >> +- wr-act: clock cycles for the active period of CS enable in i80
> >> interface
> >> +- wr-hold: clock cycles for the active period of CS disable until write
> >> signal
> >> +  is disable in i80 interface
> > 
> > Shouldn't the interface parameters be considered as a property of the
> > slave device instead ? The bus master side is programmable, and different
> > slaves would have different timing requirements. I think it would make
> > more sense to specify the timings on the slave (panel) side and query them
> > dynamically at runtime. Depending on the slave the timings could be
> > hardcoded in the driver (as they're usually an intrinsic property of the
> > slave) or partially or fully specified in the slave DT node.
> 
> Yes, you're right. These properties are related to panel in a sense.
> 
> But my intention is to use these properties to fimd node in the board
> specific dts file, because it decides the interface with panel and
> these are required by fimd only.

I agree, it's a bit of a gray area. The properties describe the connection 
between the display controller output and the panel. As such they're shared 
between the two components, so deciding on which node to include them in is a 
bit difficult. In this specific case, as the panel dictates the interface 
timings and the display controller is then programmed to comply with those 
timings, I would be tempted to consider timing information as panel 
properties. This obviously complicates driver implementation, as we would need 
to communicate timing information from panel drivers to display controller 
drivers.

> If dynamic query is more logical approach, I should find some ways
> with considering probing order.

I won't push too much for storing interface timing information in the panel DT 
node, but I'm a bit worried that storing it in the display controller DT node 
might cause issues at some point. As DT is an ABI, we need to carefully 
consider the potential issues.

> >>   The device node can contain 'port' child nodes according to the
> >>   bindings
> >> 
> >> defined in [2]. The following are properties specific to those nodes:

-- 
Regards,

Laurent Pinchart

--
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 v2 1/2] v4l: Add resolution change event.

[Laurent Pinchart]

Hi Arun,

On Monday 21 April 2014 17:19:26 Arun Kumar K wrote:
> On Mon, Apr 21, 2014 at 3:54 PM, Laurent Pinchart wrote:
> > On Monday 21 April 2014 14:56:01 Arun Kumar K wrote:
> >> From: Pawel Osciak 
> >> 
> >> This event indicates that the decoder has reached a point in the stream,
> >> at which the resolution changes. The userspace is expected to provide a
> >> new
> >> set of CAPTURE buffers for the new format before decoding can continue.
> >> The event can also be used for more generic events involving resolution
> >> or format changes at runtime for all kinds of video devices.
> >> 
> >> Signed-off-by: Pawel Osciak 
> >> Signed-off-by: Arun Kumar K 
> >> ---
> >> 
> >>  .../DocBook/media/v4l/vidioc-subscribe-event.xml   |   16
> >>  
> >>  include/uapi/linux/videodev2.h |6 ++
> >>  2 files changed, 22 insertions(+)
> >> 
> >> diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
> >> b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index
> >> 5c70b61..0aec831 100644
> >> --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
> >> +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
> >> @@ -155,6 +155,22 @@
> >>   
> >> 
> >> 
> >> + V4L2_EVENT_SOURCE_CHANGE
> >> + 5
> >> + 
> >> +   This event is triggered when a resolution or format
> >> change +is detected during runtime by the video device. It
> >> can be a +runtime resolution change triggered by a video
> >> decoder or the +format change happening on an HDMI
> >> connector. Application may +need to reinitialize buffers
> >> before proceeding further. +
> >> +  This event has a &v4l2-event-source-change;
> >> associated
> >> +   with it. This has significance only for v4l2 subdevs where
> >> the
> >> +   pad_num field will be updated with
> >> +   the pad number on which the event is triggered.
> >> + 
> >> +   
> >> +   
> >> 
> >>   V4L2_EVENT_PRIVATE_START
> >>   0x0800
> >>   Base event number for driver-private events.
> >> diff --git a/include/uapi/linux/videodev2.h
> >> b/include/uapi/linux/videodev2.h index 6ae7bbe..12e0614 100644
> >> --- a/include/uapi/linux/videodev2.h
> >> +++ b/include/uapi/linux/videodev2.h
> >> @@ -1733,6 +1733,7 @@ struct v4l2_streamparm {
> >>  #define V4L2_EVENT_EOS   2
> >>  #define V4L2_EVENT_CTRL  3
> >>  #define V4L2_EVENT_FRAME_SYNC4
> >> +#define V4L2_EVENT_SOURCE_CHANGE 5
> >>  #define V4L2_EVENT_PRIVATE_START 0x0800
> >>  
> >>  /* Payload for V4L2_EVENT_VSYNC */
> >> @@ -1764,12 +1765,17 @@ struct v4l2_event_frame_sync {
> >>   __u32 frame_sequence;
> >>  };
> >> 
> >> +struct v4l2_event_source_change {
> >> + __u32 pad_num;
> > 
> > I would call the field just "pad",
> 
> Ok.
> 
> >> +};
> >> +
> >> 
> >>  struct v4l2_event {
> >>   __u32   type;
> >>   union {
> >>   struct v4l2_event_vsync vsync;
> >>   struct v4l2_event_ctrl  ctrl;
> >>   struct v4l2_event_frame_syncframe_sync;
> >> + struct v4l2_event_source_change source_change;
> >>   __u8data[64];
> > 
> > This looks pretty good to me, but I'm a bit concerned about future
> > compatibility. We might need to report more information to userspace, and
> > in particular what has been changed at the source (resolution, format,
> > ...). In order to do so, we'll need to add a flag field to
> > v4l2_event_source_change.
>
> Ok a flag can be added with bitfields for reporting specific event type.

I don't think we need to add it now. Just making sure it can be added later 
without breaking the userspace API would be enough for me.

> > The next __u32 right after the source_change field must thus be zeroed. I
> > see two ways of doing so:
> > 
> > - zeroing the whole data array before setting event-specific data

Re: [PATCH v2 1/2] v4l: Add resolution change event.

[Laurent Pinchart]

Hi Arun,

Thank you for the patch.

On Monday 21 April 2014 14:56:01 Arun Kumar K wrote:
> From: Pawel Osciak 
> 
> This event indicates that the decoder has reached a point in the stream,
> at which the resolution changes. The userspace is expected to provide a new
> set of CAPTURE buffers for the new format before decoding can continue.
> The event can also be used for more generic events involving resolution
> or format changes at runtime for all kinds of video devices.
> 
> Signed-off-by: Pawel Osciak 
> Signed-off-by: Arun Kumar K 
> ---
>  .../DocBook/media/v4l/vidioc-subscribe-event.xml   |   16 
>  include/uapi/linux/videodev2.h |6 ++
>  2 files changed, 22 insertions(+)
> 
> diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
> b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index
> 5c70b61..0aec831 100644
> --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
> +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
> @@ -155,6 +155,22 @@
>   
> 
> 
> + V4L2_EVENT_SOURCE_CHANGE
> + 5
> + 
> +   This event is triggered when a resolution or format change
> +is detected during runtime by the video device. It can be a
> +runtime resolution change triggered by a video decoder or the
> +format change happening on an HDMI connector. Application may
> +need to reinitialize buffers before proceeding further.
> +
> +  This event has a &v4l2-event-source-change; associated
> +   with it. This has significance only for v4l2 subdevs where the
> +   pad_num field will be updated with
> +   the pad number on which the event is triggered.
> + 
> +   
> +   
>   V4L2_EVENT_PRIVATE_START
>   0x0800
>   Base event number for driver-private events.
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 6ae7bbe..12e0614 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -1733,6 +1733,7 @@ struct v4l2_streamparm {
>  #define V4L2_EVENT_EOS   2
>  #define V4L2_EVENT_CTRL  3
>  #define V4L2_EVENT_FRAME_SYNC4
> +#define V4L2_EVENT_SOURCE_CHANGE 5
>  #define V4L2_EVENT_PRIVATE_START 0x0800
> 
>  /* Payload for V4L2_EVENT_VSYNC */
> @@ -1764,12 +1765,17 @@ struct v4l2_event_frame_sync {
>   __u32 frame_sequence;
>  };
> 
> +struct v4l2_event_source_change {
> + __u32 pad_num;

I would call the field just "pad", 

> +};
> +
>  struct v4l2_event {
>   __u32   type;
>   union {
>   struct v4l2_event_vsync vsync;
>   struct v4l2_event_ctrl  ctrl;
>   struct v4l2_event_frame_syncframe_sync;
> + struct v4l2_event_source_change source_change;
>   __u8data[64];

This looks pretty good to me, but I'm a bit concerned about future 
compatibility. We might need to report more information to userspace, and in 
particular what has been changed at the source (resolution, format, ...). In 
order to do so, we'll need to add a flag field to v4l2_event_source_change. 
The next __u32 right after the source_change field must thus be zeroed. I see 
two ways of doing so:

- zeroing the whole data array before setting event-specific data
- adding a reserved must-be-zeroed field to v4l2_event_source_change

I like the former better as it's more generic, but we then need to ensure that 
all drivers zero the whole data field correctly. Adding a new 
v4l2_event_init() function would help with that.

>   } u;
>   __u32   pending;

-- 
Regards,

Laurent Pinchart

--
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 PATCH v2 09/14] ARM: dts: s6e3fa0: add DT bindings

[Laurent Pinchart]

Hi YoungJun,

Thank you for the patch.

On Wednesday 16 April 2014 13:38:57 YoungJun Cho wrote:
> This patch adds DT bindings for s6e3fa0 panel.
> The bindings describes panel resources, display timings, delays
> and physical size.
> 
> Changelog v2:
> - Adds unit address (commented by Sachin Kamat)
> 
> Signed-off-by: YoungJun Cho 
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  .../devicetree/bindings/panel/samsung,s6e3fa0.txt  |   52 +
>  1 file changed, 52 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> 
> diff --git a/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt new file mode
> 100644
> index 000..889a74d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/panel/samsung,s6e3fa0.txt
> @@ -0,0 +1,52 @@
> +Samsung S6E3FA0 AMOLED LCD 5.7 inch panel
> +
> +Required properties:
> +  - compatible: "samsung,s6e3fa0"
> +  - reg: the virtual channel number of a DSI peripheral
> +  - vdd3-supply: core voltage supply
> +  - vci-supply: voltage supply for analog circuits
> +  - reset-gpio: a GPIO spec for the reset pin
> +  - display-timings: timings for the connected panel as described by [1]
> +
> +Optional properties:
> +  - power-on-delay: delay after turning regulators on [ms]
> +  - reset-delay: delay after reset sequence [ms]
> +  - init-delay: delay after initialization sequence [ms]
> +  - panel-width-mm: physical panel width [mm]
> +  - panel-height-mm: physical panel height [mm]

Based on the next patch the panel seems to require quite a lot of device-
specific handling, although I might be mistaken as I'm not too familiar with 
DSI. If my understanding is correct, do we really need to specify all those 
properties in DT, or could they be hardcoded in the driver ? I would usually 
push for generic drivers that read device information from DT, but I'm 
wondering whether that is the right choice here.

If you decide to keep the information in DT I think you should document what 
happens when optional properties are not specified. I suppose the driver uses 
a default value, I would document it in the DT bindings.

> +The device node can contain one 'port' child node with one child
> +'endpoint' node, according to the bindings defined in [2]. This
> +node should describe panel's video bus.
> +
> +[1]: Documentation/devicetree/bindings/video/display-timing.txt
> +[2]: Documentation/devicetree/bindings/media/video-interfaces.txt
> +
> +Example:
> +
> + panel@0 {
> + compatible = "samsung,s6e3fa0";
> + reg = <0>;
> + vdd3-supply = <&vcclcd_reg>;
> + vci-supply = <&vlcd_reg>;
> + reset-gpio = <&gpy7 4 0>;
> + power-on-delay= <10>;
> + reset-delay = <5>;
> + init-delay = <120>;
> + panel-width-mm = <71>;
> + panel-height-mm = <126>;
> +
> + display-timings {
> + timing0: timing-0 {
> + clock-frequency = <57153600>;
> + hactive = <1080>;
> + vactive = <1920>;
> + hfront-porch = <2>;
> + hback-porch = <2>;
> + hsync-len = <1>;
> + vfront-porch = <1>;
> + vback-porch = <4>;
> + vsync-len = <1>;
> + };
> + };
> + };

-- 
Regards,

Laurent Pinchart

--
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 PATCH 05/14] ARM: dts: samsung-fimd: add I80 specific properties

[Laurent Pinchart]

Hi YoungJun,

Thank you for the patch.

On Tuesday 15 April 2014 14:47:33 YoungJun Cho wrote:
> In case of using CPU interface panel, the relevant registers should be set.
> So this patch adds relevant dt bindings.
> 
> Signed-off-by: YoungJun Cho 
> Signed-off-by: Inki Dae 
> Signed-off-by: Kyungmin Park 
> ---
>  .../devicetree/bindings/video/samsung-fimd.txt |9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> b/Documentation/devicetree/bindings/video/samsung-fimd.txt index
> 2dad41b..924c2e1 100644
> --- a/Documentation/devicetree/bindings/video/samsung-fimd.txt
> +++ b/Documentation/devicetree/bindings/video/samsung-fimd.txt
> @@ -44,6 +44,15 @@ Optional Properties:
>  - display-timings: timing settings for FIMD, as described in document [1].
>   Can be used in case timings cannot be provided otherwise
>   or to override timings provided by the panel.
> +- samsung,sysreg-phandle: handle to syscon used to control the system
> registers +- vidout-i80-ldi: boolean to support i80 interface instead of
> rgb one +- cs-setup: clock cycles for the active period of address signal
> enable until +chip select is enable in i80 interface
> +- wr-setup: clock cycles for the active period of CS signal enable until
> + write signal is enable in i80 interface
> +- wr-act: clock cycles for the active period of CS enable in i80 interface
> +- wr-hold: clock cycles for the active period of CS disable until write
> signal +  is disable in i80 interface

Shouldn't the interface parameters be considered as a property of the slave 
device instead ? The bus master side is programmable, and different slaves 
would have different timing requirements. I think it would make more sense to 
specify the timings on the slave (panel) side and query them dynamically at 
runtime. Depending on the slave the timings could be hardcoded in the driver 
(as they're usually an intrinsic property of the slave) or partially or fully 
specified in the slave DT node.

>  The device node can contain 'port' child nodes according to the bindings
> defined in [2]. The following are properties specific to those nodes:

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH 1/2] v4l: Add resolution change event.

[Laurent Pinchart]

Hi Arun,

Thank you for the patch.
On Wednesday 16 April 2014 18:29:21 Arun Kumar K wrote:
> From: Pawel Osciak 
> 
> This event indicates that the decoder has reached a point in the stream,
> at which the resolution changes. The userspace is expected to provide a new
> set of CAPTURE buffers for the new format before decoding can continue.
> 
> Signed-off-by: Pawel Osciak 
> Signed-off-by: Arun Kumar K 
> ---
>  .../DocBook/media/v4l/vidioc-subscribe-event.xml   |8 
>  include/uapi/linux/videodev2.h |1 +
>  2 files changed, 9 insertions(+)
> 
> diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
> b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml index
> 5c70b61..d848628 100644
> --- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
> +++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
> @@ -155,6 +155,14 @@
>   
> 
> 
> + V4L2_EVENT_RESOLUTION_CHANGE
> + 5
> + This event is triggered when a resolution change is detected
> + during runtime by the video decoder. Application may need to
> + reinitialize buffers before proceeding further.
> + 
> +   

Would it make sense to report the new resolution in the event data ? I suppose 
it might not be available in all cases though. If we can't report it, would it 
make sense to document how applications should proceed to retrieve it ?

A similar resolution change event might be useful on subdevs, in which case we 
would need to add a pad number to the event data. We could possibly leave that 
for later, but it would be worth considering the problem already.

> +   
>   V4L2_EVENT_PRIVATE_START
>   0x0800
>   Base event number for driver-private events.
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 6ae7bbe..58488b7 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -1733,6 +1733,7 @@ struct v4l2_streamparm {
>  #define V4L2_EVENT_EOS   2
>  #define V4L2_EVENT_CTRL  3
>  #define V4L2_EVENT_FRAME_SYNC4
> +#define V4L2_EVENT_RESOLUTION_CHANGE     5
>  #define V4L2_EVENT_PRIVATE_START 0x0800
> 
>  /* Payload for V4L2_EVENT_VSYNC */

-- 
Regards,

Laurent Pinchart

--
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 v6 1/4] [media] exynos-scaler: Add DT bindings for SCALER driver

[Laurent Pinchart]

Hi Sylwester,

On Wednesday 19 March 2014 12:55:21 Sylwester Nawrocki wrote:
> On 19/03/14 12:31, Laurent Pinchart wrote:
> >> +++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
> >> 
> >> > @@ -0,0 +1,24 @@
> >> > +* Samsung Exynos5 SCALER device
> >> > +
> >> > +SCALER is used for scaling, blending, color fill and color space
> >> > +conversion on EXYNOS[5420/5410] SoCs.
> >> > +
> >> > +Required properties:
> >> > +- compatible: should be "samsung,exynos5420-scaler" or
> >> > +"samsung,exynos5410-scaler"
> >> > +- reg: should contain SCALER physical address location and length
> >> > +- interrupts: should contain SCALER interrupt specifier
> >> > +- clocks: should contain the SCALER clock phandle and specifier pair
> >> > for
> >> > +each clock listed in clock-names property, according to
> >> > +the common clock bindings
> >> > +- clock-names: should contain exactly one entry
> >> > +- "scaler" - IP bus clock
> > 
> > I'm not too familiar with the Exynos platform, but wouldn't it make sense
> > to use a common name across IP cores for interface and function clocks ?
> Certainly it would, I proposed that when the exynos clock controller
> driver was posted, quite long time ago. Unfortunately it wasn't followed
> up. One of serious reasons was that there are common drivers for
> multiple Samsung platforms (also the ones not reworked to support dt) and
> thus changing the clock names would be problematic - driver would still
> need to handle multiple clock names.
> But for this driver a common name like "gate" could be better IMHO.

OMAP uses "ick" for the interface clock and "fck" for the function clock. Do 
you think it would make sense to standardize on "fck" across SoC families ?

-- 
Regards,

Laurent Pinchart

--
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 v6 1/4] [media] exynos-scaler: Add DT bindings for SCALER driver

[Laurent Pinchart]

Hi Shaik,

Thank you for the patch.

On Wednesday 19 March 2014 12:43:13 Shaik Ameer Basha wrote:
> This patch adds the DT binding documentation for the Exynos5420/5410
> based SCALER device driver.
> 
> Signed-off-by: Shaik Ameer Basha 
> Reviewed-by: Sylwester Nawrocki 
> ---
>  .../devicetree/bindings/media/exynos5-scaler.txt   |   24 +
>  1 file changed, 24 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/media/exynos5-scaler.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/exynos5-scaler.txt
> b/Documentation/devicetree/bindings/media/exynos5-scaler.txt new file mode
> 100644
> index 000..e1dd465
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/exynos5-scaler.txt
> @@ -0,0 +1,24 @@
> +* Samsung Exynos5 SCALER device
> +
> +SCALER is used for scaling, blending, color fill and color space
> +conversion on EXYNOS[5420/5410] SoCs.
> +
> +Required properties:
> +- compatible: should be "samsung,exynos5420-scaler" or
> + "samsung,exynos5410-scaler"
> +- reg: should contain SCALER physical address location and length
> +- interrupts: should contain SCALER interrupt specifier
> +- clocks: should contain the SCALER clock phandle and specifier pair for
> + each clock listed in clock-names property, according to
> + the common clock bindings
> +- clock-names: should contain exactly one entry
> + - "scaler" - IP bus clock

I'm not too familiar with the Exynos platform, but wouldn't it make sense to 
use a common name across IP cores for interface and function clocks ?

> +Example:
> + scaler_0: scaler@1280 {
> + compatible = "samsung,exynos5420-scaler";
> + reg = <0x12800000 0x1000>;
> + interrupts = <0 220 0>;
> + clocks = <&clock 381>;
> + clock-names = "scaler";
> + };

-- 
Regards,

Laurent Pinchart

--
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 v6 03/10] Documentation: devicetree: Update Samsung FIMC DT binding

[Laurent Pinchart]

Hi Sylwester,

On Tuesday 11 March 2014 14:38:37 Sylwester Nawrocki wrote:
> Hi Laurent,
> 
> Thanks for your review.

You're welcome.

> On 11/03/14 13:30, Laurent Pinchart wrote:
> [...]
> 
> >> ---
> >> 
> >>  .../devicetree/bindings/media/samsung-fimc.txt |   34 +-
> >>  1 file changed, 26 insertions(+), 8 deletions(-)
> >> 
> >> diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt
> >> b/Documentation/devicetree/bindings/media/samsung-fimc.txt index
> >> 96312f6..dbd4020 100644
> >> --- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
> >> +++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
> >> @@ -32,6 +32,21 @@ way around.
> >> 
> >>  The 'camera' node must include at least one 'fimc' child node.
> >> 
> >> +Optional properties:
> >> +
> >> +- #clock-cells: from the common clock bindings
> >> (../clock/clock-bindings.txt),
> >> +  must be 1. A clock provider is associated with the 'camera' node and
> >> it should
> >> +  be referenced by external sensors that use clocks provided by the SoC
> >> on
> >> +  CAM_*_CLKOUT pins. The clock specifier cell stores an index of a
> >> clock.
> >> +  The indices are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks
> >> respectively.
> >> +
> >> +- clock-output-names: from the common clock bindings, should contain
> >> names of
> >> +  clocks registered by the camera subsystem corresponding to
> >> CAM_A_CLKOUT,
> >> +  CAM_B_CLKOUT output clocks respectively.
> > 
> > Wouldn't it be better to document the "cam_mclk_a" and "cam_mclk_b" names
> > explicitly ? Or do you expect different names to be used in different DT
> > files ? And as they correspond to the CAM_A_CLKOUT and CAM_B_CLKOUT pins,
> > shouldn't they be named "cam_a_clkout" and "cam_b_clkout" ?
> 
> Basically I could use fixed names for these clocks, I just wanted to keep
> a possibility to override them in dts to avoid any possible clock name
> collisions, rather than keep a list of different names per SoC in the
> driver. Right now fixed names could also be used for all SoCs I'm aware of,
> nevertheless I would prefer to keep the clock-output-names property.
> "cam_a_clkout", "cam_b_clkout" may be indeed better names, I'll change
> that.

OK, variable names are fine with me.

> >> +Note: #clock-cells and clock-output-names are mandatory properties if
> >> external
> >> +image sensor devices reference 'camera' device node as a clock provider.
> >> +
> > 
> > What's the reason not to make them always mandatory ? Backward
> > compatibility only ? If so wouldn't it make sense to document the
> > properties as mandatory from now on, and treating them as optional in the
> > driver for backward compatibility ?
> 
> Yes, it's for backwards compatibility only. It may be a good idea to just
> document them as required, since this is how the device is expected to be
> described in DT from now. I'll just make these a required properties,
> the driver already handles them as optional.

OK.

> >>  'fimc' device nodes
> >>  ---
> >> 
> >> @@ -97,8 +112,8 @@ Image sensor nodes
> >> 
> >>  The sensor device nodes should be added to their control bus controller
> >> 
> >> (e.g. I2C0) nodes and linked to a port node in the csis or the
> >> parallel-ports node, using the common video interfaces bindings, defined
> >> in video-interfaces.txt.
> >> -The implementation of this bindings requires clock-frequency property to
> >> be
> >> -present in the sensor device nodes.
> >> +An optional clock-frequency property needs to be present in the sensor
> >> device
> >> +nodes. Default value when this property is not present is 24 MHz.
> > 
> > This bothers me. Having the FIMC driver read the clock-frequence property
> > from the sensor DT nodes feels like a layering violation. Shouldn't the
> > sensor drivers call clk_set_rate() explicitly instead ?
> 
> It is supposed to do so, after this whole patch series. So the camera
> controller driver will not need such properties. What do you think about
> removing this sentence altogether ?

Sure. As the FIMC won't access the clock-frequency property of the sensor 
anymore after this patch series, let's just drop the mention of clock-

Re: [PATCH v6 03/10] Documentation: devicetree: Update Samsung FIMC DT binding

[Laurent Pinchart]

 #address-cells = <1>;
> - #size-cells = <1>;
> - status = "okay";
> -
> + clocks = <&clock 132>, <&clock 133>;
> + clock-names = "sclk_cam0", "sclk_cam1";

The documentation mentions that clock-names must contain "sclk_cam0", 
"sclk_cam1", "pxl_async0", "pxl_async1". Are the last two optional ? If so I 
think you should clarify the description of the clock-names property. This can 
be done in a separate patch.

> + #clock-cells = <1>;
> + clock-output-names = "cam_mclk_a", "cam_mclk_b";
>   pinctrl-names = "default";
>   pinctrl-0 = <&cam_port_a_clk_active>;
> + status = "okay";
> + #address-cells = <1>;
> + #size-cells = <1>;
> 
>   /* parallel camera ports */
>   parallel-ports {

-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v10 1/2] s5k5baf: add camera sensor driver

[Laurent Pinchart]

Hi Sylwester,

On Thursday 19 December 2013 14:54:44 Sylwester Nawrocki wrote:
> On 05/12/13 12:38, Andrzej Hajda wrote:
> > Driver for Samsung S5K5BAF UXGA 1/5" 2M CMOS Image Sensor
> > with embedded SoC ISP.
> > The driver exposes the sensor as two V4L2 subdevices:
> > - S5K5BAF-CIS - pure CMOS Image Sensor, fixed 1600x1200 format,
> >   no controls.
> > - S5K5BAF-ISP - Image Signal Processor, formats up to 1600x1200,
> >   pre/post ISP cropping, downscaling via selection API, controls.
> > 
> > Signed-off-by: Sylwester Nawrocki 
> > Signed-off-by: Andrzej Hajda 
> > Signed-off-by: Kyungmin Park 
> 
> Hi Laurent,
> 
> Does this driver look sane to you, at its 10'th version? :)
> If so I could send a pull request including it this week.

Yes, it does. Sorry for the delay. Please send the pull request.

-- 
Regards,

Laurent Pinchart

--
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 31/51] DMA-API: media: omap3isp: use dma_coerce_mask_and_coherent()

[Laurent Pinchart]

Hi Russell,

Thank you for the patch.

On Thursday 19 September 2013 22:56:02 Russell King wrote:
> The code sequence:
>   isp->raw_dmamask = DMA_BIT_MASK(32);
>   isp->dev->dma_mask = &isp->raw_dmamask;
>   isp->dev->coherent_dma_mask = DMA_BIT_MASK(32);
> bypasses the architectures check on the DMA mask.  It can be replaced
> with dma_coerce_mask_and_coherent(), avoiding the direct initialization
> of this mask.
> 
> Signed-off-by: Russell King 

Acked-by: Laurent Pinchart 

> ---
>  drivers/media/platform/omap3isp/isp.c |6 +++---
>  drivers/media/platform/omap3isp/isp.h |3 ---
>  2 files changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/media/platform/omap3isp/isp.c
> b/drivers/media/platform/omap3isp/isp.c index df3a0ec..1c36080 100644
> --- a/drivers/media/platform/omap3isp/isp.c
> +++ b/drivers/media/platform/omap3isp/isp.c
> @@ -2182,9 +2182,9 @@ static int isp_probe(struct platform_device *pdev)
>   isp->pdata = pdata;
>   isp->ref_count = 0;
> 
> - isp->raw_dmamask = DMA_BIT_MASK(32);
> - isp->dev->dma_mask = &isp->raw_dmamask;
> - isp->dev->coherent_dma_mask = DMA_BIT_MASK(32);
> + ret = dma_coerce_mask_and_coherent(isp->dev, DMA_BIT_MASK(32));
> + if (ret)
> + return ret;
> 
>   platform_set_drvdata(pdev, isp);
> 
> diff --git a/drivers/media/platform/omap3isp/isp.h
> b/drivers/media/platform/omap3isp/isp.h index cd3eff4..ce65d3a 100644
> --- a/drivers/media/platform/omap3isp/isp.h
> +++ b/drivers/media/platform/omap3isp/isp.h
> @@ -152,7 +152,6 @@ struct isp_xclk {
>   * @mmio_base_phys: Array with physical L4 bus addresses for ISP register
>   *  regions.
>   * @mmio_size: Array with ISP register regions size in bytes.
> - * @raw_dmamask: Raw DMA mask
>   * @stat_lock: Spinlock for handling statistics
>   * @isp_mutex: Mutex for serializing requests to ISP.
>   * @crashed: Bitmask of crashed entities (indexed by entity ID)
> @@ -190,8 +189,6 @@ struct isp_device {
>   unsigned long mmio_base_phys[OMAP3_ISP_IOMEM_LAST];
>   resource_size_t mmio_size[OMAP3_ISP_IOMEM_LAST];
> 
> - u64 raw_dmamask;
> -
>   /* ISP Obj */
>   spinlock_t stat_lock;   /* common lock for statistic drivers */
>   struct mutex isp_mutex; /* For handling ref_count field */
-- 
Regards,

Laurent Pinchart

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

Re: [PATCH v4] pinctrl: Pass all configs to driver on pin_config_set()

[Laurent Pinchart]

On Tuesday 27 August 2013 11:32:12 Sherman Yin wrote:
> When setting pin configuration in the pinctrl framework, pin_config_set() or
> pin_config_group_set() is called in a loop to set one configuration at a
> time for the specified pin or group.
> 
> This patch 1) removes the loop and 2) changes the API to pass the whole pin
> config array to the driver.  It is now up to the driver to loop through the
> configs.  This allows the driver to potentially combine configs and reduce
> the number of writes to pin config registers.
> 
> All c files changed have been build-tested to verify the change compiles and
> that the corresponding .o is successfully generated.
> 
> Signed-off-by: Sherman Yin 
> Reviewed-by: Christian Daudt 
> Reviewed-by: Matt Porter 
> 
>   drivers/pinctrl/pinconf.c |   42 
>   drivers/pinctrl/pinctrl-tegra.c   |   69 ++--
>   include/linux/pinctrl/pinconf.h   |6 +-
> Reviewed-by: Stephen Warren 
> 
>   On Tegra (Tegra114 Dalmore board, on top of next-20130816),
> Tested-by: Stephen Warren 

For drivers/pinctrl/sh-pfc/pinctrl.c,

Acked-by: Laurent Pinchart 

> ---
> Please refer to the discussion with Linus W. "[PATCH] ARM: Adds pin config
> API to set all configs in one function" here:
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/166567.html
> 
> All c files changed have been build-tested to verify the change compiles and
> that the corresponding .o are successfully generated.
> 
> [v2]  rebased on LinusW's linux-pinctrl.git "devel" branch.  Fixed and
> build-tested pinctrl-sunxi.c
> [v3]  rebased on linux-pinctrl.git:devel as of 2013.08.25. Applied API
> change to new driver pinctrl-palmas.c. Re build-tested all files.
> [v4]  Changed int to unsigned int in sh-pfc/pinctrl.c
> ---
>  drivers/pinctrl/mvebu/pinctrl-mvebu.c |   26 +++--
>  drivers/pinctrl/pinconf.c |   42 
>  drivers/pinctrl/pinctrl-abx500.c  |  187 --
>  drivers/pinctrl/pinctrl-at91.c|   48 +
>  drivers/pinctrl/pinctrl-bcm2835.c |   43 
>  drivers/pinctrl/pinctrl-exynos5440.c  |  113 +++-
>  drivers/pinctrl/pinctrl-falcon.c  |   63 ++-
>  drivers/pinctrl/pinctrl-imx.c |   28 ++---
>  drivers/pinctrl/pinctrl-mxs.c |   91 
>  drivers/pinctrl/pinctrl-nomadik.c |  125 --
>  drivers/pinctrl/pinctrl-palmas.c  |  134 ---
>  drivers/pinctrl/pinctrl-rockchip.c|   57 ++
>  drivers/pinctrl/pinctrl-samsung.c |   17 ++-
>  drivers/pinctrl/pinctrl-single.c  |   33 --
>  drivers/pinctrl/pinctrl-st.c  |   11 +-
>  drivers/pinctrl/pinctrl-sunxi.c   |   77 +++---
>  drivers/pinctrl/pinctrl-tegra.c   |   69 ++--
>  drivers/pinctrl/pinctrl-tz1090-pdc.c  |  135 ++--
>  drivers/pinctrl/pinctrl-tz1090.c  |  140 +---
>  drivers/pinctrl/pinctrl-u300.c|   18 ++--
>  drivers/pinctrl/pinctrl-xway.c|  119 +
>  drivers/pinctrl/sh-pfc/pinctrl.c  |   42 
>  drivers/pinctrl/vt8500/pinctrl-wmt.c  |   54 +-
>  include/linux/pinctrl/pinconf.h   |6 +-
>  24 files changed, 952 insertions(+), 726 deletions(-)

[snip]

> diff --git a/drivers/pinctrl/sh-pfc/pinctrl.c
> b/drivers/pinctrl/sh-pfc/pinctrl.c index 8649ec3..e758af9 100644
> --- a/drivers/pinctrl/sh-pfc/pinctrl.c
> +++ b/drivers/pinctrl/sh-pfc/pinctrl.c
> @@ -529,38 +529,44 @@ static int sh_pfc_pinconf_get(struct pinctrl_dev
> *pctldev, unsigned _pin, }
> 
>  static int sh_pfc_pinconf_set(struct pinctrl_dev *pctldev, unsigned _pin,
> -   unsigned long config)
> +   unsigned long *configs, unsigned num_configs)
>  {
>   struct sh_pfc_pinctrl *pmx = pinctrl_dev_get_drvdata(pctldev);
>   struct sh_pfc *pfc = pmx->pfc;
> - enum pin_config_param param = pinconf_to_config_param(config);
> + enum pin_config_param param;
>   unsigned long flags;
> + unsigned int i;
> 
> - if (!sh_pfc_pinconf_validate(pfc, _pin, param))
> - return -ENOTSUPP;
> + for (i = 0; i < num_configs; i++) {
> + param = pinconf_to_config_param(configs[i]);
> 
> - switch (param) {
> - case PIN_CONFIG_BIAS_PULL_UP:
> - case PIN_CONFIG_BIAS_PULL_DOWN:
> - case PIN_CONFIG_BIAS_DISABLE:
> - if (!pfc->info->ops || !pfc->info->ops->set_bias)
> + if (!sh_pfc_pinconf_validate(pfc, _pin, param))
>   return -ENOTSUPP;
> 
> -  

Re: [PATCH v7] s5k5baf: add camera sensor driver

[Laurent Pinchart]

Hi Andrejz,

On Monday 26 August 2013 14:34:21 Andrzej Hajda wrote:
> On 08/23/2013 02:53 PM, Laurent Pinchart wrote:
> > On Wednesday 21 August 2013 16:41:31 Andrzej Hajda wrote:
> >> Driver for Samsung S5K5BAF UXGA 1/5" 2M CMOS Image Sensor
> >> with embedded SoC ISP.
> >> The driver exposes the sensor as two V4L2 subdevices:
> >> - S5K5BAF-CIS - pure CMOS Image Sensor, fixed 1600x1200 format,
> >>   no controls.
> >> 
> >> - S5K5BAF-ISP - Image Signal Processor, formats up to 1600x1200,
> >>   pre/post ISP cropping, downscaling via selection API, controls.
> >> 
> >> Signed-off-by: Sylwester Nawrocki 
> >> Signed-off-by: Andrzej Hajda 
> >> Signed-off-by: Kyungmin Park 
> >> ---
> >> Hi,
> >> 
> >> This patch incorporates Stephen's suggestions, thanks.
> >> 
> >> Regards
> >> Andrzej
> >> 
> >> v7
> >> - changed description of 'clock-frequency' DT property
> >> 
> >> v6
> >> - endpoint node presence is now optional,
> >> - added asynchronous subdev registration support and clock
> >> 
> >>   handling,
> >> 
> >> - use named gpios in DT bindings
> >> 
> >> v5
> >> - removed hflip/vflip device tree properties
> >> 
> >> v4
> >> - GPL changed to GPLv2,
> >> - bitfields replaced by u8,
> >> - cosmetic changes,
> >> - corrected s_stream flow,
> >> - gpio pins are no longer exported,
> >> - added I2C addresses to subdev names,
> >> - CIS subdev registration postponed after
> >> 
> >>   succesfull HW initialization,
> >> 
> >> - added enums for pads,
> >> - selections are initialized only during probe,
> >> - default resolution changed to 1600x1200,
> >> - state->error pattern removed from few other functions,
> >> - entity link creation moved to registered callback.
> >> 
> >> v3:
> >> - narrowed state->error usage to i2c and power errors,
> >> - private gain controls replaced by red/blue balance user controls,
> >> - added checks to devicetree gpio node parsing
> >> 
> >> v2:
> >> - lower-cased driver name,
> >> - removed underscore from regulator names,
> >> - removed platform data code,
> >> - v4l controls grouped in anonymous structs,
> >> - added s5k5baf_clear_error function,
> >> - private controls definitions moved to uapi header file,
> >> - added v4l2-controls.h reservation for private controls,
> >> - corrected subdev registered/unregistered code,
> >> - .log_status sudbev op set to v4l2 helper,
> >> - moved entity link creation to probe routines,
> >> - added cleanup on error to probe function.
> >> ---
> >> 
> >>  .../devicetree/bindings/media/samsung-s5k5baf.txt  |   59 +
> >>  MAINTAINERS|7 +
> >>  drivers/media/i2c/Kconfig  |7 +
> >>  drivers/media/i2c/Makefile |1 +
> >>  drivers/media/i2c/s5k5baf.c| 2045 ++
> >>  5 files changed, 2119 insertions(+)
> >>  create mode 100644
> >> 
> >> Documentation/devicetree/bindings/media/samsung-s5k5baf.txt create mode
> >> 100644 drivers/media/i2c/s5k5baf.c
> > 
> > [snip]
> > 
> >> diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
> >> new file mode 100644
> >> index 000..f21d9f1
> >> --- /dev/null
> >> +++ b/drivers/media/i2c/s5k5baf.c

[snip]

> >> +static void s5k5baf_write_arr_seq(struct s5k5baf *state, u16 addr,
> >> +u16 count, const u16 *seq)
> >> +{
> >> +  struct i2c_client *c = v4l2_get_subdevdata(&state->sd);
> >> +  u16 buf[count + 1];
> >> +  int ret, n;
> >> +
> >> +  s5k5baf_i2c_write(state, REG_CMDWR_ADDR, addr);
> >> +  if (state->error)
> >> +  return;
> > 
> > I would have a preference for returning an error directly from the write
> > function instead of storing it in state->error, that would be more
> > explicit. The same is true for all read/write functions.
> 
> I have introduced state->error to avoid code bloat. With this 'pattern'
> error is checked in about 10 places in the code, of course without
> scarifying code correctness.
> Replacing this pattern with classic 'return erro

Re: [PATCH v3] pinctrl: Pass all configs to driver on pin_config_set()

[Laurent Pinchart]

spin_lock_irqsave(&pfc->lock, flags);
> - pfc->info->ops->set_bias(pfc, _pin, param);
> - spin_unlock_irqrestore(&pfc->lock, flags);
> + switch (param) {
> + case PIN_CONFIG_BIAS_PULL_UP:
> + case PIN_CONFIG_BIAS_PULL_DOWN:
> + case PIN_CONFIG_BIAS_DISABLE:
> + if (!pfc->info->ops || !pfc->info->ops->set_bias)
> + return -ENOTSUPP;
> 
> - break;
> + spin_lock_irqsave(&pfc->lock, flags);
> + pfc->info->ops->set_bias(pfc, _pin, param);
> + spin_unlock_irqrestore(&pfc->lock, flags);
> 
> - default:
> - return -ENOTSUPP;
> - }
> + break;
> +
> + default:
> + return -ENOTSUPP;
> + }
> + } /* for each config */
> 
>   return 0;
>  }

-- 
Regards,

Laurent Pinchart

--
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 v7] s5k5baf: add camera sensor driver

[Laurent Pinchart]

mf->height = s5k5baf_cis_rect.height;
> + mf->field = V4L2_FIELD_NONE;
> +
> + *v4l2_subdev_get_try_crop(fh, PAD_CIS) = s5k5baf_cis_rect;
> + *v4l2_subdev_get_try_compose(fh, PAD_CIS) = s5k5baf_cis_rect;
> + *v4l2_subdev_get_try_crop(fh, PAD_OUT) = s5k5baf_cis_rect;
> +
> + return 0;
> +}
> +
> +static int s5k5baf_check_fw_revision(struct s5k5baf *state)
> +{
> + u16 api_ver = 0, fw_rev = 0, s_id = 0;
> + int ret;
> +
> + api_ver = s5k5baf_read(state, REG_FW_APIVER);
> + fw_rev = s5k5baf_read(state, REG_FW_REVISION) & 0xff;
> + s_id = s5k5baf_read(state, REG_FW_SENSOR_ID);
> + ret = s5k5baf_clear_error(state);
> + if (ret < 0)
> + return ret;
> +
> + v4l2_info(&state->sd, "FW API=%#x, revision=%#x sensor_id=%#x\n",
> +   api_ver, fw_rev, s_id);
> +
> + if (api_ver == S5K5BAF_FW_APIVER)
> + return 0;

I would have dealt with the error inside the if, but that's up to you.

> + v4l2_err(&state->sd, "FW API version not supported\n");
> + return -ENODEV;
> +}
> +
> +static int s5k5baf_registered(struct v4l2_subdev *sd)
> +{
> + struct s5k5baf *state = to_s5k5baf(sd);
> + int ret;
> +
> + ret = v4l2_device_register_subdev(sd->v4l2_dev, &state->cis_sd);
> + if (ret < 0)
> + v4l2_err(sd, "failed to register subdev %s\n",
> +  state->cis_sd.name);
> + else
> + ret = media_entity_create_link(&state->cis_sd.entity, PAD_CIS,
> +&state->sd.entity, PAD_CIS,
> +MEDIA_LNK_FL_IMMUTABLE |
> +MEDIA_LNK_FL_ENABLED);
> + return ret;
> +}
> +
> +static void s5k5baf_unregistered(struct v4l2_subdev *sd)
> +{
> + struct s5k5baf *state = to_s5k5baf(sd);
> + v4l2_device_unregister_subdev(&state->cis_sd);

The unregistered operation is called from v4l2_device_unregister_subdev(). 
Calling it again will be a no-op, the function will return immediately. You 
can thus get rid of the unregistered operation completely.

Similarly, the registered operation is called from 
v4l2_device_register_subdev(). You can get rid of it as well and just create 
the link in the probe function.

> +}

[snip]

> +static int s5k5baf_parse_device_node(struct s5k5baf *state, struct device
> *dev) +{
> + struct device_node *node = dev->of_node;
> + struct device_node *node_ep;
> + struct v4l2_of_endpoint ep;
> + int ret;
> +
> + if (!node) {
> + dev_err(dev, "no device-tree node provided\n");
> + return -EINVAL;
> + }
> +
> + ret = of_property_read_u32(node, "clock-frequency",
> +&state->mclk_frequency);
> + if (ret < 0) {
> + state->mclk_frequency = S5K5BAF_DEFAULT_MCLK_FREQ;
> + dev_info(dev, "using default %u Hz clock frequency\n",
> +  state->mclk_frequency);
> + }
> +
> + ret = s5k5baf_parse_gpios(state->gpios, dev);
> + if (ret < 0)
> + return ret;
> +
> + node_ep = v4l2_of_get_next_endpoint(node, NULL);
> + if (!node_ep) {
> + /* Default data bus configuration: MIPI CSI-2, 1 data lane. */
> + state->bus_type = V4L2_MBUS_CSI2;
> + state->nlanes = S5K5BAF_DEF_NUM_LANES;
> + dev_warn(dev, "no endpoint defined at node %s\n",
> +  node->full_name);
> + return 0;

Shouldn't this be a fatal error ? If there's no endpoint the sensor isn't part 
of any media pipeline, so it's unusable anyway.

> + }
> +
> + v4l2_of_parse_endpoint(node_ep, &ep);
> + of_node_put(node_ep);
> + state->bus_type = ep.bus_type;
> +
> + if (state->bus_type == V4L2_MBUS_CSI2)
> + state->nlanes = ep.bus.mipi_csi2.num_data_lanes;
> +
> + return 0;
> +}

-- 
Regards,

Laurent Pinchart

--
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 01/15] drivers: phy: add generic PHY framework

[Laurent Pinchart]

Hi Arnd,
On Thursday 25 July 2013 13:00:49 Arnd Bergmann wrote:
> On Thursday 25 July 2013, Laurent Pinchart wrote:
> > On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote:
> > > On Tuesday 23 July 2013, Tomasz Figa wrote:
> > > > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
> > > > > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > > > > > Where would you want to have those phy_address arrays stored?
> > > > > > There are no board files when booting with DT. Not even saying
> > > > > > that you don't need to use any hacky schemes like this when you
> > > > > > have DT that nicely specifies relations between devices.
> > > > > 
> > > > > If everybody agrees DT has a nice scheme for specifying relations
> > > > > between devices, why not use that same scheme in the PHY core?
> > > > 
> > > > It is already used, for cases when consumer device has a DT node
> > > > attached. In non-DT case this kind lookup translates loosely to
> > > > something that is being done in regulator framework - you can't bind
> > > > devices by pointers, because you don't have those pointers, so you
> > > > need to use device names.
> > > 
> > > Sorry for jumping in to the middle of the discussion, but why does a new
> > > framework even bother defining an interface for board files?
> > > 
> > > Can't we just drop any interfaces for platform data passing in the phy
> > > framework and put the burden of adding those to anyone who actually
> > > needs them? All the platforms we are concerned with here (exynos and
> > > omap, plus new platforms) can be booted using DT anyway.
> > 
> > What about non-DT architectures such as MIPS (still widely used in
> > consumer networking equipments from what I've heard) ?
> 
> * Vendors of such equipment have started moving on to ARM (e.g. Broadcom
> bcm47xx)
> * Some of the modern MIPS platforms are now using DT
> * Legacy platforms probably won't migrate to either DT or the generic PHY
> framework
> 
> I'm not saying that we can't support legacy board files with the common PHY
> framework, but I'd expect things to be much easier if we focus on those
> platforms that are actively being worked on for now, to bring an end to the
> pointless API discussion.

Fair enough :-)

-- 
Regards,

Laurent Pinchart

--
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 01/15] drivers: phy: add generic PHY framework

[Laurent Pinchart]

Hi Arnd,

On Wednesday 24 July 2013 20:32:03 Arnd Bergmann wrote:
> On Tuesday 23 July 2013, Tomasz Figa wrote:
> > On Tuesday 23 of July 2013 17:14:20 Alan Stern wrote:
> > > On Tue, 23 Jul 2013, Tomasz Figa wrote:
> > > > Where would you want to have those phy_address arrays stored? There
> > > > are no board files when booting with DT. Not even saying that you
> > > > don't need to use any hacky schemes like this when you have DT that
> > > > nicely specifies relations between devices.
> > > 
> > > If everybody agrees DT has a nice scheme for specifying relations
> > > between devices, why not use that same scheme in the PHY core?
> > 
> > It is already used, for cases when consumer device has a DT node attached.
> > In non-DT case this kind lookup translates loosely to something that is
> > being done in regulator framework - you can't bind devices by pointers,
> > because you don't have those pointers, so you need to use device names.
> 
> Sorry for jumping in to the middle of the discussion, but why does a *new*
> framework even bother defining an interface for board files?
> 
> Can't we just drop any interfaces for platform data passing in the phy
> framework and put the burden of adding those to anyone who actually needs
> them? All the platforms we are concerned with here (exynos and omap, plus
> new platforms) can be booted using DT anyway.

What about non-DT architectures such as MIPS (still widely used in consumer 
networking equipments from what I've heard) ?

-- 
Regards,

Laurent Pinchart

--
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 v6 1/7] media: V4L2: add temporary clock helpers

[Laurent Pinchart]

Hi Guennadi,

On Tuesday 19 March 2013 11:27:56 Guennadi Liakhovetski wrote:
> On Tue, 19 Mar 2013, Sylwester Nawrocki wrote:
> > >>> +   if (!IS_ERR(clk)&&  !try_module_get(clk->ops->owner))
> > >>> +   clk = ERR_PTR(-ENODEV);
> > >>> +   mutex_unlock(&clk_lock);
> > >>> +
> > >>> +   if (!IS_ERR(clk)) {
> > >>> +   clk->subdev = sd;
> > >> 
> > >> Why is this needed ? It seems a strange addition that might potentially
> > >> make transition to the common clocks API more difficult.
> > > 
> > > We got rid of the v4l2_clk_bind() function and the .bind() callback. Now
> > > I need a pointer to subdevice _before_ v4l2_clk_register() (former
> > > v4l2_clk_bound()), that's why I have to store it here.
> > 
> > Hmm, sorry, I'm not following. How can we store a subdev pointer in the
> > clock data structure that has not been registered yet and thus cannot be
> > found with v4l2_clk_find() ?
> 
> sorry, I meant v4l2_async_subdev_register(), not v4l2_clk_register(), my
> mistake. And I meant v4l2_async_subdev_bind(), v4l2_async_subdev_unbind().
> Before we had in the subdev driver (see imx074 example)
> 
>   /* Tell the bridge the subdevice is about to bind */
>   v4l2_async_subdev_bind();
> 
>   /* get a clock */
>   clk = v4l2_clk_get();
>   if (IS_ERR(clk))
>   return -EPROBE_DEFER;
> 
>   /*
>* enable the clock - this needs a subdev pointer, that we passed
>* to the bridge with v4l2_async_subdev_bind() above
>*/
>   v4l2_clk_enable(clk);
>   do_probe();
>   v4l2_clk_disable(clk);
> 
>   /* inform the bridge: binding successful */
>   v4l2_async_subdev_bound();
> 
> Now we have just
> 
>   /* get a clock */
>   clk = v4l2_clk_get();
>   if (IS_ERR(clk))
>   return -EPROBE_DEFER;
> 
>   /*
>* enable the clock - this needs a subdev pointer, that we stored
>* in the clock object for the bridge driver to use with
>* v4l2_clk_get() above
>*/
>   v4l2_clk_enable(clk);
>   do_probe();
>   v4l2_clk_disable(clk);

I'm sorry, but I still don't understand why you need a pointer to the subdev 
in the clock provider implementation of v4l2_clk_enable/disable() :-)

>   /* inform the bridge: binding successful */
>   v4l2_async_subdev_bound();

-- 
Regards,

Laurent Pinchart

--
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 v6 1/7] media: V4L2: add temporary clock helpers

[Laurent Pinchart]

Hello,

On Tuesday 19 March 2013 10:52:29 Sylwester Nawrocki wrote:
> On 03/19/2013 08:32 AM, Guennadi Liakhovetski wrote:
> > On Mon, 18 Mar 2013, Sylwester Nawrocki wrote:
> >> On 03/15/2013 10:27 PM, Guennadi Liakhovetski wrote:
> [...]
> 
> >>> diff --git a/drivers/media/v4l2-core/v4l2-clk.c
> >>> b/drivers/media/v4l2-core/v4l2-clk.c
> >>> new file mode 100644
> >>> index 000..3505972
> >>> --- /dev/null
> >>> +++ b/drivers/media/v4l2-core/v4l2-clk.c

[snip]

> >>> +static struct v4l2_clk *v4l2_clk_find(const struct v4l2_subdev *sd,
> >>> +   const char *dev_id, const char *id)
> >>> +{
> >>> + struct v4l2_clk *clk;
> >>> +
> >>> + list_for_each_entry(clk,&clk_list, list) {
> >>> + if (!sd || !(sd->flags&  V4L2_SUBDEV_FL_IS_I2C)) {
> >>> + if (strcmp(dev_id, clk->dev_id))
> >>> + continue;
> >>> + } else {
> >>> + char *i2c = strstr(dev_id, clk->dev_id);
> >>> + if (!i2c || i2c == dev_id || *(i2c - 1) != ' ')
> >>> + continue;
> >>> + }
> >>> +
> >>> + if (!id || !clk->id || !strcmp(clk->id, id))
> >>> + return clk;
> >>> + }
> >>> +
> >>> + return ERR_PTR(-ENODEV);
> >>> +}
> >>> +
> >>> +struct v4l2_clk *v4l2_clk_get(struct v4l2_subdev *sd, const char *id)
> >>> +{
> >>> + struct v4l2_clk *clk;
> >>> +
> >>> + mutex_lock(&clk_lock);
> >>> + clk = v4l2_clk_find(sd, sd->name, id);
> >> 
> >> Couldn't we just pass the I2C client's struct device name to this
> >> function ?
> > 
> > Certainly not. This is a part of the generic V4L2 clock API, it's not I2C
> > specific.
> 
> I have been thinking about something like dev_name(sd->dev), but struct
> v4l2_subdev doesn't have struct device associated with it.

But the caller of v4l2_clk_get() will have a struct device * available, so I 
think it would make sense to pass a struct device * to v4l2_clk_get() and call 
dev_name() on it internally. Clocks would be registered with the device ID as 
well. This requires knowledge of the clock user device in the clock provider, 
but no knowledge of the clock user module name.
 
> >> And if the host driver that registers a clock for its sub-device knows
> >> the type of device (I2C, SPI client, etc.) why we need to even bother
> >> with checking the subdev/bus type in v4l2_clk_find() function above, when
> >> the host could properly format dev_id when it registers a clock ?
> > 
> > This has been discussed. The host doesn't know the name of the I2C driver,
> > that would attach to this subdevice at the time, it registers the clock.
> > This is the easiest way to oversome this problem.
> 
> OK, thanks for reminding. It would be probably much easier to associate
> the clock with struct device, not with subdev driver. Devices have more
> clear naming rules (at last I2C, SPI clients). And most host drivers
> already have information about I2C bus id, just I2C slave address would
> need to be passed to the host driver so it can register a clock for its
> subdev.
> 
> >> Then the subdev would just pass its struct device pointer to this API to
> >> find its clock. What am I missing here ?
> > I don't think there's a 1-to-1 correspondence between devices and V4L2
> > subdevices.
> 
> I would expect at least a subdev that needs a clock to have struct device
> associated with it. It would be also much easier this way to use generic
> clocks API in the device tree instantiated systems.

I agree. Let's not overdesign the v4l2-clock API to support clock users 
without a struct device. This is a transitional API only after all.

> >>> + if (!IS_ERR(clk)&&  !try_module_get(clk->ops->owner))
> >>> + clk = ERR_PTR(-ENODEV);
> >>> + mutex_unlock(&clk_lock);
> >>> +
> >>> + if (!IS_ERR(clk)) {
> >>> + clk->subdev = sd;
> >> 
> >> Why is this needed ? It seems a strange addition that might potentially
> >> make transition to the common clocks API more difficult.
> > 
> > We got rid of the v4l2_clk_bind() function and the .bind() callback. Now I
> > need a pointer to subdevice _before_ v4l2_clk_register() (former
> > v4l2_clk_bound()), that's why I have to store it here.
> 
> Hmm, sorry, I'm not following. How can we store a subdev pointer in the
> clock data structure that has not been registered yet and thus cannot be
> found with v4l2_clk_find() ?
> 
> >>> + atomic_inc(&clk->use_count);
> >>> + }
> >>> +
> >>> + return clk;
> >>> +}
> >>> +EXPORT_SYMBOL(v4l2_clk_get);

-- 
Regards,

Laurent Pinchart

--
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 PATCH 0/4] Common Display Framework-TF

[Laurent Pinchart]

e moment, as I still have to think
>a bit about locking the entity in a way where removing it by user request
>is still possible.

One of the main locking issues here are cross-references. The display entity 
holds a reference to the video source (for video operations), and the display 
controller driver holds a reference to the display entity (for control 
operations), resulting in a cross-references lock situation. One possible 
solution would be to first unbind the display entity device from its driver to 
break the cycle.

>  - Dropped any panels and chips that I can't test.
> 
>They are irrelevant for this series, so there is no point in including
>them.
> 
>  - Added Exynos DSI video source driver.
> 
>This is a new driver for the DSI controller found in Exynos SoCs. It
>still needs some work, but in current state can be considered an example
>of DSI video source implementation for my version of CDF.
> 
>  - Added Samsung S6E8AX0 DSI panel driver.
> 
>This is the old Exynos-specific driver, just migrated to CDF and with
>some hacks to provide control over entity state to userspace using
>lcd device. However it can be used to demonstrate video source ops in
>use.
> 
> Feel free to comment as much as you can.
> 
> Tomasz Figa (4):
>   video: add display-core
>   video: add makefile & kconfig
>   video: display: Add exynos-dsi video source driver
>   video: display: Add Samsung s6e8ax0 display panel driver
> 
>  drivers/video/Kconfig |1 +
>  drivers/video/Makefile|1 +
>  drivers/video/display/Kconfig |   16 +
>  drivers/video/display/Makefile|3 +
>  drivers/video/display/display-core.c  |  295 +++
>  drivers/video/display/panel-s6e8ax0.c | 1027 ++
>  drivers/video/display/source-exynos_dsi.c | 1313 ++
>  include/video/display.h   |  230 +
>  include/video/exynos_dsi.h|   41 +
>  include/video/panel-s6e8ax0.h |   41 +
>  10 files changed, 2968 insertions(+)
>  create mode 100644 drivers/video/display/Kconfig
>  create mode 100644 drivers/video/display/Makefile
>  create mode 100644 drivers/video/display/display-core.c
>  create mode 100644 drivers/video/display/panel-s6e8ax0.c
>  create mode 100644 drivers/video/display/source-exynos_dsi.c
>  create mode 100644 include/video/display.h
>  create mode 100644 include/video/exynos_dsi.h
>  create mode 100644 include/video/panel-s6e8ax0.h
-- 
Regards,

Laurent Pinchart
--
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 RFC v4 01/14] [media] Add common video interfaces OF bindings documentation

[Laurent Pinchart]

Hi Sylwester,

On Thursday 24 January 2013 19:30:10 Sylwester Nawrocki wrote:
> On 01/24/2013 11:16 AM, Laurent Pinchart wrote:
> [...]
> 
> >> +Data interfaces on all video devices are described by their child 'port'
> >> +nodes. Configuration of a port depends on other devices participating in
> >> +the data transfer and is described by 'endpoint' subnodes.
> >> +
> >> +dev {
> >> +  #address-cells = <1>;
> >> +  #size-cells = <0>;
> >> +  port@0 {
> >> +  endpoint@0 { ... };
> >> +  endpoint@1 { ... };
> >> +  };
> >> +  port@1 { ... };
> >> +};
> >> +
> >> +If a port can be configured to work with more than one other device on
> >> +the same bus, an 'endpoint' child node must be provided for each of
> >> +them. If more than one port is present in a device node or there is more
> >> +than one endpoint at a port, a common scheme, using '#address-cells',
> >> +'#size-cells' and 'reg' properties is used.
> > 
> > Wouldn't this cause problems if the device has both video ports and a
> > child bus ? Using #address-cells and #size-cells for the video ports would
> > prevent the child bus from being handled in the usual way.
> 
> Indeed, it looks like a serious issue in these bindings.
> 
> > A possible solution would be to number ports with a dash instead of a @,
> > as done in pinctrl for instance. We would then get
> > 
> > port-0 {
> > endpoint-0 { ... };
> > endpoint-1 { ... };
> > };
> > port-1 { ... };
> 
> Sounds like a good alternative, I can't think of any better solution at the
> moment.
> 
> >> +Two 'endpoint' nodes are linked with each other through their
> >> +'remote-endpoint' phandles.  An endpoint subnode of a device contains
> >> +all properties needed for configuration of this device for data exchange
> >> +with the other device.  In most cases properties at the peer 'endpoint'
> >> +nodes will be identical, however they might need to be different when
> >> +there is any signal modifications on the bus between two devices, e.g.
> >> +there are logic signal inverters on the lines.
> >> +
> >> +Required properties
> >> +---
> >> +
> >> +If there is more than one 'port' or more than one 'endpoint' node
> >> following +properties are required in relevant parent node:
> >> +
> >> +- #address-cells : number of cells required to define port number,
> >> should be 1.
> >> +- #size-cells: should be zero.
> > 
> > I wonder if we should specify whether a port is a data sink or data
> > source. A source can be connected to multiple sinks at the same time, but
> > a sink can only be connected to a single source. If we want to perform
> > automatic sanity checks in the core knowing the direction might help.
> 
> Multiple sources can be linked to a single sink, but only one link can be
> active at any time.
> 
> So I'm not sure if knowing if a DT port is a data source or data sink would
> let us to validate device tree structure statically in general.
>
> Such source/sink property could be useful later at runtime, when data
> pipeline is set up for streaming.

Yes, I was mostly thinking about runtime.

> How do you think this could be represented ? By just having boolean
> properties like: 'source' and 'sink' in the port nodes ? Or perhaps in the
> endpoint nodes, since some devices might be bidirectional ? I don't recall
> any at the moment though.

Source and sink properties would do. We could also use a direction property 
that could take sink, source and bidirectional values, but that might be more 
complex.

I don't think we will have bidirectional link (as that would most probably 
involve a very different kind of bus, and thus new bindings).

> >> +Optional endpoint properties
> >> +
> >> +
> >> +- remote-endpoint: phandle to an 'endpoint' subnode of the other device
> >> +  node.
> >> +- slave-mode: a boolean property, run the link in slave mode.
> >> +  Default is master mode.
> > 
> > What are master and slave modes ? It might be worth it describing them.
> 
> This was originally proposed by Guennadi, I think he knows exactly what's
> the meaning of this property. I'll dig into relevant documentation to
> find out and provide more detail

Re: [PATCH RFC v4 01/14] [media] Add common video interfaces OF bindings documentation

[Laurent Pinchart]

clocks = <&mclk 0>;
> + clock-names = "xclk";
> +
> + port {
> + /* With 1 endpoint per port no need in 
> addresses. */

s/in/for/ ?

> + ov772x_1_1: endpoint {
> + bus-width = <8>;
> + remote-endpoint = <&ceu0_1>;
> + hsync-active = <1>;
> + vsync-active = <0>; /* Who came up with 
> an
> +inverter here 
> ?... */
> + data-active = <1>;
> + pclk-sample = <1>;
> + };
> + };
> + };
> +
> + imx074: camera@0x1a {
> + compatible = "sony,imx074";
> + reg = <0x1a>;
> + vddio-supply = <®ulator1>;
> + vddcore-supply = <®ulator2>;
> +
> + clock-frequency = <3000>;   /* Shared clock with 
> ov772x_1 */
> + clocks = <&mclk 0>;
> + clock-names = "sysclk"; /* Assuming this is the
> +name in the 
> datasheet */
> + port {
> + imx074_1: endpoint {
> + clock-lanes = <0>;
> + data-lanes = <1>, <2>;
> + remote-endpoint = <&csi2_1>;
> + };
> + };
> + };
> + };
> +
> + csi2: csi2@0xffc9 {
> + compatible = "renesas,sh-mobile-csi2";
> + reg = <0xffc9 0x1000>;
> + interrupts = <0x17a0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@1 {
> + compatible = "renesas,csi2c";   /* One of CSI2I and 
> CSI2C. */
> + reg = <1>;  /* CSI-2 PHY #1 of 2: 
> PHY_S,
> +PHY_M has port 
> address 0,
> +is unused. */
> + csi2_1: endpoint {
> + clock-lanes = <0>;
> + data-lanes = <2>, <1>;
> + remote-endpoint = <&imx074_1>;
> + };
> + };
> + port@2 {
> + reg = <2>;  /* port 2: link to the 
> CEU */
> +
> + csi2_2: endpoint {
> + immutable;
> + remote-endpoint = <&ceu0_0>;
> + };
> + };
> + };

-- 
Regards,

Laurent Pinchart

--
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 V6 2/2] video: drm: exynos: Add device tree support

[Laurent Pinchart]

On Monday 24 September 2012 21:35:46 Inki Dae wrote:
> 2012/9/22 Stephen Warren :
> > On 09/21/2012 01:22 AM, Inki Dae wrote:
> >> 2012/9/21 Stephen Warren :
> >>> On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote:
> >>>> This patch adds device tree based discovery support for exynos DRM-FIMD
> >>>> driver which includes driver modification to handle platform data in
> >>>> both the cases with DT and non-DT, Also adds the documentation for
> >>>> bindings.
> >>>> 
> >>>> diff --git a/Documentation/devicetree/bindings/drm/exynos/fimd.txt
> >>>> b/Documentation/devicetree/bindings/drm/exynos/fimd.txt>>> 
> >>> ...
> >>> 
> >>>> + - samsung,fimd-display: This property should specify the phandle of
> >>>> the
> >>>> +   display device node which holds the video interface timing with the
> >>>> +   below mentioned properties.
> >>>> +
> >>>> +   - lcd-htiming: Specifies the horizontal timing for the overlay. The
> >>>> + horizontal timing includes four parameters in the following
> >>>> order.
> >>>> +
> >>>> + - horizontal back porch (in number of lcd clocks)
> >>>> + - horizontal front porch (in number of lcd clocks)
> >>>> + - hsync pulse width (in number of lcd clocks)
> >>>> + - Display panels X resolution.
> >>>> +
> >>>> +   - lcd-vtiming: Specifies the vertical timing for the overlay. The
> >>>> + vertical timing includes four parameters in the following order.
> >>>> +
> >>>> + - vertical back porch (in number of lcd lines)
> >>>> + - vertical front porch (in number of lcd lines)
> >>>> + - vsync pulse width (in number of lcd clocks)
> >>>> + - Display panels Y resolution.
> >>> 
> >>> Should this not use the new videomode timings that are under discussion
> >>> at:
> >>> 
> >>> http://lists.freedesktop.org/archives/dri-devel/2012-July/024875.html
> >> 
> >> ok, I agree with you. then the videomode helper is going to be merged
> >> to mainline(3.6)? if so, this patch should be reworked based on the
> >> videomode helper.
> > 
> > I think the videomode helpers would be merged for 3.7 at the very
> > earliest; 3.6 is cooked already. Given there are still some comments on
> > the binding, perhaps it won't happen until 3.8, but it'd be best to ask
> > on that thread so that people more directly involved with the status can
> > answer.
> 
> as I mentioned before, it's better to use videomode helper instead but
> for this, we should wait for that the videomode helper are merged to
> mainline so I think it's better to merge it as is and then modify it
> for videomode helper to be used later.

Aren't DT bindings considered as an ABI, and required to be supported more or 
less forever ? If you merge this DT binding you'll have to keep supporting it. 
That's why DT bindings should not be rushed in.

-- 
Regards,

Laurent Pinchart

--
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/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation

[Laurent Pinchart]

Hi Sylwester,

On Tuesday 31 July 2012 15:28:52 Sylwester Nawrocki wrote:
> On 07/31/2012 02:59 PM, Guennadi Liakhovetski wrote:
> > On Tue, 31 Jul 2012, Sylwester Nawrocki wrote:
> >> On 07/31/2012 02:26 PM, Guennadi Liakhovetski wrote:
> >>>>>> But should we allow host probe() to succeed if the sensor isn't
> >>>>>> present ?
> >>>>> 
> >>>>> I think we should, yes. The host hardware is there and functional -
> >>>>> whether or not all or some of the clients are failing. Theoretically
> >>>>> clients can also be hot-plugged. Whether and how many video device
> >>>>> nodes
> >>>>> we create, that's a different question.
> >>>> 
> >>>> I think I can agree with you on this (although I could change my mind
> >>>> if this architecture turns out to result in unsolvable technical
> >>>> issues). That will involve a lot of work though.
> >>> 
> >>> There's however at least one more gotcha that occurs to me with this
> >>> approach: if clients fail to probe, how do we find out about that and
> >>> turn
> >>> clocks back off? One improvement to turning clocks on immediately in
> >> 
> >> Hmm, wouldn't it be the client that turns a clock on/off when needed ?
> >> I'd like to preserve this functionality, so client drivers can have
> >> full control on the power up/down sequences. While we are trying to
> >> improve the current situation...
> > 
> > Eventually, when the clock API is available - yes, the client would just
> > call clk_enable() / clk_disable(). But for now isn't it host's job to do
> > that? Or you want to add new API for that?
> 
> Indeed, looking at existing drivers, the clocks' handling is now mostly
> done in the host drivers. Only the omap3isp appears to do the right thing,
> i.e. delegating control over the clock to client drivers, but it does it
> with platform_data callbacks.
> 
> We've already discussed adding a new API for that,
> http://www.mail-archive.com/linux-media@vger.kernel.org/msg35359.html
> 
> However using common clock API and binding a clock to client device
> (either DT based or not) sounds like a best approach to me.
> 
> Waiting for the common clock API to be generally available maybe we
> could add some clock ops at the v4l2_device ? Just a humble suggestion,
> I'm not sure whether it is really good and needed or not.

I'm fine with that (or something similar) as an interim solution.

-- 
Regards,

Laurent Pinchart

--
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/PATCH 02/13] media: s5p-csis: Add device tree support

[Laurent Pinchart]

Hi Sylwester,

On Tuesday 31 July 2012 14:38:35 Sylwester Nawrocki wrote:
> On 07/31/2012 01:05 PM, Laurent Pinchart wrote:
> >>>>> What about CSI receivers that can reroute the lanes internally ? We
> >>>>> would need to specify lane indices for each lane then, maybe with
> >>>>> something like
> >>>>> 
> >>>>> clock-lane =<0>;
> >>>>> data-lanes =<2 3 1>;
> >>>> 
> >>>> Sounds good to me. And the clock-lane could be made optional, as not
> >>>> all devices would need it.
> >>>> 
> >>>> However, as far as I can see, there is currently no generic API for
> >>>> handling this kind of data structure. E.g. number of cells for the
> >>>> "interrupts" property is specified with an additional
> >>>> "#interrupt-cells" property.
> >>>> 
> >>>> It would have been much easier to handle something like:
> >>>> 
> >>>> data-lanes = <2>, <3>, <1>;
> >>>> 
> >>>> i.e. an array of the lane indexes.
> >>> 
> >>> I'm fine with that.
> >> 
> >> ...on a second thought: shouldn't this be handled by pinctrl? Or is it
> >> some CSI-2 module internal lane switching, not the global SoC pin
> >> function configuration?
> > 
> > On the hardware I came across, it's handled by the CSI2 receiver, not the
> > SoC pinmux feature.
> 
> Same here. Is there any hardware known to mux those MIPI-CSI
> D-PHY high speed differential signals with general purpose IO pins ?
> 
> Or are there mostly dedicated pins used ?

The OMAP3 multiplexes the CSI pins with other functions.

> However, if there are cases the lane configuration is done solely at CSI2
> receiver level, there seems little point in involving the pinctrl API.

The OMAP3 handles lane routing in the CSI2 receiver.

-- 
Regards,

Laurent Pinchart

--
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/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation

[Laurent Pinchart]

Hi Guennadi,

On Tuesday 31 July 2012 13:29:55 Guennadi Liakhovetski wrote:
> On Tue, 31 Jul 2012, Laurent Pinchart wrote:
> > On Tuesday 31 July 2012 13:14:13 Guennadi Liakhovetski wrote:
> > > On Tue, 31 Jul 2012, Laurent Pinchart wrote:
> > > > On Tuesday 31 July 2012 11:56:44 Guennadi Liakhovetski wrote:
> > > > > On Thu, 26 Jul 2012, Laurent Pinchart wrote:
> > > > > > On Wednesday 18 July 2012 11:18:33 Sylwester Nawrocki wrote:
> > > > > > > On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote:
> > > > > > > > On Fri, 25 May 2012, Sylwester Nawrocki wrote:
> > > > > > > >> The driver initializes all board related properties except
> > > > > > > >> the s_power() callback to board code. The platforms that
> > > > > > > >> require this callback are not supported by this driver yet
> > > > > > > >> for CONFIG_OF=y.
> > > > > > > >> 
> > > > > > > >> Signed-off-by: Sylwester Nawrocki
> > > > > > > >> Signed-off-by: Bartlomiej
> > > > > > > >> Zolnierkiewicz
> > > > > > > >> Signed-off-by: Kyungmin Park
> > > > > > > >> ---
> > > > > > > >> 
> > > > > > > >>   .../bindings/camera/samsung-s5k6aafx.txt   |   57
> > > > > > > >>   +
> > > > > > > >>   drivers/media/video/s5k6aa.c   |  129
> > > > > > > >>   ++-- 2 files changed, 146 insertions(+), 40
> > > > > > > >>   deletions(-)
> > > > > > > >>   create mode 100644
> > > > > > > >>   Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t
> > > > > > > >>   xt>>
> > > > > > > >> 
> > > > > > > >> diff --git
> > > > > > > >> a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t
> > > > > > > >> xt
> > > > > > > >> b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t
> > > > > > > >> xt
> > > > > > > >> new
> > > > > > > >> file
> > > > > > > >> mode 100644
> > > > > > > >> index 000..6685a9c
> > > > > > > >> --- /dev/null
> > > > > > > >> +++
> > > > > > > >> b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.t
> > > > > > > >> xt
> > > > > > > >> @@ -0,0 +1,57 @@
> > > > > > > >> +Samsung S5K6AAFX camera sensor
> > > > > > > >> +--
> > > > > > > >> +
> > > > > > > >> +Required properties:
> > > > > > > >> +
> > > > > > > >> +- compatible : "samsung,s5k6aafx";
> > > > > > > >> +- reg : base address of the device on I2C bus;
> > > > > > > > 
> > > > > > > > You said you ended up putting your sensors outside of I2C
> > > > > > > > busses, is this one of changes, that are present in your git-
> > > > > > > > tree but not in this series?
> > > > > > > 
> > > > > > > No, I must have been not clear enough on that. Our idea was to
> > > > > > > keep I2C slave device nodes as an I2C controller's child nodes,
> > > > > > > according to the current convention. The 'sensor' nodes (the
> > > > > > > 'camera''s children) would only contain a phandle to a
> > > > > > > respective I2C slave node.
> > > > > > > 
> > > > > > > This implies that we cannot access I2C bus in I2C client's
> > > > > > > device probe() callback. An actual H/W access could begin only
> > > > > > > from within and after invocation of v4l2_subdev .registered
> > > > > > > callback..
> > > > > > 
> > > > > > That's how I've envisioned the DT bindings for sensors as well,
> > > > > > this sounds good. The real challenge will be to get hold of the
> > > &g

Re: [RFC/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation

[Laurent Pinchart]

Hi Guennadi,

On Tuesday 31 July 2012 13:14:13 Guennadi Liakhovetski wrote:
> On Tue, 31 Jul 2012, Laurent Pinchart wrote:
> > On Tuesday 31 July 2012 11:56:44 Guennadi Liakhovetski wrote:
> > > On Thu, 26 Jul 2012, Laurent Pinchart wrote:
> > > > On Wednesday 18 July 2012 11:18:33 Sylwester Nawrocki wrote:
> > > > > On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote:
> > > > > > On Fri, 25 May 2012, Sylwester Nawrocki wrote:
> > > > > >> The driver initializes all board related properties except the
> > > > > >> s_power() callback to board code. The platforms that require this
> > > > > >> callback are not supported by this driver yet for CONFIG_OF=y.
> > > > > >> 
> > > > > >> Signed-off-by: Sylwester Nawrocki
> > > > > >> Signed-off-by: Bartlomiej
> > > > > >> Zolnierkiewicz
> > > > > >> Signed-off-by: Kyungmin Park
> > > > > >> ---
> > > > > >> 
> > > > > >>   .../bindings/camera/samsung-s5k6aafx.txt   |   57
> > > > > >>   +
> > > > > >>   drivers/media/video/s5k6aa.c   |  129
> > > > > >>   ++-- 2 files changed, 146 insertions(+), 40
> > > > > >>   deletions(-)
> > > > > >>   create mode 100644
> > > > > >>   Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt>>
> > > > > >> 
> > > > > >> diff --git
> > > > > >> a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt
> > > > > >> b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt
> > > > > >> new
> > > > > >> file
> > > > > >> mode 100644
> > > > > >> index 000..6685a9c
> > > > > >> --- /dev/null
> > > > > >> +++
> > > > > >> b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt
> > > > > >> @@ -0,0 +1,57 @@
> > > > > >> +Samsung S5K6AAFX camera sensor
> > > > > >> +--
> > > > > >> +
> > > > > >> +Required properties:
> > > > > >> +
> > > > > >> +- compatible : "samsung,s5k6aafx";
> > > > > >> +- reg : base address of the device on I2C bus;
> > > > > > 
> > > > > > You said you ended up putting your sensors outside of I2C busses,
> > > > > > is this one of changes, that are present in your git-tree but not
> > > > > > in this series?
> > > > > 
> > > > > No, I must have been not clear enough on that. Our idea was to keep
> > > > > I2C slave device nodes as an I2C controller's child nodes, according
> > > > > to the current convention.
> > > > > The 'sensor' nodes (the 'camera''s children) would only contain a
> > > > > phandle to a respective I2C slave node.
> > > > > 
> > > > > This implies that we cannot access I2C bus in I2C client's device
> > > > > probe() callback. An actual H/W access could begin only from within
> > > > > and after invocation of v4l2_subdev .registered callback..
> > > > 
> > > > That's how I've envisioned the DT bindings for sensors as well, this
> > > > sounds good. The real challenge will be to get hold of the subdev to
> > > > register it without race conditions.
> > > 
> > > Hrm... That's how early pre-subdev versions of soc-camera used to work,
> > > that's where all the _video_probe() functions come from. But
> > > then we switched to dynamic i2c device registration. Do we want to
> > > switch all drivers back now?... Couldn't we "temporarily" use references
> > > from subdevs to hosts until the clock API is available?
> > 
> > I don't think that requires a reference from subdevs to hosts in the DT.
> > The subdev will need the host to be probed before a clock can be
> > available so you won't be able to access the hardware in the probe()
> > function in the generic case. You will need to wait until the
> > registered() subdev operation is called, at which point the host can be
> > accessed through the v4l2_device.
> 
> Sure, I understand, but that's exactly what we wanted to avoid -
> succeeding client's i2c .probe() without even touching the hardware.

But should we allow host probe() to succeed if the sensor isn't present ?

-- 
Regards,

Laurent Pinchart

--
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/PATCH 02/13] media: s5p-csis: Add device tree support

[Laurent Pinchart]

Hi Guennadi,

On Tuesday 31 July 2012 12:58:50 Guennadi Liakhovetski wrote:
> On Fri, 27 Jul 2012, Laurent Pinchart wrote:
> > On Thursday 26 July 2012 21:51:30 Sylwester Nawrocki wrote:
> > > On 07/26/2012 04:38 PM, Laurent Pinchart wrote:
> > > >>>> --- /dev/null
> > > >>>> +++ b/Documentation/devicetree/bindings/video/mipi.txt
> > > >>>> @@ -0,0 +1,5 @@
> > > >>>> +Common properties of MIPI-CSI1 and MIPI-CSI2 receivers and
> > > >>>> transmitters
> > > >>>> +
> > > >>>> + - data-lanes : number of differential data lanes wired and
> > > >>>> actively
> > > >>>> used in
> > > >>>> +communication between the transmitter and the receiver, 
> > > >>>> this
> > > >>>> +excludes the clock lane;
> > > >>> 
> > > >>> Wouldn't it be better to use the standard "bus-width" DT property?
> > > >> 
> > > >> I can't see any problems with using "bus-width". It seems sufficient
> > > >> and could indeed be better, without a need to invent new MIPI-CSI
> > > >> specific names. That was my first RFC on that and my perspective
> > > >> wasn't probably broad enough. :)
> > > > 
> > > > What about CSI receivers that can reroute the lanes internally ? We
> > > > would
> > > > need to specify lane indices for each lane then, maybe with something
> > > > like
> > > > 
> > > > clock-lane =<0>;
> > > > data-lanes =<2 3 1>;
> > > 
> > > Sounds good to me. And the clock-lane could be made optional, as not all
> > > devices would need it.
> > > 
> > > However, as far as I can see, there is currently no generic API for
> > > handling this kind of data structure. E.g. number of cells for the
> > > "interrupts" property is specified with an additional
> > > "#interrupt-cells" property.
> > > 
> > > It would have been much easier to handle something like:
> > > 
> > > data-lanes = <2>, <3>, <1>;
> > > 
> > > i.e. an array of the lane indexes.
> > 
> > I'm fine with that.
> 
> ...on a second thought: shouldn't this be handled by pinctrl? Or is it
> some CSI-2 module internal lane switching, not the global SoC pin function
> configuration?

On the hardware I came across, it's handled by the CSI2 receiver, not the SoC 
pinmux feature.

-- 
Regards,

Laurent Pinchart

--
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/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation

[Laurent Pinchart]

Hi Guennadi,

On Tuesday 31 July 2012 11:56:44 Guennadi Liakhovetski wrote:
> On Thu, 26 Jul 2012, Laurent Pinchart wrote:
> > On Wednesday 18 July 2012 11:18:33 Sylwester Nawrocki wrote:
> > > On 07/16/2012 11:42 AM, Guennadi Liakhovetski wrote:
> > > > On Fri, 25 May 2012, Sylwester Nawrocki wrote:
> > > >> The driver initializes all board related properties except the
> > > >> s_power() callback to board code. The platforms that require this
> > > >> callback are not supported by this driver yet for CONFIG_OF=y.
> > > >> 
> > > >> Signed-off-by: Sylwester Nawrocki
> > > >> Signed-off-by: Bartlomiej Zolnierkiewicz
> > > >> Signed-off-by: Kyungmin Park
> > > >> ---
> > > >> 
> > > >>   .../bindings/camera/samsung-s5k6aafx.txt   |   57 +
> > > >>   drivers/media/video/s5k6aa.c   |  129
> > > >>   ++-- 2 files changed, 146 insertions(+), 40
> > > >>   deletions(-)
> > > >>   create mode 100644
> > > >>   Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt>>
> > > >> 
> > > >> diff --git
> > > >> a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt
> > > >> b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new
> > > >> file
> > > >> mode 100644
> > > >> index 000..6685a9c
> > > >> --- /dev/null
> > > >> +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt
> > > >> @@ -0,0 +1,57 @@
> > > >> +Samsung S5K6AAFX camera sensor
> > > >> +--
> > > >> +
> > > >> +Required properties:
> > > >> +
> > > >> +- compatible : "samsung,s5k6aafx";
> > > >> +- reg : base address of the device on I2C bus;
> > > > 
> > > > You said you ended up putting your sensors outside of I2C busses, is
> > > > this
> > > > one of changes, that are present in your git-tree but not in this
> > > > series?
> > > 
> > > No, I must have been not clear enough on that. Our idea was to keep
> > > I2C slave device nodes as an I2C controller's child nodes, according
> > > to the current convention.
> > > The 'sensor' nodes (the 'camera''s children) would only contain a
> > > phandle to a respective I2C slave node.
> > > 
> > > This implies that we cannot access I2C bus in I2C client's device
> > > probe() callback. An actual H/W access could begin only from within and
> > > after invocation of v4l2_subdev .registered callback..
> > 
> > That's how I've envisioned the DT bindings for sensors as well, this
> > sounds good. The real challenge will be to get hold of the subdev to
> > register it without race conditions.
> 
> Hrm... That's how early pre-subdev versions of soc-camera used to work,
> that's where all the _video_probe() functions come from. But then
> we switched to dynamic i2c device registration. Do we want to switch all
> drivers back now?... Couldn't we "temporarily" use references from subdevs
> to hosts until the clock API is available?

I don't think that requires a reference from subdevs to hosts in the DT. The 
subdev will need the host to be probed before a clock can be available so you 
won't be able to access the hardware in the probe() function in the generic 
case. You will need to wait until the registered() subdev operation is called, 
at which point the host can be accessed through the v4l2_device.

-- 
Regards,

Laurent Pinchart

--
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/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation

[Laurent Pinchart]

Hi Sylwester,

On Thursday 26 July 2012 22:39:31 Sylwester Nawrocki wrote:
> On 07/26/2012 05:21 PM, Laurent Pinchart wrote:
> > On Friday 25 May 2012 21:52:48 Sylwester Nawrocki wrote:
> >> The driver initializes all board related properties except the s_power()
> >> callback to board code. The platforms that require this callback are not
> >> supported by this driver yet for CONFIG_OF=y.
> >> 
> >> Signed-off-by: Sylwester Nawrocki
> >> Signed-off-by: Bartlomiej Zolnierkiewicz
> >> Signed-off-by: Kyungmin Park
> >> ---
> >> 
> >>   .../bindings/camera/samsung-s5k6aafx.txt   |   57 +
> >>   drivers/media/video/s5k6aa.c   |  129 +
> >>   2 files changed, 146 insertions(+), 40 deletions(-)
> >>   create mode 100644
> >> 
> >> Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt
> >> 
> >> diff --git
> >> a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt
> >> b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new file
> >> mode 100644
> >> index 000..6685a9c
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt
> >> @@ -0,0 +1,57 @@
> >> +Samsung S5K6AAFX camera sensor
> >> +--
> >> +
> >> +Required properties:
> >> +
> >> +- compatible : "samsung,s5k6aafx";
> >> +- reg : base address of the device on I2C bus;
> >> +- video-itu-601-bus : parallel bus with HSYNC and VSYNC - ITU-R BT.601;
> >> +- vdd_core-supply : digital core voltage supply 1.5V (1.4V to 1.6V);
> >> +- vdda-supply : analog power voltage supply 2.8V (2.6V to 3.0V);
> >> +- vdd_reg-supply : regulator input power voltage supply 1.8V (1.7V to
> >> 1.9V) +   or 2.8V (2.6V to 3.0);
> >> +- vddio-supply : I/O voltage supply 1.8V (1.65V to 1.95V)
> >> +   or 2.8V (2.5V to 3.1V);
> >> +
> >> +Optional properties:
> >> +
> >> +- clock-frequency : the IP's main (system bus) clock frequency in Hz,
> >> the default
> > 
> > Is that the input clock frequency ? Can't it vary ? Instead of accessing
> > the
> Yes, the description is incorrect in this patch, it should read:
> 
> +- clock-frequency : the sensor's master clock frequency in Hz;
> 
> and be a required property. As in this patch:
> https://github.com/snawrocki/linux/commit/e8a5f890dec0d7414b656bb1d1ac97d5e7
> abe563
> 
> It could vary (as this is a PLL input frequency), so probably a range would
> be a better alternative. Given that host device won't always be able to set
> this exact value...

A range sounds good, or perhaps a list of ranges. Sakari, what would you need 
for the SMIA++ driver ?

> > sensor clock frequency from the FIMC driver you should reference a clock
> > in the sensor DT node. That obviously requires generic clock support,
> > which might not be available for your platform yet (that's one of the
> > reasons the OMAP3 ISP driver doesn't support DT yet).
> 
> I agree it might be better, but waiting unknown number of kernel releases
> for the platforms to get converted to common clock API is not a good
> alternative either. I guess we could have some transitional solutions while
> other subsystems are getting adapted.

I agree, we need an interim solution.

> Yet we need to specify the clock frequency range per sensor, so
> 
> 1. either we specify it at a sensor node and host device driver references
>it, or
> 2. it could be added to a sensor specific child node of a host device
>mode, and then only the host would reference it, and sensor would
>reference a clock in its DT node; I guess it's not a problem that
>in most cases the camera host device is a clock provider.

The sensor will need to configure the clock rate, so a (list of) clock 
frequency range(s) will be needed in the sensor node anyway. As an interim 
solution the host can access that property. When the platform will be ported 
to the common clock API no modification to the DT will be needed.

-- 
Regards,

Laurent Pinchart

--
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/PATCH 02/13] media: s5p-csis: Add device tree support

[Laurent Pinchart]

Hi Sylwester,

On Thursday 26 July 2012 21:51:30 Sylwester Nawrocki wrote:
> On 07/26/2012 04:38 PM, Laurent Pinchart wrote:
> >>>> --- /dev/null
> >>>> +++ b/Documentation/devicetree/bindings/video/mipi.txt
> >>>> @@ -0,0 +1,5 @@
> >>>> +Common properties of MIPI-CSI1 and MIPI-CSI2 receivers and
> >>>> transmitters
> >>>> +
> >>>> + - data-lanes : number of differential data lanes wired and actively
> >>>> used in
> >>>> +communication between the transmitter and the receiver, 
> >>>> this
> >>>> +excludes the clock lane;
> >>> 
> >>> Wouldn't it be better to use the standard "bus-width" DT property?
> >> 
> >> I can't see any problems with using "bus-width". It seems sufficient
> >> and could indeed be better, without a need to invent new MIPI-CSI
> >> specific names. That was my first RFC on that and my perspective
> >> wasn't probably broad enough. :)
> > 
> > What about CSI receivers that can reroute the lanes internally ? We would
> > need to specify lane indices for each lane then, maybe with something
> > like
> > 
> > clock-lane =<0>;
> > data-lanes =<2 3 1>;
> 
> Sounds good to me. And the clock-lane could be made optional, as not all
> devices would need it.
> 
> However, as far as I can see, there is currently no generic API for handling
> this kind of data structure. E.g. number of cells for the "interrupts"
> property is specified with an additional "#interrupt-cells" property.
> 
> It would have been much easier to handle something like:
> 
> data-lanes = <2>, <3>, <1>;
> 
> i.e. an array of the lane indexes.

I'm fine with that.

> > For receivers that can't reroute lanes internally, the data-lanes property
> > would be need to specify lanes in sequence.
> > 
> > data-lanes =<1 2 3>;
> 
> In this case we would be only interested in the number of cells in this
> property, but how it could be retrieved ? With an array, it could have been
> calculated from property length returned by of_property_find() (divided by
> sizof(u32)).

Agreed.

-- 
Regards,

Laurent Pinchart

--
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/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation

[Laurent Pinchart]

Hi Sylwester,

On Friday 25 May 2012 21:52:48 Sylwester Nawrocki wrote:
> The driver initializes all board related properties except the s_power()
> callback to board code. The platforms that require this callback are not
> supported by this driver yet for CONFIG_OF=y.
> 
> Signed-off-by: Sylwester Nawrocki 
> Signed-off-by: Bartlomiej Zolnierkiewicz 
> Signed-off-by: Kyungmin Park 
> ---
>  .../bindings/camera/samsung-s5k6aafx.txt   |   57 +
>  drivers/media/video/s5k6aa.c   |  129 -
>  2 files changed, 146 insertions(+), 40 deletions(-)
>  create mode 100644
> Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt
> 
> diff --git a/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt
> b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt new file
> mode 100644
> index 000..6685a9c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/camera/samsung-s5k6aafx.txt
> @@ -0,0 +1,57 @@
> +Samsung S5K6AAFX camera sensor
> +--
> +
> +Required properties:
> +
> +- compatible : "samsung,s5k6aafx";
> +- reg : base address of the device on I2C bus;
> +- video-itu-601-bus : parallel bus with HSYNC and VSYNC - ITU-R BT.601;
> +- vdd_core-supply : digital core voltage supply 1.5V (1.4V to 1.6V);
> +- vdda-supply : analog power voltage supply 2.8V (2.6V to 3.0V);
> +- vdd_reg-supply : regulator input power voltage supply 1.8V (1.7V to 1.9V)
> +or 2.8V (2.6V to 3.0);
> +- vddio-supply : I/O voltage supply 1.8V (1.65V to 1.95V)
> +  or 2.8V (2.5V to 3.1V);
> +
> +Optional properties:
> +
> +- clock-frequency : the IP's main (system bus) clock frequency in Hz, the
> default 

Is that the input clock frequency ? Can't it vary ? Instead of accessing the 
sensor clock frequency from the FIMC driver you should reference a clock in 
the sensor DT node. That obviously requires generic clock support, which might 
not be available for your platform yet (that's one of the reasons the OMAP3 
ISP driver doesn't support DT yet).

> + value when this property is not specified is 24 MHz;
> +- data-lanes : number of physical lanes used (default 2 if not specified);
> +- gpio-stby : specifies the S5K6AA_STBY GPIO
> +- gpio-rst : specifies the S5K6AA_RST GPIO
> +- samsung,s5k6aa-inv-stby : set inverted S5K6AA_STBY GPIO level;
> +- samsung,s5k6aa-inv-rst : set inverted S5K6AA_RST GPIO level;
> +- samsung,s5k6aa-hflip : set the default horizontal image flipping;
> +- samsung,s5k6aa-vflip : set the default vertical image flipping;
> +
> +
> +Example:
> +
> + gpl2: gpio-controller@0 {
> + };
> +
> + reg0: regulator@0 {
> + };
> +
> + reg1: regulator@1 {
> + };
> +
> + reg2: regulator@2 {
> + };
> +
> + reg3: regulator@3 {
> + };
> +
> + s5k6aafx@3c {
> + compatible = "samsung,s5k6aafx";
> + reg = <0x3c>;
> + clock-frequency = <2400>;
> + gpio-rst = <&gpl2 0 2 0 3>;
> + gpio-stby = <&gpl2 1 2 0 3>;
> + video-itu-601-bus;
> + vdd_core-supply = <®0>;
> + vdda-supply = <®1>;
> + vdd_reg-supply = <®2>;
> + vddio-supply = <®3>;
> + };

-- 
Regards,

Laurent Pinchart

--
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/PATCH 09/13] media: s5k6aa: Add support for device tree based instantiation

[Laurent Pinchart]

> 
> >> +- vdd_core-supply : digital core voltage supply 1.5V (1.4V to 1.6V);
> >> +- vdda-supply : analog power voltage supply 2.8V (2.6V to 3.0V);
> >> +- vdd_reg-supply : regulator input power voltage supply 1.8V (1.7V to
> >> 1.9V) +   or 2.8V (2.6V to 3.0);
> > 
> > I think, underscores in property names are generally frowned upon.
> 
> Indeed, I felt something might be wrong here;) It's in this form because
> I just copied regulator supply names from the existing driver. And I
> didn't want to change them, to avoid updating them in all board files where
> they're used. Thanks for pointing it out, I'll fix that in next iteration.
> 
> >> +- vddio-supply : I/O voltage supply 1.8V (1.65V to 1.95V)
> >> +   or 2.8V (2.5V to 3.1V);
> >> +
> >> +Optional properties:
> >> +
> >> +- clock-frequency : the IP's main (system bus) clock frequency in Hz,
> >> the default +  value when this property is not specified 
> >> is 24 MHz;
> >> +- data-lanes : number of physical lanes used (default 2 if not
> >> specified);
> > 
> > bus-width?
> 
> OK.
> 
> >> +- gpio-stby : specifies the S5K6AA_STBY GPIO
> >> +- gpio-rst : specifies the S5K6AA_RST GPIO
> >> 
> >  From Documentation/devicetree/bindings/gpio/gpio.txt:
> > 
> > GPIO properties should be named "[-]gpios".
> > 
> 
> Thanks, these have been already removed in the next version, as can be seen
> above.
> 
> >> +- samsung,s5k6aa-inv-stby : set inverted S5K6AA_STBY GPIO level;
> >> +- samsung,s5k6aa-inv-rst : set inverted S5K6AA_RST GPIO level;
> > 
> > Isn't this provided by GPIO flags as described in include/linux/of_gpio.h
> > by using the OF_GPIO_ACTIVE_LOW bit?
> 
> Hmm, I wasn't aware of that. I'll see how this flag can be used.
> 
> >> +- samsung,s5k6aa-hflip : set the default horizontal image flipping;
> >> +- samsung,s5k6aa-vflip : set the default vertical image flipping;
> > 
> > This is a board property, specifying how the sensor is wired and mounted
> > on the casing, right? IIRC, libv4l has a database of these for USB
> 
> Yeah, that's exactly it. It could be used for compensating for an
> "upside down" mounting.
> 
> > cameras. So, maybe it belongs to the user-space for embedded systems too?
> 
> Using library for these things is one of the solutions, which works well
> for USB webcams. However, I wouldn't like enforcing that. Those properties
> still describe hardware IHMO, then why not add them into DT blob that is
> usually distributed with each board ? There wouldn't be a need to rely on
> any user-space database lookup, before the hardware can actually be used.

I agree. For USB devices on x86 we don't have many other options, but with DT 
we can describe the hardware properly.

> > Or at least this shouldn't be Samsung-specific?
> 
> Yes, good point. If we agree we can keep them, perhaps we could standardize
> those as boolean properties: horizontal-flip; and vertical-flip; ?

-- 
Regards,

Laurent Pinchart

--
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/PATCH 05/13] media: s5p-fimc: Add device tree support for FIMC devices

[Laurent Pinchart]

Hi Sylwester,

On Wednesday 18 July 2012 21:53:34 Sylwester Nawrocki wrote:
> On 07/18/2012 10:17 AM, Guennadi Liakhovetski wrote:
> > On Tue, 17 Jul 2012, Sylwester Nawrocki wrote:
> >> On 07/16/2012 11:13 AM, Guennadi Liakhovetski wrote:
> >>> On Fri, 25 May 2012, Sylwester Nawrocki wrote:
> >>>> Signed-off-by: Sylwester Nawrocki
> >>>> Signed-off-by: Karol Lewandowski
> >>>> Signed-off-by: Kyungmin Park
> >>>> 
> >>>From the documentation below I think, I understand what it does, but
> >>>why
> >>> 
> >>> is it needed? It doesn't describe your video subsystem topology, right?
> >>> How various subdevices are connected. It just lists them all in one
> >>> node... A description for this patch would be very welcome IMHO and,
> >>> maybe, such a node can be completely avoided?
> >> 
> >> Sorry, I'll provide better description in next iteration.
> >> It's true it doesn't describe the topology in detail, as there are
> >> multiple one-to many possible connections between sub-devices. An exact
> >> topology is coded in the driver and can be changed through MC API.
> >> The "samsung,camif-mux-id" and "video-bus-type" properties at "sensor"
> >> nodes just specify to which physical SoC camera port an image sensor
> >> is connected.
> > 
> > So, don't you think my media-link child nodes are a good solution for
> > this?
> 
> Not quite yet ;) It would be good to see some example implementation
> and how it actually works.
> 
> >> Originally the all camera devices were supposed to land under common
> >> 'camera' node. And a top level driver would be registering all platform
> >> devices. With this approach it would be possible to better control PM
> >> handling (which currently depends on an order of registering devices to
> >> the driver core). But then we discovered that we couldn't use
> >> OF_DEV_AUXDATA in such case, which was required to preserve platform
> >> device names, in order for the clock API to work. So I've moved some
> >> sub-devices out of 'camera' node and have added only a list of phandles
> >> to them in that node. This is rather a cheap workaround..
> >> 
> >> I think all camera sub-devices should be placed under common node, as
> >> there
> >> are some properties that don't belong to any sub-node: GPIO config,
> >> clocks,
> >> to name a few. Of course simpler devices might not need such a composite
> >> node. I think we can treat the sub-device interdependencies as an issue
> >> separate from a need for a common node.
> >> 
> >> If some devices need to reflect the topology better, we probably could
> >> include in some nodes (a list of) phandles to other nodes. This could
> >> ease
> >> parsing the topology at the drivers, by using existing OF infrastructure.
> > 
> > Ok, I think you have some good ideas in your RFC's, an interesting
> > question now is - how to proceed. Do you think we'd be able to work out a
> > combined RFC? Or would you prefer to make two versions and then see what
> > others think? In either case it would be nice, I think, if you could try
> > to separate what you see as common V4L DT bindings, then we could discuss
> > that separately. Whereas what you think is private to your hardware, we
> > can also look at for common ideas, or maybe even some of those properties
> > we'll wake to make common too.
> 
> I think we need a one combined RFC and continue discussions in one thread.

Agreed.

> Still, our proposals are quite different, but I believe we need something
> in between. I presume we should focus more to have common bindings for
> subdevs that are reused among different host/ISP devices, i.e. sensors and
> encoders. For simple host interfaces we can likely come up with common
> binding patterns, but more complex processing pipelines may require
> a sort of individual approach.
> 
> The suspend/resume handling is still something I don't have an idea
> on how the solution for might look like..
> Instantiating all devices from a top level driver could help, but it
> is only going to work when platforms are converted to the common clock
> framework and have their clocks instantiated from device tree.
> 
> This week I'm out of office, and next one or two I have some pending
> assignments. So there might be some delay before I can dedicate some
> reasonable amount of time to 

Re: [RFC/PATCH 01/13] ARM: Samsung: Extend MIPI PHY callback with an index argument

[Laurent Pinchart]

Hi Sylwester,

On Friday 25 May 2012 21:52:40 Sylwester Nawrocki wrote:
> For systems instantiated from device tree struct platform_device id
> field is always -1, add an 'id' argument to the s5p_csis_phy_enable()
> function so the MIPI-CSIS hardware instance index can be passed in
> by driver, for CONFIG_OF=y.
> 
> Signed-off-by: Sylwester Nawrocki 
> Signed-off-by: Kyungmin Park 
> ---
>  arch/arm/plat-s5p/setup-mipiphy.c  |   20 
>  arch/arm/plat-samsung/include/plat/mipi_csis.h |   10 ++
>  2 files changed, 14 insertions(+), 16 deletions(-)
> 
> diff --git a/arch/arm/plat-s5p/setup-mipiphy.c
> b/arch/arm/plat-s5p/setup-mipiphy.c index 683c466..146ecc3 100644
> --- a/arch/arm/plat-s5p/setup-mipiphy.c
> +++ b/arch/arm/plat-s5p/setup-mipiphy.c
> @@ -14,24 +14,19 @@
>  #include 
>  #include 
> 
> -static int __s5p_mipi_phy_control(struct platform_device *pdev,
> +static int __s5p_mipi_phy_control(struct platform_device *pdev, int id,
> bool on, u32 reset)

What about removing the pdev argument, as it's now not needed ?

-- 
Regards,

Laurent Pinchart

--
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/PATCH 02/13] media: s5p-csis: Add device tree support

[Laurent Pinchart]

Hi Sylwester,

On Tuesday 17 July 2012 20:16:23 Sylwester Nawrocki wrote:
> On 07/16/2012 10:55 AM, Guennadi Liakhovetski wrote:
> > Hi Sylwester
> > 
> > Thanks for your comments to my RFC and for pointing out to this your
> > earlier patch series. Unfortunately, I missed in in May, let me try to
> > provide some thoughts about this, we should really try to converge our
> > proposals. Maybe a discussion at KS would help too.
> 
> Thank you for the review. I was happy to see your RFC, as previously
> there seemed to be not much interest in DT among the media guys.
> Certainly, we need to work on a common approach to ensure interoperability
> of existing drivers and to avoid having people inventing different
> bindings for common features. I would also expect some share of device
> specific bindings, as diversity of media devices is significant.
> 
> I'd be great to discuss these things at KS, especially support for
> proper suspend/resume sequences. Also having common sessions with
> other subsystems folks, like ASoC, for example, might be a good idea.
> 
> I'm not sure if I'll be travelling to the KS though. :)
> 
> > On Fri, 25 May 2012, Sylwester Nawrocki wrote:
> >> s5p-csis is platform device driver for MIPI-CSI frontend to the FIMC
> >> (camera host interface DMA engine and image processor). This patch
> >> adds support for instantiating the MIPI-CSIS devices from DT and
> >> parsing all SoC and board specific properties from device tree.
> >> The MIPI DPHY control callback is now called directly from within
> >> the driver, the platform code must ensure this callback does the
> >> right thing for each SoC.
> >> 
> >> The cell-index property is used to ensure proper signal routing,
> >> from physical camera port, through MIPI-CSI2 receiver to the DMA
> >> engine (FIMC?). It's also helpful in exposing the device topology
> >> in user space at /dev/media? devnode (Media Controller API).
> >> 
> >> This patch also defines a common property ("data-lanes") for MIPI-CSI
> >> receivers and transmitters.
> >> 
> >> Signed-off-by: Sylwester Nawrocki
> >> Signed-off-by: Kyungmin Park
> >> ---
> >> 
> >>   Documentation/devicetree/bindings/video/mipi.txt   |5 +
> >>   .../bindings/video/samsung-mipi-csis.txt   |   47 ++
> >>   drivers/media/video/s5p-fimc/mipi-csis.c   |   97
> >>   +++- drivers/media/video/s5p-fimc/mipi-csis.h 
> >>|1 +
> >>   4 files changed, 126 insertions(+), 24 deletions(-)
> >>   create mode 100644 Documentation/devicetree/bindings/video/mipi.txt
> >>   create mode 100644
> >>   Documentation/devicetree/bindings/video/samsung-mipi-csis.txt>> 
> >> diff --git a/Documentation/devicetree/bindings/video/mipi.txt
> >> b/Documentation/devicetree/bindings/video/mipi.txt new file mode 100644
> >> index 000..5aed285
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/video/mipi.txt
> >> @@ -0,0 +1,5 @@
> >> +Common properties of MIPI-CSI1 and MIPI-CSI2 receivers and transmitters
> >> +
> >> + - data-lanes : number of differential data lanes wired and actively
> >> used in
> >> +  communication between the transmitter and the receiver, this
> >> +  excludes the clock lane;
> > 
> > Wouldn't it be better to use the standard "bus-width" DT property?
> 
> I can't see any problems with using "bus-width". It seems sufficient
> and could indeed be better, without a need to invent new MIPI-CSI
> specific names. That was my first RFC on that and my perspective
> wasn't probably broad enough. :)

What about CSI receivers that can reroute the lanes internally ? We would need 
to specify lane indices for each lane then, maybe with something like

clock-lane = <0>;
data-lanes = <2 3 1>;

For receivers that can't reroute lanes internally, the data-lanes property 
would be need to specify lanes in sequence.

data-lanes = <1 2 3>;

-- 
Regards,

Laurent Pinchart

--
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 0/2] video: s3c-fb: Add window positioning support

[Laurent Pinchart]

Hi Florian,

On Sunday 18 September 2011 21:29:57 Florian Tobias Schandinat wrote:
> On 09/07/2011 03:31 PM, Laurent Pinchart wrote:
> > On Thursday 01 September 2011 18:45:18 Florian Tobias Schandinat wrote:
> >> On 08/25/2011 07:51 PM, Ajay Kumar wrote:
> >>> Just as a note, there are many drivers like mx3fb.c, au1200fb.c and
> >>> OMAP seem to be doing window/plane positioning in their driver code.
> >>> Is it possible to have this window positioning support at a common
> >>> place?
> >> 
> >> Good point. Congratulations for figuring out that I like to standardize
> >> things. But I think your suggestion is far from being enough to be
> >> useful for userspace (which is our goal so that applications can be
> >> reused along drivers and don't need to know about individual drivers).
> > 
> > Beside standardizing things, do you also like to take them one level
> > higher to solve challenging issues ? I know the answer must be yes :-)
> > 
> > The problem at hand here is something we have solved in V4L2
> > (theoretically only for part of it) with the media controller API, the
> > V4L2 subdevs and their pad-level format API.
> > 
> > In a nutshell, the media controller lets drivers model hardware as a
> > graph of buliding blocks connected through their pads and expose that
> > description to userspace applications. In V4L2 most of those blocks are
> > V4L2 subdevs, which are abstract building blocks that implement sets of
> > standard operations. Those operations are exposed to userspace through
> > the V4L2 subdevs pad-level format API, allowing application to configure
> > sizes and selection rectangles at all pads in the graph. Selection
> > rectangles can be used to configure cropping and composing, which is
> > exactly what the window positioning API needs to do.
> > 
> > Instead of creating a new fbdev-specific API to do the same, shouldn't we
> > try to join forces ?
> 
> Okay, thanks for the pointer. After having a look at your API I understand
> that it would solve the problem to discover how many windows (in this
> case) are there and how they can be accessed. It looks fine for this
> purpose, powerful enough and not too complex. So if I get it correct we
> still need at least a way to configure the position of the
> windows/overlays/sink pads similar to what Ajay proposed.

Yes, the media controller API can only expose the topology to userspace, it 
can't be used to configure FB-specific parameters on the pipeline.

> Additionally a way to get and/or set the z-position of the overlays if
> multiple overlays overlap and set/get how the overlays work (overdraw,
> constant alpha, source/destination color keying). Normally I'd consider
> these link properties but I think implementing them as properties of the
> source framebuffer or sink pad would work as well.
> Is this correct or did I miss something?

That's correct.

What bothers me is that both V4L2 and DRM/KMS have the exact same needs. I 
don't think it makes sense to implement three different solutions to the same 
problem in our three video-related APIs. What's your opinion about that ?

I've tried to raise the issue on the dri-devel mailing list ("Proposal for a 
low-level Linux display framework"), but there's still a long way to go before 
convincing everybody. Feel free to help me :-)

-- 
Regards,

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