On 12/08/2024 15:41, Depeng Shao wrote:
+#define VFE_BUS_WM_CFG(n) (BUS_REG_BASE + 0x200 + (n) * 0x100)
<snip>
+#define RDI_WM(n) ((vfe_is_lite(vfe) ? 0x0 : 0x17) + (n))
+
+static void vfe_wm_start(struct vfe_device *vfe, u8 wm, struct vfe_line *line)
+{
+ struct v4l2_pix_format_mplane *pix =
+ &line->video_out.active_fmt.fmt.pix_mp;
+
+ wm = RDI_WM(wm); /* map to actual WM used (from wm=RDI index) */
OK so one more point here.
The non-lite VFE has I think in the case of sm8550 twenty seven
different bus clients.
The above code takes a given index - take the example of index 0 meaning
RDI0 and
1. Determines if is_lite() is true deriving a jump of 0 or 0x17
2. Uses this index as a further offset to functions such as
VFE_BUS_WM_CFG(n)
3. In no way articulates which bus client is which.
So for a non lite case -> RDI0 is bus client # 23
The code we have for CAMSS just assumes RDI is the only client we are
programming - which I'm not proposing to change for now, however the
code is very not obvious in what it is doing here.
This BTW isn't a criticism of what you've done here but, even though I
have access to the registers in front of me, I had to spend about 30
minutes looking up and verifying these offsets.
That's not sustainable.
Could you please add a comment which details what each index relates to.
/*
* Bus client mapping
*
* 0 = VID_Y ?
* 1 = VID_C
* .. etc
* .. etc
* 23 = RDI0
* 24 = RDI1
*/
I'll try to apply a similar level of index documentation for existing
upstream submissions so that working out client mappings is less tedious
and will be requiring these mappings for new VFE silicon enabling code
upstream.
---
bod
