subject:"\[PATCH 10\/10\] drm\: xlnx\: zynqmp\: Add debugfs"

RE: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs

2018-01-11 Thread Hyun Kwon

Hi Daniel,

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Thursday, January 11, 2018 12:06 AM
> To: Hyun Kwon <hy...@xilinx.com>
> Cc: Daniel Vetter <dan...@ffwll.ch>; dri-devel@lists.freedesktop.org;
> devicet...@vger.kernel.org; Tejas Upadhyay <tej...@xilinx.com>; Michal
> Simek <michal.si...@xilinx.com>
> Subject: Re: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs
> 
> On Thu, Jan 11, 2018 at 02:05:31AM +, Hyun Kwon wrote:
> > Hi Daniel,
> >
> > > -Original Message-
> > > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > > Vetter
> > > Sent: Tuesday, January 09, 2018 1:54 AM
> > > To: Hyun Kwon <hy...@xilinx.com>
> > > Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Tejas
> > > Upadhyay <tej...@xilinx.com>; Michal Simek <michal.si...@xilinx.com>
> > > Subject: Re: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs
> > >
> > > On Thu, Jan 04, 2018 at 06:05:59PM -0800, Hyun Kwon wrote:
> > > > Debugfs can be used to exploit some specific setting. Main purpose
> > > > is for testing and debug diagnostic.
> > > >
> > > > Signed-off-by: Tejas Upadhyay <tej...@xilinx.com>
> > > > Signed-off-by: Hyun Kwon <hyun.k...@xilinx.com>
> > >
> > > Hm, not sure what's the use, it seems to just be for setting/getting
> > > your driver-private properties. Usually people use modetest and similar
> > > tools, but if there's demand for setting properties in debugfs (we already
> > > have all the infrastructure for dumping the entire kms state, see the
> > > various atomic_print_state callbacks) I think that should be done with
> > > generic drm code.
> > >
> > > I'd drop this patch for now (if there's no other reason for it).
> >
> > Thanks for the input. It'd be helpful, for my own understanding, if this
> > can be elaborated a little more. We are using standard tools as well as
> > custom script/tool, but some specific properties / controls are hard to
> > be executed with modetest only unless we change the entire set up /
> > design between each run. The debugfs is used to run all (or as much as
> > possible) properties in a single run, and from what I understand, that
> > doesn't violate intended debugfs usage as long as it's not treated as a
> > stable ABI. The intention is to help isolate issues and enhance the
> > diagnostics. I agree, in the long term, this kind of stuff should be
> > handled in generic way, but would it be still reasonable to keep it
> > driver specific in the meantime?
> 
> Well since the property stuff needs more work anyway I think we could do
> it properly (for upstream) from the start.
> 
> What exactly is the issue with modetest? For intel we don't use it, we do
> all our testing using the igt gpu tests:
> 
> https://cgit.freedesktop.org/drm/igt
> 
> A big pile of these tests also run on non-intel (and we're definitely very
> much appreciating such work). But if you want just a bit of scripting,
> modetest should be able to do it. If not I guess we'll need patches.

For example, for DisplayPort, there are lane count / link rate, and the maximum 
values depend on the board or connected monitors. We are enforcing those values 
manually through debugfs before running tests. We will think how to remove the 
driver specific debugfs, and we can drop it for now. I'll take a look at the 
repo. Thanks for the pointer.

Thanks,
-hyun

> -Daniel
> >
> > Thanks,
> > -hyun
> >
> > > -Daniel
> > >
> > > > ---
> > > >  drivers/gpu/drm/xlnx/Kconfig   |  21 +++
> > > >  drivers/gpu/drm/xlnx/zynqmp_disp.c | 326
> > > +
> > > >  drivers/gpu/drm/xlnx/zynqmp_dp.c   | 304
> > > ++
> > > >  3 files changed, 651 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
> > > > index 7c5529c..befce0f 100644
> > > > --- a/drivers/gpu/drm/xlnx/Kconfig
> > > > +++ b/drivers/gpu/drm/xlnx/Kconfig
> > > > @@ -21,3 +21,24 @@ config DRM_ZYNQMP_DPSUB
> > > >   this option if you have a Xilinx ZynqMP SoC with DisplayPort
> > > >   subsystem. The driver provides the kernel mode setting
> > > >   functionlaities for ZynqMP DP subsystem.
> > > > +
> > > > +config DRM_ZYNQMP_DISP_DEBUG_FS
>

