All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Hans Verkuil <hansverk@cisco.com>
Cc: linux-fbdev@vger.kernel.org, David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 5/5] drm/i2c: add tda998x/tda9950 CEC driver
Date: Fri, 12 Aug 2016 15:59:03 +0000	[thread overview]
Message-ID: <20160812155902.GH1041@n2100.armlinux.org.uk> (raw)
In-Reply-To: <7722d4a0-03f6-3858-0771-e6598d838b65@cisco.com>

On Fri, Aug 12, 2016 at 05:53:17PM +0200, Hans Verkuil wrote:
> There are three possible 'states' of a CEC adapter w.r.t. logical addresses:
> 
> 1) There is no physical address or no logical addresses have been set
> by the application (CEC_ADAP_S_LOG_ADDRS): in that case the device
> will not participate on the bus, it doesn't care about receiving messages
> let alone replying to them. The only exception is if the device can
> snoop messages, that is allowed even if CEC_ADAP_S_LOG_ADDRS is never
> called. That is ideal to have a 'neutral' observer of the bus that just
> listens but never participates. Not all hardware supports snooping, though.
> 
> 2) CEC_ADAP_S_LOG_ADDRS is called and the device becomes an 'Unregistered'
> device (i.e. it gets logical address 15). In that case it should receive
> broadcast messages and be able to transmit messages.
> 
> 3) CEC_ADAP_S_LOG_ADDRS is called and the device claims one or more logical
> addresses in the range 0-14. Then it can receive broadcast and directed
> messages, and of course transmit messages.
> 
> From the point of view of the hardware state 1 is selected if adap_log_addr
> is called with LOG_ADDR_INVALID. Some hardware might still receive broadcast
> messages (because they can't turn that off) and those should be filtered out
> by the CEC framework. But I think that doesn't happen, which would be a bug.
> I'll verify that tomorrow.
> 
> State 2 is a problem for hardware that has to enable support to receive
> broadcast messages since adap_log_addr is never called with
> LOG_ADDR_UNREGISTERED as argument. I missed that, since the hardware I tested
> with always accepts broadcast messages. I'll look into this tomorrow as well.
> It should be easy to fix.
> 
> State 3 works OK.
> 
> So for the dw-hdmi cec driver that means that for state 1 you set 'addresses'
> to 0, for state 2 you set it to BIT(15) and for state 3 you always
> OR with BIT(15). At least, as I understand your hardware.

Thanks, I think that needs documenting in Documentation/cec.txt.

> BTW, if either the tda or dw-hdmi supports snooping mode, then I strongly
> recommend supporting that. It's great for debugging.

Neither do.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

WARNING: multiple messages have this Message-ID (diff)
From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 5/5] drm/i2c: add tda998x/tda9950 CEC driver
Date: Fri, 12 Aug 2016 16:59:03 +0100	[thread overview]
Message-ID: <20160812155902.GH1041@n2100.armlinux.org.uk> (raw)
In-Reply-To: <7722d4a0-03f6-3858-0771-e6598d838b65@cisco.com>

