ChanServ changed the topic of #linux-msm to:
deathmist1 has joined #linux-msm
deathmist has quit [Read error: Connection reset by peer]
zstas has joined #linux-msm
deathmist1 is now known as deathmist
zstas has quit [Ping timeout: 480 seconds]
zstas has joined #linux-msm
zstas has quit [Ping timeout: 480 seconds]
zstas has joined #linux-msm
zstas has quit [Ping timeout: 480 seconds]
<bryanodonoghue> z3ntu is the pixel format the same at the lower res ?
<z3ntu> bryanodonoghue: there's no pixel binning happening in the higher format iirc, in the lower it's 2x2 binnin
<bryanodonoghue> CSIPHY/TPG -> CSID [bus_master_write_completion] -> VFE -> RDIx -> userspace
<bryanodonoghue> likely the CSID and VFE don't agree on the completion size
<bryanodonoghue> also please check the write destination is correct
<bryanodonoghue> let me show you in a link hold on
<bryanodonoghue> port id needs to be programmed correctly
<bryanodonoghue> you can tell from the comment this bite me right in the a..
<bryanodonoghue> so either
<bryanodonoghue> CSID and VFE don't agree on the size
<bryanodonoghue> which sounds likely for you as you change pixel resoltuions
<bryanodonoghue> or potentially they do agree on the size but somehow the destination port is wrong
<bryanodonoghue> what does /proc/interrupts | grep camss show when you are running the stream ?
<bryanodonoghue> you might think about picking up the debugfs patches in that tree and applying them to your scenario
<bryanodonoghue> there are various counters / ISRs which show debug information
<bryanodonoghue> CRC errors on the RX path @ the CSIPHY is possible too
<bryanodonoghue> if you have the wrong clock there
<bryanodonoghue> actually i'd recommend the debugfs stuff
<z3ntu> I remember seeing in the qcom downstream xml that there's the main stream from the cam, the 4096x3072 and a second one for PDAF (probably wrong abbreviation, this auto-focus thingy, 4 letters) with something like 4096x768
<z3ntu> is this related to this destination port thing?
<bryanodonoghue> mmmm
<bryanodonoghue> is it a virtual channel ?
<bryanodonoghue> what exactly are you trying to do ?
<bryanodonoghue> different resoltuion or something else ?
<z3ntu> yes, trying to get higher resolution stream working
<z3ntu> a deeper reason for doing this right now is that for the main cam (the C-PHY one) I only have a higher resolution stream like that and I'm imagining it has a similar problem there
<z3ntu> so xml says it has two streams, one with datatype 10-bit RAW (4096x3072), type IMAGE, and the other one is datatype 0x30 (?) with 4096x768 and type PDAF
<z3ntu> but virtual channel for both is marked as 0
<bryanodonoghue> right so its a sensor mode
<bryanodonoghue> so are you debugging the same sensor in a lower res mode
<bryanodonoghue> or poking at the CPHY ?
<z3ntu> no, so this D-PHY sensor works as lower resolution, but not at the higher resolution
<z3ntu> I'm hoping to figure out this problem so to bringup the other sensor with C-PHY
<z3ntu> bryanodonoghue: vfe interrupt count is going up when trying to capture a frame, the rest is not moving
<z3ntu> when starting the stream there's 3 interrupts from csid
<z3ntu> but so this port ID is just related to non-zero virtual port?
<z3ntu> s/virtual port/virtual channel/
<z3ntu> bryanodonoghue: also is there any plan on getting these debugfs patches upstream? Seems they can be useful quite often
zstas has joined #linux-msm
zstas has quit [Ping timeout: 480 seconds]