[PATCH v6 1/1] Add test for new features in cec-follower
Analog tuner control test tuner_ctl_test():
- give analog tuner status
- select tuner analog service
- analog tuner step features
Signed-off-by: Jiunn Chang
---
utils/cec-compliance/cec-test.cpp | 75 +++
1 file changed, 75 insertions(+)
diff --git a/utils/cec-compliance/cec-test.cpp
b/utils/cec-compliance/cec-test.cpp
index ec07d886..1fd0ea92 100644
--- a/utils/cec-compliance/cec-test.cpp
+++ b/utils/cec-compliance/cec-test.cpp
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "cec-compliance.h"
@@ -722,6 +723,79 @@ static struct remote_subtest deck_ctl_subtests[] = {
TODO: These are very rudimentary tests which should be expanded.
*/
+static int tuner_ctl_test(struct node *node, unsigned me, unsigned la, bool
interactive)
+{
+ struct cec_msg msg = {};
+ struct cec_op_tuner_device_info info = {};
+ std::vector info_vec;
+
+ cec_msg_init(&msg, me, la);
+ cec_msg_give_tuner_device_status(&msg, true, CEC_OP_STATUS_REQ_ONCE);
+ fail_on_test(!transmit_timeout(node, &msg));
+ fail_on_test(cec_msg_status_is_abort(&msg));
+ if (timed_out(&msg) || unrecognized_op(&msg))
+ return NOTSUPPORTED;
+ if (refused(&msg))
+ return REFUSED;
+ cec_ops_tuner_device_status(&msg, &info);
+ info_vec.push_back(info);
+
+ while (1) {
+ cec_msg_init(&msg, me, la);
+ cec_msg_tuner_step_increment(&msg);
+ fail_on_test(!transmit_timeout(node, &msg));
+ fail_on_test(cec_msg_status_is_abort(&msg));
+ if (cec_msg_status_is_abort(&msg)) {
+ fail_on_test(abort_reason(&msg) ==
CEC_OP_ABORT_UNRECOGNIZED_OP);
+ if (abort_reason(&msg) == CEC_OP_ABORT_REFUSED) {
+ warn("Tuner step increment does not wrap.\n");
+ break;
+ } else {
+ warn("Tuner at end of service list did not
receive feature abort refused.\n");
+ break;
+ }
+ }
+ cec_msg_init(&msg, me, la);
+ cec_msg_give_tuner_device_status(&msg, true,
CEC_OP_STATUS_REQ_ONCE);
+ fail_on_test(!transmit_timeout(node, &msg));
+ fail_on_test(timed_out_or_abort(&msg));
+ info = {};
+ cec_ops_tuner_device_status(&msg, &info);
+ if (!memcmp(&info, &info_vec[0], sizeof(info)))
+ break;
+ info_vec.push_back(info);
+ }
+
+ for (std::vector::iterator iter =
info_vec.begin();
+ iter != info_vec.end(); iter++) {
+ cec_msg_init(&msg, me, la);
+ cec_msg_select_analogue_service(&msg,
iter->analog.ana_bcast_type,
+ iter->analog.ana_freq, iter->analog.bcast_system);
+ fail_on_test(!transmit_timeout(node, &msg));
+ fail_on_test(cec_msg_status_is_abort(&msg));
+ cec_msg_init(&msg, me, la);
+ cec_msg_give_tuner_device_status(&msg, true,
CEC_OP_STATUS_REQ_ONCE);
+ fail_on_test(!transmit_timeout(node, &msg));
+ fail_on_test(timed_out_or_abort(&msg));
+ info = {};
+ cec_ops_tuner_device_status(&msg, &info);
+ fail_on_test(memcmp(&info, &(*iter), sizeof(info)));
+ if (iter->is_analog) {
+ double freq_mhz = (iter->analog.ana_freq * 625) /
1.0;
+
+ info("Analog channel freq: %.2f MHz\n", freq_mhz);
+ }
+ }
+
+ cec_msg_init(&msg, me, la);
+ cec_msg_select_analogue_service(&msg, 3, 16000, 9);
+ fail_on_test(!transmit_timeout(node, &msg));
+ fail_on_test(!cec_msg_status_is_abort(&msg));
+ fail_on_test(abort_reason(&msg) != CEC_OP_ABORT_INVALID_OP);
+
+ return 0;
+}
+
static int tuner_ctl_give_status(struct node *node, unsigned me, unsigned la,
bool interactive)
{
struct cec_msg msg = {};
@@ -885,6 +959,7 @@ static int tuner_ctl_step_inc(struct node *node, unsigned
me, unsigned la, bool
}
static struct remote_subtest tuner_ctl_subtests[] = {
+ { "Tuner Control", CEC_LOG_ADDR_MASK_TUNER | CEC_LOG_ADDR_MASK_TV,
tuner_ctl_test },
{ "Give Tuner Device Status", CEC_LOG_ADDR_MASK_TUNER,
tuner_ctl_give_status },
{ "Select Analogue Service", CEC_LOG_ADDR_MASK_TUNER,
tuner_ctl_sel_analog_service },
{ "Select Digital Service", CEC_LOG_ADDR_MASK_TUNER,
tuner_ctl_sel_digital_service },
--
2.23.0
Re: [PATCH v5 2/2] Add test for new features in cec-follower
On 10/3/19 5:18 AM, Jiunn Chang wrote:
> Analog tuner control test tuner_ctl_test():
> - give analog tuner status
> - select tuner analog service
> - analog tuner step features
>
> Signed-off-by: Jiunn Chang
> ---
> utils/cec-compliance/cec-test.cpp | 74 +++
> 1 file changed, 74 insertions(+)
>
> diff --git a/utils/cec-compliance/cec-test.cpp
> b/utils/cec-compliance/cec-test.cpp
> index 017d1ef8..669df4b7 100644
> --- a/utils/cec-compliance/cec-test.cpp
> +++ b/utils/cec-compliance/cec-test.cpp
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include "cec-compliance.h"
>
> @@ -722,6 +723,78 @@ static struct remote_subtest deck_ctl_subtests[] = {
>TODO: These are very rudimentary tests which should be expanded.
> */
>
> +static int tuner_ctl_test(struct node *node, unsigned me, unsigned la, bool
> interactive)
> +{
> + struct cec_msg msg = {};
> + struct cec_op_tuner_device_info info = {};
> + __u16 start_freq;
> + std::vector info_vec;
> +
> + cec_msg_init(&msg, me, la);
> + cec_msg_give_tuner_device_status(&msg, true, CEC_OP_STATUS_REQ_ONCE);
> + fail_on_test(!transmit_timeout(node, &msg));
> + if (timed_out(&msg) || unrecognized_op(&msg))
> + return NOTSUPPORTED;
> + if (refused(&msg))
> + return REFUSED;
You're missing a 'fail_on_test(cec_msg_status_is_abort(&msg));' line here,
since any other abort reason means the test should fail.
> + cec_ops_tuner_device_status(&msg, &info);
> + start_freq = info.analog.ana_freq;
> + info_vec.push_back(info);
> +
> + while (1) {
> + cec_msg_init(&msg, me, la);
> + cec_msg_tuner_step_increment(&msg);
> + fail_on_test(!transmit_timeout(node, &msg));
> + fail_on_test(cec_msg_status_is_abort(&msg));
> + if (cec_msg_status_is_abort(&msg)) {
> + fail_on_test(abort_reason(&msg) ==
> CEC_OP_ABORT_UNRECOGNIZED_OP);
> + if (abort_reason(&msg) == CEC_OP_ABORT_REFUSED) {
> + warn("Tuner step increment does not wrap.\n");
> + break;
> + } else {
> + warn("Tuner at end of service list did not
> receive feature abort refused.\n");
> + break;
> + }
> + }
> + cec_msg_init(&msg, me, la);
> + cec_msg_give_tuner_device_status(&msg, true,
> CEC_OP_STATUS_REQ_ONCE);
> + fail_on_test(!transmit_timeout(node, &msg));
> + fail_on_test(timed_out_or_abort(&msg));
> + cec_ops_tuner_device_status(&msg, &info);
> + if (info.analog.ana_freq == start_freq)
> + break;
> + info_vec.push_back(info);
> + }
> +
> + for (std::vector::iterator iter =
> info_vec.begin();
> + iter != info_vec.end(); iter++) {
> + cec_msg_init(&msg, me, la);
> + cec_msg_select_analogue_service(&msg,
> iter->analog.ana_bcast_type,
> + iter->analog.ana_freq, iter->analog.bcast_system);
> + fail_on_test(!transmit_timeout(node, &msg));
> + fail_on_test(cec_msg_status_is_abort(&msg));
> + cec_msg_init(&msg, me, la);
> + cec_msg_give_tuner_device_status(&msg, true,
> CEC_OP_STATUS_REQ_ONCE);
> + fail_on_test(!transmit_timeout(node, &msg));
> + fail_on_test(timed_out_or_abort(&msg));
> + cec_ops_tuner_device_status(&msg, &info);
> + fail_on_test(info.analog.ana_freq != iter->analog.ana_freq);
> + if (iter->is_analog) {
> + double freq_mhz = (iter->analog.ana_freq * 625) /
> 1.0;
Add newline.
> + info("Analog channel freq: %.2f MHz\n", freq_mhz);
> + }
> + }
> +
> + cec_msg_init(&msg, me, la);
> + cec_msg_select_analogue_service(&msg, 3, 16000, 9);
> + fail_on_test(!transmit_timeout(node, &msg));
> + fail_on_test(!cec_msg_status_is_abort(&msg));
> + fail_on_test(unrecognized_op(&msg));
This test is unnecessary, since the next test will catch this.
> + fail_on_test(abort_reason(&msg) != CEC_OP_ABORT_INVALID_OP);
> +
> + return 0;
> +}
> +
> static int tuner_ctl_give_status(struct node *node, unsigned
[PATCH v5 2/2] Add test for new features in cec-follower
Analog tuner control test tuner_ctl_test():
- give analog tuner status
- select tuner analog service
- analog tuner step features
Signed-off-by: Jiunn Chang
---
utils/cec-compliance/cec-test.cpp | 74 +++
1 file changed, 74 insertions(+)
diff --git a/utils/cec-compliance/cec-test.cpp
b/utils/cec-compliance/cec-test.cpp
index 017d1ef8..669df4b7 100644
--- a/utils/cec-compliance/cec-test.cpp
+++ b/utils/cec-compliance/cec-test.cpp
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "cec-compliance.h"
@@ -722,6 +723,78 @@ static struct remote_subtest deck_ctl_subtests[] = {
TODO: These are very rudimentary tests which should be expanded.
*/
+static int tuner_ctl_test(struct node *node, unsigned me, unsigned la, bool
interactive)
+{
+ struct cec_msg msg = {};
+ struct cec_op_tuner_device_info info = {};
+ __u16 start_freq;
+ std::vector info_vec;
+
+ cec_msg_init(&msg, me, la);
+ cec_msg_give_tuner_device_status(&msg, true, CEC_OP_STATUS_REQ_ONCE);
+ fail_on_test(!transmit_timeout(node, &msg));
+ if (timed_out(&msg) || unrecognized_op(&msg))
+ return NOTSUPPORTED;
+ if (refused(&msg))
+ return REFUSED;
+ cec_ops_tuner_device_status(&msg, &info);
+ start_freq = info.analog.ana_freq;
+ info_vec.push_back(info);
+
+ while (1) {
+ cec_msg_init(&msg, me, la);
+ cec_msg_tuner_step_increment(&msg);
+ fail_on_test(!transmit_timeout(node, &msg));
+ fail_on_test(cec_msg_status_is_abort(&msg));
+ if (cec_msg_status_is_abort(&msg)) {
+ fail_on_test(abort_reason(&msg) ==
CEC_OP_ABORT_UNRECOGNIZED_OP);
+ if (abort_reason(&msg) == CEC_OP_ABORT_REFUSED) {
+ warn("Tuner step increment does not wrap.\n");
+ break;
+ } else {
+ warn("Tuner at end of service list did not
receive feature abort refused.\n");
+ break;
+ }
+ }
+ cec_msg_init(&msg, me, la);
+ cec_msg_give_tuner_device_status(&msg, true,
CEC_OP_STATUS_REQ_ONCE);
+ fail_on_test(!transmit_timeout(node, &msg));
+ fail_on_test(timed_out_or_abort(&msg));
+ cec_ops_tuner_device_status(&msg, &info);
+ if (info.analog.ana_freq == start_freq)
+ break;
+ info_vec.push_back(info);
+ }
+
+ for (std::vector::iterator iter =
info_vec.begin();
+ iter != info_vec.end(); iter++) {
+ cec_msg_init(&msg, me, la);
+ cec_msg_select_analogue_service(&msg,
iter->analog.ana_bcast_type,
+ iter->analog.ana_freq, iter->analog.bcast_system);
+ fail_on_test(!transmit_timeout(node, &msg));
+ fail_on_test(cec_msg_status_is_abort(&msg));
+ cec_msg_init(&msg, me, la);
+ cec_msg_give_tuner_device_status(&msg, true,
CEC_OP_STATUS_REQ_ONCE);
+ fail_on_test(!transmit_timeout(node, &msg));
+ fail_on_test(timed_out_or_abort(&msg));
+ cec_ops_tuner_device_status(&msg, &info);
+ fail_on_test(info.analog.ana_freq != iter->analog.ana_freq);
+ if (iter->is_analog) {
+ double freq_mhz = (iter->analog.ana_freq * 625) /
1.0;
+ info("Analog channel freq: %.2f MHz\n", freq_mhz);
+ }
+ }
+
+ cec_msg_init(&msg, me, la);
+ cec_msg_select_analogue_service(&msg, 3, 16000, 9);
+ fail_on_test(!transmit_timeout(node, &msg));
+ fail_on_test(!cec_msg_status_is_abort(&msg));
+ fail_on_test(unrecognized_op(&msg));
+ fail_on_test(abort_reason(&msg) != CEC_OP_ABORT_INVALID_OP);
+
+ return 0;
+}
+
static int tuner_ctl_give_status(struct node *node, unsigned me, unsigned la,
bool interactive)
{
struct cec_msg msg = {};
@@ -885,6 +958,7 @@ static int tuner_ctl_step_inc(struct node *node, unsigned
me, unsigned la, bool
}
static struct remote_subtest tuner_ctl_subtests[] = {
+ { "Tuner Control", CEC_LOG_ADDR_MASK_TUNER | CEC_LOG_ADDR_MASK_TV,
tuner_ctl_test },
{ "Give Tuner Device Status", CEC_LOG_ADDR_MASK_TUNER,
tuner_ctl_give_status },
{ "Select Analogue Service", CEC_LOG_ADDR_MASK_TUNER,
tuner_ctl_sel_analog_service },
{ "Select Digital Service", CEC_LOG_ADDR_MASK_TUNER,
tuner_ctl_sel_digital_service },
--
2.23.0
Re: [PATCH v4 3/3] cec-compliance: add tuner control test
On 10/1/19 5:18 AM, Jiunn Chang wrote:
> Add test for new features added to cec-follower.
>
> Analog tuner control test tuner_ctl_test():
> - give analog tuner status
> - select tuner analog service
> - analog tuner step features
>
> Signed-off-by: Jiunn Chang
> ---
> utils/cec-compliance/cec-test.cpp | 91 +++
> 1 file changed, 91 insertions(+)
>
> diff --git a/utils/cec-compliance/cec-test.cpp
> b/utils/cec-compliance/cec-test.cpp
> index aece546c..17f72cc6 100644
> --- a/utils/cec-compliance/cec-test.cpp
> +++ b/utils/cec-compliance/cec-test.cpp
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
>
> #include "cec-compliance.h"
>
> @@ -722,6 +723,95 @@ static struct remote_subtest deck_ctl_subtests[] = {
>TODO: These are very rudimentary tests which should be expanded.
> */
>
> +static int tuner_ctl_test(struct node *node, unsigned me, unsigned la, bool
> interactive)
> +{
> + struct cec_msg msg = {};
> + struct cec_op_tuner_device_info info = {};
> + std::vector info_vec;
> + __u16 start_freq;
> +
> + cec_msg_init(&msg, me, la);
> + cec_msg_give_tuner_device_status(&msg, true, CEC_OP_STATUS_REQ_ONCE);
That's interesting! I never noticed this Status Request argument. This is
something that
the follower doesn't implement at the moment. It also means that the
cec_msg_give_tuner_device_status
function is slightly buggy in that it sets the reply field unconditionally,
even though
there will not be a reply if status_req is CEC_OP_STATUS_REQ_OFF.
I'll post a patch for this and cec_msg_give_deck_status which has the same
problem.
> + fail_on_test(!transmit_timeout(node, &msg));
> + fail_on_test(timed_out(&msg));
Don't fail on this. Instead add to the next if:
> + if (unrecognized_op(&msg))
if (timed_out(&msg) || unrecognized_op(&msg))
Too many devices time out if they don't support a message rather than
replying with Feature Abort.
> + return NOTSUPPORTED;
> + if (refused(&msg))
> + return REFUSED;
> + cec_ops_tuner_device_status(&msg, &info);
> + start_freq = info.analog.ana_freq;
> + info_vec.push_back(info);
> +
> + while (1) {
> + struct cec_op_tuner_device_info new_info;
No need, you can reuse the existing info variable.
> +
> + cec_msg_init(&msg, me, la);
> + cec_msg_tuner_step_increment(&msg);
> + fail_on_test(!transmit_timeout(node, &msg));
> + if (unrecognized_op(&msg))
> + return NOTSUPPORTED;
> + if (refused(&msg))
> + return REFUSED;
This needs a bit more work:
It should fail if the command timed_out. If it returned feature abort, then
if the reason is CEC_OP_ABORT_UNRECOGNIZED_OP it should fail as well.
For any other reason you can assume that the tuner has reached the end of
the service list and you can break out of the loop. I would warn as well in that
case if the abort reason is anything else but REFUSED.
If give_tuner_device_status is working, but not tuner_step_increment, then
that counts as a fail.
> + cec_msg_init(&msg, me, la);
> + cec_msg_give_tuner_device_status(&msg, true,
> CEC_OP_STATUS_REQ_ONCE);
> + fail_on_test(!transmit_timeout(node, &msg));
> + fail_on_test(timed_out(&msg));
> + if (unrecognized_op(&msg))
> + return NOTSUPPORTED;
> + if (refused(&msg))
> + return REFUSED;
Just fail: fail_on_test(timed_out_or_abort(&msg));
It worked above, so if this one fails, then something is seriously wrong.
> + cec_ops_tuner_device_status(&msg, &new_info);
> + if (new_info.analog.ana_freq == start_freq)
> + break;
> + if (new_info.analog.ana_freq ==
> info_vec.back().analog.ana_freq) {
> + warn("Tuner channel step increment does not wrap.\n");
> + break;
> + }
> + info_vec.push_back(new_info);
> + }
> +
> +
> + for (std::vector::iterator iter =
> info_vec.begin();
> + iter != info_vec.end(); iter++) {
> + struct cec_op_tuner_device_info current;
Again, you can just reuse the info variable above.
> +
> + cec_msg_init(&msg, me, la);
> + cec_msg_select_analogue_service(&msg,
> iter->analog.ana_bcast_type,
> + iter->analog.ana_freq, iter->analog.bcast_system);
> +
[PATCH v4 3/3] cec-compliance: add tuner control test
Add test for new features added to cec-follower.
Analog tuner control test tuner_ctl_test():
- give analog tuner status
- select tuner analog service
- analog tuner step features
Signed-off-by: Jiunn Chang
---
utils/cec-compliance/cec-test.cpp | 91 +++
1 file changed, 91 insertions(+)
diff --git a/utils/cec-compliance/cec-test.cpp
b/utils/cec-compliance/cec-test.cpp
index aece546c..17f72cc6 100644
--- a/utils/cec-compliance/cec-test.cpp
+++ b/utils/cec-compliance/cec-test.cpp
@@ -16,6 +16,7 @@
#include
#include
#include
+#include
#include "cec-compliance.h"
@@ -722,6 +723,95 @@ static struct remote_subtest deck_ctl_subtests[] = {
TODO: These are very rudimentary tests which should be expanded.
*/
+static int tuner_ctl_test(struct node *node, unsigned me, unsigned la, bool
interactive)
+{
+ struct cec_msg msg = {};
+ struct cec_op_tuner_device_info info = {};
+ std::vector info_vec;
+ __u16 start_freq;
+
+ cec_msg_init(&msg, me, la);
+ cec_msg_give_tuner_device_status(&msg, true, CEC_OP_STATUS_REQ_ONCE);
+ fail_on_test(!transmit_timeout(node, &msg));
+ fail_on_test(timed_out(&msg));
+ if (unrecognized_op(&msg))
+ return NOTSUPPORTED;
+ if (refused(&msg))
+ return REFUSED;
+ cec_ops_tuner_device_status(&msg, &info);
+ start_freq = info.analog.ana_freq;
+ info_vec.push_back(info);
+
+ while (1) {
+ struct cec_op_tuner_device_info new_info;
+
+ cec_msg_init(&msg, me, la);
+ cec_msg_tuner_step_increment(&msg);
+ fail_on_test(!transmit_timeout(node, &msg));
+ if (unrecognized_op(&msg))
+ return NOTSUPPORTED;
+ if (refused(&msg))
+ return REFUSED;
+ cec_msg_init(&msg, me, la);
+ cec_msg_give_tuner_device_status(&msg, true,
CEC_OP_STATUS_REQ_ONCE);
+ fail_on_test(!transmit_timeout(node, &msg));
+ fail_on_test(timed_out(&msg));
+ if (unrecognized_op(&msg))
+ return NOTSUPPORTED;
+ if (refused(&msg))
+ return REFUSED;
+ cec_ops_tuner_device_status(&msg, &new_info);
+ if (new_info.analog.ana_freq == start_freq)
+ break;
+ if (new_info.analog.ana_freq ==
info_vec.back().analog.ana_freq) {
+ warn("Tuner channel step increment does not wrap.\n");
+ break;
+ }
+ info_vec.push_back(new_info);
+ }
+
+
+ for (std::vector::iterator iter =
info_vec.begin();
+ iter != info_vec.end(); iter++) {
+ struct cec_op_tuner_device_info current;
+
+ cec_msg_init(&msg, me, la);
+ cec_msg_select_analogue_service(&msg,
iter->analog.ana_bcast_type,
+ iter->analog.ana_freq, iter->analog.bcast_system);
+ fail_on_test(!transmit_timeout(node, &msg));
+ if (unrecognized_op(&msg))
+ return NOTSUPPORTED;
+ if (refused(&msg))
+ return REFUSED;
+ cec_msg_init(&msg, me, la);
+ cec_msg_give_tuner_device_status(&msg, true,
CEC_OP_STATUS_REQ_ONCE);
+ fail_on_test(!transmit_timeout(node, &msg));
+ fail_on_test(timed_out(&msg));
+ if (unrecognized_op(&msg))
+ return NOTSUPPORTED;
+ if (refused(&msg))
+ return REFUSED;
+ cec_ops_tuner_device_status(&msg, ¤t);
+ fail_on_test(current.analog.ana_freq != iter->analog.ana_freq);
+ if (iter->is_analog) {
+ float freq_mhz = (iter->analog.ana_freq * 625) / 1;
+ info("Analog channel freq: %.2f MHz\n", freq_mhz);
+ }
+ }
+
+ cec_msg_init(&msg, me, la);
+ cec_msg_select_analogue_service(&msg, 3, 16000, 9);
+ fail_on_test(!transmit_timeout(node, &msg));
+ if (unrecognized_op(&msg))
+ return NOTSUPPORTED;
+ if (refused(&msg))
+ return REFUSED;
+ fail_on_test(!cec_msg_status_is_abort(&msg));
+ fail_on_test(abort_reason(&msg) != CEC_OP_ABORT_INVALID_OP);
+
+ return 0;
+}
+
static int tuner_ctl_give_status(struct node *node, unsigned me, unsigned la,
bool interactive)
{
struct cec_msg msg = {};
@@ -885,6 +975,7 @@ static int tuner_ctl_step_inc(struct node *node, unsigned
me, unsigned la, bool
}
static struct remote_subtest tuner_ctl_subtest
Re: [PATCH 3/3] selftests: ir: fix ir_loopback test failure
On Mon, Aug 12, 2019 at 08:25:41AM -0600, shuah wrote:
> On 8/10/19 5:44 AM, Sean Young wrote:
> > The decoder is called rc-mm, not rcmm. This was renamed late in the cycle
> > so this bug crept in.
> >
> > Cc: Shuah Khan
> > Signed-off-by: Sean Young
> > ---
> > tools/testing/selftests/ir/ir_loopback.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/tools/testing/selftests/ir/ir_loopback.c
> > b/tools/testing/selftests/ir/ir_loopback.c
> > index e700e09e3682..af7f9c7d59bc 100644
> > --- a/tools/testing/selftests/ir/ir_loopback.c
> > +++ b/tools/testing/selftests/ir/ir_loopback.c
> > @@ -54,9 +54,9 @@ static const struct {
> > { RC_PROTO_RC6_MCE, "rc-6-mce", 0x7fff, "rc-6" },
> > { RC_PROTO_SHARP, "sharp", 0x1fff, "sharp" },
> > { RC_PROTO_IMON, "imon", 0x7fff, "imon" },
> > - { RC_PROTO_RCMM12, "rcmm-12", 0x0fff, "rcmm" },
> > - { RC_PROTO_RCMM24, "rcmm-24", 0x00ff, "rcmm" },
> > - { RC_PROTO_RCMM32, "rcmm-32", 0x, "rcmm" },
> > + { RC_PROTO_RCMM12, "rcmm-12", 0x0fff, "rc-mm" },
> > + { RC_PROTO_RCMM24, "rcmm-24", 0x00ff, "rc-mm" },
> > + { RC_PROTO_RCMM32, "rcmm-32", 0x, "rc-mm" },
> > };
> > int lirc_open(const char *rc)
> >
>
> Thanks Sean! Please cc - linux-keseltest makling list on these patches.
I'll do that next time, thanks.
> I can take this through my tree or here is my Ack for it go through
> media tree
>
> Acked-by: Shuah Khan
I'm just preparing a pull request for Mauro so I'll put it in there
with your Ack.
Thank you
Sean
Re: [PATCH 3/3] selftests: ir: fix ir_loopback test failure
On 8/10/19 5:44 AM, Sean Young wrote:
The decoder is called rc-mm, not rcmm. This was renamed late in the cycle
so this bug crept in.
Cc: Shuah Khan
Signed-off-by: Sean Young
---
tools/testing/selftests/ir/ir_loopback.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/ir/ir_loopback.c
b/tools/testing/selftests/ir/ir_loopback.c
index e700e09e3682..af7f9c7d59bc 100644
--- a/tools/testing/selftests/ir/ir_loopback.c
+++ b/tools/testing/selftests/ir/ir_loopback.c
@@ -54,9 +54,9 @@ static const struct {
{ RC_PROTO_RC6_MCE, "rc-6-mce", 0x7fff, "rc-6" },
{ RC_PROTO_SHARP, "sharp", 0x1fff, "sharp" },
{ RC_PROTO_IMON, "imon", 0x7fff, "imon" },
- { RC_PROTO_RCMM12, "rcmm-12", 0x0fff, "rcmm" },
- { RC_PROTO_RCMM24, "rcmm-24", 0x00ff, "rcmm" },
- { RC_PROTO_RCMM32, "rcmm-32", 0x, "rcmm" },
+ { RC_PROTO_RCMM12, "rcmm-12", 0x0fff, "rc-mm" },
+ { RC_PROTO_RCMM24, "rcmm-24", 0x00ff, "rc-mm" },
+ { RC_PROTO_RCMM32, "rcmm-32", 0x, "rc-mm" },
};
int lirc_open(const char *rc)
Thanks Sean! Please cc - linux-keseltest makling list on these patches.
I can take this through my tree or here is my Ack for it go through
media tree
Acked-by: Shuah Khan
[PATCH 3/3] selftests: ir: fix ir_loopback test failure
The decoder is called rc-mm, not rcmm. This was renamed late in the cycle
so this bug crept in.
Cc: Shuah Khan
Signed-off-by: Sean Young
---
tools/testing/selftests/ir/ir_loopback.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/ir/ir_loopback.c
b/tools/testing/selftests/ir/ir_loopback.c
index e700e09e3682..af7f9c7d59bc 100644
--- a/tools/testing/selftests/ir/ir_loopback.c
+++ b/tools/testing/selftests/ir/ir_loopback.c
@@ -54,9 +54,9 @@ static const struct {
{ RC_PROTO_RC6_MCE, "rc-6-mce", 0x7fff, "rc-6" },
{ RC_PROTO_SHARP, "sharp", 0x1fff, "sharp" },
{ RC_PROTO_IMON, "imon", 0x7fff, "imon" },
- { RC_PROTO_RCMM12, "rcmm-12", 0x0fff, "rcmm" },
- { RC_PROTO_RCMM24, "rcmm-24", 0x00ff, "rcmm" },
- { RC_PROTO_RCMM32, "rcmm-32", 0x, "rcmm" },
+ { RC_PROTO_RCMM12, "rcmm-12", 0x0fff, "rc-mm" },
+ { RC_PROTO_RCMM24, "rcmm-24", 0x00ff, "rc-mm" },
+ { RC_PROTO_RCMM32, "rcmm-32", 0x, "rc-mm" },
};
int lirc_open(const char *rc)
--
2.21.0
[PATCH v4] keytable: Add keymap test
This new test will try to parse all the ".toml" files in the directory
path passed to it, error'ing out if there were parsing problems.
Run as "make check" in the keytable directory.
Signed-off-by: Bastien Nocera
---
utils/keytable/Makefile.am | 6 +++
utils/keytable/check_keymaps.c | 67 ++
2 files changed, 73 insertions(+)
create mode 100644 utils/keytable/check_keymaps.c
diff --git a/utils/keytable/Makefile.am b/utils/keytable/Makefile.am
index 148b9446..eb296475 100644
--- a/utils/keytable/Makefile.am
+++ b/utils/keytable/Makefile.am
@@ -1,9 +1,12 @@
bin_PROGRAMS = ir-keytable
+noinst_PROGRAMS = check-keymaps
man_MANS = ir-keytable.1 rc_keymap.5
sysconf_DATA = rc_maps.cfg
keytablesystem_DATA = $(srcdir)/rc_keymaps/*
udevrules_DATA = 70-infrared.rules
+check_keymaps_SOURCES = toml.c toml.h check_keymaps.c
+
ir_keytable_SOURCES = keytable.c parse.h ir-encode.c ir-encode.h toml.c toml.h
if WITH_BPF
@@ -21,6 +24,9 @@ endif
EXTRA_DIST = 70-infrared.rules rc_keymaps rc_keymaps_userspace
gen_keytables.pl ir-keytable.1 rc_maps.cfg rc_keymap.5
# custom target
+check: check-keymaps
+ $(builddir)/check-keymaps $(srcdir)/rc_keymaps/
+
install-data-local:
$(install_sh) -d "$(DESTDIR)$(keytableuserdir)"
diff --git a/utils/keytable/check_keymaps.c b/utils/keytable/check_keymaps.c
new file mode 100644
index ..eb8e3e8f
--- /dev/null
+++ b/utils/keytable/check_keymaps.c
@@ -0,0 +1,67 @@
+#include
+#include
+#include
+#include
+#include
+
+#include "toml.h"
+
+static int
+has_suffix(const char *str, const char *suffix)
+{
+ if (strlen(str) < strlen(suffix))
+ return 0;
+ if (strncmp(str + strlen(str) - strlen(suffix), suffix, strlen(suffix))
== 0)
+ return 1;
+ return 0;
+}
+
+int main (int argc, char **argv)
+{
+ DIR *dir;
+ struct dirent *entry;
+ int ret = 0;
+
+ if (argc != 2) {
+ fprintf(stderr, "Usage: %s KEYMAPS-DIRECTORY\n", argv[0]);
+ return 1;
+ }
+
+ dir = opendir(argv[1]);
+ if (!dir) {
+ perror("Could not open directory");
+ return 1;
+ }
+
+ while ((entry = readdir(dir)) != NULL) {
+ struct toml_table_t *root;
+ FILE *fin;
+ char buf[200];
+ char path[2048];
+
+ if (!has_suffix(entry->d_name, ".toml")) {
+ /* Skipping file */
+ continue;
+ }
+
+ snprintf(path, sizeof(path), "%s/%s", argv[1], entry->d_name);
+ path[sizeof(path) - 1] = '\0';
+
+ fin = fopen(path, "r");
+ if (!fin) {
+ fprintf(stderr, "Could not open file %s: %s", path,
strerror(errno));
+ ret = 1;
+ continue;
+ }
+
+ root = toml_parse_file(fin, buf, sizeof(buf));
+ fclose(fin);
+ if (!root) {
+ fprintf(stderr, "Failed to parse %s: %s\n", path, buf);
+ ret = 1;
+ }
+ toml_free(root);
+ }
+
+ return ret;
+}
--
2.21.0
Re: [PATCH v3] keytable: Add keymap test
On Thu, Jul 04, 2019 at 03:24:54PM +0200, Bastien Nocera wrote:
> This new test will try to parse all the ".toml" files in the directory
> path passed to it, error'ing out on the first parsing problem.
That is no longer true. It reads all files and does not error out after
the first parse problem.
>
> Run as "make check" in the keytable directory.
>
> Signed-off-by: Bastien Nocera
> ---
> utils/keytable/Makefile.am | 6 +++
> utils/keytable/check_keymaps.c | 67 ++
> 2 files changed, 73 insertions(+)
> create mode 100644 utils/keytable/check_keymaps.c
>
> diff --git a/utils/keytable/Makefile.am b/utils/keytable/Makefile.am
> index 148b9446..eb296475 100644
> --- a/utils/keytable/Makefile.am
> +++ b/utils/keytable/Makefile.am
> @@ -1,9 +1,12 @@
> bin_PROGRAMS = ir-keytable
> +noinst_PROGRAMS = check-keymaps
> man_MANS = ir-keytable.1 rc_keymap.5
> sysconf_DATA = rc_maps.cfg
> keytablesystem_DATA = $(srcdir)/rc_keymaps/*
> udevrules_DATA = 70-infrared.rules
>
> +check_keymaps_SOURCES = toml.c toml.h check_keymaps.c
> +
> ir_keytable_SOURCES = keytable.c parse.h ir-encode.c ir-encode.h toml.c
> toml.h
>
> if WITH_BPF
> @@ -21,6 +24,9 @@ endif
> EXTRA_DIST = 70-infrared.rules rc_keymaps rc_keymaps_userspace
> gen_keytables.pl ir-keytable.1 rc_maps.cfg rc_keymap.5
>
> # custom target
> +check: check-keymaps
> + $(builddir)/check-keymaps $(srcdir)/rc_keymaps/
> +
> install-data-local:
> $(install_sh) -d "$(DESTDIR)$(keytableuserdir)"
>
> diff --git a/utils/keytable/check_keymaps.c b/utils/keytable/check_keymaps.c
> new file mode 100644
> index ..eb8e3e8f
> --- /dev/null
> +++ b/utils/keytable/check_keymaps.c
> @@ -0,0 +1,67 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "toml.h"
> +
> +static int
> +has_suffix(const char *str, const char *suffix)
> +{
> + if (strlen(str) < strlen(suffix))
> + return 0;
> + if (strncmp(str + strlen(str) - strlen(suffix), suffix, strlen(suffix))
> == 0)
strcmp would work here.
> + return 1;
> + return 0;
> +}
> +
> +int main (int argc, char **argv)
> +{
> + DIR *dir;
> + struct dirent *entry;
> + int ret = 0;
> +
> + if (argc != 2) {
> + fprintf(stderr, "Usage: %s KEYMAPS-DIRECTORY\n", argv[0]);
> + return 1;
> + }
> +
> + dir = opendir(argv[1]);
> + if (!dir) {
> + perror("Could not open directory");
> + return 1;
> + }
> +
> + while ((entry = readdir(dir)) != NULL) {
> + struct toml_table_t *root;
> + FILE *fin;
> + char buf[200];
> + char path[2048];
> +
> + if (!has_suffix(entry->d_name, ".toml")) {
> + /* Skipping file */
> + continue;
> + }
> +
> + snprintf(path, sizeof(path), "%s/%s", argv[1], entry->d_name);
> + path[sizeof(path) - 1] = '\0';
snprintf() always adds a zero terminator, so the last line is not needed. I
know some implementations of snprintf() on platforms other than Linux are
broken, but we don't care about that.
> +
> + fin = fopen(path, "r");
> + if (!fin) {
> + fprintf(stderr, "Could not open file %s: %s", path,
> strerror(errno));
> + ret = 1;
> + continue;
> + }
> +
> + root = toml_parse_file(fin, buf, sizeof(buf));
> + fclose(fin);
> + if (!root) {
> + fprintf(stderr, "Failed to parse %s: %s\n", path, buf);
> + ret = 1;
> + }
> + toml_free(root);
> + }
> +
> + return ret;
> +}
> --
> 2.21.0
[PATCH v3] keytable: Add keymap test
This new test will try to parse all the ".toml" files in the directory
path passed to it, error'ing out on the first parsing problem.
Run as "make check" in the keytable directory.
Signed-off-by: Bastien Nocera
---
utils/keytable/Makefile.am | 6 +++
utils/keytable/check_keymaps.c | 67 ++
2 files changed, 73 insertions(+)
create mode 100644 utils/keytable/check_keymaps.c
diff --git a/utils/keytable/Makefile.am b/utils/keytable/Makefile.am
index 148b9446..eb296475 100644
--- a/utils/keytable/Makefile.am
+++ b/utils/keytable/Makefile.am
@@ -1,9 +1,12 @@
bin_PROGRAMS = ir-keytable
+noinst_PROGRAMS = check-keymaps
man_MANS = ir-keytable.1 rc_keymap.5
sysconf_DATA = rc_maps.cfg
keytablesystem_DATA = $(srcdir)/rc_keymaps/*
udevrules_DATA = 70-infrared.rules
+check_keymaps_SOURCES = toml.c toml.h check_keymaps.c
+
ir_keytable_SOURCES = keytable.c parse.h ir-encode.c ir-encode.h toml.c toml.h
if WITH_BPF
@@ -21,6 +24,9 @@ endif
EXTRA_DIST = 70-infrared.rules rc_keymaps rc_keymaps_userspace
gen_keytables.pl ir-keytable.1 rc_maps.cfg rc_keymap.5
# custom target
+check: check-keymaps
+ $(builddir)/check-keymaps $(srcdir)/rc_keymaps/
+
install-data-local:
$(install_sh) -d "$(DESTDIR)$(keytableuserdir)"
diff --git a/utils/keytable/check_keymaps.c b/utils/keytable/check_keymaps.c
new file mode 100644
index ..eb8e3e8f
--- /dev/null
+++ b/utils/keytable/check_keymaps.c
@@ -0,0 +1,67 @@
+#include
+#include
+#include
+#include
+#include
+
+#include "toml.h"
+
+static int
+has_suffix(const char *str, const char *suffix)
+{
+ if (strlen(str) < strlen(suffix))
+ return 0;
+ if (strncmp(str + strlen(str) - strlen(suffix), suffix, strlen(suffix))
== 0)
+ return 1;
+ return 0;
+}
+
+int main (int argc, char **argv)
+{
+ DIR *dir;
+ struct dirent *entry;
+ int ret = 0;
+
+ if (argc != 2) {
+ fprintf(stderr, "Usage: %s KEYMAPS-DIRECTORY\n", argv[0]);
+ return 1;
+ }
+
+ dir = opendir(argv[1]);
+ if (!dir) {
+ perror("Could not open directory");
+ return 1;
+ }
+
+ while ((entry = readdir(dir)) != NULL) {
+ struct toml_table_t *root;
+ FILE *fin;
+ char buf[200];
+ char path[2048];
+
+ if (!has_suffix(entry->d_name, ".toml")) {
+ /* Skipping file */
+ continue;
+ }
+
+ snprintf(path, sizeof(path), "%s/%s", argv[1], entry->d_name);
+ path[sizeof(path) - 1] = '\0';
+
+ fin = fopen(path, "r");
+ if (!fin) {
+ fprintf(stderr, "Could not open file %s: %s", path,
strerror(errno));
+ ret = 1;
+ continue;
+ }
+
+ root = toml_parse_file(fin, buf, sizeof(buf));
+ fclose(fin);
+ if (!root) {
+ fprintf(stderr, "Failed to parse %s: %s\n", path, buf);
+ ret = 1;
+ }
+ toml_free(root);
+ }
+
+ return ret;
+}
--
2.21.0
Re: [PATCH v2] keytable: Add keymap test
On Mon, 2019-07-01 at 16:27 +0200, Bastien Nocera wrote: > > That would be great. They have to be patched in the kernel tree, > > they > > are generated from there. > > It's customary to put a comment at the top of generated files > indicating that they shouldn't be modified and list the name and > version of the tools used to generate that file. > > So, what's the name of the tool used, and where does it live? :) Apparently it's called gen_keytables.pl, and I've sent a couple of patches to it because it didn't ignore comments, and then sent a couple of mails to broken definitions in the kernel. Once the 3 broken definitions in the kernel are fixed, fixing all the keymaps in v4l-utils will be as easy as regenerating the keymaps, and I'll send the updated patch for the "check" target. Don't forget to remove the files before generating them again, a number of keymaps were removed from the upstream kernel. Cheers
Re: [PATCH v2] keytable: Add keymap test
On Thu, 2019-06-27 at 20:33 +0100, Sean Young wrote:
> On Thu, Jun 27, 2019 at 10:13:56AM +0200, Bastien Nocera wrote:
> > This new test will try to parse all the ".toml" files in the
> > directory
> > path passed to it, error'ing out on the first parsing problem.
> >
> > Run as "make check" in the keytable directory.
>
> Good catch, and I like your solution.
>
> It needs a Signed-off-by.
>
> > ---
> > Changes since v1:
> > - Fix patch formatting
> >
> > At least 4 keymaps look broken in the current git:
> > it913x_v2.toml
> > pinnacle310e.toml
> > hisi_poplar.toml
> > imon_mce.toml
> >
> > Let me know if you want patches to remove the duplicate entries
> > from
> > those.
>
> That would be great. They have to be patched in the kernel tree, they
> are generated from there.
It's customary to put a comment at the top of generated files
indicating that they shouldn't be modified and list the name and
version of the tools used to generate that file.
So, what's the name of the tool used, and where does it live? :)
> > utils/keytable/Makefile.am| 6
> > utils/keytable/test_keymaps.c | 68
> > +++
> > 2 files changed, 74 insertions(+)
> > create mode 100644 utils/keytable/test_keymaps.c
> >
> > diff --git a/utils/keytable/Makefile.am
> > b/utils/keytable/Makefile.am
> > index 148b9446..086d53c2 100644
> > --- a/utils/keytable/Makefile.am
> > +++ b/utils/keytable/Makefile.am
> > @@ -1,9 +1,12 @@
> > bin_PROGRAMS = ir-keytable
> > +noinst_PROGRAMS = test-keymaps
> > man_MANS = ir-keytable.1 rc_keymap.5
> > sysconf_DATA = rc_maps.cfg
> > keytablesystem_DATA = $(srcdir)/rc_keymaps/*
> > udevrules_DATA = 70-infrared.rules
> >
> > +test_keymaps_SOURCES = toml.c toml.h test_keymaps.c
> > +
>
> It could be called check keymaps in line with the make target.
I usually call tests "test" as they aren't beholden to the "check"
target to be run, but up to you.
> > ir_keytable_SOURCES = keytable.c parse.h ir-encode.c ir-encode.h
> > toml.c toml.h
> >
> > if WITH_BPF
> > @@ -21,6 +24,9 @@ endif
> > EXTRA_DIST = 70-infrared.rules rc_keymaps rc_keymaps_userspace
> > gen_keytables.pl ir-keytable.1 rc_maps.cfg rc_keymap.5
> >
> > # custom target
> > +check: test-keymaps
> > + $(builddir)/test-keymaps $(srcdir)/rc_keymaps/
> > +
> > install-data-local:
> > $(install_sh) -d "$(DESTDIR)$(keytableuserdir)"
> >
> > diff --git a/utils/keytable/test_keymaps.c
> > b/utils/keytable/test_keymaps.c
> > new file mode 100644
> > index ..23084331
> > --- /dev/null
> > +++ b/utils/keytable/test_keymaps.c
> > @@ -0,0 +1,68 @@
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "toml.h"
> > +
> > +static int
> > +has_suffix(const char *str, const char *suffix)
> > +{
> > + if (strlen(str) < strlen(suffix))
> > + return 0;
> > + if (strncmp(str + strlen(str) - strlen(suffix), suffix,
> > strlen(suffix)) == 0)
> > + return 1;
> > + return 0;
> > +}
> > +
> > +int main (int argc, char **argv)
> > +{
> > + DIR *dir;
> > + struct dirent *entry;
> > +
> > + if (argc != 2) {
> > + fprintf(stderr, "Usage: %s KEYMAPS-DIRECTORY\n",
> > argv[0]);
> > + return 1;
> > + }
> > +
> > + dir = opendir(argv[1]);
> > + if (!dir) {
> > + perror("Could not open directory");
> > + return 1;
> > + }
> > +
> > + while ((entry = readdir(dir)) != NULL) {
> > + struct toml_table_t *root;
> > + FILE *fin;
> > + char buf[200];
> > + char path[2048];
> > +
> > + if (!has_suffix(entry->d_name, ".toml")) {
> > + /* Skipping file */
> > + continue;
> > + }
> > +
> > + memset(path, 0, sizeof(path));
> > + strcpy(path, argv[1]);
> > + strcpy(path + strlen(argv[1]), "/");
> > + strcpy(path + strlen(argv[1]) + 1, entry->d_name);
> > + strcpy(path + strlen(argv[1]) + 1 + strlen(entry-
> > >d_name), "\0");
>
> These five lines could be replaced with a single snprintf().
You're right, it's marginally better.
> > +
> > + fin = fopen(path, "r");
> > + if (!fin) {
> > + fprintf(stderr, "Could not open file %s: %s",
> > path, strerror(errno));
> > + return 1;
> > + }
> > +
> > + root = toml_parse_file(fin, buf, sizeof(buf));
> > + fclose(fin);
> > + if (!root) {
> > + fprintf(stderr, "Failed to parse %s: %s\n",
> > path, buf);
> > + return 1;
> > + }
> > + toml_free(root);
> > + }
> > +
> > + return 0;
> > +}
>
> Great idea!
>
> Thanks
> Sean
Re: [PATCH v3] keytable: Add keymap test
On Mon, 2019-07-01 at 12:28 +0100, Sean Young wrote: > On Fri, Jun 28, 2019 at 11:45:29AM +0200, Bastien Nocera wrote: > > This new test will try to parse all the ".toml" files in the > > directory > > path passed to it, error'ing out on the first parsing problem. > > > > Run as "make check" in the keytable directory. > > > > Signed-off-by: Bastien Nocera > > --- > > Changes since v2: > > - Added SoB > > What about the other comments? Please mention as early as possible in your review mails that there's more comments below. I can't guess that from the mail you sent, see the screenshot attached.
Re: [PATCH v3] keytable: Add keymap test
On Fri, Jun 28, 2019 at 11:45:29AM +0200, Bastien Nocera wrote:
> This new test will try to parse all the ".toml" files in the directory
> path passed to it, error'ing out on the first parsing problem.
>
> Run as "make check" in the keytable directory.
>
> Signed-off-by: Bastien Nocera
> ---
> Changes since v2:
> - Added SoB
What about the other comments?
>
> Changes since v1:
> - Fix patch formatting
>
> At least 4 keymaps look broken in the current git:
> it913x_v2.toml
> pinnacle310e.toml
> hisi_poplar.toml
> imon_mce.toml
>
> Let me know if you want patches to remove the duplicate entries from
> those.
Actually we need those patches before we can merge this.
>
> utils/keytable/Makefile.am| 6
> utils/keytable/test_keymaps.c | 68 +++
> 2 files changed, 74 insertions(+)
> create mode 100644 utils/keytable/test_keymaps.c
>
> diff --git a/utils/keytable/Makefile.am b/utils/keytable/Makefile.am
> index 148b9446..086d53c2 100644
> --- a/utils/keytable/Makefile.am
> +++ b/utils/keytable/Makefile.am
> @@ -1,9 +1,12 @@
> bin_PROGRAMS = ir-keytable
> +noinst_PROGRAMS = test-keymaps
> man_MANS = ir-keytable.1 rc_keymap.5
> sysconf_DATA = rc_maps.cfg
> keytablesystem_DATA = $(srcdir)/rc_keymaps/*
> udevrules_DATA = 70-infrared.rules
>
> +test_keymaps_SOURCES = toml.c toml.h test_keymaps.c
> +
> ir_keytable_SOURCES = keytable.c parse.h ir-encode.c ir-encode.h toml.c
> toml.h
>
> if WITH_BPF
> @@ -21,6 +24,9 @@ endif
> EXTRA_DIST = 70-infrared.rules rc_keymaps rc_keymaps_userspace
> gen_keytables.pl ir-keytable.1 rc_maps.cfg rc_keymap.5
>
> # custom target
> +check: test-keymaps
> + $(builddir)/test-keymaps $(srcdir)/rc_keymaps/
> +
> install-data-local:
> $(install_sh) -d "$(DESTDIR)$(keytableuserdir)"
>
> diff --git a/utils/keytable/test_keymaps.c b/utils/keytable/test_keymaps.c
> new file mode 100644
> index ..23084331
> --- /dev/null
> +++ b/utils/keytable/test_keymaps.c
> @@ -0,0 +1,68 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "toml.h"
> +
> +static int
> +has_suffix(const char *str, const char *suffix)
> +{
> + if (strlen(str) < strlen(suffix))
> + return 0;
> + if (strncmp(str + strlen(str) - strlen(suffix), suffix, strlen(suffix))
> == 0)
> + return 1;
> + return 0;
> +}
> +
> +int main (int argc, char **argv)
> +{
> + DIR *dir;
> + struct dirent *entry;
> +
> + if (argc != 2) {
> + fprintf(stderr, "Usage: %s KEYMAPS-DIRECTORY\n", argv[0]);
> + return 1;
> + }
> +
> + dir = opendir(argv[1]);
> + if (!dir) {
> + perror("Could not open directory");
> + return 1;
> + }
> +
> + while ((entry = readdir(dir)) != NULL) {
> + struct toml_table_t *root;
> + FILE *fin;
> + char buf[200];
> + char path[2048];
> +
> + if (!has_suffix(entry->d_name, ".toml")) {
> + /* Skipping file */
> + continue;
> + }
> +
> + memset(path, 0, sizeof(path));
> + strcpy(path, argv[1]);
> + strcpy(path + strlen(argv[1]), "/");
> + strcpy(path + strlen(argv[1]) + 1, entry->d_name);
> + strcpy(path + strlen(argv[1]) + 1 + strlen(entry->d_name),
> "\0");
> +
> + fin = fopen(path, "r");
> + if (!fin) {
> + fprintf(stderr, "Could not open file %s: %s", path,
> strerror(errno));
> + return 1;
> + }
> +
> + root = toml_parse_file(fin, buf, sizeof(buf));
> + fclose(fin);
> + if (!root) {
> + fprintf(stderr, "Failed to parse %s: %s\n", path, buf);
> + return 1;
> + }
> + toml_free(root);
> + }
> +
> + return 0;
> +}
[PATCH v3] keytable: Add keymap test
This new test will try to parse all the ".toml" files in the directory
path passed to it, error'ing out on the first parsing problem.
Run as "make check" in the keytable directory.
Signed-off-by: Bastien Nocera
---
Changes since v2:
- Added SoB
Changes since v1:
- Fix patch formatting
At least 4 keymaps look broken in the current git:
it913x_v2.toml
pinnacle310e.toml
hisi_poplar.toml
imon_mce.toml
Let me know if you want patches to remove the duplicate entries from
those.
utils/keytable/Makefile.am| 6
utils/keytable/test_keymaps.c | 68 +++
2 files changed, 74 insertions(+)
create mode 100644 utils/keytable/test_keymaps.c
diff --git a/utils/keytable/Makefile.am b/utils/keytable/Makefile.am
index 148b9446..086d53c2 100644
--- a/utils/keytable/Makefile.am
+++ b/utils/keytable/Makefile.am
@@ -1,9 +1,12 @@
bin_PROGRAMS = ir-keytable
+noinst_PROGRAMS = test-keymaps
man_MANS = ir-keytable.1 rc_keymap.5
sysconf_DATA = rc_maps.cfg
keytablesystem_DATA = $(srcdir)/rc_keymaps/*
udevrules_DATA = 70-infrared.rules
+test_keymaps_SOURCES = toml.c toml.h test_keymaps.c
+
ir_keytable_SOURCES = keytable.c parse.h ir-encode.c ir-encode.h toml.c toml.h
if WITH_BPF
@@ -21,6 +24,9 @@ endif
EXTRA_DIST = 70-infrared.rules rc_keymaps rc_keymaps_userspace
gen_keytables.pl ir-keytable.1 rc_maps.cfg rc_keymap.5
# custom target
+check: test-keymaps
+ $(builddir)/test-keymaps $(srcdir)/rc_keymaps/
+
install-data-local:
$(install_sh) -d "$(DESTDIR)$(keytableuserdir)"
diff --git a/utils/keytable/test_keymaps.c b/utils/keytable/test_keymaps.c
new file mode 100644
index ..23084331
--- /dev/null
+++ b/utils/keytable/test_keymaps.c
@@ -0,0 +1,68 @@
+#include
+#include
+#include
+#include
+#include
+
+#include "toml.h"
+
+static int
+has_suffix(const char *str, const char *suffix)
+{
+ if (strlen(str) < strlen(suffix))
+ return 0;
+ if (strncmp(str + strlen(str) - strlen(suffix), suffix, strlen(suffix))
== 0)
+ return 1;
+ return 0;
+}
+
+int main (int argc, char **argv)
+{
+ DIR *dir;
+ struct dirent *entry;
+
+ if (argc != 2) {
+ fprintf(stderr, "Usage: %s KEYMAPS-DIRECTORY\n", argv[0]);
+ return 1;
+ }
+
+ dir = opendir(argv[1]);
+ if (!dir) {
+ perror("Could not open directory");
+ return 1;
+ }
+
+ while ((entry = readdir(dir)) != NULL) {
+ struct toml_table_t *root;
+ FILE *fin;
+ char buf[200];
+ char path[2048];
+
+ if (!has_suffix(entry->d_name, ".toml")) {
+ /* Skipping file */
+ continue;
+ }
+
+ memset(path, 0, sizeof(path));
+ strcpy(path, argv[1]);
+ strcpy(path + strlen(argv[1]), "/");
+ strcpy(path + strlen(argv[1]) + 1, entry->d_name);
+ strcpy(path + strlen(argv[1]) + 1 + strlen(entry->d_name),
"\0");
+
+ fin = fopen(path, "r");
+ if (!fin) {
+ fprintf(stderr, "Could not open file %s: %s", path,
strerror(errno));
+ return 1;
+ }
+
+ root = toml_parse_file(fin, buf, sizeof(buf));
+ fclose(fin);
+ if (!root) {
+ fprintf(stderr, "Failed to parse %s: %s\n", path, buf);
+ return 1;
+ }
+ toml_free(root);
+ }
+
+ return 0;
+}
Re: [PATCH v2] keytable: Add keymap test
On Thu, Jun 27, 2019 at 10:13:56AM +0200, Bastien Nocera wrote:
> This new test will try to parse all the ".toml" files in the directory
> path passed to it, error'ing out on the first parsing problem.
>
> Run as "make check" in the keytable directory.
Good catch, and I like your solution.
It needs a Signed-off-by.
> ---
> Changes since v1:
> - Fix patch formatting
>
> At least 4 keymaps look broken in the current git:
> it913x_v2.toml
> pinnacle310e.toml
> hisi_poplar.toml
> imon_mce.toml
>
> Let me know if you want patches to remove the duplicate entries from
> those.
That would be great. They have to be patched in the kernel tree, they
are generated from there.
> utils/keytable/Makefile.am| 6
> utils/keytable/test_keymaps.c | 68 +++
> 2 files changed, 74 insertions(+)
> create mode 100644 utils/keytable/test_keymaps.c
>
> diff --git a/utils/keytable/Makefile.am b/utils/keytable/Makefile.am
> index 148b9446..086d53c2 100644
> --- a/utils/keytable/Makefile.am
> +++ b/utils/keytable/Makefile.am
> @@ -1,9 +1,12 @@
> bin_PROGRAMS = ir-keytable
> +noinst_PROGRAMS = test-keymaps
> man_MANS = ir-keytable.1 rc_keymap.5
> sysconf_DATA = rc_maps.cfg
> keytablesystem_DATA = $(srcdir)/rc_keymaps/*
> udevrules_DATA = 70-infrared.rules
>
> +test_keymaps_SOURCES = toml.c toml.h test_keymaps.c
> +
It could be called check keymaps in line with the make target.
> ir_keytable_SOURCES = keytable.c parse.h ir-encode.c ir-encode.h toml.c
> toml.h
>
> if WITH_BPF
> @@ -21,6 +24,9 @@ endif
> EXTRA_DIST = 70-infrared.rules rc_keymaps rc_keymaps_userspace
> gen_keytables.pl ir-keytable.1 rc_maps.cfg rc_keymap.5
>
> # custom target
> +check: test-keymaps
> + $(builddir)/test-keymaps $(srcdir)/rc_keymaps/
> +
> install-data-local:
> $(install_sh) -d "$(DESTDIR)$(keytableuserdir)"
>
> diff --git a/utils/keytable/test_keymaps.c b/utils/keytable/test_keymaps.c
> new file mode 100644
> index ..23084331
> --- /dev/null
> +++ b/utils/keytable/test_keymaps.c
> @@ -0,0 +1,68 @@
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "toml.h"
> +
> +static int
> +has_suffix(const char *str, const char *suffix)
> +{
> + if (strlen(str) < strlen(suffix))
> + return 0;
> + if (strncmp(str + strlen(str) - strlen(suffix), suffix, strlen(suffix))
> == 0)
> + return 1;
> + return 0;
> +}
> +
> +int main (int argc, char **argv)
> +{
> + DIR *dir;
> + struct dirent *entry;
> +
> + if (argc != 2) {
> + fprintf(stderr, "Usage: %s KEYMAPS-DIRECTORY\n", argv[0]);
> + return 1;
> + }
> +
> + dir = opendir(argv[1]);
> + if (!dir) {
> + perror("Could not open directory");
> + return 1;
> + }
> +
> + while ((entry = readdir(dir)) != NULL) {
> + struct toml_table_t *root;
> + FILE *fin;
> + char buf[200];
> + char path[2048];
> +
> + if (!has_suffix(entry->d_name, ".toml")) {
> + /* Skipping file */
> + continue;
> + }
> +
> + memset(path, 0, sizeof(path));
> + strcpy(path, argv[1]);
> + strcpy(path + strlen(argv[1]), "/");
> + strcpy(path + strlen(argv[1]) + 1, entry->d_name);
> + strcpy(path + strlen(argv[1]) + 1 + strlen(entry->d_name),
> "\0");
These five lines could be replaced with a single snprintf().
> +
> + fin = fopen(path, "r");
> + if (!fin) {
> + fprintf(stderr, "Could not open file %s: %s", path,
> strerror(errno));
> + return 1;
> + }
> +
> + root = toml_parse_file(fin, buf, sizeof(buf));
> + fclose(fin);
> + if (!root) {
> + fprintf(stderr, "Failed to parse %s: %s\n", path, buf);
> + return 1;
> + }
> + toml_free(root);
> + }
> +
> + return 0;
> +}
Great idea!
Thanks
Sean
[PATCH v2] keytable: Add keymap test
This new test will try to parse all the ".toml" files in the directory
path passed to it, error'ing out on the first parsing problem.
Run as "make check" in the keytable directory.
---
Changes since v1:
- Fix patch formatting
At least 4 keymaps look broken in the current git:
it913x_v2.toml
pinnacle310e.toml
hisi_poplar.toml
imon_mce.toml
Let me know if you want patches to remove the duplicate entries from
those.
utils/keytable/Makefile.am| 6
utils/keytable/test_keymaps.c | 68 +++
2 files changed, 74 insertions(+)
create mode 100644 utils/keytable/test_keymaps.c
diff --git a/utils/keytable/Makefile.am b/utils/keytable/Makefile.am
index 148b9446..086d53c2 100644
--- a/utils/keytable/Makefile.am
+++ b/utils/keytable/Makefile.am
@@ -1,9 +1,12 @@
bin_PROGRAMS = ir-keytable
+noinst_PROGRAMS = test-keymaps
man_MANS = ir-keytable.1 rc_keymap.5
sysconf_DATA = rc_maps.cfg
keytablesystem_DATA = $(srcdir)/rc_keymaps/*
udevrules_DATA = 70-infrared.rules
+test_keymaps_SOURCES = toml.c toml.h test_keymaps.c
+
ir_keytable_SOURCES = keytable.c parse.h ir-encode.c ir-encode.h toml.c toml.h
if WITH_BPF
@@ -21,6 +24,9 @@ endif
EXTRA_DIST = 70-infrared.rules rc_keymaps rc_keymaps_userspace
gen_keytables.pl ir-keytable.1 rc_maps.cfg rc_keymap.5
# custom target
+check: test-keymaps
+ $(builddir)/test-keymaps $(srcdir)/rc_keymaps/
+
install-data-local:
$(install_sh) -d "$(DESTDIR)$(keytableuserdir)"
diff --git a/utils/keytable/test_keymaps.c b/utils/keytable/test_keymaps.c
new file mode 100644
index ..23084331
--- /dev/null
+++ b/utils/keytable/test_keymaps.c
@@ -0,0 +1,68 @@
+#include
+#include
+#include
+#include
+#include
+
+#include "toml.h"
+
+static int
+has_suffix(const char *str, const char *suffix)
+{
+ if (strlen(str) < strlen(suffix))
+ return 0;
+ if (strncmp(str + strlen(str) - strlen(suffix), suffix, strlen(suffix))
== 0)
+ return 1;
+ return 0;
+}
+
+int main (int argc, char **argv)
+{
+ DIR *dir;
+ struct dirent *entry;
+
+ if (argc != 2) {
+ fprintf(stderr, "Usage: %s KEYMAPS-DIRECTORY\n", argv[0]);
+ return 1;
+ }
+
+ dir = opendir(argv[1]);
+ if (!dir) {
+ perror("Could not open directory");
+ return 1;
+ }
+
+ while ((entry = readdir(dir)) != NULL) {
+ struct toml_table_t *root;
+ FILE *fin;
+ char buf[200];
+ char path[2048];
+
+ if (!has_suffix(entry->d_name, ".toml")) {
+ /* Skipping file */
+ continue;
+ }
+
+ memset(path, 0, sizeof(path));
+ strcpy(path, argv[1]);
+ strcpy(path + strlen(argv[1]), "/");
+ strcpy(path + strlen(argv[1]) + 1, entry->d_name);
+ strcpy(path + strlen(argv[1]) + 1 + strlen(entry->d_name),
"\0");
+
+ fin = fopen(path, "r");
+ if (!fin) {
+ fprintf(stderr, "Could not open file %s: %s", path,
strerror(errno));
+ return 1;
+ }
+
+ root = toml_parse_file(fin, buf, sizeof(buf));
+ fclose(fin);
+ if (!root) {
+ fprintf(stderr, "Failed to parse %s: %s\n", path, buf);
+ return 1;
+ }
+ toml_free(root);
+ }
+
+ return 0;
+}
[PATCH] keytable: Add keymap test
This new test will try to parse all the ".toml" files in the directory
path passed to it, error'ing out on the first parsing problem.
Run as "make check" in the keytable directory.
---
At least 4 keymaps look broken in the current git:
it913x_v2.toml
pinnacle310e.toml
hisi_poplar.toml
imon_mce.toml
Let me know if you want patches to remove the duplicate entries from
those.
utils/keytable/Makefile.am| 6
utils/keytable/test_keymaps.c | 68 +++
2 files changed, 74 insertions(+)
create mode 100644 utils/keytable/test_keymaps.c
diff --git a/utils/keytable/Makefile.am b/utils/keytable/Makefile.am
index 148b9446..086d53c2 100644
--- a/utils/keytable/Makefile.am
+++ b/utils/keytable/Makefile.am
@@ -1,9 +1,12 @@
bin_PROGRAMS = ir-keytable
+noinst_PROGRAMS = test-keymaps
man_MANS = ir-keytable.1 rc_keymap.5
sysconf_DATA = rc_maps.cfg
keytablesystem_DATA = $(srcdir)/rc_keymaps/*
udevrules_DATA = 70-infrared.rules
+test_keymaps_SOURCES = toml.c toml.h test_keymaps.c
+
ir_keytable_SOURCES = keytable.c parse.h ir-encode.c ir-encode.h
toml.c toml.h
if WITH_BPF
@@ -21,6 +24,9 @@ endif
EXTRA_DIST = 70-infrared.rules rc_keymaps rc_keymaps_userspace
gen_keytables.pl ir-keytable.1 rc_maps.cfg rc_keymap.5
# custom target
+check: test-keymaps
+ $(builddir)/test-keymaps $(srcdir)/rc_keymaps/
+
install-data-local:
$(install_sh) -d "$(DESTDIR)$(keytableuserdir)"
diff --git a/utils/keytable/test_keymaps.c
b/utils/keytable/test_keymaps.c
new file mode 100644
index ..23084331
--- /dev/null
+++ b/utils/keytable/test_keymaps.c
@@ -0,0 +1,68 @@
+#include
+#include
+#include
+#include
+#include
+
+#include "toml.h"
+
+static int
+has_suffix(const char *str, const char *suffix)
+{
+ if (strlen(str) < strlen(suffix))
+ return 0;
+ if (strncmp(str + strlen(str) - strlen(suffix), suffix,
strlen(suffix)) == 0)
+ return 1;
+ return 0;
+}
+
+int main (int argc, char **argv)
+{
+ DIR *dir;
+ struct dirent *entry;
+
+ if (argc != 2) {
+ fprintf(stderr, "Usage: %s KEYMAPS-DIRECTORY\n",
argv[0]);
+ return 1;
+ }
+
+ dir = opendir(argv[1]);
+ if (!dir) {
+ perror("Could not open directory");
+ return 1;
+ }
+
+ while ((entry = readdir(dir)) != NULL) {
+ struct toml_table_t *root;
+ FILE *fin;
+ char buf[200];
+ char path[2048];
+
+ if (!has_suffix(entry->d_name, ".toml")) {
+ /* Skipping file */
+ continue;
+ }
+
+ memset(path, 0, sizeof(path));
+ strcpy(path, argv[1]);
+ strcpy(path + strlen(argv[1]), "/");
+ strcpy(path + strlen(argv[1]) + 1, entry->d_name);
+ strcpy(path + strlen(argv[1]) + 1 + strlen(entry-
>d_name), "\0");
+
+ fin = fopen(path, "r");
+ if (!fin) {
+ fprintf(stderr, "Could not open file %s: %s",
path, strerror(errno));
+ return 1;
+ }
+
+ root = toml_parse_file(fin, buf, sizeof(buf));
+ fclose(fin);
+ if (!root) {
+ fprintf(stderr, "Failed to parse %s: %s\n",
path, buf);
+ return 1;
+ }
+ toml_free(root);
+ }
+
+ return 0;
+}
[PATCH] media: v4l2: Test type instead of cfg->type in v4l2_ctrl_new_custom()
cfg->type can be overridden by v4l2_ctrl_fill() and the new value is
stored in the local type var. Fix the tests to use this local var.
Fixes: 0996517cf8ea ("V4L/DVB: v4l2: Add new control handling framework")
Cc:
Signed-off-by: Boris Brezillon
---
drivers/media/v4l2-core/v4l2-ctrls.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index c342385baec3..1acc249aaeed 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -2470,16 +2470,15 @@ struct v4l2_ctrl *v4l2_ctrl_new_custom(struct
v4l2_ctrl_handler *hdl,
v4l2_ctrl_fill(cfg->id, &name, &type, &min, &max, &step,
&def, &flags);
- is_menu = (cfg->type == V4L2_CTRL_TYPE_MENU ||
- cfg->type == V4L2_CTRL_TYPE_INTEGER_MENU);
+ is_menu = (type == V4L2_CTRL_TYPE_MENU ||
+ type == V4L2_CTRL_TYPE_INTEGER_MENU);
if (is_menu)
WARN_ON(step);
else
WARN_ON(cfg->menu_skip_mask);
- if (cfg->type == V4L2_CTRL_TYPE_MENU && qmenu == NULL)
+ if (type == V4L2_CTRL_TYPE_MENU && qmenu == NULL) {
qmenu = v4l2_ctrl_get_menu(cfg->id);
- else if (cfg->type == V4L2_CTRL_TYPE_INTEGER_MENU &&
-qmenu_int == NULL) {
+ } else if (type == V4L2_CTRL_TYPE_INTEGER_MENU && qmenu_int == NULL) {
handler_set_err(hdl, -EINVAL);
return NULL;
}
--
2.20.1
[PATCH v2] ov8856: modify register to fix test pattern
From: Shawn Tu
modify registers to fix bayer order in test pattern mode
Signed-off-by: Shawn Tu
---
drivers/media/i2c/ov8856.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/ov8856.c b/drivers/media/i2c/ov8856.c
index dbf1095..cd347d6 100644
--- a/drivers/media/i2c/ov8856.c
+++ b/drivers/media/i2c/ov8856.c
@@ -195,11 +195,11 @@ static const struct ov8856_reg mode_3280x2464_regs[] = {
{0x3800, 0x00},
{0x3801, 0x00},
{0x3802, 0x00},
- {0x3803, 0x07},
+ {0x3803, 0x06},
{0x3804, 0x0c},
{0x3805, 0xdf},
{0x3806, 0x09},
- {0x3807, 0xa6},
+ {0x3807, 0xa7},
{0x3808, 0x0c},
{0x3809, 0xd0},
{0x380a, 0x09},
@@ -211,7 +211,7 @@ static const struct ov8856_reg mode_3280x2464_regs[] = {
{0x3810, 0x00},
{0x3811, 0x00},
{0x3812, 0x00},
- {0x3813, 0x00},
+ {0x3813, 0x01},
{0x3814, 0x01},
{0x3815, 0x01},
{0x3816, 0x00},
@@ -385,11 +385,11 @@ static const struct ov8856_reg mode_1640x1232_regs[] = {
{0x3800, 0x00},
{0x3801, 0x00},
{0x3802, 0x00},
- {0x3803, 0x07},
+ {0x3803, 0x06},
{0x3804, 0x0c},
{0x3805, 0xdf},
{0x3806, 0x09},
- {0x3807, 0xa6},
+ {0x3807, 0xa7},
{0x3808, 0x06},
{0x3809, 0x68},
{0x380a, 0x04},
@@ -401,7 +401,7 @@ static const struct ov8856_reg mode_1640x1232_regs[] = {
{0x3810, 0x00},
{0x3811, 0x00},
{0x3812, 0x00},
- {0x3813, 0x00},
+ {0x3813, 0x01},
{0x3814, 0x03},
{0x3815, 0x01},
{0x3816, 0x00},
--
2.7.4
[v1] media: ov8856: modify register to fix test pattern
modify registers to fix bayer order in test pattern mode
Signed-off-by: Shawnx Tu
---
drivers/media/i2c/ov8856.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/ov8856.c b/drivers/media/i2c/ov8856.c
index dbf1095..cd347d6 100644
--- a/drivers/media/i2c/ov8856.c
+++ b/drivers/media/i2c/ov8856.c
@@ -195,11 +195,11 @@ static const struct ov8856_reg mode_3280x2464_regs[] = {
{0x3800, 0x00},
{0x3801, 0x00},
{0x3802, 0x00},
- {0x3803, 0x07},
+ {0x3803, 0x06},
{0x3804, 0x0c},
{0x3805, 0xdf},
{0x3806, 0x09},
- {0x3807, 0xa6},
+ {0x3807, 0xa7},
{0x3808, 0x0c},
{0x3809, 0xd0},
{0x380a, 0x09},
@@ -211,7 +211,7 @@ static const struct ov8856_reg mode_3280x2464_regs[] = {
{0x3810, 0x00},
{0x3811, 0x00},
{0x3812, 0x00},
- {0x3813, 0x00},
+ {0x3813, 0x01},
{0x3814, 0x01},
{0x3815, 0x01},
{0x3816, 0x00},
@@ -385,11 +385,11 @@ static const struct ov8856_reg mode_1640x1232_regs[] = {
{0x3800, 0x00},
{0x3801, 0x00},
{0x3802, 0x00},
- {0x3803, 0x07},
+ {0x3803, 0x06},
{0x3804, 0x0c},
{0x3805, 0xdf},
{0x3806, 0x09},
- {0x3807, 0xa6},
+ {0x3807, 0xa7},
{0x3808, 0x06},
{0x3809, 0x68},
{0x380a, 0x04},
@@ -401,7 +401,7 @@ static const struct ov8856_reg mode_1640x1232_regs[] = {
{0x3810, 0x00},
{0x3811, 0x00},
{0x3812, 0x00},
- {0x3813, 0x00},
+ {0x3813, 0x01},
{0x3814, 0x03},
{0x3815, 0x01},
{0x3816, 0x00},
--
2.7.4
Re: [STATUS UPDATE] test-media regression script status
On 4/26/19 9:06 AM, Guillaume Tucker wrote:
> Hi Hans,
>
> On 13/03/2019 08:54, Hans Verkuil wrote:
>> Hi all,
>>
>> As you all know I have been working on creating a regression test script
>> to help catch regressions before they get into released kernels.
>>
>> The test-media script is in v4l-utils, contrib/test. It is currently testing
>> with vivid, vim2m and vimc. Once vicodec is stable enough it will be added
>> to the test suite as well.
>>
>> It is already run as part of the daily build using a kernel config with many
>> debug options enabled.
>
> Sounds great. Out of interest, do you have a config fragment or
> the list of debug configs enabled in your builds somewhere?
https://git.linuxtv.org/hverkuil/build-scripts.git/tree/configs/virtme.config
>
>> The daily build summary looks like this:
>>
>> virtme: OK: Final Summary: 1981, Succeeded: 1981, Failed: 0, Warnings:
>> 14
>>
>>
>>
>> Detailed regression test results are available here:
>>
>> http://www.xs4all.nl/~hverkuil/logs/Wednesday-test-media.log
>> http://www.xs4all.nl/~hverkuil/logs/Wednesday-test-media-dmesg.log
>>
>> The daily build is currently only checking for failures in the compliance
>> tests
>> and ignores warnings. It also ignores issues in the kernel log.
> [...]
>
>> The test can be run on a system (or VM) running the kernel you want to test
>> with
>> by simply running it as root.
>>
>> Usually for V4L2/MC changes it is enough to run it as:
>>
>> sudo test-media mc
>>
>> If you want the script to unload all media modules first, then add the
>> -unload
>> option. If you want the script to scan for memory leaks (and the
>> corresponding
>> debug option is enabled in the kernel), then add the -kmemleak option. To
>> dump
>> the kernel log when done, add the -dmesg option.
>>
>> Run test-media without options to see a help text.
>>
>> Note that 'mc' is shorthand for 'vivid vim2m vimc'.
>>
>> There are also cec compliance tests and the 'all' test which tests everything
>> (used in the daily build). The cec tests are slow (especially the cec-pwr
>> tests),
>> so unless you changed something in the cec subsystem you want to avoid
>> running
>> those.
>>
>> The test script assumes that the very latest v4l-utils are installed.
>
> This sounds very similar to what the KernelCI tests are doing.
> The main differences are that your script has a neater way of
> picking the media devices, and that the KernelCI tests break down
> the results into individual cases to spot regressions
> automatically [1].
>
> At the moment we have a shell script to parse the output of
> v4l2-compliance to find each test case result. Ultimately, it
> would be better to have some machine-readable output available,
> as I believe we've already agreed. It should then enable
> KernelCI to run your test-media script directly, removing extra
> post-processing and making the system more robust.
>
> If this sounds like a good idea then we can discuss how to
> proceed, i.e. agree on the format and command line options to
> enable it. A popular format which would seem suitable for this
> is TAP 13 [2]. As Michał now has a fix to address the last issue
> with the KernelCI email reports, we should be available to work
> on this next.
Sure, not a problem. As long as the same command line option and same
format it implemented for both v4l2-compliance and cec-compliance.
It's probably best to write the machine-readable output to a file,
so an option like --tap13 would be a natural choice.
Most (all?) tests are done like this:
printf("\ttest VIDIOC_QUERYCAP: %s\n", ok(testCap(&node)));
This should probably change to:
run_test("VIDIOC_QUERYCAP", testCap(&node));
And run_test() would then print the human readable text and, if enabled,
write the machine-readable results to a file.
There might be some corner cases where this is a bit more complex.
>
> [...]
>
>> Future plans (besides adding vicodec support) is adding support for other
>> drivers
>> like uvc and perhaps au0828 (for testing the upcoming Media Device Allocator
>> API).
>> But those tests require real hardware to be connected, and there may be
>> different
>> variants of the same hardware. We'll see how that will work out.
>
> This is obviously another strength of running the tests in
> KernelCI, such hardware could be added to an existing test lab.
Absolutely.
Regards,
Hans
>
> Best wishes,
> Guillaume
>
> [1]
> https://people.collabora.com/~gtucker/kernelci/doc/v4l2-compliance-uvcvideo-5.1-rc6.txt
> [2] https://testanything.org/tap-version-13-specification.html
>
Re: [STATUS UPDATE] test-media regression script status
Hi Hans, On 13/03/2019 08:54, Hans Verkuil wrote: > Hi all, > > As you all know I have been working on creating a regression test script > to help catch regressions before they get into released kernels. > > The test-media script is in v4l-utils, contrib/test. It is currently testing > with vivid, vim2m and vimc. Once vicodec is stable enough it will be added > to the test suite as well. > > It is already run as part of the daily build using a kernel config with many > debug options enabled. Sounds great. Out of interest, do you have a config fragment or the list of debug configs enabled in your builds somewhere? > The daily build summary looks like this: > > virtme: OK: Final Summary: 1981, Succeeded: 1981, Failed: 0, Warnings: > 14 > > > > Detailed regression test results are available here: > > http://www.xs4all.nl/~hverkuil/logs/Wednesday-test-media.log > http://www.xs4all.nl/~hverkuil/logs/Wednesday-test-media-dmesg.log > > The daily build is currently only checking for failures in the compliance > tests > and ignores warnings. It also ignores issues in the kernel log. [...] > The test can be run on a system (or VM) running the kernel you want to test > with > by simply running it as root. > > Usually for V4L2/MC changes it is enough to run it as: > > sudo test-media mc > > If you want the script to unload all media modules first, then add the -unload > option. If you want the script to scan for memory leaks (and the corresponding > debug option is enabled in the kernel), then add the -kmemleak option. To dump > the kernel log when done, add the -dmesg option. > > Run test-media without options to see a help text. > > Note that 'mc' is shorthand for 'vivid vim2m vimc'. > > There are also cec compliance tests and the 'all' test which tests everything > (used in the daily build). The cec tests are slow (especially the cec-pwr > tests), > so unless you changed something in the cec subsystem you want to avoid running > those. > > The test script assumes that the very latest v4l-utils are installed. This sounds very similar to what the KernelCI tests are doing. The main differences are that your script has a neater way of picking the media devices, and that the KernelCI tests break down the results into individual cases to spot regressions automatically [1]. At the moment we have a shell script to parse the output of v4l2-compliance to find each test case result. Ultimately, it would be better to have some machine-readable output available, as I believe we've already agreed. It should then enable KernelCI to run your test-media script directly, removing extra post-processing and making the system more robust. If this sounds like a good idea then we can discuss how to proceed, i.e. agree on the format and command line options to enable it. A popular format which would seem suitable for this is TAP 13 [2]. As Michał now has a fix to address the last issue with the KernelCI email reports, we should be available to work on this next. [...] > Future plans (besides adding vicodec support) is adding support for other > drivers > like uvc and perhaps au0828 (for testing the upcoming Media Device Allocator > API). > But those tests require real hardware to be connected, and there may be > different > variants of the same hardware. We'll see how that will work out. This is obviously another strength of running the tests in KernelCI, such hardware could be added to an existing test lab. Best wishes, Guillaume [1] https://people.collabora.com/~gtucker/kernelci/doc/v4l2-compliance-uvcvideo-5.1-rc6.txt [2] https://testanything.org/tap-version-13-specification.html
[PATCH v4 05/21] rockchip/vpu: Remove a useless test
vdev is guaranteed to be equal to vpu->vfd_enc thanks a test done a few
lines above. Remove this useless test.
Signed-off-by: Boris Brezillon
---
Changes from v3:
* Move earlier in the series
Changes from v2:
* New patch
---
drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
index 39e911797189..b68c4fc2967c 100644
--- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
+++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
@@ -271,10 +271,8 @@ static int rockchip_vpu_open(struct file *filp)
filp->private_data = &ctx->fh;
v4l2_fh_add(&ctx->fh);
- if (vdev == vpu->vfd_enc) {
- rockchip_vpu_enc_reset_dst_fmt(vpu, ctx);
- rockchip_vpu_enc_reset_src_fmt(vpu, ctx);
- }
+ rockchip_vpu_enc_reset_dst_fmt(vpu, ctx);
+ rockchip_vpu_enc_reset_src_fmt(vpu, ctx);
ret = rockchip_vpu_ctrls_setup(vpu, ctx);
if (ret) {
--
2.20.1
[PATCH v3 08/15] rockchip/vpu: Remove a useless test
vdev is guaranteed to be equal to vpu->vfd_enc thanks a test done a few
lines above. Remove this useless test.
Signed-off-by: Boris Brezillon
---
Changes from v2:
* New patch
---
drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
index a0d25bbbfa49..041116855bab 100644
--- a/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
+++ b/drivers/staging/media/rockchip/vpu/rockchip_vpu_drv.c
@@ -272,10 +272,8 @@ static int rockchip_vpu_open(struct file *filp)
filp->private_data = &ctx->fh;
v4l2_fh_add(&ctx->fh);
- if (vdev == vpu->vfd_enc) {
- rockchip_vpu_enc_reset_dst_fmt(vpu, ctx);
- rockchip_vpu_enc_reset_src_fmt(vpu, ctx);
- }
+ rockchip_vpu_enc_reset_dst_fmt(vpu, ctx);
+ rockchip_vpu_enc_reset_src_fmt(vpu, ctx);
ret = rockchip_vpu_ctrls_setup(vpu, ctx);
if (ret) {
--
2.20.1
[PATCH v1] media: ov8856: modify register to fix test pattern
modify registers to fix bayer order in test pattern mode
---
drivers/media/i2c/ov8856.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/ov8856.c b/drivers/media/i2c/ov8856.c
index dbf1095..cd347d6 100644
--- a/drivers/media/i2c/ov8856.c
+++ b/drivers/media/i2c/ov8856.c
@@ -195,11 +195,11 @@ static const struct ov8856_reg mode_3280x2464_regs[] = {
{0x3800, 0x00},
{0x3801, 0x00},
{0x3802, 0x00},
- {0x3803, 0x07},
+ {0x3803, 0x06},
{0x3804, 0x0c},
{0x3805, 0xdf},
{0x3806, 0x09},
- {0x3807, 0xa6},
+ {0x3807, 0xa7},
{0x3808, 0x0c},
{0x3809, 0xd0},
{0x380a, 0x09},
@@ -211,7 +211,7 @@ static const struct ov8856_reg mode_3280x2464_regs[] = {
{0x3810, 0x00},
{0x3811, 0x00},
{0x3812, 0x00},
- {0x3813, 0x00},
+ {0x3813, 0x01},
{0x3814, 0x01},
{0x3815, 0x01},
{0x3816, 0x00},
@@ -385,11 +385,11 @@ static const struct ov8856_reg mode_1640x1232_regs[] = {
{0x3800, 0x00},
{0x3801, 0x00},
{0x3802, 0x00},
- {0x3803, 0x07},
+ {0x3803, 0x06},
{0x3804, 0x0c},
{0x3805, 0xdf},
{0x3806, 0x09},
- {0x3807, 0xa6},
+ {0x3807, 0xa7},
{0x3808, 0x06},
{0x3809, 0x68},
{0x380a, 0x04},
@@ -401,7 +401,7 @@ static const struct ov8856_reg mode_1640x1232_regs[] = {
{0x3810, 0x00},
{0x3811, 0x00},
{0x3812, 0x00},
- {0x3813, 0x00},
+ {0x3813, 0x01},
{0x3814, 0x03},
{0x3815, 0x01},
{0x3816, 0x00},
--
2.7.4
[PATCH v3 6/9] [TEST]: rockchip: mpp: vdpu2: move qtable to input buffer
From: Randy Li
I want the memory region !!!
It can save more time if those data are prepared in userspace.
Signed-off-by: Randy Li
---
drivers/staging/rockchip-mpp/mpp_dev_common.c | 3 +--
drivers/staging/rockchip-mpp/mpp_dev_common.h | 3 ---
drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 3 +++
drivers/staging/rockchip-mpp/vdpu2/mpeg2.c| 20 +++
4 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_common.c
b/drivers/staging/rockchip-mpp/mpp_dev_common.c
index 21816ad8a43b..97c4d897f168 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_common.c
+++ b/drivers/staging/rockchip-mpp/mpp_dev_common.c
@@ -1217,8 +1217,7 @@ static int rockchip_mpp_queue_init(void *priv, struct
vb2_queue *src_vq,
src_vq->io_modes = VB2_MMAP | VB2_DMABUF;
src_vq->drv_priv = session;
src_vq->mem_ops = &vb2_dma_contig_memops;
- src_vq->dma_attrs = DMA_ATTR_ALLOC_SINGLE_PAGES |
- DMA_ATTR_NO_KERNEL_MAPPING;
+ src_vq->dma_attrs = DMA_ATTR_ALLOC_SINGLE_PAGES;
src_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
src_vq->min_buffers_needed = 1;
src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_common.h
b/drivers/staging/rockchip-mpp/mpp_dev_common.h
index 33d7725be67b..36770af53a95 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_common.h
+++ b/drivers/staging/rockchip-mpp/mpp_dev_common.h
@@ -100,9 +100,6 @@ struct mpp_session {
struct v4l2_ctrl_handler ctrl_handler;
/* TODO: FIXME: slower than helper function ? */
struct v4l2_ctrl **ctrls;
-
- dma_addr_t qtable_addr;
- void *qtable_vaddr;
};
/* The context for the a task */
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
index 1be73ab9c2be..92d68b962fe1 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
+++ b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
@@ -176,6 +176,9 @@ static int rkvdpu_s_fmt_vid_out_mplane(struct file *filp,
void *priv,
if (sizes >= SZ_16M)
return -EINVAL;
+ /* For those slice header data */
+ pix_mp->plane_fmt[pix_mp->num_planes - 1].sizeimage += SZ_1M;
+
if (vdpu_setup_ctrls(session, pix_mp->pixelformat))
return -EINVAL;
diff --git a/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
b/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
index 837ee4a4a000..c12d1a8ef2da 100644
--- a/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
+++ b/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
@@ -113,7 +113,10 @@ int rkvdpu_mpeg2_gen_reg(struct mpp_session *session, void
*regs,
const struct v4l2_ctrl_mpeg2_slice_params *params;
const struct v4l2_mpeg2_sequence *sequence;
const struct v4l2_mpeg2_picture *picture;
+ const struct v4l2_ctrl_mpeg2_quantization *quantization;
struct vdpu2_regs *p_regs = regs;
+ void *qtable = NULL;
+ size_t stream_len = 0;
params = rockchip_mpp_get_cur_ctrl(session,
V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
@@ -122,6 +125,8 @@ int rkvdpu_mpeg2_gen_reg(struct mpp_session *session, void
*regs,
sequence = ¶ms->sequence;
picture = ¶ms->picture;
+ quantization = rockchip_mpp_get_cur_ctrl(session,
+ V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
init_hw_cfg(p_regs);
@@ -198,7 +203,13 @@ int rkvdpu_mpeg2_gen_reg(struct mpp_session *session, void
*regs,
p_regs->sw64.rlc_vlc_base =
vb2_dma_contig_plane_dma_addr(&src_buf->vb2_buf, 0);
p_regs->sw122.strm_start_bit = params->data_bit_offset;
- p_regs->sw51.stream_len = vb2_get_plane_payload(&src_buf->vb2_buf, 0);
+ stream_len = vb2_get_plane_payload(&src_buf->vb2_buf, 0);
+ p_regs->sw51.stream_len = stream_len;
+
+ qtable = vb2_plane_vaddr(&src_buf->vb2_buf, 0) + ALIGN(stream_len, 8);
+ mpeg2_dec_copy_qtable(qtable, quantization);
+p_regs->sw61.qtable_base = p_regs->sw64.rlc_vlc_base
+ + ALIGN(stream_len, 8);
return 0;
}
@@ -207,7 +218,6 @@ int rkvdpu_mpeg2_prepare_buf(struct mpp_session *session,
void *regs)
{
const struct v4l2_ctrl_mpeg2_slice_params *params;
const struct v4l2_mpeg2_sequence *sequence;
- const struct v4l2_ctrl_mpeg2_quantization *quantization;
const struct v4l2_mpeg2_picture *picture;
struct vb2_v4l2_buffer *dst_buf;
dma_addr_t cur_addr, fwd_addr, bwd_addr;
@@ -220,9 +230,6 @@ int rkvdpu_mpeg2_prepare_buf(struct mpp_session *session,
void *regs)
picture = ¶ms->picture;
sequence = ¶ms->sequence;
- quantization = rockchip_mpp_get_cur_ctrl(session,
- V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
-
dst_buf = v4l2_m2m_next_dst_buf(session->fh.m2m_ctx);
cur_addr = vb2_dma_contig_
[PATCH v3 5/9] [TEST]: rockchip: mpp: support qtable
From: Randy Li
I don't care, I don't want to store buffers for a session.
I just want to use it to verify the FFmpeg.
---
drivers/staging/rockchip-mpp/mpp_dev_common.h | 3 +++
drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 5 -
drivers/staging/rockchip-mpp/vdpu2/mpeg2.c| 13 -
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_common.h
b/drivers/staging/rockchip-mpp/mpp_dev_common.h
index 36770af53a95..33d7725be67b 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_common.h
+++ b/drivers/staging/rockchip-mpp/mpp_dev_common.h
@@ -100,6 +100,9 @@ struct mpp_session {
struct v4l2_ctrl_handler ctrl_handler;
/* TODO: FIXME: slower than helper function ? */
struct v4l2_ctrl **ctrls;
+
+ dma_addr_t qtable_addr;
+ void *qtable_vaddr;
};
/* The context for the a task */
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
index dbd9f334562e..1be73ab9c2be 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
+++ b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
@@ -246,6 +246,9 @@ static int rkvdpu_open(struct file *filp)
if (IS_ERR_OR_NULL(session))
return PTR_ERR(session);
+ session->qtable_vaddr = dmam_alloc_coherent(mpp_dev->dev, 64 * 4,
+ &session->qtable_addr,
+ GFP_KERNEL);
filp->private_data = &session->fh;
pm_runtime_get_sync(mpp_dev->dev);
@@ -529,7 +532,7 @@ static int rockchip_mpp_rkvdpu_probe(struct platform_device
*pdev)
ret = mpp_dev_register_node(mpp_dev, mpp_dev->variant->node_name,
NULL, &rkvdpu_ioctl_ops);
if (ret)
- dev_err(dev, "register char device failed: %d\n", ret);
+ dev_err(dev, "register v4l2/media device failed: %d\n", ret);
memcpy(mpp_dev->fmt_out, fmt_out_templ, sizeof(fmt_out_templ));
memcpy(mpp_dev->fmt_cap, fmt_cap_templ, sizeof(fmt_cap_templ));
diff --git a/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
b/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
index d32958c4cb20..837ee4a4a000 100644
--- a/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
+++ b/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
@@ -52,7 +52,7 @@ static const u8 intra_default_q_matrix[64] = {
static void mpeg2_dec_copy_qtable(u8 * qtable, const struct
v4l2_ctrl_mpeg2_quantization
*ctrl)
{
- int i, n;
+ int i;
if (!qtable || !ctrl)
return;
@@ -111,16 +111,12 @@ int rkvdpu_mpeg2_gen_reg(struct mpp_session *session,
void *regs,
struct vb2_v4l2_buffer *src_buf)
{
const struct v4l2_ctrl_mpeg2_slice_params *params;
- const struct v4l2_ctrl_mpeg2_quantization *quantization;
const struct v4l2_mpeg2_sequence *sequence;
const struct v4l2_mpeg2_picture *picture;
struct vdpu2_regs *p_regs = regs;
params = rockchip_mpp_get_cur_ctrl(session,
V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
- quantization = rockchip_mpp_get_cur_ctrl(session,
-
V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
-
if (!params)
return -EINVAL;
@@ -211,6 +207,7 @@ int rkvdpu_mpeg2_prepare_buf(struct mpp_session *session,
void *regs)
{
const struct v4l2_ctrl_mpeg2_slice_params *params;
const struct v4l2_mpeg2_sequence *sequence;
+ const struct v4l2_ctrl_mpeg2_quantization *quantization;
const struct v4l2_mpeg2_picture *picture;
struct vb2_v4l2_buffer *dst_buf;
dma_addr_t cur_addr, fwd_addr, bwd_addr;
@@ -223,6 +220,9 @@ int rkvdpu_mpeg2_prepare_buf(struct mpp_session *session,
void *regs)
picture = ¶ms->picture;
sequence = ¶ms->sequence;
+ quantization = rockchip_mpp_get_cur_ctrl(session,
+ V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
+
dst_buf = v4l2_m2m_next_dst_buf(session->fh.m2m_ctx);
cur_addr = vb2_dma_contig_plane_dma_addr(&dst_buf->vb2_buf, 0);
@@ -266,5 +266,8 @@ int rkvdpu_mpeg2_prepare_buf(struct mpp_session *session,
void *regs)
p_regs->sw135.refer3_base = cur_addr >> 2;
}
+ mpeg2_dec_copy_qtable(session->qtable_vaddr, quantization);
+p_regs->sw61.qtable_base = session->qtable_addr;
+
return 0;
}
--
2.20.1
[PATCH v3 7/9] [TEST]: rkvdec: spspps address alignment
I found the offset for cpu access is not equal to the DMA
opeartion.
Signed-off-by: ayaka
---
drivers/staging/rockchip-mpp/mpp_dev_common.h | 3 +++
drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c | 3 +++
drivers/staging/rockchip-mpp/rkvdec/avc.c | 14 +++---
3 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_common.h
b/drivers/staging/rockchip-mpp/mpp_dev_common.h
index 36770af53a95..6718bcccde1f 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_common.h
+++ b/drivers/staging/rockchip-mpp/mpp_dev_common.h
@@ -100,6 +100,9 @@ struct mpp_session {
struct v4l2_ctrl_handler ctrl_handler;
/* TODO: FIXME: slower than helper function ? */
struct v4l2_ctrl **ctrls;
+
+ void *aux_vaddr;
+ dma_addr_t aux_addr;
};
/* The context for the a task */
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c
b/drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c
index 97abfdfc344f..cc1fa9737bc1 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c
+++ b/drivers/staging/rockchip-mpp/mpp_dev_rkvdec.c
@@ -382,6 +382,9 @@ static int rkvdec_open(struct file *filp)
filp->private_data = &session->fh;
pm_runtime_get_sync(mpp_dev->dev);
+ session->aux_vaddr = dmam_alloc_coherent(mpp_dev->dev, SZ_1M,
+&session->aux_addr,
GFP_KERNEL);
+
mpp_debug_leave();
return 0;
}
diff --git a/drivers/staging/rockchip-mpp/rkvdec/avc.c
b/drivers/staging/rockchip-mpp/rkvdec/avc.c
index 1cb5b2208bfa..8266a990dca6 100644
--- a/drivers/staging/rockchip-mpp/rkvdec/avc.c
+++ b/drivers/staging/rockchip-mpp/rkvdec/avc.c
@@ -26,8 +26,8 @@
#include "regs.h"
#include "avc-data.h"
-static void generate_input_data(struct rkvdec_regs *p_regs,
- struct vb2_v4l2_buffer *src_buf,
+static void generate_input_data(struct mpp_session *session,
+ struct rkvdec_regs *p_regs,
const struct v4l2_ctrl_h264_sps *sps,
const struct v4l2_ctrl_h264_pps *pps,
const struct v4l2_ctrl_h264_scaling_matrix
@@ -44,8 +44,8 @@ static void generate_input_data(struct rkvdec_regs *p_regs,
stream_len = slice_param->size + 64;
- r_data = vb2_plane_vaddr(&src_buf->vb2_buf, 0);
- r_scaling_offs = ALIGN(stream_len, 16);
+ r_data = session->aux_vaddr;
+ r_scaling_offs = 0;
r_data += r_scaling_offs;
if (pps->flags & V4L2_H264_PPS_FLAG_PIC_SCALING_MATRIX_PRESENT) {
@@ -62,7 +62,7 @@ static void generate_input_data(struct rkvdec_regs *p_regs,
rkvdec_avc_write_sps(&rbsp, sps);
rkvdec_avc_write_pps(&rbsp, pps);
rkvdec_avc_write_pps_tail(&rbsp, scaling_addr, decode_param);
- p_regs->sw_pps_base = p_regs->sw_strm_rlc_base + r_sps_offs;
+ p_regs->sw_pps_base = session->aux_addr + r_sps_offs;
for (i = 1; i < 256; i++)
memset(r_data + r_sps_offs + i * 32, 0, 32);
@@ -72,7 +72,7 @@ static void generate_input_data(struct rkvdec_regs *p_regs,
r_rps_offs = ALIGN(r_rps_offs, 16);
rbsp_init(&rbsp, r_data + r_rps_offs, SZ_2M - r_rps_offs, 0);
rkvdec_avc_write_rps(&rbsp, sps, slice_param, decode_param);
- p_regs->sw_rps_base = p_regs->sw_strm_rlc_base + r_rps_offs;
+ p_regs->sw_rps_base = session->aux_addr + r_rps_offs;
}
static void init_hw_cfg(struct rkvdec_regs *p_regs)
@@ -238,7 +238,7 @@ int rkvdec_avc_gen_reg(struct mpp_session *session, void
*regs,
dst_buf = v4l2_m2m_next_dst_buf(session->fh.m2m_ctx);
rkvdec_avc_gen_ref(p_regs, dst_buf, decode_param);
- generate_input_data(p_regs, src_buf, sps, pps, scaling, slice_param,
+ generate_input_data(session, p_regs, sps, pps, scaling, slice_param,
decode_param);
return 0;
--
2.20.1
[PATCH v2 10/16] media: vicodec: don't test if info is NULL
pixel info of q_data is never set to NULL
so there is no need to test if it is.
Signed-off-by: Dafna Hirschfeld
---
drivers/media/platform/vicodec/vicodec-core.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/media/platform/vicodec/vicodec-core.c
b/drivers/media/platform/vicodec/vicodec-core.c
index 4896f349b4aa..52e8128d2d28 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -662,7 +662,6 @@ static int job_ready(void *priv)
if (ntohl(ctx->state.header.width) != q_dst->visible_width ||
ntohl(ctx->state.header.height) != q_dst->visible_height ||
- !q_dst->info ||
hdr_width_div != q_dst->info->width_div ||
hdr_height_div != q_dst->info->height_div) {
static const struct v4l2_event rs_event = {
@@ -992,7 +991,6 @@ static int vidioc_s_fmt(struct vicodec_ctx *ctx, struct
v4l2_format *f)
pix = &f->fmt.pix;
if (ctx->is_enc && V4L2_TYPE_IS_OUTPUT(f->type))
fmt_changed =
- !q_data->info ||
q_data->info->id != pix->pixelformat ||
q_data->coded_width != pix->width ||
q_data->coded_height != pix->height;
@@ -1015,7 +1013,6 @@ static int vidioc_s_fmt(struct vicodec_ctx *ctx, struct
v4l2_format *f)
pix_mp = &f->fmt.pix_mp;
if (ctx->is_enc && V4L2_TYPE_IS_OUTPUT(f->type))
fmt_changed =
- !q_data->info ||
q_data->info->id != pix_mp->pixelformat ||
q_data->coded_width != pix_mp->width ||
q_data->coded_height != pix_mp->height;
@@ -1601,10 +1598,6 @@ static unsigned int total_frame_size(struct
vicodec_q_data *q_data)
unsigned int size;
unsigned int chroma_div;
- if (!q_data->info) {
- WARN_ON(1);
- return 0;
- }
size = q_data->coded_width * q_data->coded_height;
chroma_div = q_data->info->width_div * q_data->info->height_div;
@@ -1825,8 +1818,6 @@ static int vicodec_try_ctrl(struct v4l2_ctrl *ctrl)
switch (ctrl->id) {
case V4L2_CID_MPEG_VIDEO_FWHT_PARAMS:
- if (!q_dst->info)
- return -EINVAL;
params = ctrl->p_new.p_fwht_params;
if (params->width > q_dst->coded_width ||
params->width < MIN_WIDTH ||
--
2.17.1
[PATCH 09/14] media: vicodec: don't test if info is NULL
pixel info of q_data is never set to NULL
so there is no need to test if it is.
Signed-off-by: Dafna Hirschfeld
---
drivers/media/platform/vicodec/vicodec-core.c | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/media/platform/vicodec/vicodec-core.c
b/drivers/media/platform/vicodec/vicodec-core.c
index ba327512e085..6276a803cc4d 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -659,7 +659,6 @@ static int job_ready(void *priv)
if (ntohl(ctx->state.header.width) != q_dst->visible_width ||
ntohl(ctx->state.header.height) != q_dst->visible_height ||
- !q_dst->info ||
hdr_width_div != q_dst->info->width_div ||
hdr_height_div != q_dst->info->height_div) {
static const struct v4l2_event rs_event = {
@@ -768,9 +767,6 @@ static int vidioc_g_fmt(struct vicodec_ctx *ctx, struct
v4l2_format *f)
q_data = get_q_data(ctx, f->type);
info = q_data->info;
- if (!info)
- info = v4l2_fwht_get_pixfmt(0);
-
switch (f->type) {
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
case V4L2_BUF_TYPE_VIDEO_OUTPUT:
@@ -992,7 +988,6 @@ static int vidioc_s_fmt(struct vicodec_ctx *ctx, struct
v4l2_format *f)
pix = &f->fmt.pix;
if (ctx->is_enc && V4L2_TYPE_IS_OUTPUT(f->type))
fmt_changed =
- !q_data->info ||
q_data->info->id != pix->pixelformat ||
q_data->coded_width != pix->width ||
q_data->coded_height != pix->height;
@@ -1015,7 +1010,6 @@ static int vidioc_s_fmt(struct vicodec_ctx *ctx, struct
v4l2_format *f)
pix_mp = &f->fmt.pix_mp;
if (ctx->is_enc && V4L2_TYPE_IS_OUTPUT(f->type))
fmt_changed =
- !q_data->info ||
q_data->info->id != pix_mp->pixelformat ||
q_data->coded_width != pix_mp->width ||
q_data->coded_height != pix_mp->height;
@@ -1593,10 +1587,6 @@ static unsigned int total_frame_size(struct
vicodec_q_data *q_data)
unsigned int size;
unsigned int chroma_div;
- if (!q_data->info) {
- WARN_ON(1);
- return 0;
- }
size = q_data->coded_width * q_data->coded_height;
chroma_div = q_data->info->width_div * q_data->info->height_div;
@@ -1619,9 +1609,6 @@ static int vicodec_start_streaming(struct vb2_queue *q,
unsigned int total_planes_size;
u8 *new_comp_frame = NULL;
- if (!info)
- return -EINVAL;
-
chroma_div = info->width_div * info->height_div;
q_data->sequence = 0;
@@ -1820,8 +1807,6 @@ static int vicodec_try_ctrl(struct v4l2_ctrl *ctrl)
switch (ctrl->id) {
case V4L2_CID_MPEG_VIDEO_FWHT_PARAMS:
- if (!q_dst->info)
- return -EINVAL;
params = ctrl->p_new.p_fwht_params;
if (params->width > q_dst->coded_width ||
params->width < MIN_WIDTH ||
--
2.17.1
[STATUS UPDATE] test-media regression script status
Hi all, As you all know I have been working on creating a regression test script to help catch regressions before they get into released kernels. The test-media script is in v4l-utils, contrib/test. It is currently testing with vivid, vim2m and vimc. Once vicodec is stable enough it will be added to the test suite as well. It is already run as part of the daily build using a kernel config with many debug options enabled. The daily build summary looks like this: virtme: OK: Final Summary: 1981, Succeeded: 1981, Failed: 0, Warnings: 14 Detailed regression test results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday-test-media.log http://www.xs4all.nl/~hverkuil/logs/Wednesday-test-media-dmesg.log The daily build is currently only checking for failures in the compliance tests and ignores warnings. It also ignores issues in the kernel log. The main problems that I am trying to solve are kernel oopses (should be solved once all my pending 5.2 pull requests are merged) and vivid warnings (12 of the warnings are known and work is in progress to fix this, the remainder of the warnings I need to look at and are likely caused by v4l2-compliance itself). Note that there is one known remaining kernel oops when testing vimc, but resolving that takes a lot more time (low-level media life-cycle issues) and the test has been disabled for now in test-media. The test can be run on a system (or VM) running the kernel you want to test with by simply running it as root. Usually for V4L2/MC changes it is enough to run it as: sudo test-media mc If you want the script to unload all media modules first, then add the -unload option. If you want the script to scan for memory leaks (and the corresponding debug option is enabled in the kernel), then add the -kmemleak option. To dump the kernel log when done, add the -dmesg option. Run test-media without options to see a help text. Note that 'mc' is shorthand for 'vivid vim2m vimc'. There are also cec compliance tests and the 'all' test which tests everything (used in the daily build). The cec tests are slow (especially the cec-pwr tests), so unless you changed something in the cec subsystem you want to avoid running those. The test script assumes that the very latest v4l-utils are installed. The test can also be run using virtme. I made a virtme.sh script to run the tests. It assumes that it is run from the top of the kernel tree. You can find the script here: https://hverkuil.home.xs4all.nl/virtme/ The start of the script documents where to get virtme and how to install it. This also contains a kernel config that enables various kernel debug options. I strongly recommend that testing is done using virtme since this allows you to enable many kernel debug options that you don't want to enable on the host. Delayed kobject release is a particularly nasty debug option :-) Note: running virtme when a VMWare instance is also running on the same host does not work reliably. I don't know why exactly, but the only way I can use virtme is from inside a VMWare linux guest. Unfortunately, I need to use VMWare Workstation, so I'm stuck with it. I hope that during the 5.2 development cycle we can fix the last remaining issues and this can become part of the regular development process. Future plans (besides adding vicodec support) is adding support for other drivers like uvc and perhaps au0828 (for testing the upcoming Media Device Allocator API). But those tests require real hardware to be connected, and there may be different variants of the same hardware. We'll see how that will work out. Regards, Hans
[PATCH] [TEST]: media: vb2: reverse DMA addr of each plane
With the default iova and dma-iommu driver, the starting
address of a new buffer would be at lower address than
the previous one.
This patch can solve this problem simply, but I want
a way to control the address direction of the IOMMU/IOVA.
The reason why we(ayaka and I) need to do this is simple,
some devices want a contiguous memory for its pixel data.
But with the single plane buffer, there is not a properly way
to export its buffer offsets with the userspace,
since their bytesperline and offset are not full related
to the picture width or height. You can find more detail
in the previous mail.
Besides, this patch won't solve all the problem, if you
don't disable the size_aligned of the iova driver or
there would be a gap between the plane 0 and plane 1.
This patch is used for showing the problem we met not
for merging.
Signed-off-by: Randy Li
---
drivers/media/common/videobuf2/videobuf2-core.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-core.c
b/drivers/media/common/videobuf2/videobuf2-core.c
index 15b6b9c0a2e4..6762d1547e49 100644
--- a/drivers/media/common/videobuf2/videobuf2-core.c
+++ b/drivers/media/common/videobuf2/videobuf2-core.c
@@ -204,11 +204,11 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
* Allocate memory for all planes in this buffer
* NOTE: mmapped areas should be page aligned
*/
- for (plane = 0; plane < vb->num_planes; ++plane) {
- unsigned long size = PAGE_ALIGN(vb->planes[plane].length);
+ for (plane = vb->num_planes; plane > 0; --plane) {
+ unsigned long size = PAGE_ALIGN(vb->planes[plane - 1].length);
mem_priv = call_ptr_memop(vb, alloc,
- q->alloc_devs[plane] ? : q->dev,
+ q->alloc_devs[plane - 1] ? : q->dev,
q->dma_attrs, size, q->dma_dir, q->gfp_flags);
if (IS_ERR_OR_NULL(mem_priv)) {
if (mem_priv)
@@ -217,15 +217,15 @@ static int __vb2_buf_mem_alloc(struct vb2_buffer *vb)
}
/* Associate allocator private data with this plane */
- vb->planes[plane].mem_priv = mem_priv;
+ vb->planes[plane - 1].mem_priv = mem_priv;
}
return 0;
free:
/* Free already allocated memory if one of the allocations failed */
- for (; plane > 0; --plane) {
- call_void_memop(vb, put, vb->planes[plane - 1].mem_priv);
- vb->planes[plane - 1].mem_priv = NULL;
+ for (; plane < vb->num_planes; plane++) {
+ call_void_memop(vb, put, vb->planes[plane].mem_priv);
+ vb->planes[plane].mem_priv = NULL;
}
return ret;
--
2.20.1
[PATCH v2 3/6] [TEST]: rockchip: mpp: support qptable
I don't care, I don't want to store buffers for a session.
I just want to use it to verify the FFmpeg.
I want the memory region !!!
It can save more time if those data are prepared in userspace.
Signed-off-by: Randy Li
---
drivers/staging/rockchip-mpp/mpp_dev_common.c | 3 +--
drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 3 +++
drivers/staging/rockchip-mpp/vdpu2/mpeg2.c| 19 +--
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_common.c
b/drivers/staging/rockchip-mpp/mpp_dev_common.c
index c43304c3e7b8..1291b642179e 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_common.c
+++ b/drivers/staging/rockchip-mpp/mpp_dev_common.c
@@ -1193,8 +1193,7 @@ static int rockchip_mpp_queue_init(void *priv, struct
vb2_queue *src_vq,
src_vq->io_modes = VB2_MMAP | VB2_DMABUF;
src_vq->drv_priv = session;
src_vq->mem_ops = &vb2_dma_contig_memops;
- src_vq->dma_attrs = DMA_ATTR_ALLOC_SINGLE_PAGES |
- DMA_ATTR_NO_KERNEL_MAPPING;
+ src_vq->dma_attrs = DMA_ATTR_ALLOC_SINGLE_PAGES;
src_vq->buf_struct_size = sizeof(struct v4l2_m2m_buffer);
src_vq->min_buffers_needed = 1;
src_vq->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_COPY;
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
index ce98aa15025e..00413936623e 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
+++ b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
@@ -147,6 +147,9 @@ static int rkvdpu_s_fmt_vid_out_mplane(struct file *filp,
void *priv,
if (sizes >= SZ_16M)
return -EINVAL;
+ /* For those slice header data */
+ pix_mp->plane_fmt[pix_mp->num_planes - 1].sizeimage += SZ_1M;
+
session->fmt_out = *pix_mp;
/* Copy the pixel format information from OUTPUT to CAPUTRE */
diff --git a/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
b/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
index d32958c4cb20..c12d1a8ef2da 100644
--- a/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
+++ b/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
@@ -52,7 +52,7 @@ static const u8 intra_default_q_matrix[64] = {
static void mpeg2_dec_copy_qtable(u8 * qtable, const struct
v4l2_ctrl_mpeg2_quantization
*ctrl)
{
- int i, n;
+ int i;
if (!qtable || !ctrl)
return;
@@ -111,21 +111,22 @@ int rkvdpu_mpeg2_gen_reg(struct mpp_session *session,
void *regs,
struct vb2_v4l2_buffer *src_buf)
{
const struct v4l2_ctrl_mpeg2_slice_params *params;
- const struct v4l2_ctrl_mpeg2_quantization *quantization;
const struct v4l2_mpeg2_sequence *sequence;
const struct v4l2_mpeg2_picture *picture;
+ const struct v4l2_ctrl_mpeg2_quantization *quantization;
struct vdpu2_regs *p_regs = regs;
+ void *qtable = NULL;
+ size_t stream_len = 0;
params = rockchip_mpp_get_cur_ctrl(session,
V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
- quantization = rockchip_mpp_get_cur_ctrl(session,
-
V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
-
if (!params)
return -EINVAL;
sequence = ¶ms->sequence;
picture = ¶ms->picture;
+ quantization = rockchip_mpp_get_cur_ctrl(session,
+ V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
init_hw_cfg(p_regs);
@@ -202,7 +203,13 @@ int rkvdpu_mpeg2_gen_reg(struct mpp_session *session, void
*regs,
p_regs->sw64.rlc_vlc_base =
vb2_dma_contig_plane_dma_addr(&src_buf->vb2_buf, 0);
p_regs->sw122.strm_start_bit = params->data_bit_offset;
- p_regs->sw51.stream_len = vb2_get_plane_payload(&src_buf->vb2_buf, 0);
+ stream_len = vb2_get_plane_payload(&src_buf->vb2_buf, 0);
+ p_regs->sw51.stream_len = stream_len;
+
+ qtable = vb2_plane_vaddr(&src_buf->vb2_buf, 0) + ALIGN(stream_len, 8);
+ mpeg2_dec_copy_qtable(qtable, quantization);
+p_regs->sw61.qtable_base = p_regs->sw64.rlc_vlc_base
+ + ALIGN(stream_len, 8);
return 0;
}
--
2.20.1
[v4l-utils PATCH v3 3/8] v4l2-ctl: test if do_setup_out_buffers returns -1 instead of non zero
If 'do_setup_out_buffers' returns -2 it means that it finished queuing all output stream buffers and the program should not terminate in that case. Signed-off-by: Dafna Hirschfeld --- utils/v4l2-ctl/v4l2-ctl-streaming.cpp | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp index 6f4317bf..d023aa12 100644 --- a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp +++ b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp @@ -1823,7 +1823,7 @@ static void streaming_set_out(cv4l_fd &fd, cv4l_fd &exp_fd) if (q.obtain_bufs(&fd)) goto done; - if (do_setup_out_buffers(fd, q, fin, true)) + if (do_setup_out_buffers(fd, q, fin, true) == -1) goto done; fps_ts.determine_field(fd.g_fd(), type); @@ -2013,7 +2013,7 @@ static void streaming_set_m2m(cv4l_fd &fd, cv4l_fd &exp_fd) goto done; } - if (do_setup_out_buffers(fd, out, file[OUT], true)) + if (do_setup_out_buffers(fd, out, file[OUT], true) == -1) goto done; if (fd.streamon(out.g_type())) @@ -2250,7 +2250,7 @@ static void streaming_set_cap2out(cv4l_fd &fd, cv4l_fd &out_fd) if (in.obtain_bufs(&fd) || in.queue_all(&fd) || - do_setup_out_buffers(out_fd, out, file[OUT], false)) + do_setup_out_buffers(out_fd, out, file[OUT], false) == -1) goto done; fps_ts[CAP].determine_field(fd.g_fd(), in.g_type()); -- 2.17.1
[PATCH 3/4] [TEST]: rockchip: mpp: support qtable
Yes, the buffer won't be freed.
I don't want to store buffers for a session.
I just want to use it to verify the FFmpeg.
Signed-off-by: ayaka
---
drivers/staging/rockchip-mpp/mpp_dev_common.h | 3 ++
drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c | 3 ++
drivers/staging/rockchip-mpp/vdpu2/mpeg2.c| 42 +++
3 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_common.h
b/drivers/staging/rockchip-mpp/mpp_dev_common.h
index 36770af53a95..33d7725be67b 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_common.h
+++ b/drivers/staging/rockchip-mpp/mpp_dev_common.h
@@ -100,6 +100,9 @@ struct mpp_session {
struct v4l2_ctrl_handler ctrl_handler;
/* TODO: FIXME: slower than helper function ? */
struct v4l2_ctrl **ctrls;
+
+ dma_addr_t qtable_addr;
+ void *qtable_vaddr;
};
/* The context for the a task */
diff --git a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
index 03ed080bb35c..9e00501c3577 100644
--- a/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
+++ b/drivers/staging/rockchip-mpp/mpp_dev_vdpu2.c
@@ -402,6 +402,9 @@ static int rkvdpu_open(struct file *filp)
return error;
}
+ session->qtable_vaddr = dmam_alloc_coherent(mpp_dev->dev, 64 * 4,
+ &session->qtable_addr,
+ GFP_KERNEL);
filp->private_data = &session->fh;
mpp_debug_leave();
diff --git a/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
b/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
index a16f7629a811..416348630779 100644
--- a/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
+++ b/drivers/staging/rockchip-mpp/vdpu2/mpeg2.c
@@ -27,6 +27,34 @@
#define DEC_LITTLE_ENDIAN (1)
+static const u8 zigzag[64] = {
+ 0, 1, 8, 16, 9, 2, 3, 10,
+ 17, 24, 32, 25, 18, 11, 4, 5,
+ 12, 19, 26, 33, 40, 48, 41, 34,
+ 27, 20, 13, 6, 7, 14, 21, 28,
+ 35, 42, 49, 56, 57, 50, 43, 36,
+ 29, 22, 15, 23, 30, 37, 44, 51,
+ 58, 59, 52, 45, 38, 31, 39, 46,
+ 53, 60, 61, 54, 47, 55, 62, 63
+};
+
+static void mpeg2_dec_copy_qtable(u8 *qtable,
+ const struct v4l2_ctrl_mpeg2_quantization *ctrl)
+{
+ int i, n;
+
+ if (!qtable || !ctrl)
+ return;
+
+ for (i = 0; i < 64; i++) {
+ n = zigzag[i];
+ qtable[n + 0] = ctrl->intra_quantiser_matrix[i];
+ qtable[n + 64] = ctrl->non_intra_quantiser_matrix[i];
+ qtable[n + 128] = ctrl->chroma_intra_quantiser_matrix[i];
+ qtable[n + 192] = ctrl->chroma_non_intra_quantiser_matrix[i];
+ }
+}
+
static void init_hw_cfg(struct vdpu2_regs *p_regs)
{
p_regs->sw54.dec_strm_wordsp = 1;
@@ -61,7 +89,6 @@ int rkvdpu_mpeg2_gen_reg(struct mpp_session *session, void
*regs,
struct vb2_v4l2_buffer *src_buf)
{
const struct v4l2_ctrl_mpeg2_slice_params *params;
- const struct v4l2_ctrl_mpeg2_quantization *quantization;
const struct v4l2_mpeg2_sequence *sequence;
const struct v4l2_mpeg2_picture *picture;
struct sg_table *sgt;
@@ -69,9 +96,6 @@ int rkvdpu_mpeg2_gen_reg(struct mpp_session *session, void
*regs,
params = rockchip_mpp_get_cur_ctrl(session,
V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
- quantization = rockchip_mpp_get_cur_ctrl(session,
- V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
-
if (!params)
return -EINVAL;
@@ -164,6 +188,7 @@ int rkvdpu_mpeg2_prepare_buf(struct mpp_session *session,
void *regs)
{
const struct v4l2_ctrl_mpeg2_slice_params *params;
const struct v4l2_mpeg2_sequence *sequence;
+ const struct v4l2_ctrl_mpeg2_quantization *quantization;
const struct v4l2_mpeg2_picture *picture;
struct vb2_v4l2_buffer *dst_buf;
dma_addr_t cur_addr, fwd_addr, bwd_addr;
@@ -177,6 +202,9 @@ int rkvdpu_mpeg2_prepare_buf(struct mpp_session *session,
void *regs)
picture = ¶ms->picture;
sequence = ¶ms->sequence;
+ quantization = rockchip_mpp_get_cur_ctrl(session,
+ V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
+
dst_buf = v4l2_m2m_next_dst_buf(session->fh.m2m_ctx);
sgt = vb2_dma_sg_plane_desc(&dst_buf->vb2_buf, 0);
@@ -219,9 +247,7 @@ int rkvdpu_mpeg2_prepare_buf(struct mpp_session *session,
void *regs)
p_regs->sw134.refer2_base = bwd_addr >> 2;
p_regs->sw135.refer3_base = bwd_addr >> 2;
-#if 0
-//ref & qtable config
-p_regs->sw61.qtable_base = mpp_buffer_get_fd(ctx->qp_table);
-#endif
+ mpeg2_dec_copy_qtable(session->qtable_vaddr, quantization);
+p_regs->sw61.qtable_base = session->qtable_addr;
return 0;
}
--
2.20.1
Re: Test results (v4l2) for media/master - v4.20-rc5-281-gd2b4387f3bdf
Hi Mauro, Thanks for the review. We've made some progress but I would like to check things with you before putting this in production, please see below. On 18/12/2018 17:52, Mauro Carvalho Chehab wrote: > Em Tue, 18 Dec 2018 07:31:23 -0800 (PST) > "kernelci.org bot" escreveu: > >> Test results for: >> Tree:media >> Branch: master >> Kernel: v4.20-rc5-281-gd2b4387f3bdf >> URL: https://git.linuxtv.org/media_tree.git >> Commit: d2b4387f3bdf016e266d23cf657465f557721488 >> Test plans: v4l2 >> >> Summary >> --- >> 4 test groups results >> >> 1 | v4l2 | rk3399-gru-kevin | arm64 | 49 total: 17 PASS 6 >> FAIL 26 SKIP >> 2 | v4l2 | rk3288-veyron-jaq | arm | 49 total: 17 PASS 6 >> FAIL 26 SKIP >> 3 | v4l2 | qemu | arm64 | 115 total: 77 PASS 7 >> FAIL 31 SKIP >> 4 | v4l2 | qemu | arm | 115 total: 77 PASS 7 >> FAIL 31 SKIP > > Please add, at linuxtv.org's wiki page, what each test actually means... I've now added an explanation with a link to the wiki: """ V4L2 Compliance on the uvcvideo driver. This test ran "v4l2-compliance -s" from v4l-utils: https://www.linuxtv.org/wiki/index.php/V4l2-utils See each detailed section in the report below to find out the git URL and particular revision that was used to build the test binaries. """ Is this the kind of information you would expect to see here? >> --- >> 1 | v4l2 | rk3399-gru-kevin | arm64 | 49 total: 17 PASS 6 >> FAIL 26 SKIP >> >> Config: defconfig >> Lab Name:lab-collabora >> Date:2018-12-14 19:51:24.841000 >> TXT log: >> https://storage.kernelci.org//media/master/v4.20-rc5-281-gd2b4387f3bdf/arm64/defconfig/lab-collabora/v4l2-rk3399-gru-kevin.txt >> HTML log: >> https://storage.kernelci.org//media/master/v4.20-rc5-281-gd2b4387f3bdf/arm64/defconfig/lab-collabora/v4l2-rk3399-gru-kevin.html >> Rootfs: >> http://storage.kernelci.org/images/rootfs/debian/stretch-v4l2/20181207.0/arm64/rootfs.cpio.gz >> Test Git:git://linuxtv.org/v4l-utils.git >> Test Commit: 7a118f166609c0d05c6447cc79484af37875d6fc >> >> >> Output-ioctls - 5 tests: 0 PASS, 0 FAIL, 5 SKIP >> >> Buffer-ioctls-Input-0 - 3 tests: 2 PASS, 1 FAIL, 0 SKIP >> * Requests: FAIL >> >> Required-ioctls - 2 tests: 2 PASS, 0 FAIL, 0 SKIP >> >> Input/Output-configuration-ioctls - 4 tests: 0 PASS, 0 FAIL, 4 SKIP >> >> Control-ioctls-Input-0 - 6 tests: 3 PASS, 2 FAIL, 1 SKIP >> * VIDIOC_G/S/TRY_EXT_CTRLS: FAIL >> * VIDIOC_QUERY_EXT_CTRL/QUERYMENU: FAIL > > ... for example, in this specific case, I have no idea what driver > failed. Ok, one could open the log txt file, look on it and > discover that this specific test was against the uvcvideo driver, > but it is doubtful to expect that everybody would do that. Each test is now run on a per-driver basis, on relevant platforms. So there's vivid on QEMU and uvcvideo on a couple of real hardware devices as shown in this example summary: 1 | rk3288-veyron-jaq | arm | 51 total: 17 PASS 8 FAIL 26 SKIP 2 | rk3399-gru-kevin | arm64 | 51 total: 17 PASS 8 FAIL 26 SKIP The driver name is mentioned in the email subject and at the top of the report. The test first looks for a /dev/video* device corresponding to the requested driver, and then passes that on to the v4l2-compliance test suite as an argument. > The best would be to also c/c the developer of the specific > driver, if listed at MAINTAINERS, as he is the one that should > come up with a fix. Sure, it's easy to add the maintainers to the recipients for each type of report (i.e. Hans for vivid and Laurent for uvcvideo, and you for both) in addition to the linux-media list. > I also think that the patch subject should be changed to reflect the > actual problems that was got, e. g., something like: > > [KernelCI] v4l2-compliance: uvcvideo: 6 failures, driver_foo: 8 failures The email subject has been changed to look more like other KernelCI reports and take your suggestion into account. For this particular test report, it would now look like this: media/master v4l2-compliance on uvcvideo: 102 tests, 0 regressions (v4.20-rc5-281-gd2b4387f3bdf) There also would be another separate one with results for vivid. Other mailing lists are receiving similar reports without a [KernelCI] tag or anything, but it's easy to filter them based on the sender as it's always "kernelci.org bot" . >> Code
Re: [v4l-utils PATCH 3/6] v4l2-ctl: test the excpetion fds first in streaming_set_m2m
On 01/20/2019 12:15 PM, Dafna Hirschfeld wrote:
> test the excpetion fds first in the select loop
excpetion -> exception
> in streaming_set_m2m. This is needed in the next patch
> in order to dequeue a source change event before its
> coresponding last buffer.
coresponding -> corresponding
But besides those typos, I don't think this patch is needed at
all. See my comments for patch 5/6 for more info.
Regards,
Hans
>
> Signed-off-by: Dafna Hirschfeld
> ---
> utils/v4l2-ctl/v4l2-ctl-streaming.cpp | 26 +-
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
> b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
> index 3e81fdfc..fc204304 100644
> --- a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
> +++ b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
> @@ -1953,6 +1953,19 @@ static void streaming_set_m2m(cv4l_fd &fd)
> goto done;
> }
>
> + if (ex_fds && FD_ISSET(fd.g_fd(), ex_fds)) {
> + struct v4l2_event ev;
> +
> + while (!fd.dqevent(ev)) {
> + if (ev.type != V4L2_EVENT_EOS)
> + continue;
> + wr_fds = NULL;
> + fprintf(stderr, "EOS");
> + fflush(stderr);
> + break;
> + }
> + }
> +
> if (rd_fds && FD_ISSET(fd.g_fd(), rd_fds)) {
> r = do_handle_cap(fd, in, file[CAP], NULL,
> count[CAP], fps_ts[CAP]);
> @@ -1990,19 +2003,6 @@ static void streaming_set_m2m(cv4l_fd &fd)
> }
> }
> }
> -
> - if (ex_fds && FD_ISSET(fd.g_fd(), ex_fds)) {
> - struct v4l2_event ev;
> -
> - while (!fd.dqevent(ev)) {
> - if (ev.type != V4L2_EVENT_EOS)
> - continue;
> - wr_fds = NULL;
> - fprintf(stderr, "EOS");
> - fflush(stderr);
> - break;
> - }
> - }
> }
>
> fcntl(fd.g_fd(), F_SETFL, fd_flags);
>
[v4l-utils PATCH 3/6] v4l2-ctl: test the excpetion fds first in streaming_set_m2m
test the excpetion fds first in the select loop
in streaming_set_m2m. This is needed in the next patch
in order to dequeue a source change event before its
coresponding last buffer.
Signed-off-by: Dafna Hirschfeld
---
utils/v4l2-ctl/v4l2-ctl-streaming.cpp | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
index 3e81fdfc..fc204304 100644
--- a/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
+++ b/utils/v4l2-ctl/v4l2-ctl-streaming.cpp
@@ -1953,6 +1953,19 @@ static void streaming_set_m2m(cv4l_fd &fd)
goto done;
}
+ if (ex_fds && FD_ISSET(fd.g_fd(), ex_fds)) {
+ struct v4l2_event ev;
+
+ while (!fd.dqevent(ev)) {
+ if (ev.type != V4L2_EVENT_EOS)
+ continue;
+ wr_fds = NULL;
+ fprintf(stderr, "EOS");
+ fflush(stderr);
+ break;
+ }
+ }
+
if (rd_fds && FD_ISSET(fd.g_fd(), rd_fds)) {
r = do_handle_cap(fd, in, file[CAP], NULL,
count[CAP], fps_ts[CAP]);
@@ -1990,19 +2003,6 @@ static void streaming_set_m2m(cv4l_fd &fd)
}
}
}
-
- if (ex_fds && FD_ISSET(fd.g_fd(), ex_fds)) {
- struct v4l2_event ev;
-
- while (!fd.dqevent(ev)) {
- if (ev.type != V4L2_EVENT_EOS)
- continue;
- wr_fds = NULL;
- fprintf(stderr, "EOS");
- fflush(stderr);
- break;
- }
- }
}
fcntl(fd.g_fd(), F_SETFL, fd_flags);
--
2.17.1
[PATCH 4/6] media: ov5640: Add three more test patterns
The OV5640 driver currently supports a static color bar pattern with a
small vertical gamma gradient. The hardware also supports a color square
pattern, as well as having a rolling bar for dynamic sequences.
Add three more test patterns:
- color bars with a rolling bar (but without the gamma gradient)
- static color squares
- color squares with a rolling bar
Signed-off-by: Chen-Yu Tsai
---
drivers/media/i2c/ov5640.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index a1fd69a21df1..13311483792c 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -2444,6 +2444,9 @@ static int ov5640_set_ctrl_gain(struct ov5640_dev
*sensor, bool auto_gain)
static const char * const test_pattern_menu[] = {
"Disabled",
"Color bars",
+ "Color bars w/ rolling bar",
+ "Color squares",
+ "Color squares w/ rolling bar",
};
#define OV5640_TEST_ENABLE BIT(7)
@@ -2463,6 +2466,10 @@ static const u8 test_pattern_val[] = {
0,
OV5640_TEST_ENABLE | OV5640_TEST_BAR_VERT_CHANGE_1 |
OV5640_TEST_BAR,
+ OV5640_TEST_ENABLE | OV5640_TEST_ROLLING |
+ OV5640_TEST_BAR_VERT_CHANGE_1 | OV5640_TEST_BAR,
+ OV5640_TEST_ENABLE | OV5640_TEST_SQUARE,
+ OV5640_TEST_ENABLE | OV5640_TEST_ROLLING | OV5640_TEST_SQUARE,
};
static int ov5640_set_ctrl_test_pattern(struct ov5640_dev *sensor, int value)
--
2.20.1
[PATCH 0/6] media: ov5640: JPEG and test pattern improvements
Hi everyone, This series improves the JPEG compression output mode handling of the OV5640 sensor, and adds some more test patterns for users to use. The JPEG compression output mode of the sensor works, but the data framing is incorrect. Additional registers need to be set to configure the framing / timing of the data. This was found when adding support for JPEG_1X8 for the sun6i CSI sensor interface driver (improvements which I'll send in a separate series). Because the default timings might not be the same as the resolution timings, the capture device would either truncate or pad each line as it is captured. This corrupts the JPEG data. With the timings fixed, the captured data is once again a continuous JPEG file. While using the test pattern for testing, I found that the test pattern was superimposed on top of an actual captured image. This made it slightly harder to compare results, as the underlying image would change with scenery and static from the sensor. Disabling the transparency feature makes the result a "true" test pattern. I also added the "rolling bar" variant of the color bar test pattern, which is much better for testing video captures, as the image changes in a predictable way, instead of being static. Finally, another test pattern, "color squares", along with a rolling bar variant, were added as an alternative. Patch 1 is some simple code movement, in preparation for the next patch. Patch 2 adds definitions for the test pattern configuration register, to be used in the next patch. Patch 3 disables the transparency feature of the test pattern generator. Patch 4 adds more test pattern options. Patch 5 fixes the JPEG compression output data framing. Patch 6 consolidates the JPEG compression mode setting in one place, instead of being listed in the register dumps. Please have a look. Regards ChenYu Chen-Yu Tsai (6): media: ov5640: Move test_pattern_menu before ov5640_set_ctrl_test_pattern media: ov5640: Add register definition for test pattern register media: ov5640: Disable transparent feature for test pattern media: ov5640: Add three more test patterns media: ov5640: Set JPEG output timings when outputting JPEG data media: ov5640: Consolidate JPEG compression mode setting drivers/media/i2c/ov5640.c | 95 ++ 1 file changed, 77 insertions(+), 18 deletions(-) -- 2.20.1
[PATCH 2/6] media: ov5640: Add register definition for test pattern register
The OV5640 can generate many types of test patterns, some with
additional modifiers, such as a rolling bar, or gamma gradients.
Add the bit definitions for all bits in the test pattern register,
and use them to compose the values to be written to the register.
Signed-off-by: Chen-Yu Tsai
---
drivers/media/i2c/ov5640.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 8e4e8fa3685f..22d07b3cc8a2 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -2446,10 +2446,30 @@ static const char * const test_pattern_menu[] = {
"Color bars",
};
+#define OV5640_TEST_ENABLE BIT(7)
+#define OV5640_TEST_ROLLINGBIT(6) /* rolling horizontal bar */
+#define OV5640_TEST_TRANSPARENTBIT(5)
+#define OV5640_TEST_SQUARE_BW BIT(4) /* black & white squares */
+#define OV5640_TEST_BAR_STANDARD (0 << 2)
+#define OV5640_TEST_BAR_VERT_CHANGE_1 (1 << 2)
+#define OV5640_TEST_BAR_HOR_CHANGE (2 << 2)
+#define OV5640_TEST_BAR_VERT_CHANGE_2 (3 << 2)
+#define OV5640_TEST_BAR(0 << 0)
+#define OV5640_TEST_RANDOM (1 << 0)
+#define OV5640_TEST_SQUARE (2 << 0)
+#define OV5640_TEST_BLACK (3 << 0)
+
+static const u8 test_pattern_val[] = {
+ 0,
+ OV5640_TEST_ENABLE | OV5640_TEST_TRANSPARENT |
+ OV5640_TEST_BAR_VERT_CHANGE_1 |
+ OV5640_TEST_BAR,
+};
+
static int ov5640_set_ctrl_test_pattern(struct ov5640_dev *sensor, int value)
{
- return ov5640_mod_reg(sensor, OV5640_REG_PRE_ISP_TEST_SET1,
- 0xa4, value ? 0xa4 : 0);
+ return ov5640_write_reg(sensor, OV5640_REG_PRE_ISP_TEST_SET1,
+ test_pattern_val[value]);
}
static int ov5640_set_ctrl_light_freq(struct ov5640_dev *sensor, int value)
--
2.20.1
[PATCH 3/6] media: ov5640: Disable transparent feature for test pattern
The transparent feature for test patterns blends the test pattern with
an actual captured image. This makes the result non-static, subject to
changes in the sensor's field of view.
Test patterns should be predictable and deterministic, even if they are
dynamic patterns. Disable the transparent feature of the test pattern.
Signed-off-by: Chen-Yu Tsai
---
drivers/media/i2c/ov5640.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
index 22d07b3cc8a2..a1fd69a21df1 100644
--- a/drivers/media/i2c/ov5640.c
+++ b/drivers/media/i2c/ov5640.c
@@ -2461,8 +2461,7 @@ static const char * const test_pattern_menu[] = {
static const u8 test_pattern_val[] = {
0,
- OV5640_TEST_ENABLE | OV5640_TEST_TRANSPARENT |
- OV5640_TEST_BAR_VERT_CHANGE_1 |
+ OV5640_TEST_ENABLE | OV5640_TEST_BAR_VERT_CHANGE_1 |
OV5640_TEST_BAR,
};
--
2.20.1
[PATCH 8/8] soc_camera_platform: remove obsolete soc_camera test driver
From: Hans Verkuil
This is a test stub driver for soc_camera. Since soc_camera is
being deprecated (and in fact, nobody is using it anymore)
there's no sense in keeping this test driver.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/soc_camera/Kconfig | 6 -
drivers/media/platform/soc_camera/Makefile| 4 -
.../platform/soc_camera/soc_camera_platform.c | 188 --
.../platform_data/media/soc_camera_platform.h | 83
4 files changed, 281 deletions(-)
delete mode 100644 drivers/media/platform/soc_camera/soc_camera_platform.c
delete mode 100644 include/linux/platform_data/media/soc_camera_platform.h
diff --git a/drivers/media/platform/soc_camera/Kconfig
b/drivers/media/platform/soc_camera/Kconfig
index d471d34b884c..8f9b3bac5450 100644
--- a/drivers/media/platform/soc_camera/Kconfig
+++ b/drivers/media/platform/soc_camera/Kconfig
@@ -6,9 +6,3 @@ config SOC_CAMERA
SoC Camera is a common API to several cameras, not connecting
over a bus like PCI or USB. For example some i2c camera connected
directly to the data bus of an SoC.
-
-config SOC_CAMERA_PLATFORM
- tristate "platform camera support"
- depends on SOC_CAMERA
- help
- This is a generic SoC camera platform driver, useful for testing
diff --git a/drivers/media/platform/soc_camera/Makefile
b/drivers/media/platform/soc_camera/Makefile
index 2cb7022e073b..85d5e74f3b2b 100644
--- a/drivers/media/platform/soc_camera/Makefile
+++ b/drivers/media/platform/soc_camera/Makefile
@@ -1,5 +1 @@
obj-$(CONFIG_SOC_CAMERA) += soc_camera.o soc_mediabus.o
-
-# a platform subdevice driver stub, allowing to support cameras by adding a
-# couple of callback functions to the board code
-obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
diff --git a/drivers/media/platform/soc_camera/soc_camera_platform.c
b/drivers/media/platform/soc_camera/soc_camera_platform.c
deleted file mode 100644
index 79fbe1fea95f..
--- a/drivers/media/platform/soc_camera/soc_camera_platform.c
+++ /dev/null
@@ -1,188 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * Generic Platform Camera Driver
- *
- * Copyright (C) 2008 Magnus Damm
- * Based on mt9m001 driver,
- * Copyright (C) 2008, Guennadi Liakhovetski
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-struct soc_camera_platform_priv {
- struct v4l2_subdev subdev;
-};
-
-static struct soc_camera_platform_priv *get_priv(struct platform_device *pdev)
-{
- struct v4l2_subdev *subdev = platform_get_drvdata(pdev);
- return container_of(subdev, struct soc_camera_platform_priv, subdev);
-}
-
-static int soc_camera_platform_s_stream(struct v4l2_subdev *sd, int enable)
-{
- struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
- return p->set_capture(p, enable);
-}
-
-static int soc_camera_platform_fill_fmt(struct v4l2_subdev *sd,
- struct v4l2_subdev_pad_config *cfg,
- struct v4l2_subdev_format *format)
-{
- struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
- struct v4l2_mbus_framefmt *mf = &format->format;
-
- mf->width = p->format.width;
- mf->height = p->format.height;
- mf->code= p->format.code;
- mf->colorspace = p->format.colorspace;
- mf->field = p->format.field;
-
- return 0;
-}
-
-static int soc_camera_platform_s_power(struct v4l2_subdev *sd, int on)
-{
- struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
-
- return soc_camera_set_power(p->icd->control,
&p->icd->sdesc->subdev_desc, NULL, on);
-}
-
-static const struct v4l2_subdev_core_ops platform_subdev_core_ops = {
- .s_power = soc_camera_platform_s_power,
-};
-
-static int soc_camera_platform_enum_mbus_code(struct v4l2_subdev *sd,
- struct v4l2_subdev_pad_config *cfg,
- struct v4l2_subdev_mbus_code_enum *code)
-{
- struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
-
- if (code->pad || code->index)
- return -EINVAL;
-
- code->code = p->format.code;
- return 0;
-}
-
-static int soc_camera_platform_get_selection(struct v4l2_subdev *sd,
- struct v4l2_subdev_pad_config *cfg,
- struct v4l2_subdev_selection *sel)
-{
- struct soc_camera_platform_info *p = v4l2_get_subdevdata(sd);
-
- if (sel->which != V4L2_SUBDEV_FORMAT_ACTIVE)
- return -EINVAL;
-
- switch (sel->target) {
- case V4L2_SEL_TGT_CROP_BOUNDS:
- case V4L2_SEL_TGT_CROP_DEFAULT:
- case V4L2_SEL_TGT_CROP:
- sel->r.left = 0;
- sel->r.top = 0;
- sel->r.width = p->format.width;
- sel->r.height = p->format.height;
- return 0;
-
Re: [PATCH v2 1/1] media: Use common test pattern menu entries
Hi Mauro,
On Tue, Dec 04, 2018 at 12:41:42PM -0200, Mauro Carvalho Chehab wrote:
> Em Tue, 4 Dec 2018 15:40:42 +0200
> Sakari Ailus escreveu:
>
> > While the test pattern menu itself is not standardised, many devices
> > support the same test patterns. Aligning the menu entries helps the user
> > space to use the interface, and adding macros for the menu entry strings
> > helps to keep them aligned.
> >
> > Signed-off-by: Sakari Ailus
> > ---
> > since v1:
> >
> > - Fix indentation of menu strings
> > - Remove "8" from the macro names
> >
> > drivers/media/i2c/imx258.c | 10 +-
> > drivers/media/i2c/imx319.c | 10 +-
> > drivers/media/i2c/imx355.c | 10 +-
> > drivers/media/i2c/ov2640.c | 4 ++--
> > drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
> > include/uapi/linux/v4l2-controls.h | 5 +
> > 6 files changed, 27 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> > index f86ae18bc104..df5f016cebd9 100644
> > --- a/drivers/media/i2c/imx258.c
> > +++ b/drivers/media/i2c/imx258.c
> > @@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] =
> > {
> > };
> >
> > static const char * const imx258_test_pattern_menu[] = {
> > - "Disabled",
> > - "Solid Colour",
> > - "Eight Vertical Colour Bars",
> > - "Colour Bars With Fade to Grey",
> > - "Pseudorandom Sequence (PN9)",
> > + V4L2_TEST_PATTERN_DISABLED,
> > + V4L2_TEST_PATTERN_SOLID_COLOUR,
> > + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> > + V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
> > + V4L2_TEST_PATTERN_PN9,
> > };
> >
> > /* Configurations for supported link frequencies */
> > diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
> > index 17c2e4b41221..d9d4176b9d37 100644
> > --- a/drivers/media/i2c/imx319.c
> > +++ b/drivers/media/i2c/imx319.c
> > @@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[]
> > = {
> > };
> >
> > static const char * const imx319_test_pattern_menu[] = {
> > - "Disabled",
> > - "Solid Colour",
> > - "Eight Vertical Colour Bars",
> > - "Colour Bars With Fade to Grey",
> > - "Pseudorandom Sequence (PN9)",
> > + V4L2_TEST_PATTERN_DISABLED,
> > + V4L2_TEST_PATTERN_SOLID_COLOUR,
> > + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> > + V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
> > + V4L2_TEST_PATTERN_PN9,
> > };
> >
> > /* supported link frequencies */
> > diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
> > index bed293b60e50..99138a291cb8 100644
> > --- a/drivers/media/i2c/imx355.c
> > +++ b/drivers/media/i2c/imx355.c
> > @@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
> > };
> >
> > static const char * const imx355_test_pattern_menu[] = {
> > - "Disabled",
> > - "Solid Colour",
> > - "Eight Vertical Colour Bars",
> > - "Colour Bars With Fade to Grey",
> > - "Pseudorandom Sequence (PN9)",
> > + V4L2_TEST_PATTERN_DISABLED,
> > + V4L2_TEST_PATTERN_SOLID_COLOUR,
> > + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> > + V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
> > + V4L2_TEST_PATTERN_PN9,
> > };
> >
> > /* supported link frequencies */
> > diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
> > index 5d2d6735cc78..65058d9a5d51 100644
> > --- a/drivers/media/i2c/ov2640.c
> > +++ b/drivers/media/i2c/ov2640.c
> > @@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
> > }
> >
> > static const char * const ov2640_test_pattern_menu[] = {
> > - "Disabled",
> > - "Eight Vertical Colour Bars",
> > + V4L2_TEST_PATTERN_DISABLED,
> > + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> > };
> >
> > /*
> > diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
> > b/drivers/media/i2c/smiapp/smiapp-core.c
> > index 58a45c353e27..5c9bcc9438ec 100644
> > --- a/drivers/media/i2c/smiapp/smiapp-core.c
> > +++ b/drivers/media/i2c/smiapp/smiapp-core.c
> > @@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct
> > smiapp_sensor *sensor)
&g
Re: Test results (v4l2) for media/master - v4.20-rc5-281-gd2b4387f3bdf
Em Tue, 18 Dec 2018 07:31:23 -0800 (PST) "kernelci.org bot" escreveu: > Test results for: > Tree:media > Branch: master > Kernel: v4.20-rc5-281-gd2b4387f3bdf > URL: https://git.linuxtv.org/media_tree.git > Commit: d2b4387f3bdf016e266d23cf657465f557721488 > Test plans: v4l2 > > Summary > --- > 4 test groups results > > 1 | v4l2 | rk3399-gru-kevin | arm64 | 49 total: 17 PASS 6 > FAIL 26 SKIP > 2 | v4l2 | rk3288-veyron-jaq | arm | 49 total: 17 PASS 6 > FAIL 26 SKIP > 3 | v4l2 | qemu | arm64 | 115 total: 77 PASS 7 > FAIL 31 SKIP > 4 | v4l2 | qemu | arm | 115 total: 77 PASS 7 > FAIL 31 SKIP Please add, at linuxtv.org's wiki page, what each test actually means... > > --- > 1 | v4l2 | rk3399-gru-kevin | arm64 | 49 total: 17 PASS 6 > FAIL 26 SKIP > > Config: defconfig > Lab Name:lab-collabora > Date:2018-12-14 19:51:24.841000 > TXT log: > https://storage.kernelci.org//media/master/v4.20-rc5-281-gd2b4387f3bdf/arm64/defconfig/lab-collabora/v4l2-rk3399-gru-kevin.txt > HTML log: > https://storage.kernelci.org//media/master/v4.20-rc5-281-gd2b4387f3bdf/arm64/defconfig/lab-collabora/v4l2-rk3399-gru-kevin.html > Rootfs: > http://storage.kernelci.org/images/rootfs/debian/stretch-v4l2/20181207.0/arm64/rootfs.cpio.gz > Test Git:git://linuxtv.org/v4l-utils.git > Test Commit: 7a118f166609c0d05c6447cc79484af37875d6fc > > > Output-ioctls - 5 tests: 0 PASS, 0 FAIL, 5 SKIP > > Buffer-ioctls-Input-0 - 3 tests: 2 PASS, 1 FAIL, 0 SKIP > * Requests: FAIL > > Required-ioctls - 2 tests: 2 PASS, 0 FAIL, 0 SKIP > > Input/Output-configuration-ioctls - 4 tests: 0 PASS, 0 FAIL, 4 SKIP > > Control-ioctls-Input-0 - 6 tests: 3 PASS, 2 FAIL, 1 SKIP > * VIDIOC_G/S/TRY_EXT_CTRLS: FAIL > * VIDIOC_QUERY_EXT_CTRL/QUERYMENU: FAIL ... for example, in this specific case, I have no idea what driver failed. Ok, one could open the log txt file, look on it and discover that this specific test was against the uvcvideo driver, but it is doubtful to expect that everybody would do that. The best would be to also c/c the developer of the specific driver, if listed at MAINTAINERS, as he is the one that should come up with a fix. I also think that the patch subject should be changed to reflect the actual problems that was got, e. g., something like: [KernelCI] v4l2-compliance: uvcvideo: 6 failures, driver_foo: 8 failures > > Codec-ioctls-Input-0 - 3 tests: 0 PASS, 0 FAIL, 3 SKIP > > Debug-ioctls - 2 tests: 0 PASS, 0 FAIL, 2 SKIP > > Format-ioctls-Input-0 - 10 tests: 4 PASS, 1 FAIL, 5 SKIP > * VIDIOC_G/S_PARM: FAIL > > Streaming-ioctls_Test-input-0 - 4 tests: 1 PASS, 2 FAIL, 1 SKIP > * USERPTR: FAIL > * MMAP: FAIL > > Input-ioctls - 6 tests: 1 PASS, 0 FAIL, 5 SKIP > > Allow-for-multiple-opens - 4 tests: 4 PASS, 0 FAIL, 0 SKIP > > 2 | v4l2 | rk3288-veyron-jaq | arm | 49 total: 17 PASS 6 > FAIL 26 SKIP > > Config: multi_v7_defconfig > Lab Name:lab-collabora > Date:2018-12-14 19:51:35.774000 > TXT log: > https://storage.kernelci.org//media/master/v4.20-rc5-281-gd2b4387f3bdf/arm/multi_v7_defconfig/lab-collabora/v4l2-rk3288-veyron-jaq.txt > HTML log: > https://storage.kernelci.org//media/master/v4.20-rc5-281-gd2b4387f3bdf/arm/multi_v7_defconfig/lab-collabora/v4l2-rk3288-veyron-jaq.html > Rootfs: > http://storage.kernelci.org/images/rootfs/debian/stretch-v4l2/20181207.0/armhf/rootfs.cpio.gz > Test Git:git://linuxtv.org/v4l-utils.git > Test Commit: 7a118f166609c0d05c6447cc79484af37875d6fc > > > Output-ioctls - 5 tests: 0 PASS, 0 FAIL, 5 SKIP > > Buffer-ioctls-Input-0 - 3 tests: 2 PASS, 1 FAIL, 0 SKIP > * Requests: FAIL > > Required-ioctls - 2 tests: 2 PASS, 0 FAIL, 0 SKIP > > Input/Output-configuration-ioctls - 4 tests: 0 PASS, 0 FAIL, 4 SKIP > > Control-ioctls-Input-0 - 6 tests: 3 PASS, 2 FAIL, 1 SKIP > * VIDIOC_G/S/TRY_EXT_CTRLS: FAIL > * VIDIOC_QUERY_EXT_CTRL/QUERYMENU: FAIL > > Codec-ioctls-Input-0 - 3 tests: 0 PASS, 0 FAIL, 3 SKIP > > Debug-ioctls - 2 tests: 0 PASS, 0 FAIL, 2 SKIP > > Format-ioctls-Input-0 - 10 tests: 4 PASS, 1 FAIL, 5 SKIP > * VIDIOC_G/S_PARM: FAIL > > Streaming-ioctls_Test-input-0 - 4 tests: 1 PASS, 2 FAIL, 1 SKIP > * USERPTR: FAIL > * MMAP: FAIL > > Input-ioctls - 6 tests: 1 PASS, 0 FAIL, 5 SKIP
Test results (v4l2) for media/master - v4.20-rc5-281-gd2b4387f3bdf
Test results for: Tree:media Branch: master Kernel: v4.20-rc5-281-gd2b4387f3bdf URL: https://git.linuxtv.org/media_tree.git Commit: d2b4387f3bdf016e266d23cf657465f557721488 Test plans: v4l2 Summary --- 4 test groups results 1 | v4l2 | rk3399-gru-kevin | arm64 | 49 total: 17 PASS 6 FAIL 26 SKIP 2 | v4l2 | rk3288-veyron-jaq | arm | 49 total: 17 PASS 6 FAIL 26 SKIP 3 | v4l2 | qemu | arm64 | 115 total: 77 PASS 7 FAIL 31 SKIP 4 | v4l2 | qemu | arm | 115 total: 77 PASS 7 FAIL 31 SKIP --- 1 | v4l2 | rk3399-gru-kevin | arm64 | 49 total: 17 PASS 6 FAIL 26 SKIP Config: defconfig Lab Name:lab-collabora Date:2018-12-14 19:51:24.841000 TXT log: https://storage.kernelci.org//media/master/v4.20-rc5-281-gd2b4387f3bdf/arm64/defconfig/lab-collabora/v4l2-rk3399-gru-kevin.txt HTML log: https://storage.kernelci.org//media/master/v4.20-rc5-281-gd2b4387f3bdf/arm64/defconfig/lab-collabora/v4l2-rk3399-gru-kevin.html Rootfs: http://storage.kernelci.org/images/rootfs/debian/stretch-v4l2/20181207.0/arm64/rootfs.cpio.gz Test Git:git://linuxtv.org/v4l-utils.git Test Commit: 7a118f166609c0d05c6447cc79484af37875d6fc Output-ioctls - 5 tests: 0 PASS, 0 FAIL, 5 SKIP Buffer-ioctls-Input-0 - 3 tests: 2 PASS, 1 FAIL, 0 SKIP * Requests: FAIL Required-ioctls - 2 tests: 2 PASS, 0 FAIL, 0 SKIP Input/Output-configuration-ioctls - 4 tests: 0 PASS, 0 FAIL, 4 SKIP Control-ioctls-Input-0 - 6 tests: 3 PASS, 2 FAIL, 1 SKIP * VIDIOC_G/S/TRY_EXT_CTRLS: FAIL * VIDIOC_QUERY_EXT_CTRL/QUERYMENU: FAIL Codec-ioctls-Input-0 - 3 tests: 0 PASS, 0 FAIL, 3 SKIP Debug-ioctls - 2 tests: 0 PASS, 0 FAIL, 2 SKIP Format-ioctls-Input-0 - 10 tests: 4 PASS, 1 FAIL, 5 SKIP * VIDIOC_G/S_PARM: FAIL Streaming-ioctls_Test-input-0 - 4 tests: 1 PASS, 2 FAIL, 1 SKIP * USERPTR: FAIL * MMAP: FAIL Input-ioctls - 6 tests: 1 PASS, 0 FAIL, 5 SKIP Allow-for-multiple-opens - 4 tests: 4 PASS, 0 FAIL, 0 SKIP 2 | v4l2 | rk3288-veyron-jaq | arm | 49 total: 17 PASS 6 FAIL 26 SKIP Config: multi_v7_defconfig Lab Name:lab-collabora Date:2018-12-14 19:51:35.774000 TXT log: https://storage.kernelci.org//media/master/v4.20-rc5-281-gd2b4387f3bdf/arm/multi_v7_defconfig/lab-collabora/v4l2-rk3288-veyron-jaq.txt HTML log: https://storage.kernelci.org//media/master/v4.20-rc5-281-gd2b4387f3bdf/arm/multi_v7_defconfig/lab-collabora/v4l2-rk3288-veyron-jaq.html Rootfs: http://storage.kernelci.org/images/rootfs/debian/stretch-v4l2/20181207.0/armhf/rootfs.cpio.gz Test Git:git://linuxtv.org/v4l-utils.git Test Commit: 7a118f166609c0d05c6447cc79484af37875d6fc Output-ioctls - 5 tests: 0 PASS, 0 FAIL, 5 SKIP Buffer-ioctls-Input-0 - 3 tests: 2 PASS, 1 FAIL, 0 SKIP * Requests: FAIL Required-ioctls - 2 tests: 2 PASS, 0 FAIL, 0 SKIP Input/Output-configuration-ioctls - 4 tests: 0 PASS, 0 FAIL, 4 SKIP Control-ioctls-Input-0 - 6 tests: 3 PASS, 2 FAIL, 1 SKIP * VIDIOC_G/S/TRY_EXT_CTRLS: FAIL * VIDIOC_QUERY_EXT_CTRL/QUERYMENU: FAIL Codec-ioctls-Input-0 - 3 tests: 0 PASS, 0 FAIL, 3 SKIP Debug-ioctls - 2 tests: 0 PASS, 0 FAIL, 2 SKIP Format-ioctls-Input-0 - 10 tests: 4 PASS, 1 FAIL, 5 SKIP * VIDIOC_G/S_PARM: FAIL Streaming-ioctls_Test-input-0 - 4 tests: 1 PASS, 2 FAIL, 1 SKIP * USERPTR: FAIL * MMAP: FAIL Input-ioctls - 6 tests: 1 PASS, 0 FAIL, 5 SKIP Allow-for-multiple-opens - 4 tests: 4 PASS, 0 FAIL, 0 SKIP 3 | v4l2 | qemu | arm64 | 115 total: 77 PASS 7 FAIL 31 SKIP Config: defconfig+virtualvideo Lab Name:lab-collabora Date:2018-12-14 20:04:54.451000 TXT log: https://storage.kernelci.org//media/master/v4.20-rc5-281-gd2b4387f3bdf/arm64/defconfig+virtualvideo/lab-collabora/v4l2-qemu.txt HTML log: https://storage.kernelci.org//media/master/v4.20-rc5-281-gd2b4387f3bdf/arm64/defconfig+virtualvideo/lab-collabora/v4l2-qemu.html Rootfs: http://storage.kernelci.org/images/rootfs/debian/stretch-v4l2/20181207.0/arm64/rootfs.cpio.gz Test Git:git://linuxtv.org/v4l-utils.git Test Commit: 7a118f166609c0d05c6447cc79484af37875d6fc Buffer-ioctls-Input-3 - 3 tests: 2 PASS, 1 FAIL, 0 SKIP * Requests: FAIL Buffer-ioctls-Input-2 - 3 tests: 2 PASS, 1 FAIL, 0 SKIP * Requests: FAIL Buffer-ioctls-Input-1 - 3 tests: 1 PASS, 2 FAIL, 0 SKIP * Requests: FAIL * VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: FAIL Buffer-ioctls-Input-0 - 3 tests: 2 PASS, 1 FAIL, 0 SKIP * Requests: FAIL Control-ioctls-Input-3 - 6 tests: 5 PASS, 0 FAIL, 1 SKIP Control-ioctls-Input-2 - 6 tests: 5 PASS, 0 FAIL, 1
Re: [RFCv5 PATCH 4/4] vimc: add property test code
Em Thu, 13 Dec 2018 14:41:13 +0100
hverkuil-ci...@xs4all.nl escreveu:
> From: Hans Verkuil
>
> Add properties to entities and pads to be able to test the
> properties API.
Looks OK to me.
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/platform/vimc/vimc-common.c | 50 +++
> 1 file changed, 50 insertions(+)
>
> diff --git a/drivers/media/platform/vimc/vimc-common.c
> b/drivers/media/platform/vimc/vimc-common.c
> index 867e24dbd6b5..e3d5d4b3b44d 100644
> --- a/drivers/media/platform/vimc/vimc-common.c
> +++ b/drivers/media/platform/vimc/vimc-common.c
> @@ -417,6 +417,7 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
>const unsigned long *pads_flag,
>const struct v4l2_subdev_ops *sd_ops)
> {
> + struct media_prop *prop = NULL;
> int ret;
>
> /* Allocate the pads */
> @@ -454,6 +455,55 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
> goto err_clean_m_ent;
> }
>
> + ret = media_entity_add_prop_u64(&sd->entity, "u64", ~1);
> + if (!ret)
> + ret = media_entity_add_prop_s64(&sd->entity, "s64", -5);
> + if (!ret)
> + ret = media_entity_add_prop_string(&sd->entity, "string",
> +sd->name);
> + if (!ret) {
> + prop = media_entity_add_prop_group(&sd->entity, "empty-group");
> + ret = PTR_ERR_OR_ZERO(prop);
> + }
> + if (!ret) {
> + prop = media_entity_add_prop_group(&sd->entity, "group");
> + ret = PTR_ERR_OR_ZERO(prop);
> + }
> + if (!ret)
> + ret = media_prop_add_prop_u64(prop, "u64", 42);
> + if (!ret)
> + ret = media_prop_add_prop_s64(prop, "s64", -42);
> + if (!ret)
> + ret = media_prop_add_prop_string(prop, "string", "42");
> + if (!ret)
> + ret = media_pad_add_prop_u64(&sd->entity.pads[num_pads - 1],
> + "u64", ~1);
> + if (!ret)
> + ret = media_pad_add_prop_s64(&sd->entity.pads[num_pads - 1],
> + "s64", -5);
> + if (!ret) {
> + prop = media_pad_add_prop_group(&sd->entity.pads[num_pads - 1],
> + "group");
> + ret = PTR_ERR_OR_ZERO(prop);
> + }
> + if (!ret)
> + ret = media_prop_add_prop_u64(prop, "u64", 24);
> + if (!ret)
> + ret = media_prop_add_prop_s64(prop, "s64", -24);
> + if (!ret)
> + ret = media_pad_add_prop_string(&sd->entity.pads[0],
> + "string", sd->name);
> + if (!ret)
> + ret = media_prop_add_prop_string(prop, "string", "24");
> + if (!ret) {
> + prop = media_prop_add_prop_group(prop, "subgroup");
> + ret = PTR_ERR_OR_ZERO(prop);
> + }
> + if (!ret)
> + ret = media_prop_add_prop_string(prop, "string", "substring");
> + if (ret)
> + goto err_clean_m_ent;
> +
> return 0;
>
> err_clean_m_ent:
Thanks,
Mauro
[RFCv5 PATCH 4/4] vimc: add property test code
From: Hans Verkuil
Add properties to entities and pads to be able to test the
properties API.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/vimc/vimc-common.c | 50 +++
1 file changed, 50 insertions(+)
diff --git a/drivers/media/platform/vimc/vimc-common.c
b/drivers/media/platform/vimc/vimc-common.c
index 867e24dbd6b5..e3d5d4b3b44d 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -417,6 +417,7 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
const unsigned long *pads_flag,
const struct v4l2_subdev_ops *sd_ops)
{
+ struct media_prop *prop = NULL;
int ret;
/* Allocate the pads */
@@ -454,6 +455,55 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
goto err_clean_m_ent;
}
+ ret = media_entity_add_prop_u64(&sd->entity, "u64", ~1);
+ if (!ret)
+ ret = media_entity_add_prop_s64(&sd->entity, "s64", -5);
+ if (!ret)
+ ret = media_entity_add_prop_string(&sd->entity, "string",
+ sd->name);
+ if (!ret) {
+ prop = media_entity_add_prop_group(&sd->entity, "empty-group");
+ ret = PTR_ERR_OR_ZERO(prop);
+ }
+ if (!ret) {
+ prop = media_entity_add_prop_group(&sd->entity, "group");
+ ret = PTR_ERR_OR_ZERO(prop);
+ }
+ if (!ret)
+ ret = media_prop_add_prop_u64(prop, "u64", 42);
+ if (!ret)
+ ret = media_prop_add_prop_s64(prop, "s64", -42);
+ if (!ret)
+ ret = media_prop_add_prop_string(prop, "string", "42");
+ if (!ret)
+ ret = media_pad_add_prop_u64(&sd->entity.pads[num_pads - 1],
+"u64", ~1);
+ if (!ret)
+ ret = media_pad_add_prop_s64(&sd->entity.pads[num_pads - 1],
+"s64", -5);
+ if (!ret) {
+ prop = media_pad_add_prop_group(&sd->entity.pads[num_pads - 1],
+ "group");
+ ret = PTR_ERR_OR_ZERO(prop);
+ }
+ if (!ret)
+ ret = media_prop_add_prop_u64(prop, "u64", 24);
+ if (!ret)
+ ret = media_prop_add_prop_s64(prop, "s64", -24);
+ if (!ret)
+ ret = media_pad_add_prop_string(&sd->entity.pads[0],
+ "string", sd->name);
+ if (!ret)
+ ret = media_prop_add_prop_string(prop, "string", "24");
+ if (!ret) {
+ prop = media_prop_add_prop_group(prop, "subgroup");
+ ret = PTR_ERR_OR_ZERO(prop);
+ }
+ if (!ret)
+ ret = media_prop_add_prop_string(prop, "string", "substring");
+ if (ret)
+ goto err_clean_m_ent;
+
return 0;
err_clean_m_ent:
--
2.19.2
Re: [RFCv4 PATCH 3/3] vimc: add property test code
Em Wed, 21 Nov 2018 16:40:24 +0100
Hans Verkuil escreveu:
> From: Hans Verkuil
>
> Add properties to entities and pads to be able to test the
> properties API.
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/platform/vimc/vimc-common.c | 50 +++
> 1 file changed, 50 insertions(+)
>
> diff --git a/drivers/media/platform/vimc/vimc-common.c
> b/drivers/media/platform/vimc/vimc-common.c
> index dee1b9dfc4f6..2f70e4e64790 100644
> --- a/drivers/media/platform/vimc/vimc-common.c
> +++ b/drivers/media/platform/vimc/vimc-common.c
> @@ -415,6 +415,7 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
>const unsigned long *pads_flag,
>const struct v4l2_subdev_ops *sd_ops)
> {
> + struct media_prop *prop = NULL;
> int ret;
>
> /* Allocate the pads */
> @@ -452,6 +453,55 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
> goto err_clean_m_ent;
> }
>
> + ret = media_entity_add_prop_u64(&sd->entity, "u64", ~1);
> + if (!ret)
> + ret = media_entity_add_prop_s64(&sd->entity, "s64", -5);
> + if (!ret)
> + ret = media_entity_add_prop_string(&sd->entity, "string",
> +sd->name);
> + if (!ret) {
> + prop = media_entity_add_prop_group(&sd->entity, "empty-group");
> + ret = PTR_ERR_OR_ZERO(prop);
> + }
> + if (!ret) {
> + prop = media_entity_add_prop_group(&sd->entity, "group");
> + ret = PTR_ERR_OR_ZERO(prop);
> + }
> + if (!ret)
> + ret = media_prop_add_prop_u64(prop, "u64", 42);
> + if (!ret)
> + ret = media_prop_add_prop_s64(prop, "s64", -42);
> + if (!ret)
> + ret = media_prop_add_prop_string(prop, "string", "42");
> + if (!ret)
> + ret = media_pad_add_prop_u64(&sd->entity.pads[num_pads - 1],
> + "u64", ~1);
> + if (!ret)
> + ret = media_pad_add_prop_s64(&sd->entity.pads[num_pads - 1],
> + "s64", -5);
> + if (!ret) {
> + prop = media_pad_add_prop_group(&sd->entity.pads[num_pads - 1],
> + "group");
> + ret = PTR_ERR_OR_ZERO(prop);
> + }
> + if (!ret)
> + ret = media_prop_add_prop_u64(prop, "u64", 24);
> + if (!ret)
> + ret = media_prop_add_prop_s64(prop, "s64", -24);
> + if (!ret)
> + ret = media_pad_add_prop_string(&sd->entity.pads[0],
> + "string", sd->name);
> + if (!ret)
> + ret = media_prop_add_prop_string(prop, "string", "24");
> + if (!ret) {
> + prop = media_prop_add_prop_group(prop, "subgroup");
> + ret = PTR_ERR_OR_ZERO(prop);
> + }
> + if (!ret)
> + ret = media_prop_add_prop_string(prop, "string", "substring");
> + if (ret)
> + goto err_clean_m_ent;
> +
> return 0;
>
> err_clean_m_ent:
Sounds OK to me.
Thanks,
Mauro
Re: [RFC] Create test script(s?) for regression testing
A quick status update regarding creating test scripts for regression testing on kernelci. I'm also CC-ing Dmitry to give an update on the work fixing syzkaller bugs. On 11/6/18 9:37 AM, Hans Verkuil wrote: > Hi all, > > After the media summit (heavy on test discussions) and the V4L2 event > regression > we just found it is clear we need to do a better job with testing. > > All the pieces are in place, so what is needed is to combine it and create a > script that anyone of us as core developers can run to check for regressions. > The same script can be run as part of the kernelci regression testing. > > We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last one > is IMHO not quite good enough yet for testing: it is not fully compliant to > the > upcoming stateful codec spec. Work for that is planned as part of an Outreachy > project. This Outreachy project started last week, so hopefully we'll have something that is usable by January. > > My idea is to create a script that is maintained as part of v4l-utils that > loads the drivers and runs v4l2-compliance and possibly other tests against > the virtual drivers. > > It should be simple to use and require very little in the way of dependencies. > Ideally no dependencies other than what is in v4l-utils so it can easily be > run > on an embedded system as well. I have a simple script: modprobe vivid no_error_inj=1 n_devs=3 multiplanar=1,2,1 modprobe vim2m modprobe vimc v4l2-ctl -d0 -i3 -v width=3840,height=2160,pixelformat=XR24 v4l2-ctl -d1 -o1 -x width=3840,height=2160,pixelformat=XR24 v4l2-ctl -d2 -i3 -v width=3840,height=2160,pixelformat=XR24 v4l2-ctl -d3 -o1 -x width=3840,height=2160,pixelformat=XR24 v4l2-ctl -d4 -i3 -v width=3840,height=2160,pixelformat=XR24 v4l2-compliance -m0 -e4 -s10 v4l2-compliance -m1 -e4 -s10 v4l2-compliance -m3 -e4 -s10 v4l2-compliance -m4 -e4 -s10 But there are too many failures at the moment. Most are fixed, but several first need to be merged into the 4.20 mainline kernel before they can be backported to our master branch. Once they are backported, then there is still one outstanding vivid/vimc failure, fixed in this series: https://www.mail-archive.com/linux-media@vger.kernel.org/msg136900.html That won't make 4.21, but hopefully it will make 4.22. This is probably the main blocker for the kernelci regression test. vimc fails at several places, but most are known API issues that we really need to nail down at some point. Finding time is the issue, but in the meantime I can probably downgrade the errors to warnings in v4l2-compliance. In addition, work is ongoing to make the topology configurable with configfs, and I think we can postpone regression testing with vimc until that is merged (I hope for 4.22). > For a 64-bit kernel it should run the tests both with 32-bit and 64-bit > applications. Haven't done that yet. > > It should also test with both single and multiplanar modes where available. That's done (see vivid multiplanar module option in the script). > > Since vivid emulates CEC as well, it should run CEC tests too. Not done yet. > > As core developers we should have an environment where we can easily test > our patches with this script (I use a VM for that). > > I think maintaining the script (or perhaps scripts) in v4l-utils is best since > that keeps it in sync with the latest kernel and v4l-utils developments. > > Comments? Ideas? Regarding fixing the open syzkaller issues: most is done, but there is one fix still pending: https://www.mail-archive.com/linux-media@vger.kernel.org/msg136512.html It's more complex than I'd like, but I'm not sure if it can be improved. I will have to take another look when 4.22 opens. This patch series fixes issues when the filehandle is dupped and different fds can do actions in parallel that would otherwise not happen. Regards, Hans
[PATCH] media: imx274: fix wrong order in test pattern menus
The description of test patterns 11 and 12 are swapped.
Checked against the live sensor.
Signed-off-by: Luca Ceresoli
---
drivers/media/i2c/imx274.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/imx274.c b/drivers/media/i2c/imx274.c
index 5fac7fd32634..95e3d90309e8 100644
--- a/drivers/media/i2c/imx274.c
+++ b/drivers/media/i2c/imx274.c
@@ -207,8 +207,8 @@ static const char * const tp_qmenu[] = {
"Vertical Stripe (555h / 000h)",
"Vertical Stripe (000h / FFFh)",
"Vertical Stripe (FFFh / 000h)",
- "Horizontal Color Bars",
"Vertical Color Bars",
+ "Horizontal Color Bars",
};
/*
--
2.17.1
Re: [PATCH v2 1/1] media: Use common test pattern menu entries
Em Tue, 4 Dec 2018 15:40:42 +0200
Sakari Ailus escreveu:
> While the test pattern menu itself is not standardised, many devices
> support the same test patterns. Aligning the menu entries helps the user
> space to use the interface, and adding macros for the menu entry strings
> helps to keep them aligned.
>
> Signed-off-by: Sakari Ailus
> ---
> since v1:
>
> - Fix indentation of menu strings
> - Remove "8" from the macro names
>
> drivers/media/i2c/imx258.c | 10 +-
> drivers/media/i2c/imx319.c | 10 +-
> drivers/media/i2c/imx355.c | 10 +-
> drivers/media/i2c/ov2640.c | 4 ++--
> drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
> include/uapi/linux/v4l2-controls.h | 5 +
> 6 files changed, 27 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> index f86ae18bc104..df5f016cebd9 100644
> --- a/drivers/media/i2c/imx258.c
> +++ b/drivers/media/i2c/imx258.c
> @@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] = {
> };
>
> static const char * const imx258_test_pattern_menu[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
> };
>
> /* Configurations for supported link frequencies */
> diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
> index 17c2e4b41221..d9d4176b9d37 100644
> --- a/drivers/media/i2c/imx319.c
> +++ b/drivers/media/i2c/imx319.c
> @@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[] =
> {
> };
>
> static const char * const imx319_test_pattern_menu[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
> };
>
> /* supported link frequencies */
> diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
> index bed293b60e50..99138a291cb8 100644
> --- a/drivers/media/i2c/imx355.c
> +++ b/drivers/media/i2c/imx355.c
> @@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
> };
>
> static const char * const imx355_test_pattern_menu[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
> };
>
> /* supported link frequencies */
> diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
> index 5d2d6735cc78..65058d9a5d51 100644
> --- a/drivers/media/i2c/ov2640.c
> +++ b/drivers/media/i2c/ov2640.c
> @@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
> }
>
> static const char * const ov2640_test_pattern_menu[] = {
> - "Disabled",
> - "Eight Vertical Colour Bars",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> };
>
> /*
> diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
> b/drivers/media/i2c/smiapp/smiapp-core.c
> index 58a45c353e27..5c9bcc9438ec 100644
> --- a/drivers/media/i2c/smiapp/smiapp-core.c
> +++ b/drivers/media/i2c/smiapp/smiapp-core.c
> @@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct
> smiapp_sensor *sensor)
> }
>
> static const char * const smiapp_test_patterns[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
> };
>
> static int smiapp
Re: [PATCH 1/1] media: Use common test pattern menu entries
On Tue, Nov 27, 2018 at 07:19:52PM +0800, Bingbu Cao wrote:
>
> On 11/27/2018 05:33 PM, Sakari Ailus wrote:
> > diff --git a/include/uapi/linux/v4l2-controls.h
> > b/include/uapi/linux/v4l2-controls.h
> > index 998983a6e6b7..a74ff6f1ac88 100644
> > --- a/include/uapi/linux/v4l2-controls.h
> > +++ b/include/uapi/linux/v4l2-controls.h
> > @@ -1014,6 +1014,11 @@ enum v4l2_jpeg_chroma_subsampling {
> > #define V4L2_CID_LINK_FREQ
> > (V4L2_CID_IMAGE_PROC_CLASS_BASE + 1)
> > #define V4L2_CID_PIXEL_RATE
> > (V4L2_CID_IMAGE_PROC_CLASS_BASE + 2)
> > #define V4L2_CID_TEST_PATTERN
> > (V4L2_CID_IMAGE_PROC_CLASS_BASE + 3)
> > +#define V4L2_TEST_PATTERN_DISABLED "Disabled"
> > +#define V4L2_TEST_PATTERN_SOLID_COLOUR "Solid Colour"
> > +#define V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS "Eight Vertical
> > Colour Bars"
> > +#define V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY "Colour Bars
> > With Fade to Grey"
> > +#define V4L2_TEST_PATTERN_PN9 "Pseudorandom Sequence
> > (PN9)"
> More padding here for alignment?
Fixed in v2.
--
Sakari Ailus
[PATCH v2 1/1] media: Use common test pattern menu entries
While the test pattern menu itself is not standardised, many devices
support the same test patterns. Aligning the menu entries helps the user
space to use the interface, and adding macros for the menu entry strings
helps to keep them aligned.
Signed-off-by: Sakari Ailus
---
since v1:
- Fix indentation of menu strings
- Remove "8" from the macro names
drivers/media/i2c/imx258.c | 10 +-
drivers/media/i2c/imx319.c | 10 +-
drivers/media/i2c/imx355.c | 10 +-
drivers/media/i2c/ov2640.c | 4 ++--
drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
include/uapi/linux/v4l2-controls.h | 5 +
6 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
index f86ae18bc104..df5f016cebd9 100644
--- a/drivers/media/i2c/imx258.c
+++ b/drivers/media/i2c/imx258.c
@@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] = {
};
static const char * const imx258_test_pattern_menu[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
/* Configurations for supported link frequencies */
diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
index 17c2e4b41221..d9d4176b9d37 100644
--- a/drivers/media/i2c/imx319.c
+++ b/drivers/media/i2c/imx319.c
@@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[] = {
};
static const char * const imx319_test_pattern_menu[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
/* supported link frequencies */
diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index bed293b60e50..99138a291cb8 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
};
static const char * const imx355_test_pattern_menu[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
/* supported link frequencies */
diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index 5d2d6735cc78..65058d9a5d51 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
}
static const char * const ov2640_test_pattern_menu[] = {
- "Disabled",
- "Eight Vertical Colour Bars",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
};
/*
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index 58a45c353e27..5c9bcc9438ec 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct
smiapp_sensor *sensor)
}
static const char * const smiapp_test_patterns[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 998983a6e6b7..acb2a57fa5d6 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -1014,6 +1014,11 @@ enum v4l2_jpeg_chroma_subsampling {
#define V4L2_CID_LINK_FREQ (V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 1)
#define V4L2_CID_PIXEL_RATE(V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 2)
#define V4L2_CID_TEST_PATTERN (V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 3)
+#define V4L2_TEST_PATTERN_DISABLED
Re: [RESEND PATCH 1/1] media: Use common test pattern menu entries
On Tue, Nov 27, 2018 at 01:11:42PM +0100, Luca Ceresoli wrote:
> Hi Sakari, Bingbu,
>
> On 27/11/18 10:34, Sakari Ailus wrote:
> > While the test pattern menu itself is not standardised, many devices
> > support the same test patterns. Aligning the menu entries helps the user
> > space to use the interface, and adding macros for the menu entry strings
> > helps to keep them aligned.
> >
> > Signed-off-by: Sakari Ailus
> > ---
> > Fixed Andy's email.
> >
> > drivers/media/i2c/imx258.c | 10 +-
> > drivers/media/i2c/imx319.c | 10 +-
> > drivers/media/i2c/imx355.c | 10 +-
> > drivers/media/i2c/ov2640.c | 4 ++--
> > drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
> > include/uapi/linux/v4l2-controls.h | 5 +
> > 6 files changed, 27 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> > index f86ae18bc104..c795d4c4c0e4 100644
> > --- a/drivers/media/i2c/imx258.c
> > +++ b/drivers/media/i2c/imx258.c
> > @@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] =
> > {
> > };
> >
> > static const char * const imx258_test_pattern_menu[] = {
> > - "Disabled",
> > - "Solid Colour",
> > - "Eight Vertical Colour Bars",
> > - "Colour Bars With Fade to Grey",
> > - "Pseudorandom Sequence (PN9)",
> > + V4L2_TEST_PATTERN_DISABLED,
> > + V4L2_TEST_PATTERN_SOLID_COLOUR,
> > + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> > + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
> > + V4L2_TEST_PATTERN_PN9,
> > };
> >
> > /* Configurations for supported link frequencies */
> > diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
> > index 17c2e4b41221..eddaf69a67b6 100644
> > --- a/drivers/media/i2c/imx319.c
> > +++ b/drivers/media/i2c/imx319.c
> > @@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[]
> > = {
> > };
> >
> > static const char * const imx319_test_pattern_menu[] = {
> > - "Disabled",
> > - "Solid Colour",
> > - "Eight Vertical Colour Bars",
> > - "Colour Bars With Fade to Grey",
> > - "Pseudorandom Sequence (PN9)",
> > + V4L2_TEST_PATTERN_DISABLED,
> > + V4L2_TEST_PATTERN_SOLID_COLOUR,
> > + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> > + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
> > + V4L2_TEST_PATTERN_PN9,
> > };
> >
> > /* supported link frequencies */
> > diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
> > index bed293b60e50..824d07156f9c 100644
> > --- a/drivers/media/i2c/imx355.c
> > +++ b/drivers/media/i2c/imx355.c
> > @@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
> > };
> >
> > static const char * const imx355_test_pattern_menu[] = {
> > - "Disabled",
> > - "Solid Colour",
> > - "Eight Vertical Colour Bars",
> > - "Colour Bars With Fade to Grey",
> > - "Pseudorandom Sequence (PN9)",
> > + V4L2_TEST_PATTERN_DISABLED,
> > + V4L2_TEST_PATTERN_SOLID_COLOUR,
> > + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> > + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
> > + V4L2_TEST_PATTERN_PN9,
> > };
> >
> > /* supported link frequencies */
> > diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
> > index 5d2d6735cc78..507ec7176a7d 100644
> > --- a/drivers/media/i2c/ov2640.c
> > +++ b/drivers/media/i2c/ov2640.c
> > @@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
> > }
> >
> > static const char * const ov2640_test_pattern_menu[] = {
> > - "Disabled",
> > - "Eight Vertical Colour Bars",
> > + V4L2_TEST_PATTERN_DISABLED,
> > + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> > };
> >
> > /*
> > diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
> > b/drivers/media/i2c/smiapp/smiapp-core.c
> > index 58a45c353e27..f6a92b9f178c 100644
> > --- a/drivers/media/i2c/smiapp/smiapp-core.c
> > +++ b/drivers/media/i2c/smiapp/smiapp-core.c
> > @@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct
> > smiapp_sensor *sensor)
> > }
> >
> > static const char * const smiapp_test_patterns[] = {
> > -
Re: [RESEND PATCH 1/1] media: Use common test pattern menu entries
Hi Sakari, Bingbu,
On 27/11/18 10:34, Sakari Ailus wrote:
> While the test pattern menu itself is not standardised, many devices
> support the same test patterns. Aligning the menu entries helps the user
> space to use the interface, and adding macros for the menu entry strings
> helps to keep them aligned.
>
> Signed-off-by: Sakari Ailus
> ---
> Fixed Andy's email.
>
> drivers/media/i2c/imx258.c | 10 +-
> drivers/media/i2c/imx319.c | 10 +-
> drivers/media/i2c/imx355.c | 10 +-
> drivers/media/i2c/ov2640.c | 4 ++--
> drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
> include/uapi/linux/v4l2-controls.h | 5 +
> 6 files changed, 27 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> index f86ae18bc104..c795d4c4c0e4 100644
> --- a/drivers/media/i2c/imx258.c
> +++ b/drivers/media/i2c/imx258.c
> @@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] = {
> };
>
> static const char * const imx258_test_pattern_menu[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
> };
>
> /* Configurations for supported link frequencies */
> diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
> index 17c2e4b41221..eddaf69a67b6 100644
> --- a/drivers/media/i2c/imx319.c
> +++ b/drivers/media/i2c/imx319.c
> @@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[] =
> {
> };
>
> static const char * const imx319_test_pattern_menu[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
> };
>
> /* supported link frequencies */
> diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
> index bed293b60e50..824d07156f9c 100644
> --- a/drivers/media/i2c/imx355.c
> +++ b/drivers/media/i2c/imx355.c
> @@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
> };
>
> static const char * const imx355_test_pattern_menu[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
> };
>
> /* supported link frequencies */
> diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
> index 5d2d6735cc78..507ec7176a7d 100644
> --- a/drivers/media/i2c/ov2640.c
> +++ b/drivers/media/i2c/ov2640.c
> @@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
> }
>
> static const char * const ov2640_test_pattern_menu[] = {
> - "Disabled",
> - "Eight Vertical Colour Bars",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> };
>
> /*
> diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
> b/drivers/media/i2c/smiapp/smiapp-core.c
> index 58a45c353e27..f6a92b9f178c 100644
> --- a/drivers/media/i2c/smiapp/smiapp-core.c
> +++ b/drivers/media/i2c/smiapp/smiapp-core.c
> @@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct
> smiapp_sensor *sensor)
> }
>
> static const char * const smiapp_test_patterns[] = {
> - "Disabled",
> - "Solid Colour",
> - "Eight Vertical Colour Bars",
> - "Colour Bars With Fade to Grey",
> - "Pseudorandom Sequence (PN9)",
> + V4L2_TEST_PATTERN_DISABLED,
> + V4L2_TEST_PATTERN_SOLID_COLOUR,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
> + V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
> + V4L2_TEST_PATTERN_PN9,
> };
>
> static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
> diff --git a/include/uapi/linux/v
Re: [PATCH 1/1] media: Use common test pattern menu entries
On 11/27/2018 05:33 PM, Sakari Ailus wrote:
While the test pattern menu itself is not standardised, many devices
support the same test patterns. Aligning the menu entries helps the user
space to use the interface, and adding macros for the menu entry strings
helps to keep them aligned.
I like this patch.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/imx258.c | 10 +-
drivers/media/i2c/imx319.c | 10 +-
drivers/media/i2c/imx355.c | 10 +-
drivers/media/i2c/ov2640.c | 4 ++--
drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
include/uapi/linux/v4l2-controls.h | 5 +
6 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
index f86ae18bc104..c795d4c4c0e4 100644
--- a/drivers/media/i2c/imx258.c
+++ b/drivers/media/i2c/imx258.c
@@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] = {
};
static const char * const imx258_test_pattern_menu[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
/* Configurations for supported link frequencies */
diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
index 17c2e4b41221..eddaf69a67b6 100644
--- a/drivers/media/i2c/imx319.c
+++ b/drivers/media/i2c/imx319.c
@@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[] = {
};
static const char * const imx319_test_pattern_menu[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
/* supported link frequencies */
diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index bed293b60e50..824d07156f9c 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
};
static const char * const imx355_test_pattern_menu[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
/* supported link frequencies */
diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index 5d2d6735cc78..507ec7176a7d 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
}
static const char * const ov2640_test_pattern_menu[] = {
- "Disabled",
- "Eight Vertical Colour Bars",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
};
/*
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index 58a45c353e27..f6a92b9f178c 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct
smiapp_sensor *sensor)
}
static const char * const smiapp_test_patterns[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 998983a6e6b7..a74ff6f1ac88 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -1014,6 +1014,11 @@ enum v4l2_jpeg_chroma_subsampling {
#define V4L2_CID_LINK_FREQ(V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 1)
#define V4L2_CID_PIXEL_RATE (V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 2)
#define V4L2_CID_TEST_PATTERN (V4L2_CID_IMAGE_PROC_CLASS_BASE
+
[RESEND PATCH 1/1] media: Use common test pattern menu entries
While the test pattern menu itself is not standardised, many devices
support the same test patterns. Aligning the menu entries helps the user
space to use the interface, and adding macros for the menu entry strings
helps to keep them aligned.
Signed-off-by: Sakari Ailus
---
Fixed Andy's email.
drivers/media/i2c/imx258.c | 10 +-
drivers/media/i2c/imx319.c | 10 +-
drivers/media/i2c/imx355.c | 10 +-
drivers/media/i2c/ov2640.c | 4 ++--
drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
include/uapi/linux/v4l2-controls.h | 5 +
6 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
index f86ae18bc104..c795d4c4c0e4 100644
--- a/drivers/media/i2c/imx258.c
+++ b/drivers/media/i2c/imx258.c
@@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] = {
};
static const char * const imx258_test_pattern_menu[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
/* Configurations for supported link frequencies */
diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
index 17c2e4b41221..eddaf69a67b6 100644
--- a/drivers/media/i2c/imx319.c
+++ b/drivers/media/i2c/imx319.c
@@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[] = {
};
static const char * const imx319_test_pattern_menu[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
/* supported link frequencies */
diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index bed293b60e50..824d07156f9c 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
};
static const char * const imx355_test_pattern_menu[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
/* supported link frequencies */
diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index 5d2d6735cc78..507ec7176a7d 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
}
static const char * const ov2640_test_pattern_menu[] = {
- "Disabled",
- "Eight Vertical Colour Bars",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
};
/*
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index 58a45c353e27..f6a92b9f178c 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct
smiapp_sensor *sensor)
}
static const char * const smiapp_test_patterns[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 998983a6e6b7..a74ff6f1ac88 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -1014,6 +1014,11 @@ enum v4l2_jpeg_chroma_subsampling {
#define V4L2_CID_LINK_FREQ (V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 1)
#define V4L2_CID_PIXEL_RATE(V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 2)
#define V4L2_CID_TEST_PATTERN (V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 3)
+#define V4L2_TEST_PATTERN_DISABLED "Disabled"
+#define V4L2_
[PATCH 1/1] media: Use common test pattern menu entries
While the test pattern menu itself is not standardised, many devices
support the same test patterns. Aligning the menu entries helps the user
space to use the interface, and adding macros for the menu entry strings
helps to keep them aligned.
Signed-off-by: Sakari Ailus
---
drivers/media/i2c/imx258.c | 10 +-
drivers/media/i2c/imx319.c | 10 +-
drivers/media/i2c/imx355.c | 10 +-
drivers/media/i2c/ov2640.c | 4 ++--
drivers/media/i2c/smiapp/smiapp-core.c | 10 +-
include/uapi/linux/v4l2-controls.h | 5 +
6 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
index f86ae18bc104..c795d4c4c0e4 100644
--- a/drivers/media/i2c/imx258.c
+++ b/drivers/media/i2c/imx258.c
@@ -498,11 +498,11 @@ static const struct imx258_reg mode_1048_780_regs[] = {
};
static const char * const imx258_test_pattern_menu[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
/* Configurations for supported link frequencies */
diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
index 17c2e4b41221..eddaf69a67b6 100644
--- a/drivers/media/i2c/imx319.c
+++ b/drivers/media/i2c/imx319.c
@@ -1647,11 +1647,11 @@ static const struct imx319_reg mode_1280x720_regs[] = {
};
static const char * const imx319_test_pattern_menu[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
/* supported link frequencies */
diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index bed293b60e50..824d07156f9c 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -875,11 +875,11 @@ static const struct imx355_reg mode_820x616_regs[] = {
};
static const char * const imx355_test_pattern_menu[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
/* supported link frequencies */
diff --git a/drivers/media/i2c/ov2640.c b/drivers/media/i2c/ov2640.c
index 5d2d6735cc78..507ec7176a7d 100644
--- a/drivers/media/i2c/ov2640.c
+++ b/drivers/media/i2c/ov2640.c
@@ -707,8 +707,8 @@ static int ov2640_reset(struct i2c_client *client)
}
static const char * const ov2640_test_pattern_menu[] = {
- "Disabled",
- "Eight Vertical Colour Bars",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
};
/*
diff --git a/drivers/media/i2c/smiapp/smiapp-core.c
b/drivers/media/i2c/smiapp/smiapp-core.c
index 58a45c353e27..f6a92b9f178c 100644
--- a/drivers/media/i2c/smiapp/smiapp-core.c
+++ b/drivers/media/i2c/smiapp/smiapp-core.c
@@ -409,11 +409,11 @@ static void smiapp_update_mbus_formats(struct
smiapp_sensor *sensor)
}
static const char * const smiapp_test_patterns[] = {
- "Disabled",
- "Solid Colour",
- "Eight Vertical Colour Bars",
- "Colour Bars With Fade to Grey",
- "Pseudorandom Sequence (PN9)",
+ V4L2_TEST_PATTERN_DISABLED,
+ V4L2_TEST_PATTERN_SOLID_COLOUR,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS,
+ V4L2_TEST_PATTERN_8_VERT_COLOUR_BARS_FADE_TO_GREY,
+ V4L2_TEST_PATTERN_PN9,
};
static int smiapp_set_ctrl(struct v4l2_ctrl *ctrl)
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 998983a6e6b7..a74ff6f1ac88 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -1014,6 +1014,11 @@ enum v4l2_jpeg_chroma_subsampling {
#define V4L2_CID_LINK_FREQ (V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 1)
#define V4L2_CID_PIXEL_RATE(V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 2)
#define V4L2_CID_TEST_PATTERN (V4L2_CID_IMAGE_PROC_CLASS_BASE
+ 3)
+#define V4L2_TEST_PATTERN_DISABLED "Disabled"
+#define V4L2_TEST_PATTERN_SOLID_COLOUR
Re: [PATCH 2/2] media: imx355: fix wrong order in test pattern menus
On Tue, Nov 27, 2018 at 10:45:02AM +0800, Bingbu Cao wrote:
>
>
> On 11/26/2018 04:57 PM, Sakari Ailus wrote:
> > Hi Bing Bu,
> >
> > On Mon, Nov 26, 2018 at 03:43:34PM +0800, bingbu@intel.com wrote:
> > > From: Bingbu Cao
> > >
> > > current imx355 test pattern order in ctrl menu
> > > is not correct, this patch fixes it.
> > >
> > > Signed-off-by: Bingbu Cao
> > > ---
> > > drivers/media/i2c/imx355.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
> > > index 20c8eea5db4b..9c9559dfd3dd 100644
> > > --- a/drivers/media/i2c/imx355.c
> > > +++ b/drivers/media/i2c/imx355.c
> > > @@ -876,8 +876,8 @@ struct imx355 {
> > > static const char * const imx355_test_pattern_menu[] = {
> > > "Disabled",
> > > - "100% color bars",
> > > "Solid color",
> > > + "100% color bars",
> > > "Fade to gray color bars",
> > > "PN9"
> > > };
> > While at it, could you use the existing test pattern naming as well for the
> > drivers? That could be a separate patch.
> >
> > >From drivers/media/i2c/smiapp/smiapp-core.c :
> >
> > static const char * const smiapp_test_patterns[] = {
> > "Disabled",
> > "Solid Colour",
> > "Eight Vertical Colour Bars",
> > "Colour Bars With Fade to Grey",
> > "Pseudorandom Sequence (PN9)",
> > };
> >
> > It's not strictly necessary from interface point of view, but for the user
> > space it'd be good to align the naming.
> Sakari, ask a question that not really related to this patch.
> I am wondering whether there are some standardization for the camera sensor
> pattern generator.
> Currently there are varied patterns and every vendor has its own pattern
> types.
Some vendors (and some models) do have their specific patterns, but if you
look at a bunch of drivers, these ones repeat over and over. That's why I
think it'd make sense to have the menu entries aligned.
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi
Re: [PATCH 2/2] media: imx355: fix wrong order in test pattern menus
On 11/26/2018 04:57 PM, Sakari Ailus wrote:
Hi Bing Bu,
On Mon, Nov 26, 2018 at 03:43:34PM +0800, bingbu@intel.com wrote:
From: Bingbu Cao
current imx355 test pattern order in ctrl menu
is not correct, this patch fixes it.
Signed-off-by: Bingbu Cao
---
drivers/media/i2c/imx355.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index 20c8eea5db4b..9c9559dfd3dd 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -876,8 +876,8 @@ struct imx355 {
static const char * const imx355_test_pattern_menu[] = {
"Disabled",
- "100% color bars",
"Solid color",
+ "100% color bars",
"Fade to gray color bars",
"PN9"
};
While at it, could you use the existing test pattern naming as well for the
drivers? That could be a separate patch.
>From drivers/media/i2c/smiapp/smiapp-core.c :
static const char * const smiapp_test_patterns[] = {
"Disabled",
"Solid Colour",
"Eight Vertical Colour Bars",
"Colour Bars With Fade to Grey",
"Pseudorandom Sequence (PN9)",
};
It's not strictly necessary from interface point of view, but for the user
space it'd be good to align the naming.
Sakari, ask a question that not really related to this patch.
I am wondering whether there are some standardization for the camera sensor
pattern generator.
Currently there are varied patterns and every vendor has its own pattern types.
Re: [PATCH 2/2] media: imx355: fix wrong order in test pattern menus
On 11/26/2018 04:57 PM, Sakari Ailus wrote:
Hi Bing Bu,
On Mon, Nov 26, 2018 at 03:43:34PM +0800, bingbu@intel.com wrote:
From: Bingbu Cao
current imx355 test pattern order in ctrl menu
is not correct, this patch fixes it.
Signed-off-by: Bingbu Cao
---
drivers/media/i2c/imx355.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index 20c8eea5db4b..9c9559dfd3dd 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -876,8 +876,8 @@ struct imx355 {
static const char * const imx355_test_pattern_menu[] = {
"Disabled",
- "100% color bars",
"Solid color",
+ "100% color bars",
"Fade to gray color bars",
"PN9"
};
While at it, could you use the existing test pattern naming as well for the
drivers? That could be a separate patch.
Good point, thanks.
I am trying to check whether all the existing Sony camera sensors
use same test pattern definition, I can put them together.
>From drivers/media/i2c/smiapp/smiapp-core.c :
static const char * const smiapp_test_patterns[] = {
"Disabled",
"Solid Colour",
"Eight Vertical Colour Bars",
"Colour Bars With Fade to Grey",
"Pseudorandom Sequence (PN9)",
};
It's not strictly necessary from interface point of view, but for the user
space it'd be good to align the naming.
Re: [PATCH 2/2] media: imx355: fix wrong order in test pattern menus
Hi Bing Bu,
On Mon, Nov 26, 2018 at 03:43:34PM +0800, bingbu@intel.com wrote:
> From: Bingbu Cao
>
> current imx355 test pattern order in ctrl menu
> is not correct, this patch fixes it.
>
> Signed-off-by: Bingbu Cao
> ---
> drivers/media/i2c/imx355.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
> index 20c8eea5db4b..9c9559dfd3dd 100644
> --- a/drivers/media/i2c/imx355.c
> +++ b/drivers/media/i2c/imx355.c
> @@ -876,8 +876,8 @@ struct imx355 {
>
> static const char * const imx355_test_pattern_menu[] = {
> "Disabled",
> - "100% color bars",
> "Solid color",
> + "100% color bars",
> "Fade to gray color bars",
> "PN9"
> };
While at it, could you use the existing test pattern naming as well for the
drivers? That could be a separate patch.
>From drivers/media/i2c/smiapp/smiapp-core.c :
static const char * const smiapp_test_patterns[] = {
"Disabled",
"Solid Colour",
"Eight Vertical Colour Bars",
"Colour Bars With Fade to Grey",
"Pseudorandom Sequence (PN9)",
};
It's not strictly necessary from interface point of view, but for the user
space it'd be good to align the naming.
--
Regards,
Sakari Ailus
sakari.ai...@linux.intel.com
[PATCH 1/2] media: imx319: fix wrong order in test pattern menus
From: Bingbu Cao
current imx319 test pattern order in ctrl menu
is not correct, this patch fixes it.
Signed-off-by: Bingbu Cao
---
drivers/media/i2c/imx319.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/imx319.c b/drivers/media/i2c/imx319.c
index 0d3e27812b93..acd988d2d7f1 100644
--- a/drivers/media/i2c/imx319.c
+++ b/drivers/media/i2c/imx319.c
@@ -1648,8 +1648,8 @@ struct imx319 {
static const char * const imx319_test_pattern_menu[] = {
"Disabled",
- "100% color bars",
"Solid color",
+ "100% color bars",
"Fade to gray color bars",
"PN9"
};
--
1.9.1
[PATCH 2/2] media: imx355: fix wrong order in test pattern menus
From: Bingbu Cao
current imx355 test pattern order in ctrl menu
is not correct, this patch fixes it.
Signed-off-by: Bingbu Cao
---
drivers/media/i2c/imx355.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
index 20c8eea5db4b..9c9559dfd3dd 100644
--- a/drivers/media/i2c/imx355.c
+++ b/drivers/media/i2c/imx355.c
@@ -876,8 +876,8 @@ struct imx355 {
static const char * const imx355_test_pattern_menu[] = {
"Disabled",
- "100% color bars",
"Solid color",
+ "100% color bars",
"Fade to gray color bars",
"PN9"
};
--
1.9.1
[RFCv4 PATCH 3/3] vimc: add property test code
From: Hans Verkuil
Add properties to entities and pads to be able to test the
properties API.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/vimc/vimc-common.c | 50 +++
1 file changed, 50 insertions(+)
diff --git a/drivers/media/platform/vimc/vimc-common.c
b/drivers/media/platform/vimc/vimc-common.c
index dee1b9dfc4f6..2f70e4e64790 100644
--- a/drivers/media/platform/vimc/vimc-common.c
+++ b/drivers/media/platform/vimc/vimc-common.c
@@ -415,6 +415,7 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
const unsigned long *pads_flag,
const struct v4l2_subdev_ops *sd_ops)
{
+ struct media_prop *prop = NULL;
int ret;
/* Allocate the pads */
@@ -452,6 +453,55 @@ int vimc_ent_sd_register(struct vimc_ent_device *ved,
goto err_clean_m_ent;
}
+ ret = media_entity_add_prop_u64(&sd->entity, "u64", ~1);
+ if (!ret)
+ ret = media_entity_add_prop_s64(&sd->entity, "s64", -5);
+ if (!ret)
+ ret = media_entity_add_prop_string(&sd->entity, "string",
+ sd->name);
+ if (!ret) {
+ prop = media_entity_add_prop_group(&sd->entity, "empty-group");
+ ret = PTR_ERR_OR_ZERO(prop);
+ }
+ if (!ret) {
+ prop = media_entity_add_prop_group(&sd->entity, "group");
+ ret = PTR_ERR_OR_ZERO(prop);
+ }
+ if (!ret)
+ ret = media_prop_add_prop_u64(prop, "u64", 42);
+ if (!ret)
+ ret = media_prop_add_prop_s64(prop, "s64", -42);
+ if (!ret)
+ ret = media_prop_add_prop_string(prop, "string", "42");
+ if (!ret)
+ ret = media_pad_add_prop_u64(&sd->entity.pads[num_pads - 1],
+"u64", ~1);
+ if (!ret)
+ ret = media_pad_add_prop_s64(&sd->entity.pads[num_pads - 1],
+"s64", -5);
+ if (!ret) {
+ prop = media_pad_add_prop_group(&sd->entity.pads[num_pads - 1],
+ "group");
+ ret = PTR_ERR_OR_ZERO(prop);
+ }
+ if (!ret)
+ ret = media_prop_add_prop_u64(prop, "u64", 24);
+ if (!ret)
+ ret = media_prop_add_prop_s64(prop, "s64", -24);
+ if (!ret)
+ ret = media_pad_add_prop_string(&sd->entity.pads[0],
+ "string", sd->name);
+ if (!ret)
+ ret = media_prop_add_prop_string(prop, "string", "24");
+ if (!ret) {
+ prop = media_prop_add_prop_group(prop, "subgroup");
+ ret = PTR_ERR_OR_ZERO(prop);
+ }
+ if (!ret)
+ ret = media_prop_add_prop_string(prop, "string", "substring");
+ if (ret)
+ goto err_clean_m_ent;
+
return 0;
err_clean_m_ent:
--
2.19.1
[PATCH v2] v4l2-compliance: test orphaned buffer support
Test that V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS is reported equally for
both MMAP and DMABUF memory types. If supported, try to orphan buffers
by calling reqbufs(0) before unmapping or closing DMABUF fds.
Also close exported DMABUF fds and free buffers in testDmaBuf if
orphaned buffers are not supported.
Signed-off-by: Philipp Zabel
---
Changes since v1:
- Rename has_orphaned_bufs to supports_orphaned_bufs
- Check that capabilities are independent of memory type
- Check that orphaned buffer support is independent of queue for M2M
- Check that reqbufs(0) returns -EBUSY without orphaned buffer support
---
contrib/freebsd/include/linux/videodev2.h | 1 +
include/linux/videodev2.h | 1 +
utils/common/v4l2-info.cpp | 1 +
utils/v4l2-compliance/v4l2-compliance.h | 1 +
utils/v4l2-compliance/v4l2-test-buffers.cpp | 51 ++---
5 files changed, 50 insertions(+), 5 deletions(-)
diff --git a/contrib/freebsd/include/linux/videodev2.h
b/contrib/freebsd/include/linux/videodev2.h
index 9928c00e4b68..33153b53c175 100644
--- a/contrib/freebsd/include/linux/videodev2.h
+++ b/contrib/freebsd/include/linux/videodev2.h
@@ -907,6 +907,7 @@ struct v4l2_requestbuffers {
#define V4L2_BUF_CAP_SUPPORTS_USERPTR (1 << 1)
#define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
#define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
+#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
/**
* struct v4l2_plane - plane info for multi-planar buffers
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 79418cd39480..a39300cacb6a 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -873,6 +873,7 @@ struct v4l2_requestbuffers {
#define V4L2_BUF_CAP_SUPPORTS_USERPTR (1 << 1)
#define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
#define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
+#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
/**
* struct v4l2_plane - plane info for multi-planar buffers
diff --git a/utils/common/v4l2-info.cpp b/utils/common/v4l2-info.cpp
index 258e5446f030..3699c35cb9d6 100644
--- a/utils/common/v4l2-info.cpp
+++ b/utils/common/v4l2-info.cpp
@@ -200,6 +200,7 @@ static const flag_def bufcap_def[] = {
{ V4L2_BUF_CAP_SUPPORTS_USERPTR, "userptr" },
{ V4L2_BUF_CAP_SUPPORTS_DMABUF, "dmabuf" },
{ V4L2_BUF_CAP_SUPPORTS_REQUESTS, "requests" },
+ { V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS, "orphaned-bufs" },
{ 0, NULL }
};
diff --git a/utils/v4l2-compliance/v4l2-compliance.h
b/utils/v4l2-compliance/v4l2-compliance.h
index def185f17261..02d616f0b47c 100644
--- a/utils/v4l2-compliance/v4l2-compliance.h
+++ b/utils/v4l2-compliance/v4l2-compliance.h
@@ -119,6 +119,7 @@ struct base_node {
__u32 valid_buftypes;
__u32 valid_buftype;
__u32 valid_memorytype;
+ bool supports_orphaned_bufs;
};
struct node : public base_node, public cv4l_fd {
diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp
b/utils/v4l2-compliance/v4l2-test-buffers.cpp
index a84be0ab799a..42e743fef43b 100644
--- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
+++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
@@ -400,14 +400,18 @@ int testReqBufs(struct node *node)
mmap_valid = !ret;
if (mmap_valid)
caps = q.g_capabilities();
- if (caps)
+ if (caps) {
fail_on_test(mmap_valid ^ !!(caps &
V4L2_BUF_CAP_SUPPORTS_MMAP));
+ if (caps & V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS)
+ node->supports_orphaned_bufs = true;
+ }
q.init(i, V4L2_MEMORY_USERPTR);
ret = q.reqbufs(node, 0);
fail_on_test(ret && ret != EINVAL);
userptr_valid = !ret;
fail_on_test(!mmap_valid && userptr_valid);
+ fail_on_test(userptr_valid && (caps != q.g_capabilities()));
if (caps)
fail_on_test(userptr_valid ^ !!(caps &
V4L2_BUF_CAP_SUPPORTS_USERPTR));
@@ -416,6 +420,7 @@ int testReqBufs(struct node *node)
fail_on_test(ret && ret != EINVAL);
dmabuf_valid = !ret;
fail_on_test(!mmap_valid && dmabuf_valid);
+ fail_on_test(dmabuf_valid && (caps != q.g_capabilities()));
if (caps)
fail_on_test(dmabuf_valid ^ !!(caps &
V4L2_BUF_CAP_SUPPORTS_DMABUF));
@@ -754,9 +759,13 @@ static int captureBufs(struct node *node, const cv4l_queue
&q,
static int setupM2M(struct node *node, cv4l_queue &q)
{
+ __u32 caps;
+
last_m2m_seq.init();
fail_on_test(q.reqbufs(node, 2));
+ caps = q.g_capabilities();
+ fail_on_test(node->supports_orphaned_bufs
Re: [PATCH v4l-utils] v4l2-compliance: test orphaned buffer support
On 11/15/18 13:52, Philipp Zabel wrote:
> On Thu, 2018-11-15 at 11:21 +0100, Hans Verkuil wrote:
>> On 11/14/18 15:38, Philipp Zabel wrote:
>>> Test that V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS is reported equally for
>>> both MMAP and DMABUF memory types. If supported, try to orphan buffers
>>> by calling reqbufs(0) before unmapping or closing DMABUF fds.
>>>
>>> Also close exported DMABUF fds and free buffers in testDmaBuf if
>>> orphaned buffers are not supported.
>>>
>>> Signed-off-by: Philipp Zabel
>>> ---
>>> contrib/freebsd/include/linux/videodev2.h | 1 +
>>> include/linux/videodev2.h | 1 +
>>> utils/common/v4l2-info.cpp | 1 +
>>> utils/v4l2-compliance/v4l2-compliance.h | 1 +
>>> utils/v4l2-compliance/v4l2-test-buffers.cpp | 35 +
>>> 5 files changed, 33 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/contrib/freebsd/include/linux/videodev2.h
>>> b/contrib/freebsd/include/linux/videodev2.h
>>> index 9928c00e4b68..33153b53c175 100644
>>> --- a/contrib/freebsd/include/linux/videodev2.h
>>> +++ b/contrib/freebsd/include/linux/videodev2.h
>>> @@ -907,6 +907,7 @@ struct v4l2_requestbuffers {
>>> #define V4L2_BUF_CAP_SUPPORTS_USERPTR (1 << 1)
>>> #define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
>>> #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
>>> +#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
>>>
>>> /**
>>> * struct v4l2_plane - plane info for multi-planar buffers
>>> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
>>> index 79418cd39480..a39300cacb6a 100644
>>> --- a/include/linux/videodev2.h
>>> +++ b/include/linux/videodev2.h
>>> @@ -873,6 +873,7 @@ struct v4l2_requestbuffers {
>>> #define V4L2_BUF_CAP_SUPPORTS_USERPTR (1 << 1)
>>> #define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
>>> #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
>>> +#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
>>>
>>> /**
>>> * struct v4l2_plane - plane info for multi-planar buffers
>>> diff --git a/utils/common/v4l2-info.cpp b/utils/common/v4l2-info.cpp
>>> index 258e5446f030..3699c35cb9d6 100644
>>> --- a/utils/common/v4l2-info.cpp
>>> +++ b/utils/common/v4l2-info.cpp
>>> @@ -200,6 +200,7 @@ static const flag_def bufcap_def[] = {
>>> { V4L2_BUF_CAP_SUPPORTS_USERPTR, "userptr" },
>>> { V4L2_BUF_CAP_SUPPORTS_DMABUF, "dmabuf" },
>>> { V4L2_BUF_CAP_SUPPORTS_REQUESTS, "requests" },
>>> + { V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS, "orphaned-bufs" },
>>> { 0, NULL }
>>> };
>>>
>>> diff --git a/utils/v4l2-compliance/v4l2-compliance.h
>>> b/utils/v4l2-compliance/v4l2-compliance.h
>>> index def185f17261..88ec260a9bcc 100644
>>> --- a/utils/v4l2-compliance/v4l2-compliance.h
>>> +++ b/utils/v4l2-compliance/v4l2-compliance.h
>>> @@ -119,6 +119,7 @@ struct base_node {
>>> __u32 valid_buftypes;
>>> __u32 valid_buftype;
>>> __u32 valid_memorytype;
>>> + bool has_orphaned_bufs;
>>
>> I'd rename that to supports_orphaned_bufs.
>
> Ok.
>
>>> };
>>>
>>> struct node : public base_node, public cv4l_fd {
>>> diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp
>>> b/utils/v4l2-compliance/v4l2-test-buffers.cpp
>>> index c59a56d9ced7..6174015cb4e7 100644
>>> --- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
>>> +++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
>>> @@ -400,8 +400,11 @@ int testReqBufs(struct node *node)
>>> mmap_valid = !ret;
>>> if (mmap_valid)
>>> caps = q.g_capabilities();
>>> - if (caps)
>>> + if (caps) {
>>> fail_on_test(mmap_valid ^ !!(caps &
>>> V4L2_BUF_CAP_SUPPORTS_MMAP));
>>> + if (caps & V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS)
>>> + node->has_orphaned_bufs = true;
>>> + }
>>>
>>> q.init(i, V4L2_MEMORY_USERPTR);
>>> ret = q.reqbufs(node, 0);
>>> @@ -418,8 +421,11 @@ int testReqBufs(struct node *node)
>>> fail_on_test(!mmap_valid && dmabuf_valid);
>>>
Re: [PATCH v4l-utils] v4l2-compliance: test orphaned buffer support
On Thu, 2018-11-15 at 11:21 +0100, Hans Verkuil wrote:
> On 11/14/18 15:38, Philipp Zabel wrote:
> > Test that V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS is reported equally for
> > both MMAP and DMABUF memory types. If supported, try to orphan buffers
> > by calling reqbufs(0) before unmapping or closing DMABUF fds.
> >
> > Also close exported DMABUF fds and free buffers in testDmaBuf if
> > orphaned buffers are not supported.
> >
> > Signed-off-by: Philipp Zabel
> > ---
> > contrib/freebsd/include/linux/videodev2.h | 1 +
> > include/linux/videodev2.h | 1 +
> > utils/common/v4l2-info.cpp | 1 +
> > utils/v4l2-compliance/v4l2-compliance.h | 1 +
> > utils/v4l2-compliance/v4l2-test-buffers.cpp | 35 +
> > 5 files changed, 33 insertions(+), 6 deletions(-)
> >
> > diff --git a/contrib/freebsd/include/linux/videodev2.h
> > b/contrib/freebsd/include/linux/videodev2.h
> > index 9928c00e4b68..33153b53c175 100644
> > --- a/contrib/freebsd/include/linux/videodev2.h
> > +++ b/contrib/freebsd/include/linux/videodev2.h
> > @@ -907,6 +907,7 @@ struct v4l2_requestbuffers {
> > #define V4L2_BUF_CAP_SUPPORTS_USERPTR (1 << 1)
> > #define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
> > #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
> > +#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
> >
> > /**
> > * struct v4l2_plane - plane info for multi-planar buffers
> > diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> > index 79418cd39480..a39300cacb6a 100644
> > --- a/include/linux/videodev2.h
> > +++ b/include/linux/videodev2.h
> > @@ -873,6 +873,7 @@ struct v4l2_requestbuffers {
> > #define V4L2_BUF_CAP_SUPPORTS_USERPTR (1 << 1)
> > #define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
> > #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
> > +#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
> >
> > /**
> > * struct v4l2_plane - plane info for multi-planar buffers
> > diff --git a/utils/common/v4l2-info.cpp b/utils/common/v4l2-info.cpp
> > index 258e5446f030..3699c35cb9d6 100644
> > --- a/utils/common/v4l2-info.cpp
> > +++ b/utils/common/v4l2-info.cpp
> > @@ -200,6 +200,7 @@ static const flag_def bufcap_def[] = {
> > { V4L2_BUF_CAP_SUPPORTS_USERPTR, "userptr" },
> > { V4L2_BUF_CAP_SUPPORTS_DMABUF, "dmabuf" },
> > { V4L2_BUF_CAP_SUPPORTS_REQUESTS, "requests" },
> > + { V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS, "orphaned-bufs" },
> > { 0, NULL }
> > };
> >
> > diff --git a/utils/v4l2-compliance/v4l2-compliance.h
> > b/utils/v4l2-compliance/v4l2-compliance.h
> > index def185f17261..88ec260a9bcc 100644
> > --- a/utils/v4l2-compliance/v4l2-compliance.h
> > +++ b/utils/v4l2-compliance/v4l2-compliance.h
> > @@ -119,6 +119,7 @@ struct base_node {
> > __u32 valid_buftypes;
> > __u32 valid_buftype;
> > __u32 valid_memorytype;
> > + bool has_orphaned_bufs;
>
> I'd rename that to supports_orphaned_bufs.
Ok.
> > };
> >
> > struct node : public base_node, public cv4l_fd {
> > diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp
> > b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> > index c59a56d9ced7..6174015cb4e7 100644
> > --- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
> > +++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> > @@ -400,8 +400,11 @@ int testReqBufs(struct node *node)
> > mmap_valid = !ret;
> > if (mmap_valid)
> > caps = q.g_capabilities();
> > - if (caps)
> > + if (caps) {
> > fail_on_test(mmap_valid ^ !!(caps &
> > V4L2_BUF_CAP_SUPPORTS_MMAP));
> > + if (caps & V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS)
> > + node->has_orphaned_bufs = true;
> > + }
> >
> > q.init(i, V4L2_MEMORY_USERPTR);
> > ret = q.reqbufs(node, 0);
> > @@ -418,8 +421,11 @@ int testReqBufs(struct node *node)
> > fail_on_test(!mmap_valid && dmabuf_valid);
> > // Note: dmabuf is only supported with vb2, so we can assume a
> > // non-0 caps value if dmabuf is supported.
> > - if (caps || dmabuf_valid)
> > + if (caps || dmabuf_valid) {
> > fail_on_test(dmabuf_valid ^ !!(caps &
> > V4L2_BUF_
Re: [PATCH v4l-utils] v4l2-compliance: test orphaned buffer support
On 11/14/18 15:38, Philipp Zabel wrote:
> Test that V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS is reported equally for
> both MMAP and DMABUF memory types. If supported, try to orphan buffers
> by calling reqbufs(0) before unmapping or closing DMABUF fds.
>
> Also close exported DMABUF fds and free buffers in testDmaBuf if
> orphaned buffers are not supported.
>
> Signed-off-by: Philipp Zabel
> ---
> contrib/freebsd/include/linux/videodev2.h | 1 +
> include/linux/videodev2.h | 1 +
> utils/common/v4l2-info.cpp | 1 +
> utils/v4l2-compliance/v4l2-compliance.h | 1 +
> utils/v4l2-compliance/v4l2-test-buffers.cpp | 35 +
> 5 files changed, 33 insertions(+), 6 deletions(-)
>
> diff --git a/contrib/freebsd/include/linux/videodev2.h
> b/contrib/freebsd/include/linux/videodev2.h
> index 9928c00e4b68..33153b53c175 100644
> --- a/contrib/freebsd/include/linux/videodev2.h
> +++ b/contrib/freebsd/include/linux/videodev2.h
> @@ -907,6 +907,7 @@ struct v4l2_requestbuffers {
> #define V4L2_BUF_CAP_SUPPORTS_USERPTR(1 << 1)
> #define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
> #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
> +#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
>
> /**
> * struct v4l2_plane - plane info for multi-planar buffers
> diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
> index 79418cd39480..a39300cacb6a 100644
> --- a/include/linux/videodev2.h
> +++ b/include/linux/videodev2.h
> @@ -873,6 +873,7 @@ struct v4l2_requestbuffers {
> #define V4L2_BUF_CAP_SUPPORTS_USERPTR(1 << 1)
> #define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
> #define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
> +#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
>
> /**
> * struct v4l2_plane - plane info for multi-planar buffers
> diff --git a/utils/common/v4l2-info.cpp b/utils/common/v4l2-info.cpp
> index 258e5446f030..3699c35cb9d6 100644
> --- a/utils/common/v4l2-info.cpp
> +++ b/utils/common/v4l2-info.cpp
> @@ -200,6 +200,7 @@ static const flag_def bufcap_def[] = {
> { V4L2_BUF_CAP_SUPPORTS_USERPTR, "userptr" },
> { V4L2_BUF_CAP_SUPPORTS_DMABUF, "dmabuf" },
> { V4L2_BUF_CAP_SUPPORTS_REQUESTS, "requests" },
> + { V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS, "orphaned-bufs" },
> { 0, NULL }
> };
>
> diff --git a/utils/v4l2-compliance/v4l2-compliance.h
> b/utils/v4l2-compliance/v4l2-compliance.h
> index def185f17261..88ec260a9bcc 100644
> --- a/utils/v4l2-compliance/v4l2-compliance.h
> +++ b/utils/v4l2-compliance/v4l2-compliance.h
> @@ -119,6 +119,7 @@ struct base_node {
> __u32 valid_buftypes;
> __u32 valid_buftype;
> __u32 valid_memorytype;
> + bool has_orphaned_bufs;
I'd rename that to supports_orphaned_bufs.
> };
>
> struct node : public base_node, public cv4l_fd {
> diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp
> b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> index c59a56d9ced7..6174015cb4e7 100644
> --- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
> +++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
> @@ -400,8 +400,11 @@ int testReqBufs(struct node *node)
> mmap_valid = !ret;
> if (mmap_valid)
> caps = q.g_capabilities();
> - if (caps)
> + if (caps) {
> fail_on_test(mmap_valid ^ !!(caps &
> V4L2_BUF_CAP_SUPPORTS_MMAP));
> + if (caps & V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS)
> + node->has_orphaned_bufs = true;
> + }
>
> q.init(i, V4L2_MEMORY_USERPTR);
> ret = q.reqbufs(node, 0);
> @@ -418,8 +421,11 @@ int testReqBufs(struct node *node)
> fail_on_test(!mmap_valid && dmabuf_valid);
> // Note: dmabuf is only supported with vb2, so we can assume a
> // non-0 caps value if dmabuf is supported.
> - if (caps || dmabuf_valid)
> + if (caps || dmabuf_valid) {
> fail_on_test(dmabuf_valid ^ !!(caps &
> V4L2_BUF_CAP_SUPPORTS_DMABUF));
> + if (node->has_orphaned_bufs)
> + fail_on_test(userptr_valid ^ !!(caps &
> V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS));
Huh? I'm not sure what you are testing here.
> + }
>
> fail_on_test((can_stream && !is_overlay) && !mmap_valid &&
> !userptr_valid && !dmabuf_valid);
> fail_on_test((!can_stream || is_overlay)
[PATCH v4l-utils] v4l2-compliance: limit acceptable width/height to 65536 in VIDIOC_SUBDEV_G/S_FMT test
Fail if the driver returns unrealistically large frame sizes.
Signed-off-by: Philipp Zabel
---
utils/v4l2-compliance/v4l2-test-subdevs.cpp | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/utils/v4l2-compliance/v4l2-test-subdevs.cpp
b/utils/v4l2-compliance/v4l2-test-subdevs.cpp
index 031fd6e78c56..29987b310448 100644
--- a/utils/v4l2-compliance/v4l2-test-subdevs.cpp
+++ b/utils/v4l2-compliance/v4l2-test-subdevs.cpp
@@ -308,8 +308,8 @@ int testSubDevFrameInterval(struct node *node, unsigned pad)
static int checkMBusFrameFmt(struct node *node, struct v4l2_mbus_framefmt &fmt)
{
fail_on_test(check_0(fmt.reserved, sizeof(fmt.reserved)));
- fail_on_test(fmt.width == 0 || fmt.width == ~0U);
- fail_on_test(fmt.height == 0 || fmt.height == ~0U);
+ fail_on_test(fmt.width == 0 || fmt.width > 65536);
+ fail_on_test(fmt.height == 0 || fmt.height > 65536);
fail_on_test(fmt.code == 0 || fmt.code == ~0U);
fail_on_test(fmt.field == ~0U);
if (!node->is_passthrough_subdev) {
--
2.19.1
[PATCH v4l-utils] v4l2-compliance: test orphaned buffer support
Test that V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS is reported equally for
both MMAP and DMABUF memory types. If supported, try to orphan buffers
by calling reqbufs(0) before unmapping or closing DMABUF fds.
Also close exported DMABUF fds and free buffers in testDmaBuf if
orphaned buffers are not supported.
Signed-off-by: Philipp Zabel
---
contrib/freebsd/include/linux/videodev2.h | 1 +
include/linux/videodev2.h | 1 +
utils/common/v4l2-info.cpp | 1 +
utils/v4l2-compliance/v4l2-compliance.h | 1 +
utils/v4l2-compliance/v4l2-test-buffers.cpp | 35 +
5 files changed, 33 insertions(+), 6 deletions(-)
diff --git a/contrib/freebsd/include/linux/videodev2.h
b/contrib/freebsd/include/linux/videodev2.h
index 9928c00e4b68..33153b53c175 100644
--- a/contrib/freebsd/include/linux/videodev2.h
+++ b/contrib/freebsd/include/linux/videodev2.h
@@ -907,6 +907,7 @@ struct v4l2_requestbuffers {
#define V4L2_BUF_CAP_SUPPORTS_USERPTR (1 << 1)
#define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
#define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
+#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
/**
* struct v4l2_plane - plane info for multi-planar buffers
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index 79418cd39480..a39300cacb6a 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -873,6 +873,7 @@ struct v4l2_requestbuffers {
#define V4L2_BUF_CAP_SUPPORTS_USERPTR (1 << 1)
#define V4L2_BUF_CAP_SUPPORTS_DMABUF (1 << 2)
#define V4L2_BUF_CAP_SUPPORTS_REQUESTS (1 << 3)
+#define V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS (1 << 4)
/**
* struct v4l2_plane - plane info for multi-planar buffers
diff --git a/utils/common/v4l2-info.cpp b/utils/common/v4l2-info.cpp
index 258e5446f030..3699c35cb9d6 100644
--- a/utils/common/v4l2-info.cpp
+++ b/utils/common/v4l2-info.cpp
@@ -200,6 +200,7 @@ static const flag_def bufcap_def[] = {
{ V4L2_BUF_CAP_SUPPORTS_USERPTR, "userptr" },
{ V4L2_BUF_CAP_SUPPORTS_DMABUF, "dmabuf" },
{ V4L2_BUF_CAP_SUPPORTS_REQUESTS, "requests" },
+ { V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS, "orphaned-bufs" },
{ 0, NULL }
};
diff --git a/utils/v4l2-compliance/v4l2-compliance.h
b/utils/v4l2-compliance/v4l2-compliance.h
index def185f17261..88ec260a9bcc 100644
--- a/utils/v4l2-compliance/v4l2-compliance.h
+++ b/utils/v4l2-compliance/v4l2-compliance.h
@@ -119,6 +119,7 @@ struct base_node {
__u32 valid_buftypes;
__u32 valid_buftype;
__u32 valid_memorytype;
+ bool has_orphaned_bufs;
};
struct node : public base_node, public cv4l_fd {
diff --git a/utils/v4l2-compliance/v4l2-test-buffers.cpp
b/utils/v4l2-compliance/v4l2-test-buffers.cpp
index c59a56d9ced7..6174015cb4e7 100644
--- a/utils/v4l2-compliance/v4l2-test-buffers.cpp
+++ b/utils/v4l2-compliance/v4l2-test-buffers.cpp
@@ -400,8 +400,11 @@ int testReqBufs(struct node *node)
mmap_valid = !ret;
if (mmap_valid)
caps = q.g_capabilities();
- if (caps)
+ if (caps) {
fail_on_test(mmap_valid ^ !!(caps &
V4L2_BUF_CAP_SUPPORTS_MMAP));
+ if (caps & V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS)
+ node->has_orphaned_bufs = true;
+ }
q.init(i, V4L2_MEMORY_USERPTR);
ret = q.reqbufs(node, 0);
@@ -418,8 +421,11 @@ int testReqBufs(struct node *node)
fail_on_test(!mmap_valid && dmabuf_valid);
// Note: dmabuf is only supported with vb2, so we can assume a
// non-0 caps value if dmabuf is supported.
- if (caps || dmabuf_valid)
+ if (caps || dmabuf_valid) {
fail_on_test(dmabuf_valid ^ !!(caps &
V4L2_BUF_CAP_SUPPORTS_DMABUF));
+ if (node->has_orphaned_bufs)
+ fail_on_test(userptr_valid ^ !!(caps &
V4L2_BUF_CAP_SUPPORTS_ORPHANED_BUFS));
+ }
fail_on_test((can_stream && !is_overlay) && !mmap_valid &&
!userptr_valid && !dmabuf_valid);
fail_on_test((!can_stream || is_overlay) && (mmap_valid ||
userptr_valid || dmabuf_valid));
@@ -967,12 +973,22 @@ int testMmap(struct node *node, unsigned frame_count)
fail_on_test(captureBufs(node, q, m2m_q, frame_count, true));
fail_on_test(node->streamoff(q.g_type()));
fail_on_test(node->streamoff(q.g_type()));
- q.munmap_bufs(node);
- fail_on_test(q.reqbufs(node, 0));
+ if (node->has_orphaned_bufs) {
+ fail_on_test(q.reqbufs(node, 0));
+ q.munmap_bufs(node);
+
RE: [PATCH] media: imx258: remove test pattern map from driver
Hi Sakari
Thanks for your feedback.
I will update to the next patch.
B.R.,
Jason
-Original Message-
From: Sakari Ailus [mailto:sakari.ai...@linux.intel.com]
Sent: Wednesday, November 7, 2018 6:32 PM
To: Chen, JasonX Z
Cc: linux-media@vger.kernel.org; Yeh, Andy ;
tf...@chromium.org
Subject: Re: [PATCH] media: imx258: remove test pattern map from driver
Hi Jason,
Thanks for the patch.
On Wed, Nov 07, 2018 at 03:22:23PM +0800, jasonx.z.c...@intel.com wrote:
> From: "Chen, JasonX Z"
>
> Test Pattern mode be picked at HAL instead of driver.
> do a FLIP when userspace use test pattern mode.
> add entity_ops for validating imx258 link.
>
> Signed-off-by: Chen, JasonX Z
> ---
> drivers/media/i2c/imx258.c | 28
> 1 file changed, 8 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> index 31a1e22..71f9875 100644
> --- a/drivers/media/i2c/imx258.c
> +++ b/drivers/media/i2c/imx258.c
> @@ -62,11 +62,6 @@
>
> /* Test Pattern Control */
> #define IMX258_REG_TEST_PATTERN 0x0600
> -#define IMX258_TEST_PATTERN_DISABLE 0
> -#define IMX258_TEST_PATTERN_SOLID_COLOR 1
> -#define IMX258_TEST_PATTERN_COLOR_BARS 2
> -#define IMX258_TEST_PATTERN_GREY_COLOR 3
> -#define IMX258_TEST_PATTERN_PN9 4
>
> /* Orientation */
> #define REG_MIRROR_FLIP_CONTROL 0x0101
> @@ -504,20 +499,12 @@ struct imx258_mode {
>
> static const char * const imx258_test_pattern_menu[] = {
> "Disabled",
> - "Color Bars",
> "Solid Color",
> + "Color Bars",
> "Grey Color Bars",
> "PN9"
> };
>
> -static const int imx258_test_pattern_val[] = {
> - IMX258_TEST_PATTERN_DISABLE,
> - IMX258_TEST_PATTERN_COLOR_BARS,
> - IMX258_TEST_PATTERN_SOLID_COLOR,
> - IMX258_TEST_PATTERN_GREY_COLOR,
> - IMX258_TEST_PATTERN_PN9,
> -};
> -
> /* Configurations for supported link frequencies */
> #define IMX258_LINK_FREQ_634MHZ 63360ULL
> #define IMX258_LINK_FREQ_320MHZ 32000ULL
> @@ -752,7 +739,6 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
> container_of(ctrl->handler, struct imx258, ctrl_handler);
> struct i2c_client *client = v4l2_get_subdevdata(&imx258->sd);
> int ret = 0;
> -
This seems like an unrelated change, and it's a common (and usually good)
practice to add an empty line after variable declarations.
> /*
>* Applying V4L2 control value only happens
>* when power is up for streaming
> @@ -778,13 +764,10 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
> case V4L2_CID_TEST_PATTERN:
> ret = imx258_write_reg(imx258, IMX258_REG_TEST_PATTERN,
> IMX258_REG_VALUE_16BIT,
> - imx258_test_pattern_val[ctrl->val]);
> -
> + ctrl->val);
> ret = imx258_write_reg(imx258, REG_MIRROR_FLIP_CONTROL,
> IMX258_REG_VALUE_08BIT,
> - ctrl->val == imx258_test_pattern_val
> - [IMX258_TEST_PATTERN_DISABLE] ?
> - REG_CONFIG_MIRROR_FLIP :
> + !ctrl->val?REG_CONFIG_MIRROR_FLIP :
> REG_CONFIG_FLIP_TEST_PATTERN);
> break;
> default:
> @@ -1105,6 +1088,10 @@ static int imx258_identify_module(struct imx258
> *imx258)
> .pad = &imx258_pad_ops,
> };
>
> +static const struct media_entity_operations imx258_subdev_entity_ops = {
> + .link_validate = v4l2_subdev_link_validate, };
> +
This seems unrelated as well. Do you need the link validation for something?
As far as I understand, the driver exposes a single source pad; therefore the
link_validate op will never be called.
> static const struct v4l2_subdev_internal_ops imx258_internal_ops = {
> .open = imx258_open,
> };
> @@ -1250,6 +1237,7 @@ static int imx258_probe(struct i2c_client
> *client)
>
> /* Initialize subdev */
> imx258->sd.internal_ops = &imx258_internal_ops;
> + imx258->sd.entity.ops = &imx258_subdev_entity_ops;
Ditto.
> imx258->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> imx258->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
>
--
Kind regards,
Sakari Ailus
sakari.ai...@linux.intel.com
[PATCH] media: imx258: remove test pattern map from driver
From: "Chen, JasonX Z"
change bayer order when using test pattern mode.
remove test pattern mapping method
Signed-off-by: Chen, JasonX Z
---
drivers/media/i2c/imx258.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
index 31a1e22..5a72b4a 100644
--- a/drivers/media/i2c/imx258.c
+++ b/drivers/media/i2c/imx258.c
@@ -62,11 +62,6 @@
/* Test Pattern Control */
#define IMX258_REG_TEST_PATTERN0x0600
-#define IMX258_TEST_PATTERN_DISABLE0
-#define IMX258_TEST_PATTERN_SOLID_COLOR1
-#define IMX258_TEST_PATTERN_COLOR_BARS 2
-#define IMX258_TEST_PATTERN_GREY_COLOR 3
-#define IMX258_TEST_PATTERN_PN94
/* Orientation */
#define REG_MIRROR_FLIP_CONTROL0x0101
@@ -504,20 +499,12 @@ struct imx258_mode {
static const char * const imx258_test_pattern_menu[] = {
"Disabled",
- "Color Bars",
"Solid Color",
+ "Color Bars",
"Grey Color Bars",
"PN9"
};
-static const int imx258_test_pattern_val[] = {
- IMX258_TEST_PATTERN_DISABLE,
- IMX258_TEST_PATTERN_COLOR_BARS,
- IMX258_TEST_PATTERN_SOLID_COLOR,
- IMX258_TEST_PATTERN_GREY_COLOR,
- IMX258_TEST_PATTERN_PN9,
-};
-
/* Configurations for supported link frequencies */
#define IMX258_LINK_FREQ_634MHZ63360ULL
#define IMX258_LINK_FREQ_320MHZ32000ULL
@@ -757,6 +744,7 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
* Applying V4L2 control value only happens
* when power is up for streaming
*/
+
if (pm_runtime_get_if_in_use(&client->dev) == 0)
return 0;
@@ -778,13 +766,10 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_TEST_PATTERN:
ret = imx258_write_reg(imx258, IMX258_REG_TEST_PATTERN,
IMX258_REG_VALUE_16BIT,
- imx258_test_pattern_val[ctrl->val]);
-
+ ctrl->val);
ret = imx258_write_reg(imx258, REG_MIRROR_FLIP_CONTROL,
IMX258_REG_VALUE_08BIT,
- ctrl->val == imx258_test_pattern_val
- [IMX258_TEST_PATTERN_DISABLE] ?
- REG_CONFIG_MIRROR_FLIP :
+ !ctrl->val ? REG_CONFIG_MIRROR_FLIP :
REG_CONFIG_FLIP_TEST_PATTERN);
break;
default:
--
1.9.1
Re: [RFC] Create test script(s?) for regression testing
On 11/07/2018 12:10 PM, Mauro Carvalho Chehab wrote: > Em Wed, 07 Nov 2018 12:06:55 +0200 > Laurent Pinchart escreveu: > >> Hi Hans, >> >> On Wednesday, 7 November 2018 10:05:12 EET Hans Verkuil wrote: >>> On 11/06/2018 08:58 PM, Laurent Pinchart wrote: >>>> On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote: >>>>> On 11/06/18 14:12, Laurent Pinchart wrote: >>>>>> On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote: >>>>>>> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> After the media summit (heavy on test discussions) and the V4L2 event >>>>>>>> regression we just found it is clear we need to do a better job with >>>>>>>> testing. >>>>>>>> >>>>>>>> All the pieces are in place, so what is needed is to combine it and >>>>>>>> create a script that anyone of us as core developers can run to check >>>>>>>> for regressions. The same script can be run as part of the kernelci >>>>>>>> regression testing. >>>>>>> >>>>>>> I'd say that *some* pieces are in place. Of course, the more there is, >>>>>>> the better. >>>>>>> >>>>>>> The more there are tests, the more important it would be they're >>>>>>> automated, preferrably without the developer having to run them on his/ >>>>>>> her own machine. >>>>>> >>>>>> From my experience with testing, it's important to have both a core set >>>>>> of tests (a.k.a. smoke tests) that can easily be run on developers' >>>>>> machines, and extended tests that can be offloaded to a shared testing >>>>>> infrastructure (but possibly also run locally if desired). >>>>> >>>>> That was my idea as well for the longer term. First step is to do the >>>>> basic smoke tests (i.e. run compliance tests, do some (limited) streaming >>>>> test). >>>>> >>>>> There are more extensive (and longer running) tests that can be done, but >>>>> that's something to look at later. >>>>> >>>>>>>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last >>>>>>>> one is IMHO not quite good enough yet for testing: it is not fully >>>>>>>> compliant to the upcoming stateful codec spec. Work for that is >>>>>>>> planned as part of an Outreachy project. >>>>>>>> >>>>>>>> My idea is to create a script that is maintained as part of v4l-utils >>>>>>>> that loads the drivers and runs v4l2-compliance and possibly other >>>>>>>> tests against the virtual drivers. > > (adding Shuah) > > IMO, the best would be to have something like that as part of Kernel > self test, as this could give a broader covering than just Kernel CI. > I agree with the broader coverage benefit that comes with adding tests to kselftest. It makes it easier for making changes to tests/tools coupled with kernel/driver changes. Common TAP13 reporting can be taken advantage of without doing any additional work in the tests if author chooses to do so. Tests can be added such that they don't get run by default if there is a reason do so and Kernel CI and other rings can invoke it as a special case if necessary. There are very clear advantages to making these tests part of the kernel source tree. We can discuss at the Kernel Summit next week if you are interested. thanks, -- Shuah
Re: [RFC] Create test script(s?) for regression testing
Hi Mauro, On Wednesday, 7 November 2018 21:53:20 EET Mauro Carvalho Chehab wrote: > Em Wed, 07 Nov 2018 21:35:32 +0200 Laurent Pinchart escreveu: > > On Wednesday, 7 November 2018 21:10:35 EET Mauro Carvalho Chehab wrote: [snip] > >> I'm with Hans on that matter: better to start with an absolute minimum > >> of dependencies (like just: make, autotools, c, c++, bash), > > > > On a site note, for a new project, we might want to move away from > > autotools. cmake and meson are possible alternatives that are way less > > painful. > > Each toolset has advantages or disadvantages. We all know how > autotools can be painful. > > One bad thing with cmake is that they deprecate stuff. A long-live project > usually require several" backward" compat stuff at cmake files in order > to cope with different behaviors that change as cmake evolves. I don't know how much of a problem that would be. My experience with cmake is good so far, but I haven't used it in a large scale project with 10+ years of contributions :-) > I never used mason myself. It's the build system we picked for libcamera, I expect to provide feedback in the not too distant future. [snip] -- Regards, Laurent Pinchart
Re: [RFC] Create test script(s?) for regression testing
Em Wed, 07 Nov 2018 21:35:32 +0200 Laurent Pinchart escreveu: > Hi Mauro, > > On Wednesday, 7 November 2018 21:10:35 EET Mauro Carvalho Chehab wrote: > > Em Wed, 07 Nov 2018 12:06:55 +0200 Laurent Pinchart escreveu: > > > On Wednesday, 7 November 2018 10:05:12 EET Hans Verkuil wrote: > > >> On 11/06/2018 08:58 PM, Laurent Pinchart wrote: > > >>> On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote: > > >>>> On 11/06/18 14:12, Laurent Pinchart wrote: > > >>>>> On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote: > > >>>>>> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote: > > >>>>>>> Hi all, > > >>>>>>> > > >>>>>>> After the media summit (heavy on test discussions) and the V4L2 > > >>>>>>> event regression we just found it is clear we need to do a better > > >>>>>>> job with testing. > > >>>>>>> > > >>>>>>> All the pieces are in place, so what is needed is to combine it > > >>>>>>> and create a script that anyone of us as core developers can run to > > >>>>>>> check for regressions. The same script can be run as part of the > > >>>>>>> kernelci regression testing. > > >>>>>> > > >>>>>> I'd say that *some* pieces are in place. Of course, the more there > > >>>>>> is, the better. > > >>>>>> > > >>>>>> The more there are tests, the more important it would be they're > > >>>>>> automated, preferrably without the developer having to run them on > > >>>>>> his/her own machine. > > >>>>> > > >>>>> From my experience with testing, it's important to have both a core > > >>>>> set of tests (a.k.a. smoke tests) that can easily be run on > > >>>>> developers' machines, and extended tests that can be offloaded to a > > >>>>> shared testing infrastructure (but possibly also run locally if > > >>>>> desired). > > >>>> > > >>>> That was my idea as well for the longer term. First step is to do the > > >>>> basic smoke tests (i.e. run compliance tests, do some (limited) > > >>>> streaming test). > > >>>> > > >>>> There are more extensive (and longer running) tests that can be done, > > >>>> but that's something to look at later. > > >>>> > > >>>>>>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The > > >>>>>>> last one is IMHO not quite good enough yet for testing: it is not > > >>>>>>> fully compliant to the upcoming stateful codec spec. Work for that > > >>>>>>> is planned as part of an Outreachy project. > > >>>>>>> > > >>>>>>> My idea is to create a script that is maintained as part of > > >>>>>>> v4l-utils that loads the drivers and runs v4l2-compliance and > > >>>>>>> possibly other tests against the virtual drivers. > > > > (adding Shuah) > > > > IMO, the best would be to have something like that as part of Kernel > > self test, as this could give a broader covering than just Kernel CI. > > > > Yeah, I know that one of the concerns is that the *-compliance stuff > > we have are written in C++ and it is easier to maintain then at > > v4l-utils, but maybe it would be acceptable at kselftest to have a > > test bench there with would download the sources from a git tree > > and then build just the v4l2-compliance stuff, e. g. having a Kernel > > self test target that would do something like: > > > > git clone --depth 1 git://linuxtv.org/v4l-utils.git tests && \ > > cd tests && ./autogen.sh && make tests && ./run_tests.sh > > Let me make sure I understand this properly. Are you proposing to add to > kselftest, which is part of the Linux kernel, and as such benefits from the > level of trust of Linus' tree, and which is run by a very large number of > machines from developer workstations to automated large-scale test > infrastructure, a provision to execute locally code that is downloaded at > runtime from the internet, with all the s
Re: [RFC] Create test script(s?) for regression testing
On Wed, 2018-11-07 at 09:05 +0100, Hans Verkuil wrote: > On 11/06/2018 08:58 PM, Laurent Pinchart wrote: > > Hi Hans, > > > > On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote: > > > On 11/06/18 14:12, Laurent Pinchart wrote: > > > > On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote: > > > > > On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote: > > > > > > Hi all, > > > > > > > > > > > > After the media summit (heavy on test discussions) and the V4L2 > > > > > > event > > > > > > regression we just found it is clear we need to do a better job with > > > > > > testing. > > > > > > > > > > > > All the pieces are in place, so what is needed is to combine it and > > > > > > create a script that anyone of us as core developers can run to > > > > > > check > > > > > > for regressions. The same script can be run as part of the kernelci > > > > > > regression testing. > > > > > > > > > > I'd say that *some* pieces are in place. Of course, the more there is, > > > > > the better. > > > > > > > > > > The more there are tests, the more important it would be they're > > > > > automated, preferrably without the developer having to run them on > > > > > his/ > > > > > her own machine. > > > > > > > > From my experience with testing, it's important to have both a core set > > > > of > > > > tests (a.k.a. smoke tests) that can easily be run on developers' > > > > machines, > > > > and extended tests that can be offloaded to a shared testing > > > > infrastructure (but possibly also run locally if desired). > > > > > > That was my idea as well for the longer term. First step is to do the > > > basic > > > smoke tests (i.e. run compliance tests, do some (limited) streaming test). > > > > > > There are more extensive (and longer running) tests that can be done, but > > > that's something to look at later. > > > > > > > > > We have four virtual drivers: vivid, vim2m, vimc and vicodec. The > > > > > > last > > > > > > one is IMHO not quite good enough yet for testing: it is not fully > > > > > > compliant to the upcoming stateful codec spec. Work for that is > > > > > > planned > > > > > > as part of an Outreachy project. > > > > > > > > > > > > My idea is to create a script that is maintained as part of > > > > > > v4l-utils > > > > > > that loads the drivers and runs v4l2-compliance and possibly other > > > > > > tests > > > > > > against the virtual drivers. > > > > > > > > > > How about spending a little time to pick a suitable framework for > > > > > running > > > > > the tests? It could be useful to get more informative reports than > > > > > just > > > > > pass / fail. > > > > > > > > We should keep in mind that other tests will be added later, and the > > > > test > > > > framework should make that easy. > > > > > > Since we want to be able to run this on kernelci.org, I think it makes > > > sense > > > to let the kernelci folks (Hi Ezequiel!) decide this. > > > > KernelCI isn't the only test infrastructure out there, so let's not forget > > about the other ones. > > True, but they are putting time and money into this, so they get to choose as > far as I am concerned :-) > Well, we are also resource-constrained, so my idea for the first iteration is to pick the simplest yet useful setup. We plan to leverage existing tests only. Currently xxx-compliance tools are what cover more. I believe that CI and tests should be independent components. > If others are interested and willing to put up time and money, they should let > themselves be known. > > I'm not going to work on such an integration, although I happily accept > patches. > > > > As a developer all I need is a script to run smoke tests so I can catch > > > most > > > regressions (you never catch all). > > > > > > I'm happy to work with them to make any changes to compliance tools and > > > scripts so they fit better into their
Re: [RFC] Create test script(s?) for regression testing
Hi Mauro, On Wednesday, 7 November 2018 21:10:35 EET Mauro Carvalho Chehab wrote: > Em Wed, 07 Nov 2018 12:06:55 +0200 Laurent Pinchart escreveu: > > On Wednesday, 7 November 2018 10:05:12 EET Hans Verkuil wrote: > >> On 11/06/2018 08:58 PM, Laurent Pinchart wrote: > >>> On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote: > >>>> On 11/06/18 14:12, Laurent Pinchart wrote: > >>>>> On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote: > >>>>>> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote: > >>>>>>> Hi all, > >>>>>>> > >>>>>>> After the media summit (heavy on test discussions) and the V4L2 > >>>>>>> event regression we just found it is clear we need to do a better > >>>>>>> job with testing. > >>>>>>> > >>>>>>> All the pieces are in place, so what is needed is to combine it > >>>>>>> and create a script that anyone of us as core developers can run to > >>>>>>> check for regressions. The same script can be run as part of the > >>>>>>> kernelci regression testing. > >>>>>> > >>>>>> I'd say that *some* pieces are in place. Of course, the more there > >>>>>> is, the better. > >>>>>> > >>>>>> The more there are tests, the more important it would be they're > >>>>>> automated, preferrably without the developer having to run them on > >>>>>> his/her own machine. > >>>>> > >>>>> From my experience with testing, it's important to have both a core > >>>>> set of tests (a.k.a. smoke tests) that can easily be run on > >>>>> developers' machines, and extended tests that can be offloaded to a > >>>>> shared testing infrastructure (but possibly also run locally if > >>>>> desired). > >>>> > >>>> That was my idea as well for the longer term. First step is to do the > >>>> basic smoke tests (i.e. run compliance tests, do some (limited) > >>>> streaming test). > >>>> > >>>> There are more extensive (and longer running) tests that can be done, > >>>> but that's something to look at later. > >>>> > >>>>>>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The > >>>>>>> last one is IMHO not quite good enough yet for testing: it is not > >>>>>>> fully compliant to the upcoming stateful codec spec. Work for that > >>>>>>> is planned as part of an Outreachy project. > >>>>>>> > >>>>>>> My idea is to create a script that is maintained as part of > >>>>>>> v4l-utils that loads the drivers and runs v4l2-compliance and > >>>>>>> possibly other tests against the virtual drivers. > > (adding Shuah) > > IMO, the best would be to have something like that as part of Kernel > self test, as this could give a broader covering than just Kernel CI. > > Yeah, I know that one of the concerns is that the *-compliance stuff > we have are written in C++ and it is easier to maintain then at > v4l-utils, but maybe it would be acceptable at kselftest to have a > test bench there with would download the sources from a git tree > and then build just the v4l2-compliance stuff, e. g. having a Kernel > self test target that would do something like: > > git clone --depth 1 git://linuxtv.org/v4l-utils.git tests && \ > cd tests && ./autogen.sh && make tests && ./run_tests.sh Let me make sure I understand this properly. Are you proposing to add to kselftest, which is part of the Linux kernel, and as such benefits from the level of trust of Linus' tree, and which is run by a very large number of machines from developer workstations to automated large-scale test infrastructure, a provision to execute locally code that is downloaded at runtime from the internet, with all the security issues this implies ? > (the actual selftest target would likely be different, as it > should take into account make O=) > > If this would be acceptable upstream, then we'll need to stick with the > output format defined by Kernel Self Test[1]. > > [1] I guess it uses the TAP13 format: > https://testanything.org/tap-version-13-specification.html > > >>>>>> How about sp
Re: [RFC] Create test script(s?) for regression testing
Em Wed, 07 Nov 2018 12:06:55 +0200 Laurent Pinchart escreveu: > Hi Hans, > > On Wednesday, 7 November 2018 10:05:12 EET Hans Verkuil wrote: > > On 11/06/2018 08:58 PM, Laurent Pinchart wrote: > > > On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote: > > >> On 11/06/18 14:12, Laurent Pinchart wrote: > > >>> On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote: > > >>>> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote: > > >>>>> Hi all, > > >>>>> > > >>>>> After the media summit (heavy on test discussions) and the V4L2 event > > >>>>> regression we just found it is clear we need to do a better job with > > >>>>> testing. > > >>>>> > > >>>>> All the pieces are in place, so what is needed is to combine it and > > >>>>> create a script that anyone of us as core developers can run to check > > >>>>> for regressions. The same script can be run as part of the kernelci > > >>>>> regression testing. > > >>>> > > >>>> I'd say that *some* pieces are in place. Of course, the more there is, > > >>>> the better. > > >>>> > > >>>> The more there are tests, the more important it would be they're > > >>>> automated, preferrably without the developer having to run them on his/ > > >>>> her own machine. > > >>> > > >>> From my experience with testing, it's important to have both a core set > > >>> of tests (a.k.a. smoke tests) that can easily be run on developers' > > >>> machines, and extended tests that can be offloaded to a shared testing > > >>> infrastructure (but possibly also run locally if desired). > > >> > > >> That was my idea as well for the longer term. First step is to do the > > >> basic smoke tests (i.e. run compliance tests, do some (limited) streaming > > >> test). > > >> > > >> There are more extensive (and longer running) tests that can be done, but > > >> that's something to look at later. > > >> > > >>>>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last > > >>>>> one is IMHO not quite good enough yet for testing: it is not fully > > >>>>> compliant to the upcoming stateful codec spec. Work for that is > > >>>>> planned as part of an Outreachy project. > > >>>>> > > >>>>> My idea is to create a script that is maintained as part of v4l-utils > > >>>>> that loads the drivers and runs v4l2-compliance and possibly other > > >>>>> tests against the virtual drivers. (adding Shuah) IMO, the best would be to have something like that as part of Kernel self test, as this could give a broader covering than just Kernel CI. Yeah, I know that one of the concerns is that the *-compliance stuff we have are written in C++ and it is easier to maintain then at v4l-utils, but maybe it would be acceptable at kselftest to have a test bench there with would download the sources from a git tree and then build just the v4l2-compliance stuff, e. g. having a Kernel self test target that would do something like: git clone --depth 1 git://linuxtv.org/v4l-utils.git tests && \ cd tests && ./autogen.sh && make tests && ./run_tests.sh (the actual selftest target would likely be different, as it should take into account make O=) If this would be acceptable upstream, then we'll need to stick with the output format defined by Kernel Self Test[1]. [1] I guess it uses the TAP13 format: https://testanything.org/tap-version-13-specification.html > > >>>> > > >>>> How about spending a little time to pick a suitable framework for > > >>>> running the tests? It could be useful to get more informative reports > > >>>> than just pass / fail. > > >>> > > >>> We should keep in mind that other tests will be added later, and the > > >>> test framework should make that easy. > > >> > > >> Since we want to be able to run this on kernelci.org, I think it makes > > >> sense to let the kernelci folks (Hi Ezequiel!) decide this. > > > > > > KernelCI isn't the only test infrastructure out there, so let's not forget > > > about the other ones. > > >
Re: [PATCH] media: imx258: remove test pattern map from driver
Hi Jason,
Thanks for the patch.
On Wed, Nov 07, 2018 at 03:22:23PM +0800, jasonx.z.c...@intel.com wrote:
> From: "Chen, JasonX Z"
>
> Test Pattern mode be picked at HAL instead of driver.
> do a FLIP when userspace use test pattern mode.
> add entity_ops for validating imx258 link.
>
> Signed-off-by: Chen, JasonX Z
> ---
> drivers/media/i2c/imx258.c | 28
> 1 file changed, 8 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
> index 31a1e22..71f9875 100644
> --- a/drivers/media/i2c/imx258.c
> +++ b/drivers/media/i2c/imx258.c
> @@ -62,11 +62,6 @@
>
> /* Test Pattern Control */
> #define IMX258_REG_TEST_PATTERN 0x0600
> -#define IMX258_TEST_PATTERN_DISABLE 0
> -#define IMX258_TEST_PATTERN_SOLID_COLOR 1
> -#define IMX258_TEST_PATTERN_COLOR_BARS 2
> -#define IMX258_TEST_PATTERN_GREY_COLOR 3
> -#define IMX258_TEST_PATTERN_PN9 4
>
> /* Orientation */
> #define REG_MIRROR_FLIP_CONTROL 0x0101
> @@ -504,20 +499,12 @@ struct imx258_mode {
>
> static const char * const imx258_test_pattern_menu[] = {
> "Disabled",
> - "Color Bars",
> "Solid Color",
> + "Color Bars",
> "Grey Color Bars",
> "PN9"
> };
>
> -static const int imx258_test_pattern_val[] = {
> - IMX258_TEST_PATTERN_DISABLE,
> - IMX258_TEST_PATTERN_COLOR_BARS,
> - IMX258_TEST_PATTERN_SOLID_COLOR,
> - IMX258_TEST_PATTERN_GREY_COLOR,
> - IMX258_TEST_PATTERN_PN9,
> -};
> -
> /* Configurations for supported link frequencies */
> #define IMX258_LINK_FREQ_634MHZ 63360ULL
> #define IMX258_LINK_FREQ_320MHZ 32000ULL
> @@ -752,7 +739,6 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
> container_of(ctrl->handler, struct imx258, ctrl_handler);
> struct i2c_client *client = v4l2_get_subdevdata(&imx258->sd);
> int ret = 0;
> -
This seems like an unrelated change, and it's a common (and usually good)
practice to add an empty line after variable declarations.
> /*
>* Applying V4L2 control value only happens
>* when power is up for streaming
> @@ -778,13 +764,10 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
> case V4L2_CID_TEST_PATTERN:
> ret = imx258_write_reg(imx258, IMX258_REG_TEST_PATTERN,
> IMX258_REG_VALUE_16BIT,
> - imx258_test_pattern_val[ctrl->val]);
> -
> + ctrl->val);
> ret = imx258_write_reg(imx258, REG_MIRROR_FLIP_CONTROL,
> IMX258_REG_VALUE_08BIT,
> - ctrl->val == imx258_test_pattern_val
> - [IMX258_TEST_PATTERN_DISABLE] ?
> - REG_CONFIG_MIRROR_FLIP :
> + !ctrl->val?REG_CONFIG_MIRROR_FLIP :
> REG_CONFIG_FLIP_TEST_PATTERN);
> break;
> default:
> @@ -1105,6 +1088,10 @@ static int imx258_identify_module(struct imx258
> *imx258)
> .pad = &imx258_pad_ops,
> };
>
> +static const struct media_entity_operations imx258_subdev_entity_ops = {
> + .link_validate = v4l2_subdev_link_validate,
> +};
> +
This seems unrelated as well. Do you need the link validation for something?
As far as I understand, the driver exposes a single source pad; therefore
the link_validate op will never be called.
> static const struct v4l2_subdev_internal_ops imx258_internal_ops = {
> .open = imx258_open,
> };
> @@ -1250,6 +1237,7 @@ static int imx258_probe(struct i2c_client *client)
>
> /* Initialize subdev */
> imx258->sd.internal_ops = &imx258_internal_ops;
> + imx258->sd.entity.ops = &imx258_subdev_entity_ops;
Ditto.
> imx258->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
> imx258->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
>
--
Kind regards,
Sakari Ailus
sakari.ai...@linux.intel.com
Re: [RFC] Create test script(s?) for regression testing
Hi Hans, On Wednesday, 7 November 2018 10:05:12 EET Hans Verkuil wrote: > On 11/06/2018 08:58 PM, Laurent Pinchart wrote: > > On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote: > >> On 11/06/18 14:12, Laurent Pinchart wrote: > >>> On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote: > >>>> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote: > >>>>> Hi all, > >>>>> > >>>>> After the media summit (heavy on test discussions) and the V4L2 event > >>>>> regression we just found it is clear we need to do a better job with > >>>>> testing. > >>>>> > >>>>> All the pieces are in place, so what is needed is to combine it and > >>>>> create a script that anyone of us as core developers can run to check > >>>>> for regressions. The same script can be run as part of the kernelci > >>>>> regression testing. > >>>> > >>>> I'd say that *some* pieces are in place. Of course, the more there is, > >>>> the better. > >>>> > >>>> The more there are tests, the more important it would be they're > >>>> automated, preferrably without the developer having to run them on his/ > >>>> her own machine. > >>> > >>> From my experience with testing, it's important to have both a core set > >>> of tests (a.k.a. smoke tests) that can easily be run on developers' > >>> machines, and extended tests that can be offloaded to a shared testing > >>> infrastructure (but possibly also run locally if desired). > >> > >> That was my idea as well for the longer term. First step is to do the > >> basic smoke tests (i.e. run compliance tests, do some (limited) streaming > >> test). > >> > >> There are more extensive (and longer running) tests that can be done, but > >> that's something to look at later. > >> > >>>>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last > >>>>> one is IMHO not quite good enough yet for testing: it is not fully > >>>>> compliant to the upcoming stateful codec spec. Work for that is > >>>>> planned as part of an Outreachy project. > >>>>> > >>>>> My idea is to create a script that is maintained as part of v4l-utils > >>>>> that loads the drivers and runs v4l2-compliance and possibly other > >>>>> tests against the virtual drivers. > >>>> > >>>> How about spending a little time to pick a suitable framework for > >>>> running the tests? It could be useful to get more informative reports > >>>> than just pass / fail. > >>> > >>> We should keep in mind that other tests will be added later, and the > >>> test framework should make that easy. > >> > >> Since we want to be able to run this on kernelci.org, I think it makes > >> sense to let the kernelci folks (Hi Ezequiel!) decide this. > > > > KernelCI isn't the only test infrastructure out there, so let's not forget > > about the other ones. > > True, but they are putting time and money into this, so they get to choose > as far as I am concerned :-) It's still our responsibility to give V4L2 a good test framework, and to drive it in the right direction. We don't accept V4L2 API extensions blindly just because a company happens to put time and money into it (there may have been one exception, but it's not the rule), we instead review all proposals carefully. The same should be true with tests. > If others are interested and willing to put up time and money, they should > let themselves be known. > > I'm not going to work on such an integration, although I happily accept > patches. > > >> As a developer all I need is a script to run smoke tests so I can catch > >> most regressions (you never catch all). > >> > >> I'm happy to work with them to make any changes to compliance tools and > >> scripts so they fit better into their test framework. > >> > >> The one key requirement to all this is that you should be able to run > >> these tests without dependencies to all sorts of external packages/ > >> libraries. > > > > v4l-utils already has a set of dependencies, but those are largely > > manageable. For v4l2-compliance we'll install libv4l, which depends on > > libjpeg. > > T
Re: [RFC] Create test script(s?) for regression testing
On 11/06/2018 08:58 PM, Laurent Pinchart wrote: > Hi Hans, > > On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote: >> On 11/06/18 14:12, Laurent Pinchart wrote: >>> On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote: >>>> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote: >>>>> Hi all, >>>>> >>>>> After the media summit (heavy on test discussions) and the V4L2 event >>>>> regression we just found it is clear we need to do a better job with >>>>> testing. >>>>> >>>>> All the pieces are in place, so what is needed is to combine it and >>>>> create a script that anyone of us as core developers can run to check >>>>> for regressions. The same script can be run as part of the kernelci >>>>> regression testing. >>>> >>>> I'd say that *some* pieces are in place. Of course, the more there is, >>>> the better. >>>> >>>> The more there are tests, the more important it would be they're >>>> automated, preferrably without the developer having to run them on his/ >>>> her own machine. >>> >>> From my experience with testing, it's important to have both a core set of >>> tests (a.k.a. smoke tests) that can easily be run on developers' machines, >>> and extended tests that can be offloaded to a shared testing >>> infrastructure (but possibly also run locally if desired). >> >> That was my idea as well for the longer term. First step is to do the basic >> smoke tests (i.e. run compliance tests, do some (limited) streaming test). >> >> There are more extensive (and longer running) tests that can be done, but >> that's something to look at later. >> >>>>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last >>>>> one is IMHO not quite good enough yet for testing: it is not fully >>>>> compliant to the upcoming stateful codec spec. Work for that is planned >>>>> as part of an Outreachy project. >>>>> >>>>> My idea is to create a script that is maintained as part of v4l-utils >>>>> that loads the drivers and runs v4l2-compliance and possibly other tests >>>>> against the virtual drivers. >>>> >>>> How about spending a little time to pick a suitable framework for running >>>> the tests? It could be useful to get more informative reports than just >>>> pass / fail. >>> >>> We should keep in mind that other tests will be added later, and the test >>> framework should make that easy. >> >> Since we want to be able to run this on kernelci.org, I think it makes sense >> to let the kernelci folks (Hi Ezequiel!) decide this. > > KernelCI isn't the only test infrastructure out there, so let's not forget > about the other ones. True, but they are putting time and money into this, so they get to choose as far as I am concerned :-) If others are interested and willing to put up time and money, they should let themselves be known. I'm not going to work on such an integration, although I happily accept patches. > >> As a developer all I need is a script to run smoke tests so I can catch most >> regressions (you never catch all). >> >> I'm happy to work with them to make any changes to compliance tools and >> scripts so they fit better into their test framework. >> >> The one key requirement to all this is that you should be able to run these >> tests without dependencies to all sorts of external packages/libraries. > > v4l-utils already has a set of dependencies, but those are largely > manageable. > For v4l2-compliance we'll install libv4l, which depends on libjpeg. That's already too much. You can manually build v4l2-compliance with no dependencies whatsoever, but we're missing a Makefile target for that. It's been useful for embedded systems with poor cross-compile environments. It is really very useful to be able to compile those core utilities with no external libraries other than glibc. You obviously will loose some functionality when you compile it that way. These utilities are not like a typical application. I really don't care how many libraries are linked in by e.g. qv4l2, xawtv, etc. But for v4l2-ctl, v4l2-compliance, cec-ctl/follower/compliance (and probably a few others as well) you want a minimum of dependencies so you can run them everywhere, even with the crappiest toolchains or cross-compile environments. > >>> Regarding the test
[PATCH] media: imx258: remove test pattern map from driver
From: "Chen, JasonX Z"
Test Pattern mode be picked at HAL instead of driver.
do a FLIP when userspace use test pattern mode.
add entity_ops for validating imx258 link.
Signed-off-by: Chen, JasonX Z
---
drivers/media/i2c/imx258.c | 28
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/media/i2c/imx258.c b/drivers/media/i2c/imx258.c
index 31a1e22..71f9875 100644
--- a/drivers/media/i2c/imx258.c
+++ b/drivers/media/i2c/imx258.c
@@ -62,11 +62,6 @@
/* Test Pattern Control */
#define IMX258_REG_TEST_PATTERN0x0600
-#define IMX258_TEST_PATTERN_DISABLE0
-#define IMX258_TEST_PATTERN_SOLID_COLOR1
-#define IMX258_TEST_PATTERN_COLOR_BARS 2
-#define IMX258_TEST_PATTERN_GREY_COLOR 3
-#define IMX258_TEST_PATTERN_PN94
/* Orientation */
#define REG_MIRROR_FLIP_CONTROL0x0101
@@ -504,20 +499,12 @@ struct imx258_mode {
static const char * const imx258_test_pattern_menu[] = {
"Disabled",
- "Color Bars",
"Solid Color",
+ "Color Bars",
"Grey Color Bars",
"PN9"
};
-static const int imx258_test_pattern_val[] = {
- IMX258_TEST_PATTERN_DISABLE,
- IMX258_TEST_PATTERN_COLOR_BARS,
- IMX258_TEST_PATTERN_SOLID_COLOR,
- IMX258_TEST_PATTERN_GREY_COLOR,
- IMX258_TEST_PATTERN_PN9,
-};
-
/* Configurations for supported link frequencies */
#define IMX258_LINK_FREQ_634MHZ63360ULL
#define IMX258_LINK_FREQ_320MHZ32000ULL
@@ -752,7 +739,6 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
container_of(ctrl->handler, struct imx258, ctrl_handler);
struct i2c_client *client = v4l2_get_subdevdata(&imx258->sd);
int ret = 0;
-
/*
* Applying V4L2 control value only happens
* when power is up for streaming
@@ -778,13 +764,10 @@ static int imx258_set_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_TEST_PATTERN:
ret = imx258_write_reg(imx258, IMX258_REG_TEST_PATTERN,
IMX258_REG_VALUE_16BIT,
- imx258_test_pattern_val[ctrl->val]);
-
+ ctrl->val);
ret = imx258_write_reg(imx258, REG_MIRROR_FLIP_CONTROL,
IMX258_REG_VALUE_08BIT,
- ctrl->val == imx258_test_pattern_val
- [IMX258_TEST_PATTERN_DISABLE] ?
- REG_CONFIG_MIRROR_FLIP :
+ !ctrl->val?REG_CONFIG_MIRROR_FLIP :
REG_CONFIG_FLIP_TEST_PATTERN);
break;
default:
@@ -1105,6 +1088,10 @@ static int imx258_identify_module(struct imx258 *imx258)
.pad = &imx258_pad_ops,
};
+static const struct media_entity_operations imx258_subdev_entity_ops = {
+ .link_validate = v4l2_subdev_link_validate,
+};
+
static const struct v4l2_subdev_internal_ops imx258_internal_ops = {
.open = imx258_open,
};
@@ -1250,6 +1237,7 @@ static int imx258_probe(struct i2c_client *client)
/* Initialize subdev */
imx258->sd.internal_ops = &imx258_internal_ops;
+ imx258->sd.entity.ops = &imx258_subdev_entity_ops;
imx258->sd.flags |= V4L2_SUBDEV_FL_HAS_DEVNODE;
imx258->sd.entity.function = MEDIA_ENT_F_CAM_SENSOR;
--
1.9.1
Re: [RFC] Create test script(s?) for regression testing
Hi Hans, On Tuesday, 6 November 2018 15:56:34 EET Hans Verkuil wrote: > On 11/06/18 14:12, Laurent Pinchart wrote: > > On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote: > >> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote: > >>> Hi all, > >>> > >>> After the media summit (heavy on test discussions) and the V4L2 event > >>> regression we just found it is clear we need to do a better job with > >>> testing. > >>> > >>> All the pieces are in place, so what is needed is to combine it and > >>> create a script that anyone of us as core developers can run to check > >>> for regressions. The same script can be run as part of the kernelci > >>> regression testing. > >> > >> I'd say that *some* pieces are in place. Of course, the more there is, > >> the better. > >> > >> The more there are tests, the more important it would be they're > >> automated, preferrably without the developer having to run them on his/ > >> her own machine. > > > > From my experience with testing, it's important to have both a core set of > > tests (a.k.a. smoke tests) that can easily be run on developers' machines, > > and extended tests that can be offloaded to a shared testing > > infrastructure (but possibly also run locally if desired). > > That was my idea as well for the longer term. First step is to do the basic > smoke tests (i.e. run compliance tests, do some (limited) streaming test). > > There are more extensive (and longer running) tests that can be done, but > that's something to look at later. > > >>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last > >>> one is IMHO not quite good enough yet for testing: it is not fully > >>> compliant to the upcoming stateful codec spec. Work for that is planned > >>> as part of an Outreachy project. > >>> > >>> My idea is to create a script that is maintained as part of v4l-utils > >>> that loads the drivers and runs v4l2-compliance and possibly other tests > >>> against the virtual drivers. > >> > >> How about spending a little time to pick a suitable framework for running > >> the tests? It could be useful to get more informative reports than just > >> pass / fail. > > > > We should keep in mind that other tests will be added later, and the test > > framework should make that easy. > > Since we want to be able to run this on kernelci.org, I think it makes sense > to let the kernelci folks (Hi Ezequiel!) decide this. KernelCI isn't the only test infrastructure out there, so let's not forget about the other ones. > As a developer all I need is a script to run smoke tests so I can catch most > regressions (you never catch all). > > I'm happy to work with them to make any changes to compliance tools and > scripts so they fit better into their test framework. > > The one key requirement to all this is that you should be able to run these > tests without dependencies to all sorts of external packages/libraries. v4l-utils already has a set of dependencies, but those are largely manageable. For v4l2-compliance we'll install libv4l, which depends on libjpeg. > > Regarding the test output, many formats exist (see > > https://testanything.org/ and > > https://chromium.googlesource.com/chromium/src/+/master/docs/testing/ > > json_test_results_format.md for instance), we should pick one of the > > leading industry standards (what those standards are still needs to be > > researched :-)). > > > >> Do note that for different hardware the tests would be likely different > >> as well although there are classes of devices for which the exact same > >> tests would be applicable. > > > > See http://git.ideasonboard.com/renesas/vsp-tests.git for an example of > > device-specific tests. I think some of that could be generalized. > > > >>> It should be simple to use and require very little in the way of > >>> dependencies. Ideally no dependencies other than what is in v4l-utils so > >>> it can easily be run on an embedded system as well. > >>> > >>> For a 64-bit kernel it should run the tests both with 32-bit and 64-bit > >>> applications. > >>> > >>> It should also test with both single and multiplanar modes where > >>> available. > >>> > >>> Since vivid emulates CEC as well, it should run CEC tests too. > >>> > >>> As
Re: [RFC] Create test script(s?) for regression testing
On 11/06/18 14:12, Laurent Pinchart wrote: > Hello, > > On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote: >> On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote: >>> Hi all, >>> >>> After the media summit (heavy on test discussions) and the V4L2 event >>> regression we just found it is clear we need to do a better job with >>> testing. >>> >>> All the pieces are in place, so what is needed is to combine it and create >>> a script that anyone of us as core developers can run to check for >>> regressions. The same script can be run as part of the kernelci >>> regression testing. >> >> I'd say that *some* pieces are in place. Of course, the more there is, the >> better. >> >> The more there are tests, the more important it would be they're automated, >> preferrably without the developer having to run them on his/her own >> machine. > > From my experience with testing, it's important to have both a core set of > tests (a.k.a. smoke tests) that can easily be run on developers' machines, > and > extended tests that can be offloaded to a shared testing infrastructure (but > possibly also run locally if desired). That was my idea as well for the longer term. First step is to do the basic smoke tests (i.e. run compliance tests, do some (limited) streaming test). There are more extensive (and longer running) tests that can be done, but that's something to look at later. >>> We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last one >>> is IMHO not quite good enough yet for testing: it is not fully compliant >>> to the upcoming stateful codec spec. Work for that is planned as part of >>> an Outreachy project. >>> >>> My idea is to create a script that is maintained as part of v4l-utils that >>> loads the drivers and runs v4l2-compliance and possibly other tests >>> against the virtual drivers. >> >> How about spending a little time to pick a suitable framework for running >> the tests? It could be useful to get more informative reports than just >> pass / fail. > > We should keep in mind that other tests will be added later, and the test > framework should make that easy. Since we want to be able to run this on kernelci.org, I think it makes sense to let the kernelci folks (Hi Ezequiel!) decide this. As a developer all I need is a script to run smoke tests so I can catch most regressions (you never catch all). I'm happy to work with them to make any changes to compliance tools and scripts so they fit better into their test framework. The one key requirement to all this is that you should be able to run these tests without dependencies to all sorts of external packages/libraries. > Regarding the test output, many formats exist (see https://testanything.org/ > and https://chromium.googlesource.com/chromium/src/+/master/docs/testing/ > json_test_results_format.md for instance), we should pick one of the leading > industry standards (what those standards are still needs to be researched > :-)). > >> Do note that for different hardware the tests would be likely different as >> well although there are classes of devices for which the exact same tests >> would be applicable. > > See http://git.ideasonboard.com/renesas/vsp-tests.git for an example of > device-specific tests. I think some of that could be generalized. > >>> It should be simple to use and require very little in the way of >>> dependencies. Ideally no dependencies other than what is in v4l-utils so >>> it can easily be run on an embedded system as well. >>> >>> For a 64-bit kernel it should run the tests both with 32-bit and 64-bit >>> applications. >>> >>> It should also test with both single and multiplanar modes where >>> available. >>> >>> Since vivid emulates CEC as well, it should run CEC tests too. >>> >>> As core developers we should have an environment where we can easily test >>> our patches with this script (I use a VM for that). >>> >>> I think maintaining the script (or perhaps scripts) in v4l-utils is best >>> since that keeps it in sync with the latest kernel and v4l-utils >>> developments. >> >> Makes sense --- and that can be always changed later on if there's a need >> to. > > I wonder whether that would be best going forward, especially if we want to > add more tests. Wouldn't a v4l-tests project make sense ? > Let's see what happens. The more repos you have, the harder it becomes to keep everything in sync with the latest kernel code. My experience is that if you want to have good tests, then writing tests should be as easy as possible. Keep dependencies at an absolute minimum. Let's be honest, we (well, mainly me) are doing these tests as a side job, it's not our main focus. Anything that makes writing tests more painful is bad and just gets in the way. Regards, Hans
Re: [RFC] Create test script(s?) for regression testing
On Tue, 2018-11-06 at 09:37 +0100, Hans Verkuil wrote: > Hi all, > > After the media summit (heavy on test discussions) and the V4L2 event > regression > we just found it is clear we need to do a better job with testing. > > All the pieces are in place, so what is needed is to combine it and create a > script that anyone of us as core developers can run to check for regressions. > The same script can be run as part of the kernelci regression testing. > > We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last one > is IMHO not quite good enough yet for testing: it is not fully compliant to > the > upcoming stateful codec spec. Work for that is planned as part of an Outreachy > project. > > My idea is to create a script that is maintained as part of v4l-utils that > loads the drivers and runs v4l2-compliance and possibly other tests against > the virtual drivers. > > It should be simple to use and require very little in the way of dependencies. > Ideally no dependencies other than what is in v4l-utils so it can easily be > run > on an embedded system as well. > > For a 64-bit kernel it should run the tests both with 32-bit and 64-bit > applications. > > It should also test with both single and multiplanar modes where available. > > Since vivid emulates CEC as well, it should run CEC tests too. > > As core developers we should have an environment where we can easily test > our patches with this script (I use a VM for that). > It's quite trivial to setup a qemu environment for this, e.g. you can use virtme [1] and set it up so that it runs a script after booting. > I think maintaining the script (or perhaps scripts) in v4l-utils is best since > that keeps it in sync with the latest kernel and v4l-utils developments. > > Comments? Ideas? > Sounds great. I think it makes a lot of sense to have a script for CIs and developers to run. I guess we can start simple, with just a bash script? > Regards, > > Hans [1] https://www.collabora.com/news-and-blog/blog/2018/09/18/virtme-the-kernel-developers-best-friend/
Re: [RFC] Create test script(s?) for regression testing
Hello, On Tuesday, 6 November 2018 13:36:55 EET Sakari Ailus wrote: > On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote: > > Hi all, > > > > After the media summit (heavy on test discussions) and the V4L2 event > > regression we just found it is clear we need to do a better job with > > testing. > > > > All the pieces are in place, so what is needed is to combine it and create > > a script that anyone of us as core developers can run to check for > > regressions. The same script can be run as part of the kernelci > > regression testing. > > I'd say that *some* pieces are in place. Of course, the more there is, the > better. > > The more there are tests, the more important it would be they're automated, > preferrably without the developer having to run them on his/her own > machine. >From my experience with testing, it's important to have both a core set of tests (a.k.a. smoke tests) that can easily be run on developers' machines, and extended tests that can be offloaded to a shared testing infrastructure (but possibly also run locally if desired). > > We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last one > > is IMHO not quite good enough yet for testing: it is not fully compliant > > to the upcoming stateful codec spec. Work for that is planned as part of > > an Outreachy project. > > > > My idea is to create a script that is maintained as part of v4l-utils that > > loads the drivers and runs v4l2-compliance and possibly other tests > > against the virtual drivers. > > How about spending a little time to pick a suitable framework for running > the tests? It could be useful to get more informative reports than just > pass / fail. We should keep in mind that other tests will be added later, and the test framework should make that easy. Regarding the test output, many formats exist (see https://testanything.org/ and https://chromium.googlesource.com/chromium/src/+/master/docs/testing/ json_test_results_format.md for instance), we should pick one of the leading industry standards (what those standards are still needs to be researched :-)). > Do note that for different hardware the tests would be likely different as > well although there are classes of devices for which the exact same tests > would be applicable. See http://git.ideasonboard.com/renesas/vsp-tests.git for an example of device-specific tests. I think some of that could be generalized. > > It should be simple to use and require very little in the way of > > dependencies. Ideally no dependencies other than what is in v4l-utils so > > it can easily be run on an embedded system as well. > > > > For a 64-bit kernel it should run the tests both with 32-bit and 64-bit > > applications. > > > > It should also test with both single and multiplanar modes where > > available. > > > > Since vivid emulates CEC as well, it should run CEC tests too. > > > > As core developers we should have an environment where we can easily test > > our patches with this script (I use a VM for that). > > > > I think maintaining the script (or perhaps scripts) in v4l-utils is best > > since that keeps it in sync with the latest kernel and v4l-utils > > developments. > > Makes sense --- and that can be always changed later on if there's a need > to. I wonder whether that would be best going forward, especially if we want to add more tests. Wouldn't a v4l-tests project make sense ? -- Regards, Laurent Pinchart
Re: [RFC] Create test script(s?) for regression testing
Hi Hans, On Tue, Nov 06, 2018 at 09:37:07AM +0100, Hans Verkuil wrote: > Hi all, > > After the media summit (heavy on test discussions) and the V4L2 event > regression > we just found it is clear we need to do a better job with testing. > > All the pieces are in place, so what is needed is to combine it and create a > script that anyone of us as core developers can run to check for regressions. > The same script can be run as part of the kernelci regression testing. I'd say that *some* pieces are in place. Of course, the more there is, the better. The more there are tests, the more important it would be they're automated, preferrably without the developer having to run them on his/her own machine. > > We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last one > is IMHO not quite good enough yet for testing: it is not fully compliant to > the > upcoming stateful codec spec. Work for that is planned as part of an Outreachy > project. > > My idea is to create a script that is maintained as part of v4l-utils that > loads the drivers and runs v4l2-compliance and possibly other tests against > the virtual drivers. How about spending a little time to pick a suitable framework for running the tests? It could be useful to get more informative reports than just pass / fail. Do note that for different hardware the tests would be likely different as well although there are classes of devices for which the exact same tests would be applicable. > > It should be simple to use and require very little in the way of dependencies. > Ideally no dependencies other than what is in v4l-utils so it can easily be > run > on an embedded system as well. > > For a 64-bit kernel it should run the tests both with 32-bit and 64-bit > applications. > > It should also test with both single and multiplanar modes where available. > > Since vivid emulates CEC as well, it should run CEC tests too. > > As core developers we should have an environment where we can easily test > our patches with this script (I use a VM for that). > > I think maintaining the script (or perhaps scripts) in v4l-utils is best since > that keeps it in sync with the latest kernel and v4l-utils developments. Makes sense --- and that can be always changed later on if there's a need to. -- Regards, Sakari Ailus sakari.ai...@linux.intel.com
[RFC] Create test script(s?) for regression testing
Hi all, After the media summit (heavy on test discussions) and the V4L2 event regression we just found it is clear we need to do a better job with testing. All the pieces are in place, so what is needed is to combine it and create a script that anyone of us as core developers can run to check for regressions. The same script can be run as part of the kernelci regression testing. We have four virtual drivers: vivid, vim2m, vimc and vicodec. The last one is IMHO not quite good enough yet for testing: it is not fully compliant to the upcoming stateful codec spec. Work for that is planned as part of an Outreachy project. My idea is to create a script that is maintained as part of v4l-utils that loads the drivers and runs v4l2-compliance and possibly other tests against the virtual drivers. It should be simple to use and require very little in the way of dependencies. Ideally no dependencies other than what is in v4l-utils so it can easily be run on an embedded system as well. For a 64-bit kernel it should run the tests both with 32-bit and 64-bit applications. It should also test with both single and multiplanar modes where available. Since vivid emulates CEC as well, it should run CEC tests too. As core developers we should have an environment where we can easily test our patches with this script (I use a VM for that). I think maintaining the script (or perhaps scripts) in v4l-utils is best since that keeps it in sync with the latest kernel and v4l-utils developments. Comments? Ideas? Regards, Hans
Re: [PATCH] media: rc: self test for IR encoders and decoders
Hi Shuah, On Thu, Nov 01, 2018 at 08:59:39AM -0600, Shuah Khan wrote: > On 10/16/2018 08:09 AM, Sean Young wrote: > > ir-loopback can transmit IR on one rc device and check the correct > > scancode and protocol is decoded on a different rc device. This can be > > used to check IR transmission between two rc devices. Using rc-loopback, > > we use it to check the IR encoders and decoders themselves. > > > > No hardware is required for this test. > > > > Signed-off-by: Sean Young > > Cc: Shuah Khan > > Hi Sean, > > This looks good. I will get this into the next release. It will show > up in linux-kselftest next after 4.20-rc1 comes out. Great, thank you very much. Regards, Sean
Re: [PATCH] media: rc: self test for IR encoders and decoders
On 10/16/2018 08:09 AM, Sean Young wrote: > ir-loopback can transmit IR on one rc device and check the correct > scancode and protocol is decoded on a different rc device. This can be > used to check IR transmission between two rc devices. Using rc-loopback, > we use it to check the IR encoders and decoders themselves. > > No hardware is required for this test. > > Signed-off-by: Sean Young > Cc: Shuah Khan Hi Sean, This looks good. I will get this into the next release. It will show up in linux-kselftest next after 4.20-rc1 comes out. thanks, -- Shuah
Re: RFC: kernelCI media subsystem pilot (Test results for gtucker/kernelci-media - gtucker-kernelci-media-001-6-g1b2c6e5844d8)
On Fri, 2018-10-19 at 09:06 +0200, Hans Verkuil wrote: > On 10/18/2018 09:23 PM, Ezequiel Garcia wrote: > > Hi everyone, > > > > In Collabora, and as part of our kernelci work, we are doing > > research on kernel functional testing with kernelci. > > > > For those new to kernelci, see > > https://github.com/kernelci/kernelci-doc/wiki/KernelCI > > and https://kernelci.org/. > > > > The goal is to lay down the infrastructure required to make > > automated test coverage an integral part of our feature > > and bugfix development process. > > > > So, as a first attempt, we've decided to extend kernelci test > > v4l2 plan support, leading the way to extending > > other subsystems' test plans. > > > > Currently, kernelci looks for a list of branches every hour and > > see if anything changed. For any branch that has changed, it triggers > > builds, boots, tests and reports for each branch that had some changes > > since last time it ran. > > > > For this pilot, we've decided to target just a few devices: > > qemu with vivid, rk3399-gru-kevin and rk3288-veyron-jaq > > with uvc. > > It's running v4l2-compliance, right? > Exactly. > Looking at the test cases, they appear in the reverse order that > v4l2-compliance > performs them, that's a bit odd. > That's something to check in the parser. I'm sure it's fixable if you find it annoying. > And if we include uvc in the testing, then I need to prioritize the work I > started for uvc to remove the last FAILs. > Well, we can run anything. We decided to go for uvc and vivid, just too pick two popular examples, but there are really no restrictions. Thanks, Ezequiel
Re: RFC: kernelCI media subsystem pilot (Test results for gtucker/kernelci-media - gtucker-kernelci-media-001-6-g1b2c6e5844d8)
On 10/18/2018 09:23 PM, Ezequiel Garcia wrote: > Hi everyone, > > In Collabora, and as part of our kernelci work, we are doing > research on kernel functional testing with kernelci. > > For those new to kernelci, see > https://github.com/kernelci/kernelci-doc/wiki/KernelCI > and https://kernelci.org/. > > The goal is to lay down the infrastructure required to make > automated test coverage an integral part of our feature > and bugfix development process. > > So, as a first attempt, we've decided to extend kernelci test > v4l2 plan support, leading the way to extending > other subsystems' test plans. > > Currently, kernelci looks for a list of branches every hour and > see if anything changed. For any branch that has changed, it triggers > builds, boots, tests and reports for each branch that had some changes > since last time it ran. > > For this pilot, we've decided to target just a few devices: > qemu with vivid, rk3399-gru-kevin and rk3288-veyron-jaq > with uvc. It's running v4l2-compliance, right? Looking at the test cases, they appear in the reverse order that v4l2-compliance performs them, that's a bit odd. And if we include uvc in the testing, then I need to prioritize the work I started for uvc to remove the last FAILs. Regards, Hans > > We'd like to get some early feedback on this, so we are sending > an example of how a kernelci report would look like, to trigger > some discussion around > the direction this should take. > > Thanks! > > === > Test results for: > Tree:gtucker > Branch: kernelci-media > Kernel: gtucker-kernelci-media-002-2-gaa27eb0392c7 > URL: https://gitlab.collabora.com/gtucker/linux.git > Commit: aa27eb0392c70adec713e911a9b5267a1d853624 > Test plans: v4l2 > > Summary > --- > 3 test groups results > > 1 | v4l2 | rk3399-gru-kevin | arm64 | 49 total: 17 PASS 4 > FAIL 28 SKIP > 2 | v4l2 | rk3288-veyron-jaq | arm | 49 total: 17 PASS 4 > FAIL 28 SKIP > 3 | v4l2 | qemu | arm64 | 168 total: 102 PASS 0 > FAIL 66 SKIP > > > Tests > - > > 1 | v4l2 | rk3399-gru-kevin | arm64 | 49 total: 17 PASS 4 > FAIL 28 SKIP > > Config: defconfig > Lab Name:lab-collabora-dev > Date:2018-10-18 18:48:52.426000 > TXT log: > http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm64/defconfig/lab-collabora-dev > /v4l2-rk3399-gru-kevin.txt > HTML log: > http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm64/defconfig/lab-collabora-dev > /v4l2-rk3399-gru-kevin.html > Rootfs: > http://staging-storage.kernelci.org/images/rootfs/debian/stretchv4l2/20181017.1//arm64/rootfs.cpio.gz > Test Git:git://linuxtv.org/v4l-utils.git > Test Commit: e889b0d56757b9a74eb8c4c8cc2ebd5b18e228b2 > > > Test cases: > > * MMAP: FAIL > * blocking-wait: PASS > * read/write: SKIP > * read/write: SKIP > * read/write: SKIP > * VIDIOC_EXPBUF: PASS > * VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: PASS > * VIDIOC_TRY_DECODER_CMD: SKIP > * VIDIOC_G_ENC_INDEX: SKIP > * VIDIOC_TRY_ENCODER_CMD: SKIP > * Scaling: SKIP > * Composing: SKIP > * Cropping: SKIP > * VIDIOC_G_SLICED_VBI_CAP: SKIP > * VIDIOC_S_FMT: PASS > * VIDIOC_TRY_FMT: PASS > * VIDIOC_G_FMT: PASS > * VIDIOC_G_FBUF: SKIP > * VIDIOC_G/S_PARM: FAIL > * VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: PASS > * VIDIOC_G/S_JPEGCOMP: SKIP > * VIDIOC_UNSUBSCRIBE_EVENT/DQEVENT: PASS > * VIDIOC_G/S/TRY_EXT_CTRLS: FAIL > * VIDIOC_G/S_CTRL: PASS > * VIDIOC_QUERYCTRL: PASS > * VIDIOC_QUERY_EXT_CTRL/QUERYMENU: FAIL > * VIDIOC_G/S_EDID: SKIP > * VIDIOC_DV_TIMINGS_CAP: SKIP > * VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: SKIP > * VIDIOC_ENUM/G/S/QUERY_STD: SKIP > * VIDIOC_G/S_AUDOUT: SKIP > * VIDIOC_G/S/ENUMOUTPUT: SKIP > * VIDIOC_ENUMAUDOUT: SKIP > * VIDIOC_G/S_FREQUENCY: SKIP > * VIDIOC_G/S_MODULATOR: SKIP > * VIDIOC_G/S_AUDIO: SKIP > * VIDIOC_G/S/ENUMINPUT: PASS > * VIDIOC_ENUMAUDIO: SKIP > * VIDIOC_S_HW_FREQ_SEEK: SKIP > * VIDIOC_G/S_FREQUENCY: SKIP > * VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: SKIP > * VIDIOC_LOG_STATUS: SKIP > * VIDIOC_DBG_G/S_REGISTER: SKIP > * for-unlimited-opens: PASS > * VIDIOC_G/S_PRIORITY: PASS > * VIDIOC_QUERYCAP: PASS > * second-/dev/video0-open: PASS > * VIDIOC_QUERYCAP: PASS > * MC-information-see-Medi
RFC: kernelCI media subsystem pilot (Test results for gtucker/kernelci-media - gtucker-kernelci-media-001-6-g1b2c6e5844d8)
Hi everyone, In Collabora, and as part of our kernelci work, we are doing research on kernel functional testing with kernelci. For those new to kernelci, see https://github.com/kernelci/kernelci-doc/wiki/KernelCI and https://kernelci.org/. The goal is to lay down the infrastructure required to make automated test coverage an integral part of our feature and bugfix development process. So, as a first attempt, we've decided to extend kernelci test v4l2 plan support, leading the way to extending other subsystems' test plans. Currently, kernelci looks for a list of branches every hour and see if anything changed. For any branch that has changed, it triggers builds, boots, tests and reports for each branch that had some changes since last time it ran. For this pilot, we've decided to target just a few devices: qemu with vivid, rk3399-gru-kevin and rk3288-veyron-jaq with uvc. We'd like to get some early feedback on this, so we are sending an example of how a kernelci report would look like, to trigger some discussion around the direction this should take. Thanks! === Test results for: Tree:gtucker Branch: kernelci-media Kernel: gtucker-kernelci-media-002-2-gaa27eb0392c7 URL: https://gitlab.collabora.com/gtucker/linux.git Commit: aa27eb0392c70adec713e911a9b5267a1d853624 Test plans: v4l2 Summary --- 3 test groups results 1 | v4l2 | rk3399-gru-kevin | arm64 | 49 total: 17 PASS 4 FAIL 28 SKIP 2 | v4l2 | rk3288-veyron-jaq | arm | 49 total: 17 PASS 4 FAIL 28 SKIP 3 | v4l2 | qemu | arm64 | 168 total: 102 PASS 0 FAIL 66 SKIP Tests - 1 | v4l2 | rk3399-gru-kevin | arm64 | 49 total: 17 PASS 4 FAIL 28 SKIP Config: defconfig Lab Name:lab-collabora-dev Date:2018-10-18 18:48:52.426000 TXT log: http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm64/defconfig/lab-collabora-dev /v4l2-rk3399-gru-kevin.txt HTML log: http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm64/defconfig/lab-collabora-dev /v4l2-rk3399-gru-kevin.html Rootfs: http://staging-storage.kernelci.org/images/rootfs/debian/stretchv4l2/20181017.1//arm64/rootfs.cpio.gz Test Git:git://linuxtv.org/v4l-utils.git Test Commit: e889b0d56757b9a74eb8c4c8cc2ebd5b18e228b2 Test cases: * MMAP: FAIL * blocking-wait: PASS * read/write: SKIP * read/write: SKIP * read/write: SKIP * VIDIOC_EXPBUF: PASS * VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: PASS * VIDIOC_TRY_DECODER_CMD: SKIP * VIDIOC_G_ENC_INDEX: SKIP * VIDIOC_TRY_ENCODER_CMD: SKIP * Scaling: SKIP * Composing: SKIP * Cropping: SKIP * VIDIOC_G_SLICED_VBI_CAP: SKIP * VIDIOC_S_FMT: PASS * VIDIOC_TRY_FMT: PASS * VIDIOC_G_FMT: PASS * VIDIOC_G_FBUF: SKIP * VIDIOC_G/S_PARM: FAIL * VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: PASS * VIDIOC_G/S_JPEGCOMP: SKIP * VIDIOC_UNSUBSCRIBE_EVENT/DQEVENT: PASS * VIDIOC_G/S/TRY_EXT_CTRLS: FAIL * VIDIOC_G/S_CTRL: PASS * VIDIOC_QUERYCTRL: PASS * VIDIOC_QUERY_EXT_CTRL/QUERYMENU: FAIL * VIDIOC_G/S_EDID: SKIP * VIDIOC_DV_TIMINGS_CAP: SKIP * VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: SKIP * VIDIOC_ENUM/G/S/QUERY_STD: SKIP * VIDIOC_G/S_AUDOUT: SKIP * VIDIOC_G/S/ENUMOUTPUT: SKIP * VIDIOC_ENUMAUDOUT: SKIP * VIDIOC_G/S_FREQUENCY: SKIP * VIDIOC_G/S_MODULATOR: SKIP * VIDIOC_G/S_AUDIO: SKIP * VIDIOC_G/S/ENUMINPUT: PASS * VIDIOC_ENUMAUDIO: SKIP * VIDIOC_S_HW_FREQ_SEEK: SKIP * VIDIOC_G/S_FREQUENCY: SKIP * VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: SKIP * VIDIOC_LOG_STATUS: SKIP * VIDIOC_DBG_G/S_REGISTER: SKIP * for-unlimited-opens: PASS * VIDIOC_G/S_PRIORITY: PASS * VIDIOC_QUERYCAP: PASS * second-/dev/video0-open: PASS * VIDIOC_QUERYCAP: PASS * MC-information-see-Media-Driver-Info-above: PASS 2 | v4l2 | rk3288-veyron-jaq | arm | 49 total: 17 PASS 4 FAIL 28 SKIP Config: multi_v7_defconfig Lab Name:lab-collabora-dev Date:2018-10-18 17:00:41.724000 TXT log: http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm/multi_v7_defconfig/lab-collab ora-dev/v4l2-rk3288-veyron-jaq.txt HTML log: http://staging-storage.kernelci.org/gtucker/kernelci-media/gtucker-kernelci-media-002-2-gaa27eb0392c7/arm/multi_v7_defconfig/lab-collab ora-dev/v4l2-rk3288-veyron-jaq.html Rootfs: http://staging-storage.kernelci.org/images/rootfs/debian/stretchv4l2/20181017.1//armhf/rootfs.cpio.gz Test Git:git://linuxtv.org/v4l-utils.git Test Commit: e889b0d56757b9a74eb8c4c8cc2ebd5b18e228b2 Test cases: * MMAP: FAIL * blocking-wait: PASS * read/write: SKIP * read/write: SKIP * read/write: SKIP * VIDIOC_EXPBUF: PASS
[PATCH] media: rc: self test for IR encoders and decoders
ir-loopback can transmit IR on one rc device and check the correct
scancode and protocol is decoded on a different rc device. This can be
used to check IR transmission between two rc devices. Using rc-loopback,
we use it to check the IR encoders and decoders themselves.
No hardware is required for this test.
Signed-off-by: Sean Young
Cc: Shuah Khan
---
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/ir/.gitignore | 1 +
tools/testing/selftests/ir/Makefile | 5 +
tools/testing/selftests/ir/ir_loopback.c | 199 ++
tools/testing/selftests/ir/ir_loopback.sh | 20 +++
5 files changed, 226 insertions(+)
create mode 100644 tools/testing/selftests/ir/.gitignore
create mode 100644 tools/testing/selftests/ir/Makefile
create mode 100644 tools/testing/selftests/ir/ir_loopback.c
create mode 100755 tools/testing/selftests/ir/ir_loopback.sh
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index f1fe492c8e17..995034ea5546 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -15,6 +15,7 @@ TARGETS += futex
TARGETS += gpio
TARGETS += intel_pstate
TARGETS += ipc
+TARGETS += ir
TARGETS += kcmp
TARGETS += kvm
TARGETS += lib
diff --git a/tools/testing/selftests/ir/.gitignore
b/tools/testing/selftests/ir/.gitignore
new file mode 100644
index ..070ea0c75fb8
--- /dev/null
+++ b/tools/testing/selftests/ir/.gitignore
@@ -0,0 +1 @@
+ir_loopback
diff --git a/tools/testing/selftests/ir/Makefile
b/tools/testing/selftests/ir/Makefile
new file mode 100644
index ..f4ba8eb84b95
--- /dev/null
+++ b/tools/testing/selftests/ir/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0
+TEST_PROGS := ir_loopback.sh
+TEST_GEN_PROGS_EXTENDED := ir_loopback
+
+include ../lib.mk
diff --git a/tools/testing/selftests/ir/ir_loopback.c
b/tools/testing/selftests/ir/ir_loopback.c
new file mode 100644
index ..858c19caf224
--- /dev/null
+++ b/tools/testing/selftests/ir/ir_loopback.c
@@ -0,0 +1,199 @@
+// SPDX-License-Identifier: GPL-2.0
+// test ir decoder
+//
+// Copyright (C) 2018 Sean Young
+
+// When sending LIRC_MODE_SCANCODE, the IR will be encoded. rc-loopback
+// will send this IR to the receiver side, where we try to read the decoded
+// IR. Decoding happens in a separate kernel thread, so we will need to
+// wait until that is scheduled, hence we use poll to check for read
+// readiness.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "../kselftest.h"
+
+#define TEST_SCANCODES 10
+#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]))
+
+static const struct {
+ enum rc_proto proto;
+ const char *name;
+ unsigned int mask;
+ const char *decoder;
+} protocols[] = {
+ { RC_PROTO_RC5, "rc-5", 0x1f7f, "rc-5" },
+ { RC_PROTO_RC5X_20, "rc-5x-20", 0x1f7f3f, "rc-5" },
+ { RC_PROTO_RC5_SZ, "rc-5-sz", 0x2fff, "rc-5-sz" },
+ { RC_PROTO_JVC, "jvc", 0x, "jvc" },
+ { RC_PROTO_SONY12, "sony-12", 0x1f007f, "sony" },
+ { RC_PROTO_SONY15, "sony-15", 0xff007f, "sony" },
+ { RC_PROTO_SONY20, "sony-20", 0x1fff7f, "sony" },
+ { RC_PROTO_NEC, "nec", 0x, "nec" },
+ { RC_PROTO_NECX, "nec-x", 0xff, "nec" },
+ { RC_PROTO_NEC32, "nec-32", 0x, "nec" },
+ { RC_PROTO_SANYO, "sanyo", 0x1f, "sanyo" },
+ { RC_PROTO_RC6_0, "rc-6-0", 0x, "rc-6" },
+ { RC_PROTO_RC6_6A_20, "rc-6-6a-20", 0xf, "rc-6" },
+ { RC_PROTO_RC6_6A_24, "rc-6-6a-24", 0xff, "rc-6" },
+ { RC_PROTO_RC6_6A_32, "rc-6-6a-32", 0x, "rc-6" },
+ { RC_PROTO_RC6_MCE, "rc-6-mce", 0x7fff, "rc-6" },
+ { RC_PROTO_SHARP, "sharp", 0x1fff, "sharp" },
+};
+
+int lirc_open(const char *rc)
+{
+ struct dirent *dent;
+ char buf[100];
+ DIR *d;
+ int fd;
+
+ snprintf(buf, sizeof(buf), "/sys/class/rc/%s", rc);
+
+ d = opendir(buf);
+ if (!d)
+ ksft_exit_fail_msg("cannot open %s: %m\n", buf);
+
+ while ((dent = readdir(d)) != NULL) {
+ if (!strncmp(dent->d_name, "lirc", 4)) {
+ snprintf(buf, sizeof(buf), "/dev/%s", dent->d_name);
+ break;
+ }
+ }
+
+ if (!dent)
+ ksft_exit_fail_msg("cannot find lirc device for %s\n", rc);
+
+ closedir(d);
+
+ fd = open(buf, O_RDWR | O_NONBLOCK);
+ if
Working test 5
Did you get my email from last week? Let me know if you have photos for cutting out or retouching? We are an image team who can do editing for your the web store photos, industry photos or portrait photos. Send photos, we will do testing for you to check quality. Waiting for your reply soon. Thanks, Judy
Working test 3
Did you get my email from last week? Let me know if you have photos for cutting out or retouching? We are an image team who can do editing for your the web store photos, industry photos or portrait photos. Send photos, we will do testing for you to check quality. Waiting for your reply soon. Thanks, Judy
