mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hans Verkuil <hansverk@cisco.com>
To: ektor5 <ek5.chimenti@gmail.com>, Hans Verkuil <hverkuil@xs4all.nl>
Cc: luca.pisani@udoo.org, jose.abreu@synopsys.com, sean@mess.org,
	sakari.ailus@linux.intel.com, jacopo@jmondi.org,
	Mauro Carvalho Chehab <mchehab@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"David S. Miller" <davem@davemloft.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Hans Verkuil <hans.verkuil@cisco.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Todor Tomov <todor.tomov@linaro.org>,
	Maxime Ripard <maxime.ripard@bootlin.com>,
	Jacopo Mondi <jacopo+renesas@jmondi.org>,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org
Subject: Re: [PATCH v3 1/2] media: add SECO cec driver
Date: Fri, 19 Oct 2018 15:19:45 +0200	[thread overview]
Message-ID: <0ae193a7-b651-0564-c4de-a159b1e2bfb2@cisco.com> (raw)
In-Reply-To: <20181019130205.lqb3sopqqangefr4@Ettosoft-T55>

On 10/19/18 15:02, ektor5 wrote:
> Hi Hans,
> 
> On Thu, Oct 18, 2018 at 09:14:55AM +0200, Hans Verkuil wrote:
>> Hi Ettore,
>>
>> Just a few small things and it is ready to go:
>>
>> On 10/17/2018 11:31 PM, ektor5 wrote:
>>> From: Ettore Chimenti <ek5.chimenti@gmail.com>
>>>
>>> This patch adds support to the CEC device implemented with a STM32
>>> microcontroller in X86 SECO Boards, including UDOO X86.
>>>
>>> The communication is achieved via Braswell integrated SMBus
>>> (i2c-i801). The driver use direct access to the PCI addresses, due to
>>> the limitations of the specific driver in presence of ACPI calls.
>>>
>>> The basic functionalities are tested with success with cec-ctl and
>>> cec-compliance.
>>>
>>> Inspired by cros-ec-cec implementation, attaches to i915 driver
>>> cec-notifier.
>>>
>>> Signed-off-by: Ettore Chimenti <ek5.chimenti@gmail.com>
>>> ---
>>>  MAINTAINERS                                |   6 +
>>>  drivers/media/platform/Kconfig             |  12 +
>>>  drivers/media/platform/Makefile            |   2 +
>>>  drivers/media/platform/seco-cec/Makefile   |   1 +
>>>  drivers/media/platform/seco-cec/seco-cec.c | 699 +++++++++++++++++++++
>>>  drivers/media/platform/seco-cec/seco-cec.h | 130 ++++
>>>  6 files changed, 850 insertions(+)
>>>  create mode 100644 drivers/media/platform/seco-cec/Makefile
>>>  create mode 100644 drivers/media/platform/seco-cec/seco-cec.c
>>>  create mode 100644 drivers/media/platform/seco-cec/seco-cec.h

<snip>

