From: Marc Gonzalez <marc.w.gonzalez@free.fr>
To: Wolfram Sang <wsa+renesas@sang-engineering.com>,
Simon Horman <horms+renesas@verge.net.au>,
Peter Korsgaard <peter.korsgaard@barco.com>
Cc: I2C <linux-i2c@vger.kernel.org>,
linux-media <linux-media@vger.kernel.org>,
Linux ARM <linux-arm-kernel@lists.infradead.org>,
Bjorn Andersson <bjorn.andersson@linaro.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Arnd Bergmann <arnd@arndb.de>
Subject: Generic get_something from an i2c_client
Date: Thu, 4 Jul 2019 18:43:39 +0200 [thread overview]
Message-ID: <07aa1229-2b67-e191-5740-70e6ed2a8ce3@free.fr> (raw)
Hello,
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:
https://elixir.bootlin.com/linux/latest/source/drivers/media/usb/dvb-usb-v2/dvbsky.c#L466
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");
printk("\tdemod=%px\n", demod);
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?
Regards.
reply other threads:[~2019-07-04 16:43 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=07aa1229-2b67-e191-5740-70e6ed2a8ce3@free.fr \
--to=marc.w.gonzalez@free.fr \
--cc=ard.biesheuvel@linaro.org \
--cc=arnd@arndb.de \
--cc=bjorn.andersson@linaro.org \
--cc=horms+renesas@verge.net.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=peter.korsgaard@barco.com \
--cc=wsa+renesas@sang-engineering.com \
/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 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).