On 2022-07-11 12:04, Piotr Oniszczuk wrote:
Wiadomość napisana przez Robin Murphy <robin.mur...@arm.com> w dniu 11.07.2022,
o godz. 12:41:
On 2022-06-25 16:31, Piotr Oniszczuk wrote:
Wiadomość napisana przez Peter Geis <pgwipe...@gmail.com> w dniu 25.06.2022, o
godz. 16:00:
The first issue you have is the TV isn't responding until the absolute
end.
I suspect this is because lack on idle gaps between cec commands sent from
board to tv.
Maybe TV sw. can't deal with consecutive commands without any idle between them?
It is interesting that disconnecting TV - so CEC line is driven only by board -
rock3a still don't have any idle gaps while rock3b (and radxa 4.19 bsp) has
them (very similar between 5.18mailine and 4.19 bsp).
How this is possible that change I/O from m0->m1 impacts _timings_ on free
hanging CEC line?
Check all the pinctrl settings beyond just the function mux - pulls, drive
strength, output type, etc. - the defaults tend to be all over the place, and
rarely what you want.
Robin.
Robin,
I'm not sure do I looked in right place...
but:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi?h=v5.18.10#n788
vs.
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-pinctrl.dtsi?h=v5.18.10#n795
are looking ok?
I meant more in terms of dumping out the actual hardware state to
compare across both axes of cec_m0 vs. cec_m1 and mainline vs. BSP.
However from a quick skim of the Rock3 schematic there doesn't appear to
be an external pull-up, so the internal pull-up also being disabled is a
clear suspect to start with.
Robin.