Re: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs

2018-01-11 Thread Daniel Vetter

On Thu, Jan 11, 2018 at 02:05:31AM +, Hyun Kwon wrote:
> Hi Daniel,
> 
> > -Original Message-
> > From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> > Vetter
> > Sent: Tuesday, January 09, 2018 1:54 AM
> > To: Hyun Kwon <hy...@xilinx.com>
> > Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Tejas
> > Upadhyay <tej...@xilinx.com>; Michal Simek <michal.si...@xilinx.com>
> > Subject: Re: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs
> > 
> > On Thu, Jan 04, 2018 at 06:05:59PM -0800, Hyun Kwon wrote:
> > > Debugfs can be used to exploit some specific setting. Main purpose
> > > is for testing and debug diagnostic.
> > >
> > > Signed-off-by: Tejas Upadhyay <tej...@xilinx.com>
> > > Signed-off-by: Hyun Kwon <hyun.k...@xilinx.com>
> > 
> > Hm, not sure what's the use, it seems to just be for setting/getting
> > your driver-private properties. Usually people use modetest and similar
> > tools, but if there's demand for setting properties in debugfs (we already
> > have all the infrastructure for dumping the entire kms state, see the
> > various atomic_print_state callbacks) I think that should be done with
> > generic drm code.
> > 
> > I'd drop this patch for now (if there's no other reason for it).
> 
> Thanks for the input. It'd be helpful, for my own understanding, if this
> can be elaborated a little more. We are using standard tools as well as
> custom script/tool, but some specific properties / controls are hard to
> be executed with modetest only unless we change the entire set up /
> design between each run. The debugfs is used to run all (or as much as
> possible) properties in a single run, and from what I understand, that
> doesn't violate intended debugfs usage as long as it's not treated as a
> stable ABI. The intention is to help isolate issues and enhance the
> diagnostics. I agree, in the long term, this kind of stuff should be
> handled in generic way, but would it be still reasonable to keep it
> driver specific in the meantime?

Well since the property stuff needs more work anyway I think we could do
it properly (for upstream) from the start.

What exactly is the issue with modetest? For intel we don't use it, we do
all our testing using the igt gpu tests:

https://cgit.freedesktop.org/drm/igt

A big pile of these tests also run on non-intel (and we're definitely very
much appreciating such work). But if you want just a bit of scripting,
modetest should be able to do it. If not I guess we'll need patches.
-Daniel
> 
> Thanks,
> -hyun
> 
> > -Daniel
> > 
> > > ---
> > >  drivers/gpu/drm/xlnx/Kconfig   |  21 +++
> > >  drivers/gpu/drm/xlnx/zynqmp_disp.c | 326
> > +
> > >  drivers/gpu/drm/xlnx/zynqmp_dp.c   | 304
> > ++
> > >  3 files changed, 651 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
> > > index 7c5529c..befce0f 100644
> > > --- a/drivers/gpu/drm/xlnx/Kconfig
> > > +++ b/drivers/gpu/drm/xlnx/Kconfig
> > > @@ -21,3 +21,24 @@ config DRM_ZYNQMP_DPSUB
> > > this option if you have a Xilinx ZynqMP SoC with DisplayPort
> > > subsystem. The driver provides the kernel mode setting
> > > functionlaities for ZynqMP DP subsystem.
> > > +
> > > +config DRM_ZYNQMP_DISP_DEBUG_FS
> > > + bool "ZynqMP Display debugfs"
> > > + depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
> > > + select DRM_ZYNQMP_DP_DEBUG_FS
> > > + help
> > > +   Enable the debugfs code for DP Sub driver. The debugfs code
> > > +   enables debugging or testing related features. It exposes some
> > > +   low level controls to the user space to help testing automation,
> > > +   as well as can enable additional diagnostic or statistical
> > > +   information.
> > > +
> > > +config DRM_ZYNQMP_DP_DEBUG_FS
> > > + bool "ZynqMP DP debugfs"
> > > + depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
> > > + help
> > > +   Enable the debugfs code for DP driver. The debugfs code
> > > +   enables debugging or testing related features. It exposes some
> > > +   low level controls to the user space to help testing automation,
> > > +   as well as can enable additional diagnostic or statistical
> > > +   information.
> > > diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > > index 68f829c..9fe6d49 10

