Re: [PATCH v3 0/7] Add AMD ISP4 driver

["Du, Bin" <bin.du@amd.com>]

Hi,

On 9/10/2025 10:15 AM, Du, Bin wrote:
> Hi Shengyu,
> 
> On 9/7/2025 2:40 AM, Shengyu Qu wrote:
>> Hi,
>>
>>
>>> Changes v2 -> v3:
>>>
>>> - All the dependent patches in other modules (drm/amd/amdgpu, 
>>> platform/x86, pinctrl/amd) merged on upstream mainline kernel 
>>> (https://github.com/torvalds/linux) v6.17.
>>> - Removed usage of amdgpu structs in ISP driver. Added helper 
>>> functions in amdgpu accepting opaque params from ISP driver to 
>>> allocate and release ISP GART buffers.
>>> - Moved sensor and MIPI phy control entirely into ISP FW instead of 
>>> the previous hybrid approach controlling sensor from both FW and x86 
>>> (sensor driver).
>>> - Removed phy configuration and sensor binding as x86 (sensor driver) 
>>> had relinquished the sensor control for ISP FW. With this approach 
>>> the driver will be exposed as web camera like interface.
>>> - New FW with built-in sensor driver is submitted on upstream linux- 
>>> firmware repo (https://gitlab.com/kernel-firmware/linux-firmware/).
>>
>>
>> The sensor is MIPI CSI and controlled by I2C, isn't it? Then why we 
>> put all control logic into FW rather than driver? Any existing CSI 
>> camera ISP support implementation are not doing this by FW.
>>
> 
> Yes, it's MIPI CSI sensor and controlled by I2C. In AMD ISP 3A algo 
> architecture, part of the sensor control resides in the FW and in 
> previous version, sensor init control is put in the sensor driver. With 
> discussion with the V4L2 maintainer, the current approach starting from 
> V3 is to move all sensor control into FW and remove the sensor driver 
> dependency. Please refer to https://lore.kernel.org/all/63949b3b- 
> ca2d-42aa-bc8d-43f2952d307a@amd.com/#t which provides the context and 
> background on how we arrived at the current architectural change in v3.
> 

Also quote the comments from Laurent Pinchart in 
https://lore.kernel.org/all/20250812134222.GN30054@pendragon.ideasonboard.com/ 
"Exposing the camera sensor to both the firmware and the host 
concurrently is asking for trouble. If you really want to abstract the 
camera behind a firmware and only expose a webcam-like API (or not even 
that in this version, as the driver exposes no control as far as I can 
see), then you should push the whole sensor handling to the firmware 
too. In my opinion that would not be a good solution compared to 
exposing the ISP to the host, but it would be better than this hybrid 
model." Many thanks Laurent Pinchart and Sakari Ailus for the arch 
change guide.

>> Cheers,
>> Shengyu
> 

-- 
Regards,
Bin