[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230816081130.GB103419@ediswmail.ad.cirrus.com>
Date: Wed, 16 Aug 2023 08:11:30 +0000
From: Charles Keepax <ckeepax@...nsource.cirrus.com>
To: James Ogletree <James.Ogletree@...rus.com>
CC: Dmitry Torokhov <dmitry.torokhov@...il.com>,
Fred Treven <Fred.Treven@...rus.com>,
Ben Bright <Ben.Bright@...rus.com>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
"Lee Jones" <lee@...nel.org>, Jeff LaBundy <jeff@...undy.com>,
Joel Stanley <joel@....id.au>, Arnd Bergmann <arnd@...db.de>,
Jacky Bai <ping.bai@....com>, Jean Delvare <jdelvare@...e.de>,
Eddie James <eajames@...ux.ibm.com>,
Markus Schneider-Pargmann <msp@...libre.com>,
ChiYuan Huang <cy_huang@...htek.com>,
Randy Dunlap <rdunlap@...radead.org>,
Wolfram Sang <wsa+renesas@...g-engineering.com>,
"patches@...nsource.cirrus.com" <patches@...nsource.cirrus.com>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 2/2] Input: cs40l50 - Initial support for Cirrus Logic
CS40L50
On Tue, Aug 15, 2023 at 10:33:00PM +0000, James Ogletree wrote:
>
>
> > On Aug 10, 2023, at 5:30 AM, Charles Keepax <ckeepax@...nsource.cirrus.com> wrote:
> >
> > On Wed, Aug 09, 2023 at 07:10:28PM +0000, James Ogletree wrote:
> >> +
> >> +static int cs40l50_pseq_write(struct cs40l50_private *cs40l50, u32 addr, u32 data)
> >> +{
> >> +
> >> +static int cs40l50_owt_upload(struct cs40l50_private *cs40l50, s16 *in_data, u32 in_data_nibbles)
> >> +{
> >
> > These pseq and OWT bits, could they be shared with l26?
> > Definitely worth syncing with those guys, my assumption is the
> > wavetable/pseq won't have changed much and it might be nice to
> > factor these bits out into some library code that both drivers
> > can use.
>
> The pseq code most certainly can, likely the OWT code, perhaps others. I assume it is
> acceptable to move some of these functions to a library in this patch set, even though this is
> the only driver utilizing them as far as mainline is concerned? In other words, we shouldn’t
> wait for one of L26 or L50 drivers to be accepted before splitting off the common code as part
> of the others’ patchset? I’m probably overcomplicating; just want to be sure on the process here.
>
> Everything else in your review will be fixed in V4. Thank you.
>
I think this makes sense to do now, just need to make sure the
next series of L26 is synced up to it.
Thanks,
Charles
Powered by blists - more mailing lists