All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Rosin <peda@axentia.se>
To: Marc Gonzalez <marc.w.gonzalez@free.fr>,
	I2C <linux-i2c@vger.kernel.org>,
	linux-media <linux-media@vger.kernel.org>,
	GPIO <linux-gpio@vger.kernel.org>
Cc: "Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
	"Brad Love" <brad@nextdimension.cc>,
	"Antti Palosaari" <crope@iki.fi>,
	"Olli Salonen" <olli.salonen@iki.fi>,
	"Bjorn Andersson" <bjorn.andersson@linaro.org>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Jeffrey Hugo" <jeffrey.l.hugo@gmail.com>,
	"Wolfram Sang" <wsa@the-dreams.de>,
	"Simon Horman" <horms+renesas@verge.net.au>,
	"Peter Korsgaard" <peter@korsgaard.com>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC] SW connection between DVB Transport Stream demuxer and I2C-based frontend
Date: Mon, 8 Jul 2019 19:58:00 +0000	[thread overview]
Message-ID: <7d47a978-5307-a2c8-acc2-f29ce7567bd5@axentia.se> (raw)
In-Reply-To: <5e35b4fb-646d-6428-f372-ee47d7352cd6@free.fr>

On 2019-07-08 13:08, Marc Gonzalez wrote:
> Hello everyone,

*snip*

Focusing on #2...

