Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp7822939ybi; Tue, 9 Jul 2019 05:00:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqw76S2eNwpMasg77e/JdvUSNwVa6BNSLyfJDEebhZtazp4mHrORpCOSac3QoeH1eWXfet5o X-Received: by 2002:a63:58c:: with SMTP id 134mr31384061pgf.106.1562673640822; Tue, 09 Jul 2019 05:00:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562673640; cv=none; d=google.com; s=arc-20160816; b=f0SMRHQpZyINnhfBfQf8CJc2IuhGQtEHXTWKa7x80eLTd3P0/xSC6o/Us1ju394B96 nc2y3hU7/iNOAYjSlv/DJrg2HQUxdrc5DMZzVJXQ+UdVPYXQ7Ns82fvnReTRQpVfy/uI 94lWp9osXIMwOLseAk07B/H7H2BrAgevvM2x5fpp0ssabtc7BfrCTHaR2suKFi2RxfHR u+jWUCxL2CYz1u9FBoUzcT7BMUQBgO+oRGmvOgn+gs7nfC4mos7fm3J6y8cpoTx0T/nn +bDmK95AjonMn+ph2pqDB0GCmAW5ALta5GRH8SJQ6wyXV57HidDtbIIA3/59hZ5SeClU 79BQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=RiTv9D9r+HWewv08+uDjzds8jJ160NpsMW3nG+2KdoY=; b=G5jR+vwOBuTMWbeVNmZqGwUTH5eZ+w9yuoofoZcOwPY4KmuYMhn54GKofmmIh/C0Iy osDO3/XqK96mj5Q7yzOhOvJ/h0bkwVwdw1B31O8yH/l2U6c9ONk2Mwrdp8VdJmm6tbQ8 75Lk3/Xld22nPHDtwuumCLLZD9r5LCXltVJ8eC+3P4/y635s2HhPwe69PxkoZgwUZc4e Kux3KmpmqfcVi5YkN/AXDG6WEAkS51tqCrljgeiE5nVCsshEQpSi0CPm2903L2I8tHNU 7zGrkaRPKpgKYc9PnCv4NOL3a12yjDluTZLtavUP35BnStOJVsMsh2UV3YuupOs8/H1I Uk/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=b6eUu3HO; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z13si23926384pfr.86.2019.07.09.05.00.25; Tue, 09 Jul 2019 05:00:40 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=b6eUu3HO; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726403AbfGIL7Z (ORCPT + 99 others); Tue, 9 Jul 2019 07:59:25 -0400 Received: from mail-vs1-f65.google.com ([209.85.217.65]:37598 "EHLO mail-vs1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726002AbfGIL7Y (ORCPT ); Tue, 9 Jul 2019 07:59:24 -0400 Received: by mail-vs1-f65.google.com with SMTP id v6so10448697vsq.4 for ; Tue, 09 Jul 2019 04:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RiTv9D9r+HWewv08+uDjzds8jJ160NpsMW3nG+2KdoY=; b=b6eUu3HOZ32VMVxihS1TEiZDDJGMWpTKkUmCzgDy0Wn1UIqQ2Hg/sRGYSq7RTss8Dt EUsDIbda6QYf9S42qsjMSo76RaQmk/AXAegCp/GvMR+GeNmoH1GewBpHbDxaucdsY43j Ic831T+DuHkmI1k4SYW5LLWcFpi0VyYWE6dxU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RiTv9D9r+HWewv08+uDjzds8jJ160NpsMW3nG+2KdoY=; b=GQ8V/GnNsuh7MwpCdYBGS+SBHOx+ni7/DLPBGxfqi74SLTgRzaMnamrwPKvv3yeej3 kyuOZSvsavl7XWcPdoQ2eCy46IZTeCHEdDwRVMgeZAed7UuBXNVCooNpFFZ46Yqd+2pU rQHVRbvQimbyD4gjvVn2rhtO6VyY4IcpTevCOYQUVjeCP4tlTWWVP148WvxoDnP4VVFI ivG+oY20P8YsH9ZrO0xwGQ9xI2NBttTUtkloyzZkKxv6J9SnhfBriv76A1sH5cq9UfnZ 0R8QqP33Lt2gr++QVDFm/x2PCj9QXRgKYvwkExyk5j/UKZdYnCgOU0Fpcy3pwaxSedy5 0lRA== X-Gm-Message-State: APjAAAUB3KSRZI/HK2VjaRZBogmTpNbiRn9RQBcp6dQXAH9vzluWNzQl OhXfa9V8qF4Gi4Zh7EfHkd6z4zsa6yyFPTtfX3qLpQ== X-Received: by 2002:a67:d386:: with SMTP id b6mr14020005vsj.170.1562673563188; Tue, 09 Jul 2019 04:59:23 -0700 (PDT) MIME-Version: 1.0 References: <20190705042623.129541-1-cychiang@chromium.org> <20190705042623.129541-2-cychiang@chromium.org> <20190705121240.GA20625@sirena.org.uk> In-Reply-To: From: Cheng-yi Chiang Date: Tue, 9 Jul 2019 19:58:56 +0800 Message-ID: Subject: Re: [PATCH 1/4] ASoC: hdmi-codec: Add an op to set callback function for plug event To: Mark Brown Cc: Tzung-Bi Shih , linux-kernel , Hans Verkuil , Liam Girdwood , Takashi Iwai , Jaroslav Kysela , Russell King , Andrzej Hajda , Laurent Pinchart , David Airlie , Daniel Vetter , Heiko Stuebner , Doug Anderson , Dylan Reid , tzungbi@chromium.org, ALSA development , dri-devel@lists.freedesktop.org, linux-arm-kernel@lists.infradead.org, linux-rockchip@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 8, 2019 at 1:03 PM Cheng-yi Chiang wrote: > > On Fri, Jul 5, 2019 at 8:12 PM Mark Brown wrote: > > > > On Fri, Jul 05, 2019 at 03:08:37PM +0800, Tzung-Bi Shih wrote: > > > On Fri, Jul 5, 2019 at 12:26 PM Cheng-Yi Chiang wrote: > > > > > > +typedef void (*hdmi_codec_plugged_cb)(struct platform_device *dev, > > > > + bool plugged); > > > > + > > > > > The callback prototype is "weird" by struct platform_device. Is it > > > possible to having snd_soc_component instead of platform_device? > > > > Or if it's got to be a device why not just a generic device so > > we're not tied to a particular bus here? > > My intention was to invoke the call in dw-hdmi.c like this: > > hdmi->plugged_cb(hdmi->audio, > result == connector_status_connected); > > Here hdmi->audio is a platform_device. > I think dw-hdmi can not get snd_soc_component easily. > I can use a generic device here so the ops is more general. > The calling will be like > hdmi->plugged_cb(&hdmi->audio->dev, > result == connector_status_connected); > I will update this in v2. > Thanks! I have thought about this a bit more. And I think the more proper interface is to pass in a generic struct device* for codec. This way, the user of hdmi-codec driver on the DRM side is not limited to the relation chain of audio platform device -> codec platform device, which is just a special case in dw-hdmi driver. As long as DRM side can get hdmi-codec device pointer through drv_data, it can use this callback. Hope this makes the interface more generic.