Camera杂记（碎碎念）

1.linux磁盘查看挂在的路径

 

我们电脑安装Ubuntu的系统时，感觉内存不够。就会新加一些内存存，但是我们又不确定文件是否放到我们的安装的内存当中。在linux环境下一切皆文件，所以我们增加的内存在linux系统中也是以文件的形式存放的。所以我们能找到磁盘对应的文件就找到了磁盘的位置。（至于磁盘怎么分区初始化这些我没有实际操作过，所以我也不会，以后有机会实操一下）

我们只需要执行一个：lsblk

lsblk命令默认情况下将以树状列出所有块设备。

 “ lsblk可以看成是“List block device”的缩写,即列为出所有存储设备。

最上面有一些属性：

NAME：块设备名

MAJ:MIN：主要和次要设备号

RM：显示可移动设备。0表示非移动设备，1表示可移动设备

SIZE：块设备的空间大小

RO：是否只读，0表示非只读，1表示只读

TYPE：块设备类型，比如disk磁盘，part分区，lvm逻辑卷，rom只读存储

MOUNTPOINT：设备挂载点

还有一个命令可以查看当前总内存以及剩余的内存

df -h

其实可以看出来跟上面的展示的差不都，但是显示出来还可以使用的内存容量。

2.linux查看当前文件及子文件夹占用的内存

du . -sh

可以看出来当前这个文件夹总共占用的内存是406G 

3.Android刷image的命令

adb reboot bootloader

fastboot flash boot boot.img

4.在pipeline中怎么对各个node输出的size进行设置。

背景：想验证一下IFE和IPE的裁剪之后对效果的影响

修改前：

 

修改后：

在confugure_stream的时候会stream的size就是最后target的size。其实一条pipeline中影响size的因素主要就是两个，一个是选择sensor mode，这个会影响sensor出图的size，另外一个就是配流的时候，下发的target的stream size，这条pipeline的最终输出的size。在配流过程当中会从后往前推对应的size，如果中间没有什么变故的话，这个size会一直往前传，传到IFE的输出这里，然后IFE进行裁剪。IPE也可以进行裁剪，但是IFE和IPE内部的功能模块不一样，所以对应不同的size，进行处理之后效果肯定会有些不一样。

每个node都会调用这个函数设置每个node的输出size，两个link在一起的node，前一个node的输出的size，就是后面那个node的输入的size。

InitializeSinkPortBufferProperties 

 这里面要详细的看一下，因为这个分为两种情况，一个是改变最后输出的size，还有一种要从中间改变size上图中因为这个IPE后面连的是Target，所以这是一个sink port。中间还有相连的不是sink，是直接获取到这个值之后直接往前推导，导致这个node到sensor以前的都是这个size。总结起来一句话就是修改pipeline最后输出的size就修改这里。因为上图中修改的地方不是最后configure_stream最终输出的targat的地方，所以是没有冲突的。后面还有一段逻辑是把size传递给前一个node的逻辑，在哪里修改就可以实现上图中的pipeline的需求。IFE也输出FULL size，最后在IPE进行裁剪。

最后的结果就是IFE corp之后的图片FOV和清晰度这些都会好一些。后续原因需要了解IFE内部的模块了。

5.关于IFE和IFE-Lite

如果sensor尺寸太大，超出IFE的处理数据量，就会用两个IFE同时处理一个sensor，在UMD中一个realtime pipeline只有一个IFE node， kmd ife hw mgr context会用两个IFE硬件与之对应,是否启用两个IFE DualIFEUtils::EvaluateDualIFEMode这个函数内部会根据一些size的限制来判断是否需要启用两个IFE处理。

在手机的这个路径下可以看到当前的设备使能了几个IFE和IFE-Lite

UC-SB2-CAM-A-F074E442F96B:/sys/bus/platform/drivers/cam_vfe # ls
acb4000.qcom,ife0 acc3000.qcom,ife1 acd9000.qcom,ife-lite0 acdb200.qcom,ife-lite1 acdd400.qcom,ife-lite2 acdf600.qcom,ife-lite3 ace1800.qcom,ife-lite4 uevent

cat /proc/interrupts

可以通过查看这个结点，有几个ife和ife lite产生了中断，就能知道当前场景使用了几个ife和ife lite 

在dtsi中把IFE屏蔽掉，只使能IFE Lite。  cam_vfe1 and cam_csid1 status = "disabled"

rdi不过isp，一般是从ife lite直接出 平台一个ife支持多少ife lite要看datasheet哈

rdi的port也不一定用的就是IFE-Lite

6.HDMI Virtual Sensor（可以实现投屏）

这块我其实还是不太明白，但是有这个应用的场景，我就简单的介绍一下，就当留个钩子了，以后万一我用到了呢。

简单的原理就是有一个芯片可以把它当作一颗sensor来点亮。点亮之后投屏显示的数据就跟平时sensor采集的数据一样这个整体当作一颗sensor，然后就是一个普通的Preview流程，在HAL这块有对应的so，bin这些文件。底层走的也是camera驱动的框架，但是跟camera又有些差异，有一个专门的文件夹来操作HDMI这些cam_hdmi_bdg这个路径下。在camxhal3module.cpp文件中hotPlugThreadLoop函数中还有一些逻辑的修改。这个好像在IOT中特有的。

pipeline name:PreviewYUVSensor

7.V4L2的节点的命名规则在哪里指定的

我当时一直好奇为什么V4L2的设备为什么命名都是有规律的，我查了一下资料结点的注册是在设备被注册的时候，对应的名字也是当成一个参数传递进去的后面还有对应的一些数字的代号，就是每个设备都分了类别，然后存放在一个统一的结构体中，在注册的时候会把这些name_base+对应的下标然后去命名的。后来不停的追代码的流程发现是在camera驱动中会去调用V4L2的接口，好像对V4L2有了新的了解个认识。里面还有好多V4L2相关的结构体都是嵌入到对应的设备当中。camera的驱动结构好像就是按照这种V4L2的这种主设备子设备的这种框架来写的。这都是我的一面之词。

文件名：v4l2-dev.c