>>> +static int secocec_adap_log_addr(struct cec_adapter *adap, u8 logical_addr)
>>> +{
>>> +	u16 enable_val = 0;
>>> +	int status;
>>
>> If logical_addr == CEC_LOG_ADDR_INVALID, then this function must not return
>> an error or the CEC framework will WARN about it.
>>
>>> +
>>> +	/* Disable device */
>>> +	status = smb_rd16(SECOCEC_ENABLE_REG_1, &enable_val);
>>> +	if (status)
>>> +		return status;
>>> +
>>> +	status = smb_wr16(SECOCEC_ENABLE_REG_1,
>>> +			  enable_val & ~SECOCEC_ENABLE_REG_1_CEC);
>>> +	if (status)
>>> +		return status;
>>> +
>>> +	/* Write logical address */
>>> +	status = smb_wr16(SECOCEC_DEVICE_LA, logical_addr);
>>
>> So does writing CEC_LOG_ADDR_INVALID (0xff) invalidate all logical
>> addresses? I see no special code for that. If that is indeed the
>> case, then you should document this.
> 
> The micro can have only one LA at a time. 
> 
> In the micro datasheet there isn't any reference to an invalid addr, so
> it shouldn't complain. It will just set LA = 0xf. Is this correct or it
> should disable the device instead?

Setting it to 0xf is OK, but you might want to write 'logical_addr & 0xf'
to the register with a note that CEC_LOG_ADDR_INVALID is mapped to the
'Unregistered' logical address.

> 
>>
>>> +	if (status)
>>> +		return status;
>>> +
>>> +	/* Re-enable device */
>>> +	status = smb_wr16(SECOCEC_ENABLE_REG_1,
>>> +			  enable_val | SECOCEC_ENABLE_REG_1_CEC);
>>> +	if (status)
>>> +		return status;
>>> +
>>> +	return 0;
>>> +}
>>> +
>>> +static int secocec_adap_transmit(struct cec_adapter *adap, u8 attempts,
>>> +				 u32 signal_free_time, struct cec_msg *msg)
>>> +{
>>> +	struct secocec_data *cec = cec_get_drvdata(adap);
>>> +	struct device *dev = cec->dev;
>>> +	u16 payload_len, payload_id_len, destination, val = 0;
>>> +	u8 *payload_msg;
>>> +	int status;
>>> +	u8 i;
>>> +
>>> +	/* Device msg len already accounts for header */
>>> +	payload_id_len = msg->len - 1;
>>> +
>>> +	/* Send data length */
>>> +	status = smb_wr16(SECOCEC_WRITE_DATA_LENGTH, payload_id_len);
>>> +	if (status)
>>> +		goto err;
>>> +
>>> +	/* Send Operation ID if present */
>>> +	if (payload_id_len > 0) {
>>> +		status = smb_wr16(SECOCEC_WRITE_OPERATION_ID, msg->msg[1]);
>>> +		if (status)
>>> +			goto err;
>>> +	}
>>> +	/* Send data if present */
>>> +	if (payload_id_len > 1) {
>>> +		/* Only data; */
>>> +		payload_len = msg->len - 2;
>>> +		payload_msg = &msg->msg[2];
>>> +
>>> +		/* Copy message into registers */
>>> +		for (i = 0; i < payload_len; i += 2) {
>>> +			/* hi byte */
>>> +			val = payload_msg[i + 1] << 8;
>>> +
>>> +			/* lo byte */
>>> +			val |= payload_msg[i];
>>> +
>>> +			status = smb_wr16(SECOCEC_WRITE_DATA_00 + i / 2, val);
>>> +			if (status)
>>> +				goto err;
>>> +		}
>>> +	}
>>> +	/* Send msg source/destination and fire msg */
>>> +	destination = msg->msg[0];
>>> +	status = smb_wr16(SECOCEC_WRITE_BYTE0, destination);
>>> +	if (status)
>>> +		goto err;
>>> +
>>> +	return 0;
>>> +
>>> +err:
>>> +	dev_err(dev, "Transmit failed (%d)", status);
>>
>> You can drop this: the cec module has already debug code for that.
>>
>>> +	return status;
>>> +}
>>> +
>>> +static int secocec_tx_done(struct cec_adapter *adap, u16 status_val)
>>
>> Just return void since the return code is ignored anyway.
> 
> Ok, will drop those.
> 
>>
>>> +{
>>> +	int status = 0;
>>> +
>>> +	if (status_val & SECOCEC_STATUS_TX_ERROR_MASK) {
>>> +		if (status_val & SECOCEC_STATUS_TX_NACK_ERROR) {
>>> +			cec_transmit_attempt_done(adap, CEC_TX_STATUS_NACK);
>>> +			status = -EAGAIN;
>>> +		} else {
>>> +			cec_transmit_attempt_done(adap, CEC_TX_STATUS_ERROR);
>>> +			status = -EIO;
>>> +		}
>>> +	} else {
>>> +		cec_transmit_attempt_done(adap, CEC_TX_STATUS_OK);
>>> +	}
>>> +
>>> +	/* Reset status reg */
>>> +	status_val = SECOCEC_STATUS_TX_ERROR_MASK |
>>> +		SECOCEC_STATUS_MSG_SENT_MASK |
>>> +		SECOCEC_STATUS_TX_NACK_ERROR;
>>> +	smb_wr16(SECOCEC_STATUS, status_val);
>>> +
>>> +	return status;
>>> +}
>>> +
>>> +static int secocec_rx_done(struct cec_adapter *adap, u16 status_val)
>>> +{
>>
>> Ditto.
>>
>>> +	struct secocec_data *cec = cec_get_drvdata(adap);
>>> +	struct device *dev = cec->dev;
>>> +	struct cec_msg msg = { };
>>> +	bool flag_overflow = false;
>>> +	u8 payload_len, i = 0;
>>> +	u8 *payload_msg;
>>> +	u16 val = 0;
>>> +	int status;
>>> +
>>> +	if (status_val & SECOCEC_STATUS_RX_OVERFLOW_MASK) {
>>> +		dev_warn(dev, "Received more than 16 bytes. Discarding");
>>
>> Is it better to just receive the first 16 bytes?
> 
> In case of an overflow, it should discard the overflowing bytes, but I
> don't have any equipment that can test this. (this device can send up to
> 16 bytes).

Add a note that this might not be necessary, but that you couldn't test
this. I can test it when I find some time.

> 
>>
>>> +		flag_overflow = true;
>>> +	}

Regards,

	Hans


  reply	other threads:[~2018-10-19 13:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-17 21:31 [PATCH v3 0/2] Add SECO Boards CEC device driver ektor5
2018-10-17 21:31 ` [PATCH v3 1/2] media: add SECO cec driver ektor5
2018-10-18  7:14   ` Hans Verkuil
2018-10-19 13:02     ` ektor5
2018-10-19 13:19       ` Hans Verkuil [this message]
2018-10-18  8:47   ` jacopo mondi
2018-10-19 14:44     ` ektor5
2018-10-17 21:31 ` [PATCH v3 2/2] seco-cec: add Consumer-IR support ektor5

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=0ae193a7-b651-0564-c4de-a159b1e2bfb2@cisco.com \
    --to=hansverk@cisco.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=ek5.chimenti@gmail.com \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hans.verkuil@cisco.com \
    --cc=hverkuil@xs4all.nl \
    --cc=jacopo+renesas@jmondi.org \
    --cc=jacopo@jmondi.org \
    --cc=jose.abreu@synopsys.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=luca.pisani@udoo.org \
    --cc=maxime.ripard@bootlin.com \
    --cc=mchehab@kernel.org \
    --cc=narmstrong@baylibre.com \
    --cc=sakari.ailus@linux.intel.com \
    --cc=sean@mess.org \
    --cc=todor.tomov@linaro.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

all inboxes | Powered by JetHome®