RE: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs

2018-01-10 Thread Hyun Kwon

Hi Daniel,

> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Tuesday, January 09, 2018 1:54 AM
> To: Hyun Kwon <hy...@xilinx.com>
> Cc: dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; Tejas
> Upadhyay <tej...@xilinx.com>; Michal Simek <michal.si...@xilinx.com>
> Subject: Re: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs
> 
> On Thu, Jan 04, 2018 at 06:05:59PM -0800, Hyun Kwon wrote:
> > Debugfs can be used to exploit some specific setting. Main purpose
> > is for testing and debug diagnostic.
> >
> > Signed-off-by: Tejas Upadhyay <tej...@xilinx.com>
> > Signed-off-by: Hyun Kwon <hyun.k...@xilinx.com>
> 
> Hm, not sure what's the use, it seems to just be for setting/getting
> your driver-private properties. Usually people use modetest and similar
> tools, but if there's demand for setting properties in debugfs (we already
> have all the infrastructure for dumping the entire kms state, see the
> various atomic_print_state callbacks) I think that should be done with
> generic drm code.
> 
> I'd drop this patch for now (if there's no other reason for it).

Thanks for the input. It'd be helpful, for my own understanding, if this can be 
elaborated a little more. We are using standard tools as well as custom 
script/tool, but some specific properties / controls are hard to be executed 
with modetest only unless we change the entire set up / design between each 
run. The debugfs is used to run all (or as much as possible) properties in a 
single run, and from what I understand, that doesn't violate intended debugfs 
usage as long as it's not treated as a stable ABI. The intention is to help 
isolate issues and enhance the diagnostics. I agree, in the long term, this 
kind of stuff should be handled in generic way, but would it be still 
reasonable to keep it driver specific in the meantime?

Thanks,
-hyun