> PROBLEM #2
> 
> The tuner (si2157) is not on the i2c5 bus, instead it is on a private
> i2c bus *behind* si2168, which routes requests to the proper client.
> For the time being, I don't know how to model this relationship in DT.
> (TODO: check i2c_slave_cb_t slave_cb in struct i2c_client)
> I have initialized si2157 in the si2168 driver, but this doesn't feel
> right. (Though it seems all(?) users pair 2168 with 2157.)
> 
> 
> It would really help if I could get some guidance from media and i2c
> people for these two issues. (I'd like to upstream the driver in time
> for 5.3)
> 
> Regards.
> 
> 
> 
> diff --git a/arch/arm64/boot/dts/qcom/apq8098-batfish.dts b/arch/arm64/boot/dts/qcom/apq8098-batfish.dts
> index 29d59ecad138..9353e62375a7 100644
> --- a/arch/arm64/boot/dts/qcom/apq8098-batfish.dts
> +++ b/arch/arm64/boot/dts/qcom/apq8098-batfish.dts
> @@ -30,6 +30,28 @@
>  	status = "ok";
>  };
>  
> +&blsp1_i2c5 {
> +	status = "ok";
> +	clock-frequency = <100000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c5_default>;
> +
> +	dvb_demod: si2168@64 {
> +		compatible = "silabs,si2168";
> +		reg = <0x64>;
> +		reset-gpios = <&tlmm 84 GPIO_ACTIVE_LOW>;


In principle, I think you should be able to add something like this here:

		i2c-gate {
			#address-cells = <1>;
			#size-cells = <0>;

			tuner@60 {
				compatible = "silabs,si2157";
				reg = <0x60>;
				/* whatever else is needed */
			};
		};

But in practice, I don't know if the si2157 driver understands that or
if there is anything else that gets in the way. Totally untested...

The i2c-gate child node is examined when you call i2c_mux_add_adapter
if you have provided the correct struct device in the second argument
when you called i2c_mux_alloc (I think that is already the case). You
also need to set the I2C_MUX_GATE flag in the i2c_mux_alloc call, but
I do not see a problem with that since I think only one child adapter
is added. If it is a problem to add the I2C_MUX_GATE flag, then you
can just adjust the above i2c-gate node according to the bindings in
Documentation/devicetree/bindings/i2c/i2c-mux.txt. I.e. add this
instead of the above i2c-gate node:

		i2c-mux {
			#address-cells = <1>;
			#size-cells = <0>;

			i2c@0 {
	                        #address-cells = <1>;
        	                #size-cells = <0>;
                	        reg = <0>;

				tuner@60 {
					compatible = "silabs,si2157";
					reg = <0x60>;
					/* whatever else is needed */
				};
			};
		};

But it feels *right* to add the I2C_MUX_GATE flag, because a gate is
what you have. I think?

Cheers,
Peter

> +	};
> +};
> +
> +&tsif {
> +	demod = <&dvb_demod>;
> +};
> +
> +&i2c5_default {
> +	drive-strength = <2>;
> +	bias-disable;
> +};
> +
>  &qusb2phy {
>  	status = "ok";
>  	vdda-pll-supply = <&vreg_l12a_1p8>;


WARNING: multiple messages have this Message-ID (diff)
From: Peter Rosin <peda@axentia.se>
To: Marc Gonzalez <marc.w.gonzalez@free.fr>,
	I2C <linux-i2c@vger.kernel.org>,
	linux-media <linux-media@vger.kernel.org>,
	GPIO <linux-gpio@vger.kernel.org>
Cc: "Peter Korsgaard" <peter@korsgaard.com>,
	"Jeffrey Hugo" <jeffrey.l.hugo@gmail.com>,
	"Wolfram Sang" <wsa@the-dreams.de>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Brad Love" <brad@nextdimension.cc>,
	"Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
	"Bjorn Andersson" <bjorn.andersson@linaro.org>,
	"Antti Palosaari" <crope@iki.fi>,
	"Simon Horman" <horms+renesas@verge.net.au>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Olli Salonen" <olli.salonen@iki.fi>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC] SW connection between DVB Transport Stream demuxer and I2C-based frontend
Date: Mon, 8 Jul 2019 19:58:00 +0000	[thread overview]
Message-ID: <7d47a978-5307-a2c8-acc2-f29ce7567bd5@axentia.se> (raw)
In-Reply-To: <5e35b4fb-646d-6428-f372-ee47d7352cd6@free.fr>

On 2019-07-08 13:08, Marc Gonzalez wrote:
> Hello everyone,

*snip*

Focusing on #2...

> PROBLEM #2
> 
> The tuner (si2157) is not on the i2c5 bus, instead it is on a private
> i2c bus *behind* si2168, which routes requests to the proper client.
> For the time being, I don't know how to model this relationship in DT.
> (TODO: check i2c_slave_cb_t slave_cb in struct i2c_client)
> I have initialized si2157 in the si2168 driver, but this doesn't feel
> right. (Though it seems all(?) users pair 2168 with 2157.)
> 
> 
> It would really help if I could get some guidance from media and i2c
> people for these two issues. (I'd like to upstream the driver in time
> for 5.3)
> 
> Regards.
> 
> 
> 
> diff --git a/arch/arm64/boot/dts/qcom/apq8098-batfish.dts b/arch/arm64/boot/dts/qcom/apq8098-batfish.dts
> index 29d59ecad138..9353e62375a7 100644
> --- a/arch/arm64/boot/dts/qcom/apq8098-batfish.dts
> +++ b/arch/arm64/boot/dts/qcom/apq8098-batfish.dts
> @@ -30,6 +30,28 @@
>  	status = "ok";
>  };
>  
> +&blsp1_i2c5 {
> +	status = "ok";
> +	clock-frequency = <100000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c5_default>;
> +
> +	dvb_demod: si2168@64 {
> +		compatible = "silabs,si2168";
> +		reg = <0x64>;
> +		reset-gpios = <&tlmm 84 GPIO_ACTIVE_LOW>;


In principle, I think you should be able to add something like this here:

		i2c-gate {
			#address-cells = <1>;
			#size-cells = <0>;

			tuner@60 {
				compatible = "silabs,si2157";
				reg = <0x60>;
				/* whatever else is needed */
			};
		};

But in practice, I don't know if the si2157 driver understands that or
if there is anything else that gets in the way. Totally untested...

The i2c-gate child node is examined when you call i2c_mux_add_adapter
if you have provided the correct struct device in the second argument
when you called i2c_mux_alloc (I think that is already the case). You
also need to set the I2C_MUX_GATE flag in the i2c_mux_alloc call, but
I do not see a problem with that since I think only one child adapter
is added. If it is a problem to add the I2C_MUX_GATE flag, then you
can just adjust the above i2c-gate node according to the bindings in
Documentation/devicetree/bindings/i2c/i2c-mux.txt. I.e. add this
instead of the above i2c-gate node:

		i2c-mux {
			#address-cells = <1>;
			#size-cells = <0>;

			i2c@0 {
	                        #address-cells = <1>;
        	                #size-cells = <0>;
                	        reg = <0>;

				tuner@60 {
					compatible = "silabs,si2157";
					reg = <0x60>;
					/* whatever else is needed */
				};
			};
		};

But it feels *right* to add the I2C_MUX_GATE flag, because a gate is
what you have. I think?

Cheers,
Peter

> +	};
> +};
> +
> +&tsif {
> +	demod = <&dvb_demod>;
> +};
> +
> +&i2c5_default {
> +	drive-strength = <2>;
> +	bias-disable;
> +};
> +
>  &qusb2phy {
>  	status = "ok";
>  	vdda-pll-supply = <&vreg_l12a_1p8>;

WARNING: multiple messages have this Message-ID (diff)
From: Peter Rosin <peda@axentia.se>
To: Marc Gonzalez <marc.w.gonzalez@free.fr>,
	I2C <linux-i2c@vger.kernel.org>,
	 linux-media <linux-media@vger.kernel.org>,
	GPIO <linux-gpio@vger.kernel.org>
Cc: "Peter Korsgaard" <peter@korsgaard.com>,
	"Jeffrey Hugo" <jeffrey.l.hugo@gmail.com>,
	"Wolfram Sang" <wsa@the-dreams.de>,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Brad Love" <brad@nextdimension.cc>,
	"Jonathan Neuschäfer" <j.neuschaefer@gmx.net>,
	"Bjorn Andersson" <bjorn.andersson@linaro.org>,
	"Antti Palosaari" <crope@iki.fi>,
	"Simon Horman" <horms+renesas@verge.net.au>,
	"Mauro Carvalho Chehab" <mchehab@kernel.org>,
	"Olli Salonen" <olli.salonen@iki.fi>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC] SW connection between DVB Transport Stream demuxer and I2C-based frontend
