[6/7] ARM: bcm2835: Add the DDC I2C controller to the device tree.
diff mbox

Message ID 1439427380-2436-7-git-send-email-eric@anholt.net
State New
Headers show

Commit Message

Eric Anholt Aug. 13, 2015, 12:56 a.m. UTC
We need to use it for getting video modes over HDMI.

Signed-off-by: Eric Anholt <eric@anholt.net>
---
 arch/arm/boot/dts/bcm2835.dtsi | 9 +++++++++
 1 file changed, 9 insertions(+)

Comments

Stephen Warren Aug. 15, 2015, 4:51 a.m. UTC | #1
On 08/12/2015 06:56 PM, Eric Anholt wrote:
> We need to use it for getting video modes over HDMI.

> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi

> +		i2c2: i2c@7e805000 {
> +			compatible = "brcm,bcm2835-i2c";
> +			reg = <0x7e805000 0x1000>;
> +			interrupts = <2 21>;
> +			clocks = <&clk_i2c>;
> +			#address-cells = <1>;
> +			#size-cells = <0>;
> +		};

In an SoC .dtsi file, you'd typically write:

	status = "disabled";

... in all nodes that represent IO controllers that interface to
external HW, so that board DT files can/must explicitly choose to enable
the device if it's actually in use on the board. Some systems might not
have HDMI and hence might not hook up the HDMI_SCL/SDA pads.

BCM2835-ARM-Peripherals.pdf states "Note that the BSC2 master is used
dedicated with the HDMI interface and should not be accessed by user
programs.". Does this imply the Linux kernel shouldn't be touching this
I2C controller; that the VC4 firmware might also be attempting to use
it? I wonder how any such sharing of the HW would work.
Eric Anholt Aug. 17, 2015, 6:35 p.m. UTC | #2
Stephen Warren <swarren@wwwdotorg.org> writes:

> On 08/12/2015 06:56 PM, Eric Anholt wrote:
>> We need to use it for getting video modes over HDMI.
>
>> diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
>
>> +		i2c2: i2c@7e805000 {
>> +			compatible = "brcm,bcm2835-i2c";
>> +			reg = <0x7e805000 0x1000>;
>> +			interrupts = <2 21>;
>> +			clocks = <&clk_i2c>;
>> +			#address-cells = <1>;
>> +			#size-cells = <0>;
>> +		};
>
> In an SoC .dtsi file, you'd typically write:
>
> 	status = "disabled";
>
> ... in all nodes that represent IO controllers that interface to
> external HW, so that board DT files can/must explicitly choose to enable
> the device if it's actually in use on the board. Some systems might not
> have HDMI and hence might not hook up the HDMI_SCL/SDA pads.
>
> BCM2835-ARM-Peripherals.pdf states "Note that the BSC2 master is used
> dedicated with the HDMI interface and should not be accessed by user
> programs.". Does this imply the Linux kernel shouldn't be touching this
> I2C controller; that the VC4 firmware might also be attempting to use
> it? I wonder how any such sharing of the HW would work.

In order for *any* of this driver to work, we need to ensure that the
firmware doesn't try to write to the corresponding part of the hardware.
DDC I2C is no different.  All that will cause the firmware to do
anything with display is generating mbox/dispmanx requests (through the
firmware driver), and the undervoltage warnings.

Patch
diff mbox

diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 301c73f..8f3ba88 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -149,6 +149,15 @@ 
 			status = "disabled";
 		};
 
+		i2c2: i2c@7e805000 {
+			compatible = "brcm,bcm2835-i2c";
+			reg = <0x7e805000 0x1000>;
+			interrupts = <2 21>;
+			clocks = <&clk_i2c>;
+			#address-cells = <1>;
+			#size-cells = <0>;
+		};
+
 		usb@7e980000 {
 			compatible = "brcm,bcm2835-usb";
 			reg = <0x7e980000 0x10000>;