On Tue, Dec 12, 2017 at 03:37:21PM +0100, Hans Verkuil wrote:
Hi Russell,
On 08/12/17 12:59, Russell King - ARM Linux wrote:
On Wed, Dec 06, 2017 at 02:54:04PM +0100, Hans Verkuil wrote:
On 12/06/17 13:35, Russell King wrote:
We no longer use the CEC client to access the CEC part itself, so we can move this later in the initialisation sequence.
Signed-off-by: Russell King rmk+kernel@armlinux.org.uk
drivers/gpu/drm/i2c/tda998x_drv.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c b/drivers/gpu/drm/i2c/tda998x_drv.c index 7f4dbca7f7f4..4aeac2127974 100644 --- a/drivers/gpu/drm/i2c/tda998x_drv.c +++ b/drivers/gpu/drm/i2c/tda998x_drv.c @@ -1490,9 +1490,6 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv) priv->cec_addr = 0x34 + (client->addr & 0x03); priv->current_page = 0xff; priv->hdmi = client;
priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
if (!priv->cec)
return -ENODEV;/* wake up the device: */ cec_write(priv, REG_CEC_ENAMODS,
@@ -1546,6 +1543,10 @@ static int tda998x_create(struct i2c_client *client, struct tda998x_priv *priv) CEC_FRO_IM_CLK_CTRL_GHOST_DIS | CEC_FRO_IM_CLK_CTRL_IMCLK_SEL);
/* initialize the optional IRQ */
- priv->cec = i2c_new_dummy(client->adapter, priv->cec_addr);
- if (!priv->cec)
return -ENODEV;I'd move this up to before the 'initialize the optional IRQ' comment, since that should stay with the 'if (client->irq) {' line below.
I've swapped the order of patches 2 and 3, and moved this further down near where we add the real cec device in a later patch. This is starting to get quite different from the patch series that I've tested, and as I've already mentioned, testing is not going to happen for a while.
I added support for this to am335x-boneblack-common.dtsi (see patch below), but it doesn't work. I suspect the calibration since I see these messages:
gpio-57 (nxp,calib): gpiod_direction_output: tried to set a GPIO tied to an IRQ as output
It's annoying that different gpiochips have different behaviours, it means you can't develop a driver using gpios and know that it'll work elsewhere. It would be nice if everywhere behaved the same so that could've been detected earlier.
Which makes sense. I had a similar case in my cec-gpio driver and I had to completely free the interrupt before I could set the direction to output.
I do get nice interrupts when a transmit is done, so the interrupt works correctly. And it correctly detects Ack/Nack.
I looked a bit closer and I see that even without calibration the timings are reasonably OK: 2.3 ms for a bit period instead of the recommended 2.4 ms. Slightly off but within margins.
But receiving messages fails: I get no interrupt at all. Not sure if the lack of calibration is the cause of that, or if it is something else. I can take another look once the calibration is fixed.
Unfortuantely NXP don't document what the allowable tolerances are for the chip. I'd suggest getting the calibration working correctly would be a good first step.