Date: Mon, 8 Jul 2019 19:58:00 +0000	[thread overview]
Message-ID: <7d47a978-5307-a2c8-acc2-f29ce7567bd5@axentia.se> (raw)
In-Reply-To: <5e35b4fb-646d-6428-f372-ee47d7352cd6@free.fr>

On 2019-07-08 13:08, Marc Gonzalez wrote:
> Hello everyone,

*snip*

Focusing on #2...

> PROBLEM #2
> 
> The tuner (si2157) is not on the i2c5 bus, instead it is on a private
> i2c bus *behind* si2168, which routes requests to the proper client.
> For the time being, I don't know how to model this relationship in DT.
> (TODO: check i2c_slave_cb_t slave_cb in struct i2c_client)
> I have initialized si2157 in the si2168 driver, but this doesn't feel
> right. (Though it seems all(?) users pair 2168 with 2157.)
> 
> 
> It would really help if I could get some guidance from media and i2c
> people for these two issues. (I'd like to upstream the driver in time
> for 5.3)
> 
> Regards.
> 
> 
> 
> diff --git a/arch/arm64/boot/dts/qcom/apq8098-batfish.dts b/arch/arm64/boot/dts/qcom/apq8098-batfish.dts
> index 29d59ecad138..9353e62375a7 100644
> --- a/arch/arm64/boot/dts/qcom/apq8098-batfish.dts
> +++ b/arch/arm64/boot/dts/qcom/apq8098-batfish.dts
> @@ -30,6 +30,28 @@
>  	status = "ok";
>  };
>  
> +&blsp1_i2c5 {
> +	status = "ok";
> +	clock-frequency = <100000>;
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c5_default>;
> +
> +	dvb_demod: si2168@64 {
> +		compatible = "silabs,si2168";
> +		reg = <0x64>;
> +		reset-gpios = <&tlmm 84 GPIO_ACTIVE_LOW>;


In principle, I think you should be able to add something like this here:

		i2c-gate {
			#address-cells = <1>;
			#size-cells = <0>;

			tuner@60 {
				compatible = "silabs,si2157";
				reg = <0x60>;
				/* whatever else is needed */
			};
		};

But in practice, I don't know if the si2157 driver understands that or
if there is anything else that gets in the way. Totally untested...

The i2c-gate child node is examined when you call i2c_mux_add_adapter
if you have provided the correct struct device in the second argument
when you called i2c_mux_alloc (I think that is already the case). You
also need to set the I2C_MUX_GATE flag in the i2c_mux_alloc call, but
I do not see a problem with that since I think only one child adapter
is added. If it is a problem to add the I2C_MUX_GATE flag, then you
can just adjust the above i2c-gate node according to the bindings in
Documentation/devicetree/bindings/i2c/i2c-mux.txt. I.e. add this
instead of the above i2c-gate node:

		i2c-mux {
			#address-cells = <1>;
			#size-cells = <0>;

			i2c@0 {
	                        #address-cells = <1>;
        	                #size-cells = <0>;
                	        reg = <0>;

				tuner@60 {
					compatible = "silabs,si2157";
					reg = <0x60>;
					/* whatever else is needed */
				};
			};
		};

But it feels *right* to add the I2C_MUX_GATE flag, because a gate is
what you have. I think?

Cheers,
Peter

> +	};
> +};
> +
> +&tsif {
> +	demod = <&dvb_demod>;
> +};
> +
> +&i2c5_default {
> +	drive-strength = <2>;
> +	bias-disable;
> +};
> +
>  &qusb2phy {
>  	status = "ok";
>  	vdda-pll-supply = <&vreg_l12a_1p8>;

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2019-07-08 19:58 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-08 11:08 [RFC] SW connection between DVB Transport Stream demuxer and I2C-based frontend Marc Gonzalez
2019-07-08 11:08 ` Marc Gonzalez
2019-07-08 11:08 ` Marc Gonzalez
2019-07-08 14:44 ` Enrico Weigelt, metux IT consult
2019-07-08 14:44   ` Enrico Weigelt, metux IT consult
2019-07-08 14:44   ` Enrico Weigelt, metux IT consult
2019-07-08 15:03   ` Marc Gonzalez
2019-07-08 15:03     ` Marc Gonzalez
2019-07-08 15:03     ` Marc Gonzalez
2019-07-08 19:10     ` Enrico Weigelt, metux IT consult
2019-07-08 19:10       ` Enrico Weigelt, metux IT consult
2019-07-08 19:10       ` Enrico Weigelt, metux IT consult
2019-07-08 16:42 ` Marc Gonzalez
2019-07-08 16:42   ` Marc Gonzalez
2019-07-08 16:42   ` Marc Gonzalez
2019-07-08 19:58 ` Peter Rosin [this message]
2019-07-08 19:58   ` Peter Rosin
2019-07-08 19:58   ` Peter Rosin
2019-07-09 23:21   ` Jonathan Neuschäfer
2019-07-09 23:21     ` Jonathan Neuschäfer
2019-07-10 13:52   ` Marc Gonzalez
2019-07-10 13:52     ` Marc Gonzalez
2019-07-10 13:52     ` Marc Gonzalez
2019-07-10 15:07     ` Marc Gonzalez
2019-07-10 15:07       ` Marc Gonzalez
2019-07-10 15:07       ` Marc Gonzalez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7d47a978-5307-a2c8-acc2-f29ce7567bd5@axentia.se \
    --to=peda@axentia.se \
    --cc=bjorn.andersson@linaro.org \
    --cc=brad@nextdimension.cc \
    --cc=crope@iki.fi \
    --cc=horms+renesas@verge.net.au \
    --cc=j.neuschaefer@gmx.net \
    --cc=jeffrey.l.hugo@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=marc.w.gonzalez@free.fr \
    --cc=mchehab@kernel.org \
    --cc=olli.salonen@iki.fi \
    --cc=peter@korsgaard.com \
    --cc=wsa@the-dreams.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.