* Generic get_something from an i2c_client
@ 2019-07-04 16:43 Marc Gonzalez
0 siblings, 0 replies; only message in thread
From: Marc Gonzalez @ 2019-07-04 16:43 UTC (permalink / raw)
To: Wolfram Sang, Simon Horman, Peter Korsgaard
Cc: I2C, linux-media, Linux ARM, Bjorn Andersson, Ard Biesheuvel,
In media drivers, TS drivers typically hard-code their front-end (demod and tuner)
init by loading the modules themselves.
I feel this is not a good solution for SoCs, where the TS HW might be on the SoC,
and the front-end be on the board. So we may have different front-ends for
different boards, and the driver would have to hard-code all of them.
Am I making sense?
Here's an example of what I mean:
I've been working on defining the demod in DT, and having a phandle
to the demod in the TSIF node.
I've got everything working like I had hoped, but I have many ugly hacks.
The TSIF driver needs to register the frontend, which is created in
the demod driver.
So I have:
struct device_node *toto = of_parse_phandle(np, "demod", 0);
if (!toto) panic("of_parse_phandle");
struct i2c_client *demod = of_find_i2c_device_by_node(toto);
if (!demod) panic("of_find_i2c_device_by_node");
struct dvb_frontend *get_fe(struct i2c_client *client);
my_dvb_frontend = get_fe(demod);
The problem is get_fe(). It needs to be a call-back, so that every
demod can implement his own version. But only a few i2c_client's
have a dvb_frontend to return.
Could we have a generic void *get_something() callback in struct i2c_client?
(Seems like the wrong place)
How can I solve this conundrum?
Maybe look above i2c, in struct device?
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2019-07-04 16:43 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-04 16:43 Generic get_something from an i2c_client Marc Gonzalez
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).