LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Embedded & Single-board computer (https://www.linuxquestions.org/questions/linux-embedded-and-single-board-computer-78/)
-   -   Issue with device driver initialization and a question on devicetree reg property syntax. (https://www.linuxquestions.org/questions/linux-embedded-and-single-board-computer-78/issue-with-device-driver-initialization-and-a-question-on-devicetree-reg-property-syntax-4175716031/)

Luk 08-24-2022 11:13 AM

Issue with device driver initialization and a question on devicetree reg property syntax.
 
Hi,

I'm having a weird problem running Linux (Kernel 4.19) on a Rockchip RK3566 based Pine64 boards (Soquartz and Quartz64-A - both). I partially wrote the device tree file myself , other parts were lifted from similar devices so I expect some errors to be present.

Specifically I'm getting an error like this during ISP (a camera image processing chip) driver initialization:
Code:

[    0.905435] iommu: Adding device fdff0000.rkisp to group 7
[    0.905494] rkisp_hw fdff0000.rkisp: Linked as a consumer to fdff1a00.iommu
[    0.905699] rkisp_hw fdff0000.rkisp: is_thunderboot: 0
[    0.905733] rkisp_hw fdff0000.rkisp: max input:0x0@0fps
[    0.905774] rkisp_hw fdff0000.rkisp: can't request region for resource [mem 0xfdff0000-0xfdff5fff

This is the relevant part of the devicetree:
Code:

rkisp: rkisp@fdff0000 {
                compatible = "rockchip,rk3568-rkisp";
                reg = <0x0 0xfdff0000 0x0 0xFFFF>;
                interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
                            <GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH>,
                            <GIC_SPI 60 IRQ_TYPE_LEVEL_HIGH>;
                interrupt-names = "mipi_irq", "mi_irq", "isp_irq";
                clocks = <&cru ACLK_ISP>, <&cru HCLK_ISP>, <&cru CLK_ISP>;
                clock-names = "aclk_isp", "hclk_isp", "clk_isp";
                resets = <&cru SRST_ISP>, <&cru SRST_H_ISP>;
                reset-names = "isp", "isp-h";
                rockchip,grf = <&grf>;
                power-domains = <&power RK3568_PD_VI>;
                iommus = <&rkisp_mmu>;
                rockchip,iq-feature = /bits/ 64 <0x3FBFFFE67FF>;
                status = "disabled";
        };

I would like to mention that I have the RK3566 chip documentation and the the memory region specified is correct. I used to have exact same error with another component (rkcif). However despite the fact the manufacturer's TRM says both rkcif and rkisp use entire 64kb at their respective addresses I noticed rkcif actually uses registers below 0x800 and then its iommu starts at 0x800 so I changed the devicetree reg line for rkcif to only give it 0x800 of memory. This made the error go away and the device appeared to work fine.

However, the same "trick" doesn't work for rkisp. First, it is a very complex component and it actually uses registers that go up to 0x5700. So I tried to change the line to give it 0x6000 range, but this didn't help.

Additionally I would like to ask, why is it that we have 4 numbers on the reg property line? If this line specifies an address and a region length, why are there 4 numbers? Like this:
Code:

reg = <0x0 0xfdff0000 0x0 0xFFFF>;
BTW. despite the error, the rkisp device appears to be working, but I'm experiencing some unexplained delays so I'm trying to fix this to exclude it as a possible source of those delays.

If someone has some ideas or can shed some light on the above, that would be great.

blue_z 08-25-2022 01:32 PM

Quote:

Originally Posted by Luk (Post 6375879)
This is the relevant part of the devicetree:
...

Is that really all of the relevant parts for that node?
What you posted still has the status as disabled, meaning the device driver will not be initialized!



Quote:

Originally Posted by Luk (Post 6375879)
Additionally I would like to ask, why is it that we have 4 numbers on the reg property line? If this line specifies an address and a region length, why are there 4 numbers?

Each number is a <u32> cell.
The number of <u32> cells for the address in the reg property is specified by the #address-cells property in the parent node (or the default value is 2).
The number of <u32> cells for the length in the reg property is specified by the #size-cells property in the parent node (or the default value is 1).

Regards

Luk 08-27-2022 01:11 AM

Quote:

Originally Posted by blue_z (Post 6376087)
Is that really all of the relevant parts for that node?
What you posted still has the status as disabled, meaning the device driver will not be initialized!


Thank you for the reply. Yes, you're right this is set to disabled. In the file that includes this one it simply has one line enabling the device (status="okay"). So I thought it was the only relevant part.

The parent node has only one property:
compatible="rockchip, rk3568"

And both address-cells and size-cells are commented out.

Quote:

Originally Posted by blue_z (Post 6376087)
Each number is a <u32> cell.
The number of <u32> cells for the address in the reg property is specified by the #address-cells property in the parent node (or the default value is 2).
The number of <u32> cells for the length in the reg property is specified by the #size-cells property in the parent node (or the default value is 1).

Regards

Ok, so in simple terms each value is specified as a pair of numbers. Taking the address pair represented in binary the zero would form the most significant 32 bits and the 0xfdff0000 the least significant 32 bits. Thanks for explaining.

However both address-size and size-cells are commented out. So if indeed the defaults are:
Code:

address-cells=2
size-cells=1

Then the second pair of numbers (0x00 0xffff) should be just one number, but there are lots of other devices with 4 number entries like this in the same parent that have the size specifies as 0x00 0xSomeNumber that work fine. So size-cells has to be set to 2 somewhere else I'm not seeing.

So this answers well my <reg> format question, but it still leaves the reason for the error message as an unknown.


All times are GMT -5. The time now is 06:30 PM.