devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
To: Takashi Iwai <tiwai-l3A5Bk7waGM@public.gmane.org>
Cc: Jean-Francois Moine <moinejf-GANU6spQydw@public.gmane.org>,
	Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Dave Airlie <airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Andrew Jackson <Andrew.Jackson-5wv7dgnIgG8@public.gmane.org>,
	Jyri Sarha <jsarha-l0cyMroinI0@public.gmane.org>,
	alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH v13 3/3] ASoC: tda998x: add a codec to the HDMI transmitter
Date: Tue, 28 Jul 2015 15:18:42 +0100	[thread overview]
Message-ID: <20150728141842.GL7557@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <s5hio94tmb2.wl-tiwai-l3A5Bk7waGM@public.gmane.org>

On Tue, Jul 28, 2015 at 03:59:45PM +0200, Takashi Iwai wrote:
> FWIW, we're currently discussing about extending the i915/hda
> component binding so that the audio driver gets a notification and
> queries the ELD via callbacks instead of the flaky hardware access.
> 
> It'd be best if we have a common infrastructure for that, of course.
> But currently it's a start, just a bit step forward there.

Okay, so it sounds like i915/hda also needs this.

I think in addition to what I said above, we need whatever provides the
notification system to generate state notifications for new "listeners"
that would otherwise be unaware of the current state.

I'm thinking at the moment that something along these lines to go into
drivers/video/hdmi.c / include/linux/hdmi.h:

struct hdmi_state {
	struct mutex mutex;
	struct raw_notifier_head head;
	bool connected;
	bool edid_valid;
	u8 edid[MAX_EDID_SIZE];
};

enum {
	HDMI_CONNECTED,
	HDMI_DISCONNECTED,
	HDMI_NEW_EDID,
};

int hdmi_register_notifier(struct notifier_block *nb)
{
	struct hdmi_state *state = ...;
	int ret;

	mutex_lock(&state->mutex);
	if (state->connected) {
		nb->notifier_call(nb, HDMI_CONNECTED, NULL);
		if (state->edid_valid)
			nb->notifier_call(nb, HDMI_NEW_EDID, state->edid);
	} else {
		nb->notifier_call(nb, HDMI_DISCONNECTED, NULL);
	}
	ret = raw_notifier_chain_register(&state->head, nb);
	mutex_unlock(&state->mutex);

	return ret;
}

int hdmi_unregister_notifier(struct notifier_block *nb)
{
	struct hdmi_state *state = ...;
	int ret;

	mutex_lock(&state->mutex);
	ret = raw_notifier_chain_unregister(&state->head, nb);
	mutex_unlock(&state->mutex);

	return ret;
}

void hdmi_event_connect(struct device *dev)
{
	struct hdmi_state *state = lookup_state_from_dev(dev);

	mutex_lock(&state->mutex);
	state->connected = true;
	raw_notifier_call_chain(&state->head, HDMI_CONNECTED, NULL);
	mutex_unlock(&state->mutex);
}

void hdmi_event_disconnect(struct device *dev)
{
	struct hdmi_state *state = lookup_state_from_dev(dev);

	mutex_lock(&state->mutex);
	state->connected = false;
	state->valid_edid = false;
	raw_notifier_call_chain(&state->head, HDMI_DISCONNECTED, NULL);
	mutex_unlock(&state->mutex);
}

int hdmi_event_new_edid(struct device *dev, const void *edid, size_t size)
{
	struct hdmi_state *state = lookup_state_from_dev(dev);

	if (size > sizeof(state->edid))
		return -EINVAL;

	mutex_lock(&state->mutex);
	state->valid_edid = true;
	memcpy(state->edid, edid, size);
	raw_notifier_call_chain(&state->head, HDMI_NEW_EDID, state->edid);
	mutex_unlock(&state->mutex);

	return 0;
}

The problems here are: how to go from a struct device to the state (iow,
the implementation of lookup_state_from_dev()) and how to convey on the
client side which 'state' to attach to.  I'd rather not involve DT at
this level: DT is not the world's only firmware system, we have to cater
for x86 too here, so we need something that is firmware agnostic.

This is something I've just banged out in this email...

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2015-07-28 14:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-20 13:01 [PATCH v13 0/3] ASoC: tda998x: add a codec to the HDMI transmitter Jean-Francois Moine
     [not found] ` <cover.1437397270.git.moinejf-GANU6spQydw@public.gmane.org>
2015-05-08  8:18   ` [PATCH v13 1/3] drm/i2c: tda998x: Add support of a DT graph of ports Jean-Francois Moine
2015-05-08  8:23   ` [PATCH v13 2/3] drm/i2c: tda998x: Change drvdata for audio extension Jean-Francois Moine
2015-05-08  8:41   ` [PATCH v13 3/3] ASoC: tda998x: add a codec to the HDMI transmitter Jean-Francois Moine
     [not found]     ` <e036c88aa945e72b40ec965c9358dacf564e79f2.1437397272.git.moinejf-GANU6spQydw@public.gmane.org>
2015-07-20 18:06       ` Mark Brown
     [not found]         ` <20150720180606.GL11162-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2015-07-28 10:19           ` Jean-Francois Moine
2015-07-28 10:24             ` Mark Brown
2015-07-28 13:23               ` Jean-Francois Moine
2015-07-28 13:53                 ` Russell King - ARM Linux
2015-07-28 13:59                   ` Takashi Iwai
     [not found]                     ` <s5hio94tmb2.wl-tiwai-l3A5Bk7waGM@public.gmane.org>
2015-07-28 14:18                       ` Russell King - ARM Linux [this message]
     [not found]                   ` <20150728135358.GK7557-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
2015-07-28 14:39                     ` Jean-Francois Moine
2015-07-28 15:06                       ` Russell King - ARM Linux

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=20150728141842.GL7557@n2100.arm.linux.org.uk \
    --to=linux-lfz/pmaqli7xmaaqvzeohq@public.gmane.org \
    --cc=Andrew.Jackson-5wv7dgnIgG8@public.gmane.org \
    --cc=airlied-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org \
    --cc=broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=jsarha-l0cyMroinI0@public.gmane.org \
    --cc=moinejf-GANU6spQydw@public.gmane.org \
    --cc=tiwai-l3A5Bk7waGM@public.gmane.org \
    /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).