[RFC] SW connection between DVB Transport Stream demuxer and I2C-based frontend

  Hello everyone,

My first message(*) might have been too vague. Let me try explaining
the goal in a different way, using code this time. (Provided at the
end of this message.)

(*) https://www.spinics.net/lists/arm-kernel/msg739657.html

Background: I'm working with a SoC that provides a TSIF HW block,
and I'm trying to write a driver for it.

The purpose of this "Transport Stream Interface" is to merge incoming
bits together into a 188-byte TS packet, add a timestamp, then raise
an interrupt to notify the system that a new packet is ready.
(Driver for this HW block is tsif.c)

Pretty basic stuff so far...

While the TSIF block is embedded in the SoC, the block that feeds the
TSIF (a demodulator) is not, therefore the demod is provided on the
board. (On the board I have, demod=si2168, tuner=2141). Different boards
may have different demods/tuners.

So, I have a DT node for the TSIF in the SoC DTSI, and a DT node for
the si2168 in the board DTSI; and the TSIF node has a phandle to the
demod node. The system communicates with si2168 over an I2C bus.
The si2168 is connected to the TSIF using 3 GPIO pins.


PROBLEM #1

The media framework requires that the TSIF and demod be "tied" together,
by calling dvb_register_frontend(). If I do that in tsif.c, then I need to
get the frontend pointer from the demod at some point. There is no such
callback presently. Since si2168 lives on an I2C bus, I can get a
struct i2c_client pointer, through the DT phandle. But some kind of
abstraction is missing to query the i2c_client object to make sure it
is a demodulator and request its frontend pointer.

For the time being, I have added a very generic pointer to struct i2c_client
but I feel this is not quite right... (though it gets the job done)


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.
  

On 08.07.19 13:08, Marc Gonzalez wrote:

> 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.

Should the si2168 make up it's own i2c controller ?


--mtx
  

On 08/07/2019 16:44, Enrico Weigelt wrote:

> On 08.07.19 13:08, Marc Gonzalez wrote:
> 
>> 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.
> 
> Should the si2168 make up its own i2c controller ?

It does AFAIU ;-)

https://elixir.bootlin.com/linux/latest/source/drivers/media/dvb-frontends/si2168.c#L780

	/* create mux i2c adapter for tuner */
	dev->muxc = i2c_mux_alloc(client->adapter, &client->dev, 1, 0, I2C_MUX_LOCKED, si2168_select, si2168_deselect);

	ret = i2c_mux_add_adapter(dev->muxc, 0, 0, 0);

	/* this is the new internal i2c bus */
	struct i2c_adapter *si2168_bus = dev->muxc->adapter[0];


One problem is that since the internal bus is "created" (declared?) at run-time,
it doesn't seem possible to define it (or its client) in DT.

Regards.
  

On 08/07/2019 13:08, Marc Gonzalez wrote:

> PROBLEM #1
> 
> The media framework requires that the TSIF and demod be "tied" together,
> by calling dvb_register_frontend(). If I do that in tsif.c, then I need to
> get the frontend pointer from the demod at some point. There is no such
> callback presently. Since si2168 lives on an I2C bus, I can get a
> struct i2c_client pointer, through the DT phandle. But some kind of
> abstraction is missing to query the i2c_client object to make sure it
> is a demodulator and request its frontend pointer.
> 
> For the time being, I have added a very generic pointer to struct i2c_client
> but I feel this is not quite right... (though it gets the job done)

As far as PROBLEM #1 is concerned, I think I have a better solution;
one that doesn't involve messing with struct i2c_client.

Basically, we embed a common struct in every demod driver, at the
beginning of their private control struct. That way, demod consumers
have a generic/common data type to inspect, and don't need to know
the specific demod they are working with. (I left the removals in
the diff below, to show the two proposed solutions so far.)

@linux-media maintainers, I think this solution is acceptable for
mainline, right?

Regards.



diff --git a/drivers/media/dvb-frontends/si2168.c b/drivers/media/dvb-frontends/si2168.c
index 726bb6759315..692f3207cd9d 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -666,12 +666,6 @@ struct si2168_config si2168_config;
 struct si2157_config si2157_config;
 struct i2c_client *tuner;
 