> -Daniel
> 
> > ---
> >  drivers/gpu/drm/xlnx/Kconfig   |  21 +++
> >  drivers/gpu/drm/xlnx/zynqmp_disp.c | 326
> +
> >  drivers/gpu/drm/xlnx/zynqmp_dp.c   | 304
> ++
> >  3 files changed, 651 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
> > index 7c5529c..befce0f 100644
> > --- a/drivers/gpu/drm/xlnx/Kconfig
> > +++ b/drivers/gpu/drm/xlnx/Kconfig
> > @@ -21,3 +21,24 @@ config DRM_ZYNQMP_DPSUB
> >   this option if you have a Xilinx ZynqMP SoC with DisplayPort
> >   subsystem. The driver provides the kernel mode setting
> >   functionlaities for ZynqMP DP subsystem.
> > +
> > +config DRM_ZYNQMP_DISP_DEBUG_FS
> > +   bool "ZynqMP Display debugfs"
> > +   depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
> > +   select DRM_ZYNQMP_DP_DEBUG_FS
> > +   help
> > + Enable the debugfs code for DP Sub driver. The debugfs code
> > + enables debugging or testing related features. It exposes some
> > + low level controls to the user space to help testing automation,
> > + as well as can enable additional diagnostic or statistical
> > + information.
> > +
> > +config DRM_ZYNQMP_DP_DEBUG_FS
> > +   bool "ZynqMP DP debugfs"
> > +   depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
> > +   help
> > + Enable the debugfs code for DP driver. The debugfs code
> > + enables debugging or testing related features. It exposes some
> > + low level controls to the user space to help testing automation,
> > + as well as can enable additional diagnostic or statistical
> > + information.
> > diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > index 68f829c..9fe6d49 100644
> > --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> > @@ -17,6 +17,7 @@
> >  #include 
> >
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -508,6 +509,325 @@ static void zynqmp_disp_set(void __iomem
> *base, int offset, u32 set)
> > zynqmp_disp_write(base, offset, zynqmp_disp_read(base, offset) |
> set);
> >  }
> >
> > +#ifdef CONFIG_DRM_ZYNQMP_DISP_DEBUG_FS
> > +
> > +#define ZYNQMP_DISP_DEBUGFS_READ_MAX_SIZE  32UL
> > +#define ZYNQMP_DISP_DEBUGFS_MAX_BG_COLOR_VAL   0xFFF
> > +#define IN_RANGE(x, min, max) ({   \
> > +   typeof(x) _x = (x); \
> > +   _x >= (min) && _x <= (max); })
> > +
> > +/* Match xilinx_dp_testcases vs dp_deb

Re: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs

2018-01-09 Thread Daniel Vetter

On Thu, Jan 04, 2018 at 06:05:59PM -0800, Hyun Kwon wrote:
> Debugfs can be used to exploit some specific setting. Main purpose
> is for testing and debug diagnostic.
> 
> Signed-off-by: Tejas Upadhyay 
> Signed-off-by: Hyun Kwon 

Hm, not sure what's the use, it seems to just be for setting/getting
your driver-private properties. Usually people use modetest and similar
tools, but if there's demand for setting properties in debugfs (we already
have all the infrastructure for dumping the entire kms state, see the
various atomic_print_state callbacks) I think that should be done with
generic drm code.

I'd drop this patch for now (if there's no other reason for it).
-Daniel

> ---
>  drivers/gpu/drm/xlnx/Kconfig   |  21 +++
>  drivers/gpu/drm/xlnx/zynqmp_disp.c | 326 
> +
>  drivers/gpu/drm/xlnx/zynqmp_dp.c   | 304 ++
>  3 files changed, 651 insertions(+)
> 
> diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
> index 7c5529c..befce0f 100644
> --- a/drivers/gpu/drm/xlnx/Kconfig
> +++ b/drivers/gpu/drm/xlnx/Kconfig
> @@ -21,3 +21,24 @@ config DRM_ZYNQMP_DPSUB
> this option if you have a Xilinx ZynqMP SoC with DisplayPort
> subsystem. The driver provides the kernel mode setting
> functionlaities for ZynqMP DP subsystem.
> +
> +config DRM_ZYNQMP_DISP_DEBUG_FS
> + bool "ZynqMP Display debugfs"
> + depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
> + select DRM_ZYNQMP_DP_DEBUG_FS
> + help
> +   Enable the debugfs code for DP Sub driver. The debugfs code
> +   enables debugging or testing related features. It exposes some
> +   low level controls to the user space to help testing automation,
> +   as well as can enable additional diagnostic or statistical
> +   information.
> +
> +config DRM_ZYNQMP_DP_DEBUG_FS
> + bool "ZynqMP DP debugfs"
> + depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
> + help
> +   Enable the debugfs code for DP driver. The debugfs code
> +   enables debugging or testing related features. It exposes some
> +   low level controls to the user space to help testing automation,
> +   as well as can enable additional diagnostic or statistical
> +   information.
> diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
> b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> index 68f829c..9fe6d49 100644
> --- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
> +++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
> @@ -17,6 +17,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -508,6 +509,325 @@ static void zynqmp_disp_set(void __iomem *base, int 
> offset, u32 set)
>   zynqmp_disp_write(base, offset, zynqmp_disp_read(base, offset) | set);
>  }
>  
> +#ifdef CONFIG_DRM_ZYNQMP_DISP_DEBUG_FS
> +
> +#define ZYNQMP_DISP_DEBUGFS_READ_MAX_SIZE32UL
> +#define ZYNQMP_DISP_DEBUGFS_MAX_BG_COLOR_VAL 0xFFF
> +#define IN_RANGE(x, min, max) ({ \
> + typeof(x) _x = (x); \
> + _x >= (min) && _x <= (max); })
> +
> +/* Match xilinx_dp_testcases vs dp_debugfs_reqs[] entry */
> +enum zynqmp_disp_testcases {
> + DP_SUB_TC_BG_COLOR,
> + DP_SUB_TC_OUTPUT_FMT,
> + DP_SUB_TC_NONE
> +};
> +
> +struct zynqmp_disp_debugfs {
> + enum zynqmp_disp_testcases testcase;
> + u16 r_value;
> + u16 g_value;
> + u16 b_value;
> + u32 output_fmt;
> + struct zynqmp_disp *zynqmp_disp;
> +};
> +
> +static struct dentry *zynqmp_disp_debugfs_dir;
> +struct zynqmp_disp_debugfs disp_debugfs;
> +struct zynqmp_disp_debugfs_request {
> + const char *req;
> + enum zynqmp_disp_testcases tc;
> + ssize_t (*read_handler)(char **kern_buff);
> + ssize_t (*write_handler)(char **cmd);
> +};
> +
> +static void
> +zynqmp_disp_set_output_fmt(struct zynqmp_disp *disp, unsigned int id);
> +static s64 zynqmp_disp_debugfs_argument_value(char *arg)
> +{
> + s64 value;
> +
> + if (!arg)
> + return -1;
> +
> + if (!kstrtos64(arg, 0, ))
> + return value;
> +
> + return -1;
> +}
> +
> +static ssize_t
> +zynqmp_disp_debugfs_background_color_write(char **disp_test_arg)
> +{
> + char *r_color, *g_color, *b_color;
> + s64 r_val, g_val, b_val;
> +
> + r_color = strsep(disp_test_arg, " ");
> + g_color = strsep(disp_test_arg, " ");
> + b_color = strsep(disp_test_arg, " ");
> +
> + /* char * to int conversion */
> + r_val = zynqmp_disp_debugfs_argument_value(r_color);
> + g_val = zynqmp_disp_debugfs_argument_value(g_color);
> + b_val = zynqmp_disp_debugfs_argument_value(b_color);
> +
> + if (!(IN_RANGE(r_val, 0, ZYNQMP_DISP_DEBUGFS_MAX_BG_COLOR_VAL) &&
> +   IN_RANGE(g_val, 0, ZYNQMP_DISP_DEBUGFS_MAX_BG_COLOR_VAL) &&
> +   IN_RANGE(b_val, 0, ZYNQMP_DISP_DEBUGFS_MAX_BG_COLOR_VAL)))
> + return -EINVAL;
> +
> + disp_debugfs.r_value = r_val;
> +

[PATCH 10/10] drm: xlnx: zynqmp: Add debugfs

2018-01-04 Thread Hyun Kwon

Debugfs can be used to exploit some specific setting. Main purpose
is for testing and debug diagnostic.

Signed-off-by: Tejas Upadhyay 
Signed-off-by: Hyun Kwon 
---
 drivers/gpu/drm/xlnx/Kconfig   |  21 +++
 drivers/gpu/drm/xlnx/zynqmp_disp.c | 326 +
 drivers/gpu/drm/xlnx/zynqmp_dp.c   | 304 ++
 3 files changed, 651 insertions(+)

diff --git a/drivers/gpu/drm/xlnx/Kconfig b/drivers/gpu/drm/xlnx/Kconfig
index 7c5529c..befce0f 100644
--- a/drivers/gpu/drm/xlnx/Kconfig
+++ b/drivers/gpu/drm/xlnx/Kconfig
@@ -21,3 +21,24 @@ config DRM_ZYNQMP_DPSUB
  this option if you have a Xilinx ZynqMP SoC with DisplayPort
  subsystem. The driver provides the kernel mode setting
  functionlaities for ZynqMP DP subsystem.
+
+config DRM_ZYNQMP_DISP_DEBUG_FS
+   bool "ZynqMP Display debugfs"
+   depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
+   select DRM_ZYNQMP_DP_DEBUG_FS
+   help
+ Enable the debugfs code for DP Sub driver. The debugfs code
+ enables debugging or testing related features. It exposes some
+ low level controls to the user space to help testing automation,
+ as well as can enable additional diagnostic or statistical
+ information.
+
+config DRM_ZYNQMP_DP_DEBUG_FS
+   bool "ZynqMP DP debugfs"
+   depends on DEBUG_FS && DRM_ZYNQMP_DPSUB
+   help
+ Enable the debugfs code for DP driver. The debugfs code
+ enables debugging or testing related features. It exposes some
+ low level controls to the user space to help testing automation,
+ as well as can enable additional diagnostic or statistical
+ information.
diff --git a/drivers/gpu/drm/xlnx/zynqmp_disp.c 
b/drivers/gpu/drm/xlnx/zynqmp_disp.c
index 68f829c..9fe6d49 100644
--- a/drivers/gpu/drm/xlnx/zynqmp_disp.c
+++ b/drivers/gpu/drm/xlnx/zynqmp_disp.c
@@ -17,6 +17,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -508,6 +509,325 @@ static void zynqmp_disp_set(void __iomem *base, int 
offset, u32 set)
zynqmp_disp_write(base, offset, zynqmp_disp_read(base, offset) | set);
 }
 
