Re: [PATCH v8 1/3] media: qcom: camss: Add common TPG support
From: Vladimir Zapolskiy
Date: Fri Jan 16 2026 - 04:24:55 EST
On 1/15/26 17:54, Bryan O'Donoghue wrote:
On 15/01/2026 02:58, Vladimir Zapolskiy wrote:
Writing proper values to registers should be a concern on the driver
level,
it sounds improper to push this simple task and responsibility to
userspace.
I think we should stick to the same format as is already upstream for
the CSID version of this - which is the same data.
It is not the same and it will not be the same, if the currently presented
version is taken. If TPG modes in CSID are continuous, here they are not,
so it makes a big difference for userspace, and better it should be
removed.
Not sure I follow you here.
The set of strings for camss-csid we have now is:
const char * const csid_testgen_modes[] = {
"Disabled",
"Incrementing",
"Alternating 0x55/0xAA",
"All Zeros 0x00",
"All Ones 0xFF",
"Pseudo-random Data",
"User Specified",
"Complex pattern",
"Color box",
"Color bars",
NULL
};
Wengmeng has
+const char * const testgen_payload_modes[] = {
+ "Disabled",
+ "Incrementing",
+ "Alternating 0x55/0xAA",
+ "Reserved",
+ "Reserved",
+ "Pseudo-random Data",
+ "User Specified",
+ "Reserved",
+ "Reserved",
+ "Color bars",
+ "Reserved"
+};
I think the "Reserved" should go away but, other than that we should
That's what I've asked, there is no dispute.
keep namespace consistency between CSID-TPG and standalone-TPG.
When "consistency" is not defined, it's just a fine sounding buzzword.
CSID TPG has:
* modes, which numbers are continuously incremented,
* the number of TPG modes for a user is expectedly the number of TPG modes.
The displayed v8 of the "standalone TPG" broke both assumptions from above,
so there is no more "consistency" between two TPGs, while I explicitly ask
to preserve the "consistency".
--
Best wishes,
Vladimir