-static void *get_fe(struct i2c_client *client)
-{
-	struct si2168_dev *dev = i2c_get_clientdata(client);
-	return &dev->fe;
-}
-
 static int si2168_probe(struct i2c_client *client,
 		const struct i2c_device_id *id)
 {
@@ -700,7 +694,7 @@ static int si2168_probe(struct i2c_client *client,
 		goto err;
 	}
 
-	client->get_something = get_fe;
+	dev->common.fe = &dev->fe;
 	i2c_set_clientdata(client, dev);
 	mutex_init(&dev->i2c_mutex);
 
diff --git a/drivers/media/dvb-frontends/si2168_priv.h b/drivers/media/dvb-frontends/si2168_priv.h
index 804d5b30c697..2e69080f8a1c 100644
--- a/drivers/media/dvb-frontends/si2168_priv.h
+++ b/drivers/media/dvb-frontends/si2168_priv.h
@@ -22,6 +22,7 @@
 
 /* state struct */
 struct si2168_dev {
+	struct dvb_demod_common common;
 	struct mutex i2c_mutex;
 	struct i2c_mux_core *muxc;
 	struct dvb_frontend fe;
diff --git a/drivers/media/platform/tsif.c b/drivers/media/platform/tsif.c
index a0118c2ee870..c13fa19c9779 100644
--- a/drivers/media/platform/tsif.c
+++ b/drivers/media/platform/tsif.c
@@ -237,6 +237,7 @@ static int msm_tspp_probe(struct platform_device *pdev)
 	{
 		struct device_node *tsif_node, *demod_node;
 		struct i2c_client *demod;
+		struct dvb_demod_common *demod_data;
 
 		tsif_node = pdev->dev.of_node;
 		demod_node = of_parse_phandle(tsif_node, "demod", 0);
@@ -244,10 +245,8 @@ static int msm_tspp_probe(struct platform_device *pdev)
 		demod = of_find_i2c_device_by_node(demod_node);
 		if (!demod) panic("of_find_i2c_device_by_node");
 
-		/*** TODO: Improve callback naming & handling ***/
-		if (!demod->get_something)
-			panic("Wrong i2c_client");
-		my_dvb_frontend = demod->get_something(demod);
+		demod_data = i2c_get_clientdata(demod);
+		my_dvb_frontend = demod_data->fe;
 		of_node_put(demod_node);
 	}
 
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 5fca596e0dd0..e982b8913b73 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -295,8 +295,6 @@ struct i2c_driver {
 };
 #define to_i2c_driver(d) container_of(d, struct i2c_driver, driver)
 
-typedef void *generic_func(struct i2c_client *this);
-
 /**
  * struct i2c_client - represent an I2C slave device
  * @flags: I2C_CLIENT_TEN indicates the device uses a ten bit chip address;
@@ -330,7 +328,6 @@ struct i2c_client {
 #if IS_ENABLED(CONFIG_I2C_SLAVE)
 	i2c_slave_cb_t slave_cb;	/* callback for slave mode	*/
 #endif
-	generic_func *get_something;
 };
 #define to_i2c_client(d) container_of(d, struct i2c_client, dev)
 
diff --git a/include/media/dvb_frontend.h b/include/media/dvb_frontend.h
index f05cd7b94a2c..087486bc027e 100644
--- a/include/media/dvb_frontend.h
+++ b/include/media/dvb_frontend.h
@@ -73,6 +73,10 @@ struct dvb_frontend_tune_settings {
 
 struct dvb_frontend;
 
+struct dvb_demod_common {
+	struct dvb_frontend *fe;
+};
+
 /**
  * struct dvb_tuner_info - Frontend name and min/max ranges/bandwidths
  *
  

On 08.07.19 17:03, Marc Gonzalez wrote:

> One problem is that since the internal bus is "created" (declared?) at run-time,
> it doesn't seem possible to define it (or its client) in DT.

Maybe declare it nested inside the si2168 device ?
The driver then needs a piece of glue code for triggering device probing
on that bus. (so, it really needs to provide a full blown i2c driver ?)

--mtx
  

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>;
  

On Mon, Jul 08, 2019 at 07:58:00PM +0000, Peter Rosin wrote:
> On 2019-07-08 13:08, Marc Gonzalez wrote:
[...]
> > +	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...

So far, both drivers don't deal with devicetree at all, and there are no
bindings, so we have the chance to write the best bindings possible.

An i2c-gate subnode on the si2168 node looks good to me, FWIW.


Greetings,
Jonathan Neuschäfer
  

On 08/07/2019 21:58, Peter Rosin wrote:

> On 2019-07-08 13:08, Marc Gonzalez wrote:
> 
>> 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.)
>>
>>
>> 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?

Thanks, Peter!

Your solution works great. It's refreshing to have stuff work
out-of-the-box!

Problem #2 is now taken care of. And Brad proposed an elegant
solution (IMO) for Problem #1.

I'll send an updated RFC v2 tomorrow. (My patch series is a
complete mess right now.)

Regards.
  

On 10/07/2019 15:52, Marc Gonzalez wrote:

> Your solution works great. It's refreshing to have stuff work
> out-of-the-box!

Arg! I spoke too soon. For some reason, si2157_init() is not being
called when it should. I'm trying to trace it down...