[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230515112554.GA10825@google.com>
Date: Mon, 15 May 2023 12:25:54 +0100
From: Lee Jones <lee@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Charles Keepax <ckeepax@...nsource.cirrus.com>, broonie@...nel.org,
robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
conor+dt@...nel.org, tglx@...utronix.de, linus.walleij@...aro.org,
vkoul@...nel.org, lgirdwood@...il.com,
yung-chuan.liao@...ux.intel.com, sanyog.r.kale@...el.com,
pierre-louis.bossart@...ux.intel.com, alsa-devel@...a-project.org,
patches@...nsource.cirrus.com, devicetree@...r.kernel.org,
linux-gpio@...r.kernel.org, linux-spi@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 07/10] irqchip/cs42l43: Add support for the cs42l43 IRQs
On Fri, 12 May 2023, Marc Zyngier wrote:
> On Fri, 12 May 2023 16:39:33 +0100,
> Charles Keepax <ckeepax@...nsource.cirrus.com> wrote:
> >
> > On Fri, May 12, 2023 at 04:10:05PM +0100, Marc Zyngier wrote:
> > > On Fri, 12 May 2023 13:28:35 +0100,
> > > Charles Keepax <ckeepax@...nsource.cirrus.com> wrote:
> > > >
> > > > The CS42L43 is an audio CODEC with integrated MIPI SoundWire interface
> > > > (Version 1.2.1 compliant), I2C, SPI, and I2S/TDM interfaces designed
> > > > for portable applications. It provides a high dynamic range, stereo
> > > > DAC for headphone output, two integrated Class D amplifiers for
> > > > loudspeakers, and two ADCs for wired headset microphone input or
> > > > stereo line input. PDM inputs are provided for digital microphones.
> > > >
> > > > The IRQ chip provides IRQ functionality both to other parts of the
> > > > cs42l43 device and to external devices that wish to use its IRQs.
> > >
> > > Sorry, but this isn't much of an interrupt controller driver. A modern
> > > interrupt controller driver is firmware-driven (DT or ACPI, pick your
> > > poison), uses irq domains, and uses the irqchip API.
> > >
> >
> > Apologies but I really need a little help clarifying the issues
> > here. I am totally happy to fix things up but might need a couple
> > pointers.
> >
> > 1) uses the irqchip API / uses irq domains
> >
> > The driver does use both the irqchip API and domains, what
> > part of the IRQ API are we not using that we should be?
> >
> > The driver registers an irq domain using
> > irq_domain_create_linear. It requests its parent IRQ using
> > request_threaded_irq. It passes IRQs onto the devices requesting
> > IRQs from it using handle_nested_irq and irq_find_mapping.
> >
> > Is the objection here that regmap is making these calls for us,
> > rather than them being hard coded into this driver?
>
> That's one of the reasons. Look at the existing irqchip drivers: they
> have nothing in common with yours. The regmap irqchip abstraction may
> be convenient for what you are doing, but the result isn't really an
> irqchip driver. It is something that is a small bit of a larger device
> and not an interrupt controller driver on its own. The irqchip
> subsystem is there for "first class" interrupt controllers.
I'm not aware of another subsystem that deals with !IRQChip level IRQ
controllers. Where do simple or "second class" interrupt controllers
go?
--
Lee Jones [李琼斯]
Powered by blists - more mailing lists