On Fri, Aug 12, 2016 at 05:53:17PM +0200, Hans Verkuil wrote:
> There are three possible 'states' of a CEC adapter w.r.t. logical addresses:
> 
> 1) There is no physical address or no logical addresses have been set
> by the application (CEC_ADAP_S_LOG_ADDRS): in that case the device
> will not participate on the bus, it doesn't care about receiving messages
> let alone replying to them. The only exception is if the device can
> snoop messages, that is allowed even if CEC_ADAP_S_LOG_ADDRS is never
> called. That is ideal to have a 'neutral' observer of the bus that just
> listens but never participates. Not all hardware supports snooping, though.
> 
> 2) CEC_ADAP_S_LOG_ADDRS is called and the device becomes an 'Unregistered'
> device (i.e. it gets logical address 15). In that case it should receive
> broadcast messages and be able to transmit messages.
> 
> 3) CEC_ADAP_S_LOG_ADDRS is called and the device claims one or more logical
> addresses in the range 0-14. Then it can receive broadcast and directed
> messages, and of course transmit messages.
> 
> From the point of view of the hardware state 1 is selected if adap_log_addr
> is called with LOG_ADDR_INVALID. Some hardware might still receive broadcast
> messages (because they can't turn that off) and those should be filtered out
> by the CEC framework. But I think that doesn't happen, which would be a bug.
> I'll verify that tomorrow.
> 
> State 2 is a problem for hardware that has to enable support to receive
> broadcast messages since adap_log_addr is never called with
> LOG_ADDR_UNREGISTERED as argument. I missed that, since the hardware I tested
> with always accepts broadcast messages. I'll look into this tomorrow as well.
> It should be easy to fix.
> 
> State 3 works OK.
> 
> So for the dw-hdmi cec driver that means that for state 1 you set 'addresses'
> to 0, for state 2 you set it to BIT(15) and for state 3 you always
> OR with BIT(15). At least, as I understand your hardware.

Thanks, I think that needs documenting in Documentation/cec.txt.

> BTW, if either the tda or dw-hdmi supports snooping mode, then I strongly
> recommend supporting that. It's great for debugging.

Neither do.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Hans Verkuil <hansverk@cisco.com>
Cc: linux-fbdev@vger.kernel.org, David Airlie <airlied@linux.ie>,
	dri-devel@lists.freedesktop.org,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH RFC 5/5] drm/i2c: add tda998x/tda9950 CEC driver
Date: Fri, 12 Aug 2016 16:59:03 +0100	[thread overview]
Message-ID: <20160812155902.GH1041@n2100.armlinux.org.uk> (raw)
In-Reply-To: <7722d4a0-03f6-3858-0771-e6598d838b65@cisco.com>

