devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ludwig Zenz <lzenz@dh-electronics.com>
To: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Cc: "Matti.Vaittinen@fi.rohmeurope.com" 
	<Matti.Vaittinen@fi.rohmeurope.com>,
	"andriy.shevchenko@intel.com" <andriy.shevchenko@intel.com>,
	"andriy.shevchenko@linux.intel.com" 
	<andriy.shevchenko@linux.intel.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"hverkuil@xs4all.nl" <hverkuil@xs4all.nl>,
	"khalasa@piap.pl" <khalasa@piap.pl>,
	"krzysztof.kozlowski+dt@linaro.org" 
	<krzysztof.kozlowski+dt@linaro.org>,
	"laurent.pinchart+renesas@ideasonboard.com" 
	<laurent.pinchart+renesas@ideasonboard.com>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"luca.ceresoli@bootlin.com" <luca.ceresoli@bootlin.com>,
	"m.tretter@pengutronix.de" <m.tretter@pengutronix.de>,
	"marex@denx.de" <marex@denx.de>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"mpagano@gentoo.org" <mpagano@gentoo.org>,
	"peda@axentia.se" <peda@axentia.se>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"sakari.ailus@linux.intel.com" <sakari.ailus@linux.intel.com>,
	"satish.nagireddy@getcruise.com" <satish.nagireddy@getcruise.com>,
	"wsa@kernel.org" <wsa@kernel.org>
Subject: Re: [PATCH v13 6/8] media: i2c: add DS90UB960 driver
Date: Mon, 22 May 2023 11:42:24 +0000	[thread overview]
Message-ID: <d7e992a23c7d40b09e0a931bd6857d53@dh-electronics.com> (raw)

