| Message ID | 20220522162802.208275-1-luca@z3ntu.xyz |
|---|---|
| Headers | show |
| Series | CAMSS support for MSM8974 | expand |
On 22/05/2022 18:27, Luca Weiss wrote: > Add the compatible for the CCI found in MSM8974 which supports two I2C > masters. > > Signed-off-by: Luca Weiss <luca@z3ntu.xyz> > --- > Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt | 7 ++++--- > 1 file changed, 4 insertions(+), 3 deletions(-) > Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Best regards, Krzysztof
On 22/05/2022 19:27, Luca Weiss wrote: > This RFC series adds support for CAMSS and CCI that are found on > msm8974, including the OV8865 found on the FP2. > > The only reason it's marked RFC is that CAMSS doesn't behave properly on > this SoC without the last commit which is obviously not upstreamable. > Not sure if this should be a blocker for including most of the other > patches because other than that it seems to work fine and I can get a > picture from the camera sensor. When/if msm8974 gets IOMMU support I > hope this should be resolved and it works without this hack. > > I think at least the CCI patches could get applied as they're not > dependent on the CAMSS hack? I'd also vote for the camcc patches to be applied. As for the camss, I'd suggest to get them verified to work properly with a hacked/non-upstreamable/etc. IOMMU driver if one exists. Otherwise we can easily get into a situation where we merge up code that contains bugs itself. Another option might be to actually check whether the device has an IOMMU attached (see device_iommu_mapped()) and to select whether the driver should use SG or CONTIG depending on that. As an additional note regarding the offset issue you've mentioned. It looks like there is an issue with the swiotlb. On the IFC6410 (apq8064, no IOMMU) I got an issue with the PCI-attached networking card. Received packets are offset by 4 (IIRC) bytes. The same type of adapter works on db820c (apq8096, working IOMMU). What kind of issues did you observe with the camss? If it looks like the issue I had, it might be a symptom of a more generic issue. > > Luca Weiss (5): > dt-bindings: i2c: qcom-cci: add QCOM MSM8974 compatible > ARM: dts: qcom: msm8974: add CCI bus > ARM: dts: qcom: msm8974: add CAMSS node > ARM: dts: qcom: msm8974-FP2: Add OV8865 rear camera > [DNM] media: camss: hacks for MSM8974 > > Matti Lehtimäki (9): > media: dt-bindings: media: camss: Add qcom,msm8974-camss binding > media: camss: Add CAMSS_8x74 camss version > media: camss: vfe: Add support for 8x74 > media: camss: video: Add support for 8x74 > media: camss: csid: Add support for 8x74 > media: camss: ispif: Add support for 8x74 > media: camss: csiphy: Add support for 8x74 > media: camss: Add 8x74 resources > i2c: qcom-cci: add msm8974 compatible > > .../devicetree/bindings/i2c/i2c-qcom-cci.txt | 7 +- > .../bindings/media/qcom,msm8974-camss.yaml | 321 ++++++++++++++++++ > arch/arm/boot/dts/qcom-msm8974.dtsi | 184 ++++++++++ > .../dts/qcom-msm8974pro-fairphone-fp2.dts | 70 ++++ > drivers/i2c/busses/i2c-qcom-cci.c | 35 ++ > drivers/media/platform/qcom/camss/Kconfig | 4 +- > .../media/platform/qcom/camss/camss-csid.c | 3 +- > .../media/platform/qcom/camss/camss-csiphy.c | 4 +- > .../media/platform/qcom/camss/camss-ispif.c | 5 +- > drivers/media/platform/qcom/camss/camss-vfe.c | 7 +- > .../media/platform/qcom/camss/camss-video.c | 17 +- > drivers/media/platform/qcom/camss/camss.c | 161 +++++++++ > drivers/media/platform/qcom/camss/camss.h | 1 + > 13 files changed, 801 insertions(+), 18 deletions(-) > create mode 100644 Documentation/devicetree/bindings/media/qcom,msm8974-camss.yaml >
On Mon, May 23, 2022 at 03:39:53PM +0300, Dmitry Baryshkov wrote: > On 22/05/2022 19:27, Luca Weiss wrote: > > This RFC series adds support for CAMSS and CCI that are found on > > msm8974, including the OV8865 found on the FP2. > > > > The only reason it's marked RFC is that CAMSS doesn't behave properly on > > this SoC without the last commit which is obviously not upstreamable. > > Not sure if this should be a blocker for including most of the other > > patches because other than that it seems to work fine and I can get a > > picture from the camera sensor. When/if msm8974 gets IOMMU support I > > hope this should be resolved and it works without this hack. > > > > I think at least the CCI patches could get applied as they're not > > dependent on the CAMSS hack? > > I'd also vote for the camcc patches to be applied. > > As for the camss, I'd suggest to get them verified to work properly with a > hacked/non-upstreamable/etc. IOMMU driver if one exists. Otherwise we can > easily get into a situation where we merge up code that contains bugs > itself. Last I checked, there's no IOMMU driver for msm8974 that works with an upstream kernel at the moment. About 2 years ago, I took a stab at attempting to enable IOMMU for the display and ran into some issues that I documented at: https://lore.kernel.org/lkml/20200109002606.35653-1-masneyb@onstation.org/ I'm not familiar with this part of the hardware and haven't had time since then to look into this further. Brian