From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=-6.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,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 8C82BC33C9E for ; Tue, 14 Jan 2020 16:46:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 5D3EB24656 for ; Tue, 14 Jan 2020 16:46:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726669AbgANQqS (ORCPT ); Tue, 14 Jan 2020 11:46:18 -0500 Received: from muru.com ([72.249.23.125]:50930 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728777AbgANQqR (ORCPT ); Tue, 14 Jan 2020 11:46:17 -0500 Received: from atomide.com (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 60F9F816C; Tue, 14 Jan 2020 16:46:58 +0000 (UTC) Date: Tue, 14 Jan 2020 08:46:13 -0800 From: Tony Lindgren To: "H. Nikolaus Schaller" Cc: linux-omap@vger.kernel.org, =?utf-8?Q?Beno=C3=AEt?= Cousson , devicetree@vger.kernel.org, Matthijs van Duin , Peter Ujfalusi , Tero Kristo Subject: Re: [PATCH] ARM: dts: Configure omap5 AESS Message-ID: <20200114164613.GR5885@atomide.com> References: <20200114150937.18304-1-tony@atomide.com> <52905C15-A2D1-4372-9781-D602D0B274B6@goldelico.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52905C15-A2D1-4372-9781-D602D0B274B6@goldelico.com> Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org * H. Nikolaus Schaller [200114 16:38]: > Hi Tony, > > > Am 14.01.2020 um 16:09 schrieb Tony Lindgren : > > > > We are missing AESS for omap5. Looks like it's similar to what we have > > for omap4, and this gets ti-sysc interconnect target module driver to > > detect it properly. > > > > Note that we currently have no child device driver available for it. > > What I have is a non-working and no more compiling driver originally written by > Peter Ujfalusi and reworked by Andrej Utkin. We did have it almost running on > v4.14 or so except problems with firmware versions and headers... > > There we used classical hwmods and I could revert them now to try your new patches. > Unfortunately, I could only compile-test your two patches but nothing with AESS. > > We had tried to follow kernel API changes in the sound subsystem but today it is > not even compiling any more :( > > So getting a working device driver is an even bigger task than SGX was. OK. Well hopefully that's at least a little bit easier now though. > > Cc: H. Nikolaus Schaller > > Cc: Matthijs van Duin > > Cc: Peter Ujfalusi > > Cc: Tero Kristo > > Signed-off-by: Tony Lindgren > > --- > > > > Note that this depends on "[PATCH] clk: ti: omap5: Add missing AESS clock". > > > > arch/arm/boot/dts/omap5-l4-abe.dtsi | 16 ++++++++++++++-- > > 1 file changed, 14 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/boot/dts/omap5-l4-abe.dtsi b/arch/arm/boot/dts/omap5-l4-abe.dtsi > > --- a/arch/arm/boot/dts/omap5-l4-abe.dtsi > > +++ b/arch/arm/boot/dts/omap5-l4-abe.dtsi > > @@ -426,8 +426,20 @@ target-module@c0000 { /* 0x401c0000, ap 30 1e.0 */ > > }; > > > > target-module@f1000 { /* 0x401f1000, ap 32 20.0 */ > > Here its may be good to have an "aess" label. Care to clarify what you have in mind? The module is generic, aess device will be the child node. How about just a comment for aess? Regards, Tony From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH] ARM: dts: Configure omap5 AESS Date: Tue, 14 Jan 2020 08:46:13 -0800 Message-ID: <20200114164613.GR5885@atomide.com> References: <20200114150937.18304-1-tony@atomide.com> <52905C15-A2D1-4372-9781-D602D0B274B6@goldelico.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <52905C15-A2D1-4372-9781-D602D0B274B6-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: "H. Nikolaus Schaller" Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, =?utf-8?Q?Beno=C3=AEt?= Cousson , devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Matthijs van Duin , Peter Ujfalusi , Tero Kristo List-Id: linux-omap@vger.kernel.org * H. Nikolaus Schaller [200114 16:38]: > Hi Tony, > > > Am 14.01.2020 um 16:09 schrieb Tony Lindgren : > > > > We are missing AESS for omap5. Looks like it's similar to what we have > > for omap4, and this gets ti-sysc interconnect target module driver to > > detect it properly. > > > > Note that we currently have no child device driver available for it. > > What I have is a non-working and no more compiling driver originally written by > Peter Ujfalusi and reworked by Andrej Utkin. We did have it almost running on > v4.14 or so except problems with firmware versions and headers... > > There we used classical hwmods and I could revert them now to try your new patches. > Unfortunately, I could only compile-test your two patches but nothing with AESS. > > We had tried to follow kernel API changes in the sound subsystem but today it is > not even compiling any more :( > > So getting a working device driver is an even bigger task than SGX was. OK. Well hopefully that's at least a little bit easier now though. > > Cc: H. Nikolaus Schaller > > Cc: Matthijs van Duin > > Cc: Peter Ujfalusi > > Cc: Tero Kristo > > Signed-off-by: Tony Lindgren > > --- > > > > Note that this depends on "[PATCH] clk: ti: omap5: Add missing AESS clock". > > > > arch/arm/boot/dts/omap5-l4-abe.dtsi | 16 ++++++++++++++-- > > 1 file changed, 14 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm/boot/dts/omap5-l4-abe.dtsi b/arch/arm/boot/dts/omap5-l4-abe.dtsi > > --- a/arch/arm/boot/dts/omap5-l4-abe.dtsi > > +++ b/arch/arm/boot/dts/omap5-l4-abe.dtsi > > @@ -426,8 +426,20 @@ target-module@c0000 { /* 0x401c0000, ap 30 1e.0 */ > > }; > > > > target-module@f1000 { /* 0x401f1000, ap 32 20.0 */ > > Here its may be good to have an "aess" label. Care to clarify what you have in mind? The module is generic, aess device will be the child node. How about just a comment for aess? Regards, Tony