> On 16/05/2023 22:05, Ludwig Zenz wrote:
>>> On 16/05/2023 16:32, Ludwig Zenz wrote:
>>>>> Hi,
>>>>>
>>>>> On 16/05/2023 15:35, Ludwig Zenz wrote:
>>>>>> On Wed, 26 Apr 2023 14:51:12 +0300, Tomi Valkeinen wrote:
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>>     +static int ub960_configure_ports_for_streaming(struct ub960_data *priv,
>>>>>>>     +                                         struct v4l2_subdev_state *state)
>>>>>>>     +{
>>>>>>>     +  u8 fwd_ctl;
>>>>>>>     +  struct {
>>>>>>>     +          u32 num_streams;
>>>>>>>     +          u8 pixel_dt;
>>>>>>>     +          u8 meta_dt;
>>>>>>>     +          u32 meta_lines;
>>>>>>>     +          u32 tx_port;
>>>>>>>     +  } rx_data[UB960_MAX_RX_NPORTS] = {};
>>>>>>>     +  u8 vc_map[UB960_MAX_RX_NPORTS] = {};
>>>>>>>     +  struct v4l2_subdev_route *route;
>>>>>>>     +  unsigned int nport;
>>>>>>>     +  int ret;
>>>>>>>     +
>>>>>>>     +  ret = ub960_validate_stream_vcs(priv);
>>>>>>>     +  if (ret)
>>>>>>>     +          return ret;
>>>>>>>     +
>>>>>>>     +  ub960_get_vc_maps(priv, state, vc_map);
>>>>>>>     +
>>>>>>>     +  for_each_active_route(&state->routing, route) {
>>>>>>>     +          struct ub960_rxport *rxport;
>>>>>>>     +          struct ub960_txport *txport;
>>>>>>>     +          struct v4l2_mbus_framefmt *fmt;
>>>>>>>     +          const struct ub960_format_info *ub960_fmt;
>>>>>>>     +          unsigned int nport;
>>>>>>>     +
>>>>>>>     +          nport = ub960_pad_to_port(priv, route->sink_pad);
>>>>>>>     +
>>>>>>>     +          rxport = priv->rxports[nport];
>>>>>>>     +          if (!rxport)
>>>>>>>     +                  return -EINVAL;
>>>>>>>     +
>>>>>>>     +          txport = priv->txports[ub960_pad_to_port(priv, route->source_pad)];
>>>>>>>     +          if (!txport)
>>>>>>>     +                  return -EINVAL;
>>>>>>>     +
>>>>>>>     +          rx_data[nport].tx_port = ub960_pad_to_port(priv, route->source_pad);
>>>>>>>     +
>>>>>>>     +          rx_data[nport].num_streams++;
>>>>>>>     +
>>>>>>>     +          /* For the rest, we are only interested in parallel busses */
>>>>>>>     +          if (rxport->rx_mode == RXPORT_MODE_CSI2_SYNC ||
>>>>>>>     +              rxport->rx_mode == RXPORT_MODE_CSI2_ASYNC)
>>>>>>>     +                  continue;
>>>>>>>     +
>>>>>>>     +          if (rx_data[nport].num_streams > 2)
>>>>>>>     +                  return -EPIPE;
>>>>>>>     +
>>>>>>>     +          fmt = v4l2_subdev_state_get_stream_format(state,
>>>>>>>     +                                                    route->sink_pad,
>>>>>>>     +                                                    route->sink_stream);
>>>>>>>     +          if (!fmt)
>>>>>>>     +                  return -EPIPE;
>>>>>>>     +
>>>>>>>     +          ub960_fmt = ub960_find_format(fmt->code);
>>>>>>>     +          if (!ub960_fmt)
>>>>>>>     +                  return -EPIPE;
>>>>>>>     +
>>>>>>>     +          if (ub960_fmt->meta) {
>>>>>>>     +                  if (fmt->height > 3) {
>>>>>>>     +                          dev_err(&priv->client->dev,
>>>>>>>     +                                  "rx%u: unsupported metadata height %u\n",
>>>>>>>     +                                  nport, fmt->height);
>>>>>>>     +                          return -EPIPE;
>>>>>>>     +                  }
>>>>>>>     +
>>>>>>>     +                  rx_data[nport].meta_dt = ub960_fmt->datatype;
>>>>>>>     +                  rx_data[nport].meta_lines = fmt->height;
>>>>>>>     +          } else {
>>>>>>>     +                  rx_data[nport].pixel_dt = ub960_fmt->datatype;
>>>>>>>     +          }
>>>>>>>     +  }
>>>>>>>     +
>>>>>>>     +  /* Configure RX ports */
>>>>>>>     +
>>>>>>>     +  fwd_ctl = 0;
>>>>>>
>>>>>> Hello, I have only used the first RX port in my setup (ds90ub933 to ds90ub964). The logic for activating/deactivating the Rx ports did not work for me. My suggestion is:
>>>>>>
>>>>> Why doesn't it work? What happens?
>>>>>
>>>>>    Tomi
>>>>
>>>> Hello Tomi,
>>>>
>>>> the port rx0 which I need was disabled and the other ports rx1 to rx3 were enabled. In other words, the exact inverse of the required selection.
>>>>
>>>>>>>    +                /* Forwarding */
>>>>>>>    +
>>>>>>>    +                fwd_ctl |= BIT(4 + nport); /* forward disable */
>>>> According to the data sheet, a set bit4-7 in fwd_ctl means that the channel is disabled. So the comment 'forward disable' is correct. While debugging, however, this code was only reached for the ports to be enabled but not for the ones which should be disabled.
>>
>>> This is just a setup phase, where we initialize the registers for the ports we want to use. The forwarding is then enabled later, in ub960_enable_rx_port, and even later disabled in ub960_disable_rx_port.
>>
>> Thank you for the clarification. I had misinterpreted the intention of the code here.
>>
>>> This assumes that the forwarding is disabled in the registers by default (which it is in UB960).
>>>
>>> I need to try this on my HW to verify my understanding is correct, but looking at the code, it is indeed a bit buggy.
>>>
>>> At this setup phase we disable the forwarding for ports we'll use, and enable the forwarding for ports we don't use (which doesn't make sense).
>>> Later, when the streaming is started for that port, we enable the forwarding. So here we should just always disable the forwarding for all ports.
>>>
>>
>> The unused Rx ports were not disabled in my tests. Disabling all ports here should also work for my setup.
>>
>>> Saying "disable the forwarding" is perhaps a bit confusing here, as the the
> forwarding should already be disabled in the HW here anyway. But as we write
> the UB960_SR_FWD_CTL1, we need to set that bit.
>>>
>>> So. You should see the rx0 getting enabled (later, in ub960_enable_rx_port),
> and I'm curious why you don't see that.
>>
>> I will have another look at that next week. It could well be that in the end only
> the enabled but unused ports are the problem.
> 
> This should fix the issue:
> 
> @ -2486,7 +2488,7 @@ static int
> ub960_configure_ports_for_streaming(struct ub960_data *priv,
> 
>          /* Configure RX ports */
> 
> -       fwd_ctl = 0;
> +       fwd_ctl = GENMASK(7, 4);
> 
>          for (nport = 0; nport < priv->hw_data->num_rxports; nport++) {
>                  struct ub960_rxport *rxport = priv->rxports[nport]; @@ -2536,8
> +2538,6 @@ static int ub960_configure_ports_for_streaming(struct
> ub960_data *priv,
> 
>                  /* Forwarding */
> 
> -               fwd_ctl |= BIT(4 + nport); /* forward disable */
> -
>                  if (rx_data[nport].tx_port == 1)
>                          fwd_ctl |= BIT(nport); /* forward to TX1 */
>                  else
> 

Hello Tomi,

yes, this does fix the issue. I was able to test it successfully today with my hardware (ds90ub933 + ds90ub964 + i.MX8Mplus).

Thanks and regards,
Ludwig

             reply	other threads:[~2023-05-22 11:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-22 11:42 Ludwig Zenz [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-05-16 19:05 [PATCH v13 6/8] media: i2c: add DS90UB960 driver Ludwig Zenz
2023-05-19 12:19 ` Tomi Valkeinen
2023-05-16 13:32 Ludwig Zenz
2023-05-16 13:58 ` Tomi Valkeinen
2023-04-26 11:51 [PATCH v13 0/8] i2c-atr and FPDLink Tomi Valkeinen
2023-04-26 11:51 ` [PATCH v13 6/8] media: i2c: add DS90UB960 driver Tomi Valkeinen
2023-05-16 12:35   ` Ludwig Zenz
2023-05-16 13:02     ` Tomi Valkeinen
2023-05-16 12:44   ` Sakari Ailus

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=d7e992a23c7d40b09e0a931bd6857d53@dh-electronics.com \
    --to=lzenz@dh-electronics.com \
    --cc=Matti.Vaittinen@fi.rohmeurope.com \
    --cc=andriy.shevchenko@intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=hverkuil@xs4all.nl \
    --cc=khalasa@piap.pl \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=luca.ceresoli@bootlin.com \
    --cc=m.tretter@pengutronix.de \
    --cc=marex@denx.de \
    --cc=mchehab@kernel.org \
    --cc=mpagano@gentoo.org \
    --cc=peda@axentia.se \
    --cc=robh+dt@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=satish.nagireddy@getcruise.com \
    --cc=tomi.valkeinen@ideasonboard.com \
    --cc=wsa@kernel.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).