From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=yjy/=OW=vger.kernel.org=linux-kernel-owner@kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0
Received: from mail.kernel.org (mail.kernel.org [198.145.29.99])
	by smtp.lore.kernel.org (Postfix) with ESMTP id 16ADDC67839
	for <linux-kernel@archiver.kernel.org>; Thu, 13 Dec 2018 00:24:12 +0000 (UTC)
Received: from vger.kernel.org (vger.kernel.org [209.132.180.67])
	by mail.kernel.org (Postfix) with ESMTP id D6A7A20811
	for <linux-kernel@archiver.kernel.org>; Thu, 13 Dec 2018 00:24:11 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D6A7A20811
Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=renesas.com
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1728546AbeLMAYK (ORCPT
        <rfc822;linux-kernel@archiver.kernel.org>);
        Wed, 12 Dec 2018 19:24:10 -0500
Received: from relmlor2.renesas.com ([210.160.252.172]:10554 "EHLO
        relmlie6.idc.renesas.com" rhost-flags-OK-OK-OK-FAIL)
        by vger.kernel.org with ESMTP id S1726278AbeLMAYK (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 12 Dec 2018 19:24:10 -0500
Date:   13 Dec 2018 09:24:06 +0900
X-IronPort-AV: E=Sophos;i="5.56,346,1539615600"; 
   d="scan'208";a="2455728"
Received: from unknown (HELO relmlir5.idc.renesas.com) ([10.200.68.151])
  by relmlie6.idc.renesas.com with ESMTP; 13 Dec 2018 09:24:06 +0900
Received: from morimoto-PC.renesas.com (unknown [10.166.18.140])
        by relmlir5.idc.renesas.com (Postfix) with ESMTP id C3CEE401428E;
        Thu, 13 Dec 2018 09:24:06 +0900 (JST)
Message-ID: <87imzy2sh1.wl-kuninori.morimoto.gx@renesas.com>
From:   Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
To:     Tony Lindgren <tony@atomide.com>
Cc:     "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
        "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
        Liam Girdwood <lgirdwood@gmail.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Takashi Iwai <tiwai@suse.com>,
        Peter Ujfalusi <peter.ujfalusi@ti.com>,
        Mark Brown <broonie@kernel.org>,
        Sebastian Reichel <sre@kernel.org>,
        Jarkko Nikula <jarkko.nikula@bitmer.com>
Subject: Re: [alsa-devel] [PATCH 0/2] Graph fixes for using multiple    endpoints per port
In-Reply-To: <20181212152725.GE6707@atomide.com>
References: <8736r4bvf3.wl-kuninori.morimoto.gx@renesas.com>
        <20181211045220.GI6707@atomide.com>
        <871s6obqkb.wl-kuninori.morimoto.gx@renesas.com>
        <20181211053536.GJ6707@atomide.com>
        <87wooga9an.wl-kuninori.morimoto.gx@renesas.com>
        <20181211141649.GL6707@atomide.com>
        <87ftv33bpg.wl-kuninori.morimoto.gx@renesas.com>
        <20181212001950.GX6707@atomide.com>
        <877egf33m9.wl-kuninori.morimoto.gx@renesas.com>
        <87k1kfs0u5.wl-kuninori.morimoto.gx@renesas.com>
        <20181212152725.GE6707@atomide.com>
User-Agent: Wanderlust/2.15.9 Emacs/24.5 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


Hi Tony

>  	/* Codec has 1 DAI */
>  	Codec {
>  		port {
> 			#address-cells = <2>;
> 			#size-cells = <1>;
> 
>  			ep: endpoint {
>  				remote-endpoint = <xxx>;
>  			};
>  		};
>  	}
(snip)
> foo = <&ep 0>;
> bar = <&ep 1>;

Ahh, it looks nice idea !
but hmm..., it seems dtc doesn't allow us to use #address-cells = <2>
for "remote-endpoint".

--- ${LINUX}/scripts/dtc/checks.c ---
static struct node *get_remote_endpoint(struct check *c, struct dt_info *dti,
					struct node *endpoint)
{
	...
	prop = get_property(endpoint, "remote-endpoint");
	if (!prop)
		return NULL;

=>	phandle = propval_cell(prop);
	/* Give up if this is an overlay with external references */
	...
}

I'm not good at dtc, but propval_cell() is assuming it is single address cell.
We will have many assert warning on

	remote-endpoint = <&xxx 0>;

Can you please double check it ?

And, I'm wonder remote-endpoint need to cross pointing, right ?
one way looks nice by address-cells <2>, but other way is ?

	port {
		cpu-ep0: endpoint@0 {
			remote-endpoint = <&codec-ep 0>;
		};
		cpu-ep1: endpoint@1 {
			remote-endpoint = <&codec-ep 1>;
		};
	};

	port {
		#address-cells = <2>;
		#size-cells = <1>;
		codec-ep: endpoint {
(*1)			remote-endpoint = <&cpu-ep0>;
		};
	};

This case, cpu-epX -> codec-ep are OK.
But, codec-ep -> cpu-epX case can point only 1 endpoint (*1).
I'm not sure, but maybe this is not a OF graph policy (?)

> > Can you agree this ? we need extra patch,
> > but it can solve your / my problem.
> 
> Yes it's starting to make sense :)

Thanks

> > Now I'm posting patches to merging
> > "audio-graph-card" and "DPCM ver audio-graph-card".
> > If you are OK, I will include above solution patch
> > to this patch-set.
> 
> Sure, maybe please first check if the #size-cells = <2>
> option would work though?

maybe #address-cells, instead of #size-cells ;P
But, yeah, please double check it too.

> > Current audio-graph doesn't expect your use-case,
> > and I want to avoid conflict.
> > 
> > So, "merged" audio-graph should solve your use-case.
> > If you can agree about this, I will post patch-set.
> 
> Yeah I agree, just still wondering what might be the best
> way to represent 1 DAI vs 2 DAIs.

According to OF graph maintainer, he said that
counting port / endpoint are not guaranteed,
and we need to use "reg".
(It is the reason of b6f3fc005a2c8b425d7a0973b43bef05890bf479)

If you could double checked, and we could agreed
that "reg" is the solution for us.
I will post patches.

Best regards
---
Kuninori Morimoto