Hacker News Reader

Comment by megous | Hacker News Reader

The Pinephone Pro ISP is documented in RK3399 TRM (part3), and in various PDFs available online. It's not really a huge blackbox.

It does not make the calibration (or preparation of profiles for various light conditions) easy though. There's a need for a bunch of HW tooling that is somewhat expensive for a hobbyist. And there's a lot of work and algorithm design that needs to be done outside of ISP for controling the autofocus, autoexpsoure and detection of type lighting in the scene and profile switching. None of this is particularly trivial.

View on HN

It's registers are documented yes, but from the point of how it actually works. How data flows, how it is buffered internally, how it is timed etc it is absolute mystery. Yes, you can configure various parameters, but you can't for example skip functional blocks and get data quicker. It is unknown if it is all done with hardcoded static logic blocks, some sort of purpose made vector cpu and firmware. No one knows(or those that do don't say).

I worked with rk3566, but I believe rk3399 has the earlier version of the exact same isp. The version in rk3566 is 1.1. There are also versions 1.0 and just 1. All are documented in TRMs in the same way.

Edit: BTW, if you need the tooling (Rockchips isp profile development tool v2.1 and the manual for it) please let me know and I'll send it to you.

> Edit: BTW, if you need the tooling (Rockchips isp profile development tool v2.1 and the manual for it) please let me know and I'll send it to you.

It's not usable for RK3399 version of the ISP. BTW the same/very similar ISP (to RK3399) is used in NXP SoC, and it has documentation there, too. (NXP docs tend to be better ;))

It's very clear he is talking about black boxes from the perspective of one trying to reverse one to fix pinephones isp...

Respectfully, the person you are responding to knows what he is talking about: https://xnux.eu/log/

So they write a bunch of drivers and stuff for pine phone. As a pine fan I thank them, but this doesn't mean we can't have a difference in opinion what does it mean for some component to be a black box.

If you compare with some other manufacturer that gives us absolutely no docs, then yes having register level docs and user side source is really nice. But if you want to do something unconventional (like switch the whole damn thing off and bypass its latency) not knowing how it works internally is still a black box. For example there is an irq that fires when the first component of the isp(MI-memory interface) sees a vsync signal for a frame. We know it exists. We know how to enable/disable that irq. We can write code that does stuff when it fires. But what we don't know is is this vsync signal fired truly at the input of the ISP? It's output? Or perhaps between some specific components? It turns out that vsync fires not when the isp sees the very first vsync what the location of the registers suggests, but after all the processing is done at the output buffer (40ms later usually), but one wouldn't be able to tell without a lot of profiling. This amongst other things is what I call a black box.

However, compare it with let's say a raspberry pi, and at register level the documentation is much better (for the isp).

https://megous.com/dl/tmp/3add845b7e814de9.png

There are bunch of interrupt statuses around frame capture: RIS_FRAME_IN, RIS_FRAME, RIS_V_START.

Not sure why you'd decide to use V_START for deciding when the frame is in memory. VSYNC start is sent at the start of a frame and it's documented as just a interrupt that is directly triggered from the MIPI CSI sync signal in the datasheet.

quote: "The incoming hsync and vsync control signals from the camera are connected to interrupt logic. It is possible to trigger on these signals for an event triggered configuration during processing."

Parts of the ISP are blackboxes (debayer), other parts are quite trivial and documented in a bit more detail (gamma/degamma, BLC, color matrix transformation, etc.) and some parts are a bit of a mix.

The documentation is spread over many PDFs, incl. from different venors who use the same ISP like NXP, who tend to document things in a bit more detail.

So at worst, it's a gray box. ;)

Reply on news.ycombinator.com