stikonas has quit [Remote host closed the connection]
kaspter has joined #linux-rockchip
kaspter has quit [Excess Flood]
kaspter has joined #linux-rockchip
camus has joined #linux-rockchip
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
kevery has quit [Quit: kevery]
ganbold has joined #linux-rockchip
WoC has quit [Remote host closed the connection]
anarsoul|c has joined #linux-rockchip
WoC has joined #linux-rockchip
mx08 has quit [*.net *.split]
mx08 has joined #linux-rockchip
alpernebbi has joined #linux-rockchip
vstehle has joined #linux-rockchip
mriesch has joined #linux-rockchip
mriesch has quit [Client Quit]
lkcl has quit [Ping timeout: 240 seconds]
lkcl has joined #linux-rockchip
apritzel has joined #linux-rockchip
apritzel has quit [Ping timeout: 240 seconds]
chewitt has quit [Quit: Adios!]
unkraut has joined #linux-rockchip
camus has joined #linux-rockchip
kaspter has quit [Ping timeout: 268 seconds]
camus is now known as kaspter
mriesch has joined #linux-rockchip
ldevulder has joined #linux-rockchip
<mriesch>
does anyone know how the versioning of the rockchip isp's works? will the most recent versions (in the rk356x chips, for example) be backwards compatible?
apritzel has joined #linux-rockchip
lkcl has quit [Ping timeout: 240 seconds]
matthias_bgg has joined #linux-rockchip
lkcl has joined #linux-rockchip
stikonas has joined #linux-rockchip
macc24 has joined #linux-rockchip
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-rockchip
camus has joined #linux-rockchip
kaspter has quit [Remote host closed the connection]
camus is now known as kaspter
robmur01 has joined #linux-rockchip
chewitt has joined #linux-rockchip
field^Mop has joined #linux-rockchip
warpme_ has joined #linux-rockchip
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #linux-rockchip
ldevulder_ has joined #linux-rockchip
ldevulder has quit [Ping timeout: 240 seconds]
ldevulder_ is now known as ldevulder
matthias_bgg has quit [Ping timeout: 252 seconds]
matthias_bgg has joined #linux-rockchip
kaspter has quit [Ping timeout: 252 seconds]
kaspter has joined #linux-rockchip
macromorgan has joined #linux-rockchip
matthias_bgg has quit [Ping timeout: 240 seconds]
WoC has quit [Remote host closed the connection]
WoC has joined #linux-rockchip
superherointj has joined #linux-rockchip
<mmind00>
mriesch: probably not ... i.e. the versioning denotes evolution steps of the ip block ... and from what I gathered from looking at the sources (and TRM) the changes are quite big from v1.x (up to px30/rk3326) to v2.x (rk3566 and probably following)
camus has joined #linux-rockchip
<mmind00>
so we'll need a bit of engineering for the v2.x to be usable on mainline
kaspter has quit [Ping timeout: 240 seconds]
camus is now known as kaspter
<mriesch>
mmind00: ok, that is what we feared. but thanks for the info, at least we are aware that there are troubles ahead.
<mriesch>
are there any ongoing or planned efforts to provide rkisp2 mainline support that we could join?
<mmind00>
mriesch: rk3566/rk3568 upstreaming is in its infancy right now (clocks, pinctrl) ... so I'm not sure how many people have already thought so far ahead ;-)
<mmind00>
mriesch: joining #libcamera and asking there could be helpful though
<mriesch>
mmind00: so the usual suspects are hiding out there? ;-)
<mmind00>
mriesch: yep :-D ... #libcamera and #v4l
<mriesch>
ok, then i'll cross-post the question there in a while -- maybe give the people some time to unwrap their eval kits
<mriesch>
as to the elementary mainlining efforts, i think i can offer some testing on a rk3568 eval kit. i might need some initial guidance, though
<mriesch>
mmind00: does the current for-next already produce something bootable?
<mmind00>
mriesch: nope
<mmind00>
mriesch: I also do have a rk3566-based board here, but haven't had too much time yet and -next right now only contains clock controller and half of pinctrl/gpio support
<mmind00>
mriesch: if you have contact with Rockchip (sales/developer)-people make sure to tell them very loudly that you want/need/require mainline support for your project :-D
<mmind00>
sales-people can be very accomodating when they smell business :-)
<mriesch>
can do. i actually need mainline support in my job and i like to be a pushy customer in private. so why not combine those two ;-)
<mmind00>
mriesch: also in a lot of cases developer resources are allocated by demands from sales ... see Google-ChromeOS projects ... so if everybody complains loud enough about needing mainline for the Rockchip-based projects they will shift focus as least a bit
matthias_bgg has joined #linux-rockchip
amstan has joined #linux-rockchip
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #linux-rockchip
mriesch has quit [Quit: mriesch]
mriesch has joined #linux-rockchip
mriesch has quit [Ping timeout: 240 seconds]
mriesch has joined #linux-rockchip
mriesch has quit [Quit: Quit]
camus has joined #linux-rockchip
kaspter has quit [Ping timeout: 252 seconds]
camus is now known as kaspter
matthias_bgg has quit [Ping timeout: 260 seconds]
kaspter has quit [Ping timeout: 240 seconds]
kaspter has joined #linux-rockchip
matthias_bgg has joined #linux-rockchip
apritzel has quit [Ping timeout: 240 seconds]
einthecorgi2 has joined #linux-rockchip
<einthecorgi2>
Hello, I was wondering if it would be okay for me to ask here about some issue I am seeing with the isp1 on the 3399.
<amstan>
einthecorgi2: \o
<amstan>
einthecorgi2: it's customary to just ask your question
field^Mop has quit [Ping timeout: 240 seconds]
<einthecorgi2>
I am working on an RK3399 and am having some trouble correctly allocating the clocks for ISP1. I am trying to get the CSI1 Interface running correctly. Device tree is correct based on review of a couple patches. 'rkisp1 ff920000.isp1: Failed to get clk 'clk_isp': -`
<einthecorgi2>
the clock is defined in the dt-bindings and DTC does not have any complaints about this when compiling. So far it seems like the parent connection is incorrect for isp1.
<amstan>
einthecorgi2: can you also paste the relevant snippet (or maybe all if not too secret) from your device tree
<amstan>
if i understand this right, your isp1 handle is missing/not liking your clk_isp reference
<einthecorgi2>
this is a reference from isp0, isp1 is not in mainline dt
<amstan>
but it's the same driver for isp0, right (at least that's what the compatible tells me)? so i'm surprised upstream driver doesn't like what's already in upstream dts (the "isp" without the clk_)
<einthecorgi2>
Progress! I changed all three clocks and now it is complaining about the ` rkisp1 ff920000.isp1: Failed to get clk 'aclk_isp_wrap': -2`
<einthecorgi2>
Sorry I am on 5.10, from the Armbian guys, im poking through their patches as well. It looks like they may have made some patches on isp1 as well.
<amstan>
seems like there's been changes there, you should standardize on one kernel (instead of taking an older kernel with a newer dts), perferrably on upstream since it might be more up to date