On Fri, Aug 12, 2016 at 05:53:17PM +0200, Hans Verkuil wrote:
> There are three possible 'states' of a CEC adapter w.r.t. logical addresses:
> 
> 1) There is no physical address or no logical addresses have been set
> by the application (CEC_ADAP_S_LOG_ADDRS): in that case the device
> will not participate on the bus, it doesn't care about receiving messages
> let alone replying to them. The only exception is if the device can
> snoop messages, that is allowed even if CEC_ADAP_S_LOG_ADDRS is never
> called. That is ideal to have a 'neutral' observer of the bus that just
> listens but never participates. Not all hardware supports snooping, though.
> 
> 2) CEC_ADAP_S_LOG_ADDRS is called and the device becomes an 'Unregistered'
> device (i.e. it gets logical address 15). In that case it should receive
> broadcast messages and be able to transmit messages.
> 
> 3) CEC_ADAP_S_LOG_ADDRS is called and the device claims one or more logical
> addresses in the range 0-14. Then it can receive broadcast and directed
> messages, and of course transmit messages.
> 
> From the point of view of the hardware state 1 is selected if adap_log_addr
> is called with LOG_ADDR_INVALID. Some hardware might still receive broadcast
> messages (because they can't turn that off) and those should be filtered out
> by the CEC framework. But I think that doesn't happen, which would be a bug.
> I'll verify that tomorrow.
> 
> State 2 is a problem for hardware that has to enable support to receive
> broadcast messages since adap_log_addr is never called with
> LOG_ADDR_UNREGISTERED as argument. I missed that, since the hardware I tested
> with always accepts broadcast messages. I'll look into this tomorrow as well.
> It should be easy to fix.
> 
> State 3 works OK.
> 
> So for the dw-hdmi cec driver that means that for state 1 you set 'addresses'
> to 0, for state 2 you set it to BIT(15) and for state 3 you always
> OR with BIT(15). At least, as I understand your hardware.

Thanks, I think that needs documenting in Documentation/cec.txt.

> BTW, if either the tda or dw-hdmi supports snooping mode, then I strongly
> recommend supporting that. It's great for debugging.

Neither do.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

  reply	other threads:[~2016-08-12 15:59 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-12 14:14 [PATCH RFC 0/5] CEC drivers for iMX6 and TDA9950 Russell King - ARM Linux
2016-08-12 14:14 ` Russell King - ARM Linux
2016-08-12 14:14 ` Russell King - ARM Linux
2016-08-12 14:14 ` [PATCH RFC 1/5] video: add HDMI state notifier support Russell King
2016-08-12 14:14   ` Russell King
2016-08-12 14:14   ` Russell King
2016-08-12 15:26   ` Hans Verkuil
2016-08-12 15:26     ` Hans Verkuil
2016-08-12 15:26     ` Hans Verkuil
2016-08-12 14:15 ` [PATCH RFC 2/5] drm/bridge: dw_hdmi: remove CEC engine register definitions Russell King
2016-08-12 14:15   ` Russell King
2016-08-12 14:15   ` Russell King
2016-08-12 14:15 ` [PATCH RFC 3/5] drm/bridge: dw_hdmi: add HDMI notifier support Russell King
2016-08-12 14:15   ` Russell King
2016-08-12 14:15   ` Russell King
2016-08-12 14:15 ` [PATCH RFC 4/5] drm/bridge: add dw-hdmi cec driver using Hans Verkil's CEC code Russell King
2016-08-12 14:15   ` Russell King
2016-08-12 14:15   ` Russell King
2016-08-12 14:25   ` Hans Verkuil
2016-08-12 14:25     ` Hans Verkuil
2016-08-12 14:25     ` Hans Verkuil
2016-08-12 14:26     ` Russell King - ARM Linux
2016-08-12 14:26       ` Russell King - ARM Linux
2016-08-12 14:26       ` Russell King - ARM Linux
2016-08-23  7:21   ` Hans Verkuil
2016-08-23  7:21     ` Hans Verkuil
2016-08-23  7:21     ` Hans Verkuil
2016-08-23  7:59     ` Russell King - ARM Linux
2016-08-23  7:59       ` Russell King - ARM Linux
2016-08-23  7:59       ` Russell King - ARM Linux
2016-08-23  8:05       ` Hans Verkuil
2016-08-23  8:05         ` Hans Verkuil
2016-08-23  8:05         ` Hans Verkuil
2016-08-31 12:28         ` Russell King - ARM Linux
2016-08-31 12:28           ` Russell King - ARM Linux
2016-08-31 12:28           ` Russell King - ARM Linux
2016-08-23  8:03   ` Hans Verkuil
2016-08-23  8:03     ` Hans Verkuil
2016-08-23  8:03     ` Hans Verkuil
2016-08-31 12:28     ` Russell King - ARM Linux
2016-08-31 12:28       ` Russell King - ARM Linux
2016-08-31 12:28       ` Russell King - ARM Linux
2016-08-12 14:15 ` [PATCH RFC 5/5] drm/i2c: add tda998x/tda9950 CEC driver Russell King
2016-08-12 14:15   ` Russell King
2016-08-12 14:15   ` Russell King
2016-08-12 14:38   ` Hans Verkuil
2016-08-12 14:38     ` Hans Verkuil
2016-08-12 14:38     ` Hans Verkuil
2016-08-12 14:52     ` Russell King - ARM Linux
2016-08-12 14:52       ` Russell King - ARM Linux
2016-08-12 14:52       ` Russell King - ARM Linux
2016-08-12 15:16     ` Hans Verkuil
2016-08-12 15:16       ` Hans Verkuil
2016-08-12 15:16       ` Hans Verkuil
2016-08-12 15:29       ` Russell King - ARM Linux
2016-08-12 15:29         ` Russell King - ARM Linux
2016-08-12 15:29         ` Russell King - ARM Linux
2016-08-12 15:53         ` Hans Verkuil
2016-08-12 15:53           ` Hans Verkuil
2016-08-12 15:53           ` Hans Verkuil
2016-08-12 15:59           ` Russell King - ARM Linux [this message]
2016-08-12 15:59             ` Russell King - ARM Linux
2016-08-12 15:59             ` 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=20160812155902.GH1041@n2100.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hansverk@cisco.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=plagnioj@jcrosoft.com \
    --cc=tomi.valkeinen@ti.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 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.