+#ifdef CONFIG_DRM_ZYNQMP_DISP_DEBUG_FS
+
+#define ZYNQMP_DISP_DEBUGFS_READ_MAX_SIZE  32UL
+#define ZYNQMP_DISP_DEBUGFS_MAX_BG_COLOR_VAL   0xFFF
+#define IN_RANGE(x, min, max) ({   \
+   typeof(x) _x = (x); \
+   _x >= (min) && _x <= (max); })
+
+/* Match xilinx_dp_testcases vs dp_debugfs_reqs[] entry */
+enum zynqmp_disp_testcases {
+   DP_SUB_TC_BG_COLOR,
+   DP_SUB_TC_OUTPUT_FMT,
+   DP_SUB_TC_NONE
+};
+
+struct zynqmp_disp_debugfs {
+   enum zynqmp_disp_testcases testcase;
+   u16 r_value;
+   u16 g_value;
+   u16 b_value;
+   u32 output_fmt;
+   struct zynqmp_disp *zynqmp_disp;
+};
+
+static struct dentry *zynqmp_disp_debugfs_dir;
+struct zynqmp_disp_debugfs disp_debugfs;
+struct zynqmp_disp_debugfs_request {
+   const char *req;
+   enum zynqmp_disp_testcases tc;
+   ssize_t (*read_handler)(char **kern_buff);
+   ssize_t (*write_handler)(char **cmd);
+};
+
+static void
+zynqmp_disp_set_output_fmt(struct zynqmp_disp *disp, unsigned int id);
+static s64 zynqmp_disp_debugfs_argument_value(char *arg)
+{
+   s64 value;
+
+   if (!arg)
+   return -1;
+
+   if (!kstrtos64(arg, 0, ))
+   return value;
+
+   return -1;
+}
+
+static ssize_t
+zynqmp_disp_debugfs_background_color_write(char **disp_test_arg)
+{
+   char *r_color, *g_color, *b_color;
+   s64 r_val, g_val, b_val;
+
+   r_color = strsep(disp_test_arg, " ");
+   g_color = strsep(disp_test_arg, " ");
+   b_color = strsep(disp_test_arg, " ");
+
+   /* char * to int conversion */
+   r_val = zynqmp_disp_debugfs_argument_value(r_color);
+   g_val = zynqmp_disp_debugfs_argument_value(g_color);
+   b_val = zynqmp_disp_debugfs_argument_value(b_color);
+
+   if (!(IN_RANGE(r_val, 0, ZYNQMP_DISP_DEBUGFS_MAX_BG_COLOR_VAL) &&
+ IN_RANGE(g_val, 0, ZYNQMP_DISP_DEBUGFS_MAX_BG_COLOR_VAL) &&
+ IN_RANGE(b_val, 0, ZYNQMP_DISP_DEBUGFS_MAX_BG_COLOR_VAL)))
+   return -EINVAL;
+
+   disp_debugfs.r_value = r_val;
+   disp_debugfs.g_value = g_val;
+   disp_debugfs.b_value = b_val;
+
+   disp_debugfs.testcase = DP_SUB_TC_BG_COLOR;
+
+   return 0;
+}
+
+static ssize_t
+zynqmp_disp_debugfs_output_display_format_write(char **disp_test_arg)
+{
+   char *output_format;
+   struct zynqmp_disp *disp = disp_debugfs.zynqmp_disp;
+
+   /* Read the value from a user value */
+   output_format = strsep(disp_test_arg, " ");
+   if (strncmp(output_format, "rgb", 3) == 0) {
+   disp_debugfs.output_fmt =
+   ZYNQMP_DISP_V_BLEND_OUTPUT_VID_FMT_RGB;
+   } else if (strncmp(output_format, "ycbcr444", 8) == 0) {
+

RE: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs

Re: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs

RE: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs

Re: [PATCH 10/10] drm: xlnx: zynqmp: Add debugfs

[PATCH 10/10] drm: xlnx: zynqmp: Add debugfs

5 matches

Site Navigation

Mail list logo

Footer information