* Re: [RESEND PATCH v4 3/3] perf/marvell : Odyssey LLC-TAD performance monitor
From: kernel test robot @ 2024-03-28 15:01 UTC (permalink / raw)
To: Gowthami Thiagarajan, will, mark.rutland, linux-arm-kernel,
linux-kernel
Cc: oe-kbuild-all, sgoutham, bbhushan2, gcherian,
Gowthami Thiagarajan
In-Reply-To: <20240327071832.1556576-4-gthiagarajan@marvell.com>
Hi Gowthami,
kernel test robot noticed the following build warnings:
[auto build test WARNING on soc/for-next]
[also build test WARNING on linus/master v6.9-rc1 next-20240328]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Gowthami-Thiagarajan/perf-marvell-Refactor-to-extract-platform-data/20240327-152242
base: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git for-next
patch link: https://lore.kernel.org/r/20240327071832.1556576-4-gthiagarajan%40marvell.com
patch subject: [RESEND PATCH v4 3/3] perf/marvell : Odyssey LLC-TAD performance monitor
config: alpha-randconfig-r071-20240328 (https://download.01.org/0day-ci/archive/20240328/202403282246.ybWRrXj7-lkp@intel.com/config)
compiler: alpha-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240328/202403282246.ybWRrXj7-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202403282246.ybWRrXj7-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/perf/marvell_cn10k_tad_pmu.c:416:34: warning: 'tad_pmu_v2_data' defined but not used [-Wunused-const-variable=]
416 | static const struct tad_pmu_data tad_pmu_v2_data = {
| ^~~~~~~~~~~~~~~
>> drivers/perf/marvell_cn10k_tad_pmu.c:412:34: warning: 'tad_pmu_data' defined but not used [-Wunused-const-variable=]
412 | static const struct tad_pmu_data tad_pmu_data = {
| ^~~~~~~~~~~~
vim +/tad_pmu_data +412 drivers/perf/marvell_cn10k_tad_pmu.c
411
> 412 static const struct tad_pmu_data tad_pmu_data = {
413 .id = TAD_PMU_V1,
414 };
415
> 416 static const struct tad_pmu_data tad_pmu_v2_data = {
417 .id = TAD_PMU_V2,
418 };
419
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ASoC: sunxi: sun4i-i2s: Enable 32-bit audio formats
From: John Watts @ 2024-03-28 14:56 UTC (permalink / raw)
To: Mark Brown
Cc: Jernej Škrabec, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Chen-Yu Tsai, Samuel Holland, linux-sound, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <9055efa5-8da6-47b2-b2db-d1f8e02d2267@sirena.org.uk>
On Thu, Mar 28, 2024 at 01:56:42PM +0000, Mark Brown wrote:
> On Thu, Mar 28, 2024 at 01:21:21PM +1100, John Watts wrote:
> > On Wed, Mar 27, 2024 at 08:53:32PM +0100, Jernej Škrabec wrote:
>
> > > I wish it would be that simple. SUN4I_FORMATS is cross section of all I2S
> > > variants that are supported by this driver. If you check A10, you'll see that
> > > it doesn't support S32.
>
> > > If you want to add support for S32, you'll have to add new quirk for each
> > > variant.
>
> > Yes, A10 doesn't support it. But it should error out in hw_params due to
> > get_sr not supporting 32-bit, no?
>
> The constraints shouldn't be advertising things that hw_params() will
> error out on, sometimes there are contingent constraints that prevent
> this but something that just doesn't work isn't one of those times.
Oh right! I'm not sure how I forgot about this, given I went through this
exact discussion for my wm8782 patch.
I'll try and get v2 patch for this soon. :)
John.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/3] dma: xilinx_dpdma: Remove unnecessary use of irqsave/restore
From: Sean Anderson @ 2024-03-28 15:00 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Michal Simek, linux-kernel, linux-arm-kernel, Laurent Pinchart,
Vinod Koul, dmaengine
In-Reply-To: <0652c82f-b0a2-4881-ac51-38399b180ad4@ideasonboard.com>
On 3/27/24 08:27, Tomi Valkeinen wrote:
> Hi,
>
> On 08/03/2024 23:00, Sean Anderson wrote:
>> xilinx_dpdma_chan_done_irq and xilinx_dpdma_chan_vsync_irq are always
>> called with IRQs disabled from xilinx_dpdma_irq_handler. Therefore we
>> don't need to save/restore the IRQ flags.
>
> I think this is fine, but a few thoughts:
>
> - Is spin_lock clearly faster than the irqsave variant, or is this a pointless optimization? It's safer to just use irqsave variant, instead of making sure the code is always called from the expected contexts.
It's not an optimization. Technically this will save a few instructions,
but...
> - Is this style documented/recommended anywhere? Going through docs, I only found docs telling to use irqsave when mixing irq and non-irq contexts.
The purpose is mainly to make it clear that this is meant to be called
in IRQ context. With irqsave, there's an implication that this could be
called in non-IRQ context, which it never is.
> - Does this cause issues on PREEMPT_RT?
Why would it?
--Sean
>
> Tomi
>
>> Signed-off-by: Sean Anderson <sean.anderson@linux.dev>
>> ---
>>
>> drivers/dma/xilinx/xilinx_dpdma.c | 10 ++++------
>> 1 file changed, 4 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/dma/xilinx/xilinx_dpdma.c b/drivers/dma/xilinx/xilinx_dpdma.c
>> index eb0637d90342..36bd4825d389 100644
>> --- a/drivers/dma/xilinx/xilinx_dpdma.c
>> +++ b/drivers/dma/xilinx/xilinx_dpdma.c
>> @@ -1043,9 +1043,8 @@ static int xilinx_dpdma_chan_stop(struct xilinx_dpdma_chan *chan)
>> static void xilinx_dpdma_chan_done_irq(struct xilinx_dpdma_chan *chan)
>> {
>> struct xilinx_dpdma_tx_desc *active;
>> - unsigned long flags;
>> - spin_lock_irqsave(&chan->lock, flags);
>> + spin_lock(&chan->lock);
>> xilinx_dpdma_debugfs_desc_done_irq(chan);
>> @@ -1057,7 +1056,7 @@ static void xilinx_dpdma_chan_done_irq(struct xilinx_dpdma_chan *chan)
>> "chan%u: DONE IRQ with no active descriptor!\n",
>> chan->id);
>> - spin_unlock_irqrestore(&chan->lock, flags);
>> + spin_unlock(&chan->lock);
>> }
>> /**
>> @@ -1072,10 +1071,9 @@ static void xilinx_dpdma_chan_vsync_irq(struct xilinx_dpdma_chan *chan)
>> {
>> struct xilinx_dpdma_tx_desc *pending;
>> struct xilinx_dpdma_sw_desc *sw_desc;
>> - unsigned long flags;
>> u32 desc_id;
>> - spin_lock_irqsave(&chan->lock, flags);
>> + spin_lock(&chan->lock);
>> pending = chan->desc.pending;
>> if (!chan->running || !pending)
>> @@ -1108,7 +1106,7 @@ static void xilinx_dpdma_chan_vsync_irq(struct xilinx_dpdma_chan *chan)
>> spin_unlock(&chan->vchan.lock);
>> out:
>> - spin_unlock_irqrestore(&chan->lock, flags);
>> + spin_unlock(&chan->lock);
>> }
>> /**
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/3] arch: Remove struct fb_info from video helpers
From: Helge Deller @ 2024-03-28 14:59 UTC (permalink / raw)
To: Thomas Zimmermann, arnd, javierm, sui.jingfeng
Cc: linux-arch, dri-devel, linux-fbdev, sparclinux, linux-sh,
linuxppc-dev, linux-parisc, linux-mips, linux-m68k, loongarch,
linux-arm-kernel, linux-snps-arc, linux-kernel,
James E.J. Bottomley, David S. Miller, Andreas Larsson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin
In-Reply-To: <9db306b2-b102-4bf5-a120-e1d279269fe9@suse.de>
On 3/28/24 14:33, Thomas Zimmermann wrote:
> Am 28.03.24 um 12:04 schrieb Helge Deller:
>> On 3/27/24 21:41, Thomas Zimmermann wrote:
>>> The per-architecture video helpers do not depend on struct fb_info
>>> or anything else from fbdev. Remove it from the interface and replace
>>> fb_is_primary_device() with video_is_primary_device(). The new helper
>>
>> Since you rename this function, wouldn't something similar to
>>
>> device_is_primary_display()
>> or
>> device_is_primary_console()
>> or
>> is_primary_graphics_device()
>> or
>> is_primary_display_device()
>>
>> be a better name?
>
> The video_ prefix is there to signal that the code is part of the video subsystem.
>
> But there's too much code that tried to figure out a default video
> device. So I actually have different plans for this function. I'd
> like to replace it with a helper that returns the default device
> instead of just testing for it. Sample code for x86 is already in
> vgaarb.c. [1] The function's name would then be
> video_default_device() and return the appropriate struct device*.
> video_is_primary device() will be removed. This rename here is the
> easiest step towards the new helper. Ok?
Sounds ok.
Helge
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: imx8qxp: add asrc[0,1], esai0, spdif[0,1] and sai[4,5]
From: Frank Li @ 2024-03-28 14:57 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <ZgV6a7ZMwM4aR7f+@dragon>
On Thu, Mar 28, 2024 at 10:10:51PM +0800, Shawn Guo wrote:
> On Mon, Feb 26, 2024 at 02:21:29PM -0500, Frank Li wrote:
> > Add asrc[0,1], esai0, spdif[0,1], sai[4,5] and related lpcg node for
> > imx8 audio subsystem.
> >
> > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > ---
> > .../boot/dts/freescale/imx8-ss-audio.dtsi | 306 ++++++++++++++++++
> > 1 file changed, 306 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
> > index 07afeb78ed564..6d78d6c0d9002 100644
> > --- a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
> > @@ -6,6 +6,7 @@
> >
> > #include <dt-bindings/clock/imx8-clock.h>
> > #include <dt-bindings/clock/imx8-lpcg.h>
> > +#include <dt-bindings/dma/fsl-edma.h>
> > #include <dt-bindings/firmware/imx/rsrc.h>
> >
> > audio_ipg_clk: clock-audio-ipg {
> > @@ -481,4 +482,309 @@ acm: acm@59e00000 {
> > "sai3_rx_bclk",
> > "sai4_rx_bclk";
> > };
> > +
> > + asrc0: asrc@59000000 {
>
> We want to sort nodes in unit-address, right?
Actually it is fixed at v2. I just send out v8, which include extra space
fix and wrong clock index fixes.
https://lore.kernel.org/imx/20240328-asrc_8qxp-v8-0-801cd6bb5be2@nxp.com/T/#t
Also need below patches to make board level audio work.
https://lore.kernel.org/imx/20240305-m4_lpuart-v3-0-592463ef1d22@nxp.com/
Frank
>
> > + compatible = "fsl,imx8qm-asrc";
> > + reg = <0x59000000 0x10000>;
> > + interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&asrc0_lpcg 0>,
> > + <&asrc0_lpcg 0>,
> > + <&aud_pll_div0_lpcg 0>,
> > + <&aud_pll_div1_lpcg 0>,
> > + <&acm IMX_ADMA_ACM_AUD_CLK0_SEL>,
> > + <&acm IMX_ADMA_ACM_AUD_CLK1_SEL>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>;
> > + clock-names = "ipg", "mem",
> > + "asrck_0", "asrck_1", "asrck_2", "asrck_3",
> > + "asrck_4", "asrck_5", "asrck_6", "asrck_7",
> > + "asrck_8", "asrck_9", "asrck_a", "asrck_b",
> > + "asrck_c", "asrck_d", "asrck_e", "asrck_f",
> > + "spba";
> > + dmas = <&edma0 0 0 0>,
> > + <&edma0 1 0 0>,
> > + <&edma0 2 0 0>,
> > + <&edma0 3 0 FSL_EDMA_RX>,
> > + <&edma0 4 0 FSL_EDMA_RX>,
> > + <&edma0 5 0 FSL_EDMA_RX>;
> > + /* tx* is output channel of asrc, it is rx channel for eDMA */
> > + dma-names = "rxa", "rxb", "rxc", "txa", "txb", "txc";
> > + fsl,asrc-rate = <8000>;
>
> One space around =
>
> > + fsl,asrc-width = <16>;
> > + fsl,asrc-clk-map = <0>;
> > + power-domains = <&pd IMX_SC_R_ASRC_0>;
> > + status = "disabled";
> > + };
> > +
> > + esai0: esai@59010000 {
> > + compatible = "fsl,imx8qm-esai", "fsl,imx6ull-esai";
> > + reg = <0x59010000 0x10000>;
> > + interrupts = <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&esai0_lpcg 1>, <&esai0_lpcg 0>, <&esai0_lpcg 1>, <&clk_dummy>;
> > + clock-names = "core", "extal", "fsys", "spba";
> > + dmas = <&edma0 6 0 FSL_EDMA_RX>, <&edma0 7 0 0>;
> > + dma-names = "rx", "tx";
> > + power-domains = <&pd IMX_SC_R_ESAI_0>;
> > + status = "disabled";
> > + };
> > +
> > + spdif0: spdif@59020000 {
> > + compatible = "fsl,imx8qm-spdif";
> > + reg = <0x59020000 0x10000>;
> > + interrupts = <GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>, /* rx */
>
> Ditto
>
> > + <GIC_SPI 458 IRQ_TYPE_LEVEL_HIGH>; /* tx */
> > + clocks = <&spdif0_lpcg 1>, /* core */
> > + <&clk_dummy>, /* rxtx0 */
> > + <&spdif0_lpcg 0>, /* rxtx1 */
> > + <&clk_dummy>, /* rxtx2 */
> > + <&clk_dummy>, /* rxtx3 */
> > + <&clk_dummy>, /* rxtx4 */
> > + <&audio_ipg_clk>, /* rxtx5 */
> > + <&clk_dummy>, /* rxtx6 */
> > + <&clk_dummy>, /* rxtx7 */
> > + <&clk_dummy>; /* spba */
> > + clock-names = "core", "rxtx0", "rxtx1", "rxtx2", "rxtx3", "rxtx4",
> > + "rxtx5", "rxtx6", "rxtx7", "spba";
> > + dmas = <&edma0 8 0 (FSL_EDMA_MULTI_FIFO | FSL_EDMA_RX)>,
> > + <&edma0 9 0 FSL_EDMA_MULTI_FIFO>;
> > + dma-names = "rx", "tx";
> > + power-domains = <&pd IMX_SC_R_SPDIF_0>;
> > + status = "disabled";
> > + };
> > +
> > + spdif1: spdif@59030000 {
> > + compatible = "fsl,imx8qm-spdif";
> > + reg = <0x59030000 0x10000>;
> > + interrupts = <GIC_SPI 460 IRQ_TYPE_LEVEL_HIGH>, /* rx */
>
> Ditto
>
> Shawn
>
> > + <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH>; /* tx */
> > + clocks = <&spdif1_lpcg 1>, /* core */
> > + <&clk_dummy>, /* rxtx0 */
> > + <&spdif1_lpcg 0>, /* rxtx1 */
> > + <&clk_dummy>, /* rxtx2 */
> > + <&clk_dummy>, /* rxtx3 */
> > + <&clk_dummy>, /* rxtx4 */
> > + <&audio_ipg_clk>, /* rxtx5 */
> > + <&clk_dummy>, /* rxtx6 */
> > + <&clk_dummy>, /* rxtx7 */
> > + <&clk_dummy>; /* spba */
> > + clock-names = "core", "rxtx0", "rxtx1", "rxtx2", "rxtx3", "rxtx4",
> > + "rxtx5", "rxtx6", "rxtx7", "spba";
> > + dmas = <&edma0 10 0 (FSL_EDMA_MULTI_FIFO | FSL_EDMA_RX)>,
> > + <&edma0 11 0 FSL_EDMA_MULTI_FIFO>;
> > + dma-names = "rx", "tx";
> > + power-domains = <&pd IMX_SC_R_SPDIF_1>;
> > + status = "disabled";
> > + };
> > +
> > + asrc1: asrc@59800000 {
> > + compatible = "fsl,imx8qm-asrc";
> > + reg = <0x59800000 0x10000>;
> > + interrupts = <GIC_SPI 380 IRQ_TYPE_LEVEL_HIGH>,
> > + <GIC_SPI 381 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&asrc1_lpcg 0>,
> > + <&asrc1_lpcg 0>,
> > + <&aud_pll_div0_lpcg 0>,
> > + <&aud_pll_div1_lpcg 0>,
> > + <&acm IMX_ADMA_ACM_AUD_CLK0_SEL>,
> > + <&acm IMX_ADMA_ACM_AUD_CLK1_SEL>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>,
> > + <&clk_dummy>;
> > + clock-names = "ipg", "mem",
> > + "asrck_0", "asrck_1", "asrck_2", "asrck_3",
> > + "asrck_4", "asrck_5", "asrck_6", "asrck_7",
> > + "asrck_8", "asrck_9", "asrck_a", "asrck_b",
> > + "asrck_c", "asrck_d", "asrck_e", "asrck_f",
> > + "spba";
> > + dmas = <&edma1 0 0 0>,
> > + <&edma1 1 0 0>,
> > + <&edma1 2 0 0>,
> > + <&edma1 3 0 FSL_EDMA_RX>,
> > + <&edma1 4 0 FSL_EDMA_RX>,
> > + <&edma1 5 0 FSL_EDMA_RX>;
> > + /* tx* is output channel of asrc, it is rx channel for eDMA */
> > + dma-names = "txa", "txb", "txc", "rxa", "rxb", "rxc";
> > + fsl,asrc-rate = <8000>;
> > + fsl,asrc-width = <16>;
> > + fsl,asrc-clk-map = <1>;
> > + power-domains = <&pd IMX_SC_R_ASRC_1>;
> > + status = "disabled";
> > + };
> > +
> > + sai4: sai@59820000 {
> > + compatible = "fsl,imx8qm-sai";
> > + reg = <0x59820000 0x10000>;
> > + interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&sai4_lpcg 1>,
> > + <&clk_dummy>,
> > + <&sai4_lpcg 0>,
> > + <&clk_dummy>,
> > + <&clk_dummy>;
> > + clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
> > + dmas = <&edma1 8 0 FSL_EDMA_RX>, <&edma1 9 0 0>;
> > + dma-names = "rx", "tx";
> > + power-domains = <&pd IMX_SC_R_SAI_4>;
> > + status = "disabled";
> > + };
> > +
> > + sai5: sai@59830000 {
> > + compatible = "fsl,imx8qm-sai";
> > + reg = <0x59830000 0x10000>;
> > + interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&sai5_lpcg 1>,
> > + <&clk_dummy>,
> > + <&sai5_lpcg 0>,
> > + <&clk_dummy>,
> > + <&clk_dummy>;
> > + clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
> > + dmas = <&edma1 10 0 0>;
> > + dma-names = "tx";
> > + power-domains = <&pd IMX_SC_R_SAI_5>;
> > + status = "disabled";
> > + };
> > +
> > + amix: amix@59840000 {
> > + compatible = "fsl,imx8qm-audmix";
> > + reg = <0x59840000 0x10000>;
> > + clocks = <&amix_lpcg 0>;
> > + clock-names = "ipg";
> > + power-domains = <&pd IMX_SC_R_AMIX>;
> > + dais = <&sai4>, <&sai5>;
> > + status = "disabled";
> > + };
> > +
> > + mqs: mqs@59850000 {
> > + compatible = "fsl,imx8qm-mqs";
> > + reg = <0x59850000 0x10000>;
> > + clocks = <&mqs0_lpcg 1>,
> > + <&mqs0_lpcg 0>;
> > + clock-names = "core", "mclk";
> > + power-domains = <&pd IMX_SC_R_MQS_0>;
> > + status = "disabled";
> > + };
> > +
> > + asrc0_lpcg: clock-controller@59400000 {
> > + compatible = "fsl,imx8qxp-lpcg";
> > + reg = <0x59400000 0x10000>;
> > + #clock-cells = <1>;
> > + clocks = <&audio_ipg_clk>;
> > + clock-indices = <IMX_LPCG_CLK_4>;
> > + clock-output-names = "asrc0_lpcg_ipg_clk";
> > + power-domains = <&pd IMX_SC_R_ASRC_0>;
> > + };
> > +
> > + esai0_lpcg: clock-controller@59410000 {
> > + compatible = "fsl,imx8qxp-lpcg";
> > + reg = <0x59410000 0x10000>;
> > + #clock-cells = <1>;
> > + clocks = <&acm IMX_ADMA_ACM_ESAI0_MCLK_SEL>,
> > + <&audio_ipg_clk>;
> > + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> > + clock-output-names = "esai0_lpcg_extal_clk",
> > + "esai0_lpcg_ipg_clk";
> > + power-domains = <&pd IMX_SC_R_ESAI_0>;
> > + };
> > +
> > + spdif0_lpcg: clock-controller@59420000 {
> > + compatible = "fsl,imx8qxp-lpcg";
> > + reg = <0x59420000 0x10000>;
> > + #clock-cells = <1>;
> > + clocks = <&acm IMX_ADMA_ACM_SPDIF0_TX_CLK_SEL>,
> > + <&audio_ipg_clk>;
> > + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> > + clock-output-names = "spdif0_lpcg_tx_clk",
> > + "spdif0_lpcg_gclkw";
> > + power-domains = <&pd IMX_SC_R_SPDIF_0>;
> > + };
> > +
> > + spdif1_lpcg: clock-controller@59430000 {
> > + compatible = "fsl,imx8qxp-lpcg";
> > + reg = <0x59430000 0x10000>;
> > + #clock-cells = <1>;
> > + clocks = <&acm IMX_ADMA_ACM_SPDIF1_TX_CLK_SEL>,
> > + <&audio_ipg_clk>;
> > + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> > + clock-output-names = "spdif1_lpcg_tx_clk",
> > + "spdif1_lpcg_gclkw";
> > + power-domains = <&pd IMX_SC_R_SPDIF_1>;
> > + status = "disabled";
> > + };
> > +
> > + asrc1_lpcg: clock-controller@59c00000 {
> > + compatible = "fsl,imx8qxp-lpcg";
> > + reg = <0x59c00000 0x10000>;
> > + #clock-cells = <1>;
> > + clocks = <&audio_ipg_clk>;
> > + clock-indices = <IMX_LPCG_CLK_4>;
> > + clock-output-names = "asrc1_lpcg_ipg_clk";
> > + power-domains = <&pd IMX_SC_R_ASRC_1>;
> > + };
> > +
> > + sai4_lpcg: clock-controller@59c20000 {
> > + compatible = "fsl,imx8qxp-lpcg";
> > + reg = <0x59c20000 0x10000>;
> > + #clock-cells = <1>;
> > + clocks = <&acm IMX_ADMA_ACM_SAI4_MCLK_SEL>,
> > + <&audio_ipg_clk>;
> > + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> > + clock-output-names = "sai4_lpcg_mclk",
> > + "sai4_lpcg_ipg_clk";
> > + power-domains = <&pd IMX_SC_R_SAI_4>;
> > + };
> > +
> > + sai5_lpcg: clock-controller@59c30000 {
> > + compatible = "fsl,imx8qxp-lpcg";
> > + reg = <0x59c30000 0x10000>;
> > + #clock-cells = <1>;
> > + clocks = <&acm IMX_ADMA_ACM_SAI5_MCLK_SEL>,
> > + <&audio_ipg_clk>;
> > + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> > + clock-output-names = "sai5_lpcg_mclk",
> > + "sai5_lpcg_ipg_clk";
> > + power-domains = <&pd IMX_SC_R_SAI_5>;
> > + };
> > +
> > + amix_lpcg: clock-controller@59c40000 {
> > + compatible = "fsl,imx8qxp-lpcg";
> > + reg = <0x59c40000 0x10000>;
> > + #clock-cells = <1>;
> > + clocks = <&audio_ipg_clk>;
> > + clock-indices = <IMX_LPCG_CLK_0>;
> > + clock-output-names = "amix_lpcg_ipg_clk";
> > + power-domains = <&pd IMX_SC_R_AMIX>;
> > + };
> > +
> > + mqs0_lpcg: clock-controller@59c50000 {
> > + compatible = "fsl,imx8qxp-lpcg";
> > + reg = <0x59c50000 0x10000>;
> > + #clock-cells = <1>;
> > + clocks = <&acm IMX_ADMA_ACM_MQS_TX_CLK_SEL>,
> > + <&audio_ipg_clk>;
> > + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> > + clock-output-names = "mqs0_lpcg_mclk",
> > + "mqs0_lpcg_ipg_clk";
> > + power-domains = <&pd IMX_SC_R_MQS_0>;
> > + };
> > };
> > --
> > 2.34.1
> >
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] remoteproc: zynqmp: Add coredump support
From: Mathieu Poirier @ 2024-03-28 14:53 UTC (permalink / raw)
To: Leonard Crestez
Cc: Tanmay Shah, Bjorn Andersson, Michal Simek, linux-remoteproc,
linux-arm-kernel
In-Reply-To: <07183fd8-a5a1-4cae-b317-d703ef7c1de1@gmail.com>
On Thu, Mar 28, 2024 at 10:17:13AM +0200, Leonard Crestez wrote:
> On 3/18/24 18:52, Mathieu Poirier wrote:
> > Hi Leonard,
> >
> > I have queued patches for this driver that will break this patch. Please
> > re-submit when v6.9-rc1 is out and rproc-next has been updated, which should be
> > around the middle of next week.
>
> Hello,
>
> It's been a while - v6.9-rc1 is out and rproc-next has been rebased on top of
> it. But the coredump patch still applies? I expected some unrelated
> xlnx_r5_remoteproc patches to cause conflicts but there's nothing there.
>
> It seems to me that the patch can be applied as-is and no resend is required.
> Am I missing something?
>
You're not missing anything. Back when I wrote my initial comment Tanmay had
submitted patches to fix the way TCMs are initialized, which conflicted with
your patch. There were some last minute modifications to Tanmay's patchset and
I ended up not applying it, leading us to where we are today.
Tanmay - please review and test this patch.
Thanks,
Mathieu
> --
> Regards,
> Leonard
>
> > On Sat, Mar 16, 2024 at 08:16:42PM +0200, Leonard Crestez wrote:
> >> Supporting remoteproc coredump requires the platform-specific driver to
> >> register coredump segments to be dumped. Do this by calling
> >> rproc_coredump_add_segment for every carveout.
> >>
> >> Also call rproc_coredump_set_elf_info when then rproc is created. If the
> >> ELFCLASS parameter is not provided then coredump fails with an error.
> >> Other drivers seem to pass EM_NONE for the machine argument but for me
> >> this shows a warning in gdb. Pass EM_ARM because this is an ARM R5.
> >>
> >> Signed-off-by: Leonard Crestez <cdleonard@gmail.com>
> >> ---
> >>
> >> Tests were done by triggering an deliberate crash using remoteproc
> >> debugfs: echo 2 > /sys/kernel/debug/remoteproc/remoteproc0/crash
> >>
> >> This was tested using RPU apps which use RAM for everything so TCM dump
> >> was not verified. The freertos-gdb script package showed credible data:
> >>
> >> https://github.com/espressif/freertos-gdb
> >>
> >> The R5 cache is not flushed so RAM might be out of date which is
> >> actually very bad because information most relevant to determining the
> >> cause of a crash is lost. Possible workaround would be to flush caches
> >> in some sort of R5 crash handler? I don't think Linux can do anything
> >> about this limitation.
> >>
> >> The generated coredump doesn't contain registers, this seems to be a
> >> limitation shared with other rproc coredumps. It's not clear how the apu
> >> could access rpu registers on zynqmp, my only idea would be to use the
> >> coresight dap but that sounds difficult.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v8 5/5] arm64: dts: imx8qxp: add asrc[0,1], esai0, spdif0 and sai[4,5]
From: Frank Li @ 2024-03-28 14:51 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shengjiu Wang
Cc: linux-sound, devicetree, imx, linux-arm-kernel, linux-kernel,
Frank Li
In-Reply-To: <20240328-asrc_8qxp-v8-0-801cd6bb5be2@nxp.com>
Add asrc[0,1], esai0, spdif0, sai[4,5] and related lpcg node for
imx8 audio subsystem.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi | 269 +++++++++++++++++++++++
1 file changed, 269 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
index d8bbe53320bce..897cbb7b67422 100644
--- a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
@@ -6,6 +6,7 @@
#include <dt-bindings/clock/imx8-clock.h>
#include <dt-bindings/clock/imx8-lpcg.h>
+#include <dt-bindings/dma/fsl-edma.h>
#include <dt-bindings/firmware/imx/rsrc.h>
audio_ipg_clk: clock-audio-ipg {
@@ -119,6 +120,89 @@ audio_subsys: bus@59000000 {
#size-cells = <1>;
ranges = <0x59000000 0x0 0x59000000 0x1000000>;
+ asrc0: asrc@59000000 {
+ compatible = "fsl,imx8qm-asrc";
+ reg = <0x59000000 0x10000>;
+ interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&asrc0_lpcg IMX_LPCG_CLK_0>,
+ <&asrc0_lpcg IMX_LPCG_CLK_0>,
+ <&aud_pll_div0_lpcg IMX_LPCG_CLK_4>,
+ <&aud_pll_div1_lpcg IMX_LPCG_CLK_4>,
+ <&acm IMX_ADMA_ACM_AUD_CLK0_SEL>,
+ <&acm IMX_ADMA_ACM_AUD_CLK1_SEL>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>;
+ clock-names = "mem", "ipg",
+ "asrck_0", "asrck_1", "asrck_2", "asrck_3",
+ "asrck_4", "asrck_5", "asrck_6", "asrck_7",
+ "asrck_8", "asrck_9", "asrck_a", "asrck_b",
+ "asrck_c", "asrck_d", "asrck_e", "asrck_f",
+ "spba";
+ dmas = <&edma0 0 0 0>,
+ <&edma0 1 0 0>,
+ <&edma0 2 0 0>,
+ <&edma0 3 0 FSL_EDMA_RX>,
+ <&edma0 4 0 FSL_EDMA_RX>,
+ <&edma0 5 0 FSL_EDMA_RX>;
+ /* tx* is output channel of asrc, it is rx channel for eDMA */
+ dma-names = "rxa", "rxb", "rxc", "txa", "txb", "txc";
+ fsl,asrc-rate = <8000>;
+ fsl,asrc-width = <16>;
+ fsl,asrc-clk-map = <0>;
+ power-domains = <&pd IMX_SC_R_ASRC_0>;
+ status = "disabled";
+ };
+
+ esai0: esai@59010000 {
+ compatible = "fsl,imx8qm-esai";
+ reg = <0x59010000 0x10000>;
+ interrupts = <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&esai0_lpcg IMX_LPCG_CLK_4>,
+ <&esai0_lpcg IMX_LPCG_CLK_0>,
+ <&esai0_lpcg IMX_LPCG_CLK_4>,
+ <&clk_dummy>;
+ clock-names = "core", "extal", "fsys", "spba";
+ dmas = <&edma0 6 0 FSL_EDMA_RX>, <&edma0 7 0 0>;
+ dma-names = "rx", "tx";
+ power-domains = <&pd IMX_SC_R_ESAI_0>;
+ status = "disabled";
+ };
+
+ spdif0: spdif@59020000 {
+ compatible = "fsl,imx8qm-spdif";
+ reg = <0x59020000 0x10000>;
+ interrupts = <GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>, /* rx */
+ <GIC_SPI 458 IRQ_TYPE_LEVEL_HIGH>; /* tx */
+ clocks = <&spdif0_lpcg IMX_LPCG_CLK_4>, /* core */
+ <&clk_dummy>, /* rxtx0 */
+ <&spdif0_lpcg IMX_LPCG_CLK_0>, /* rxtx1 */
+ <&clk_dummy>, /* rxtx2 */
+ <&clk_dummy>, /* rxtx3 */
+ <&clk_dummy>, /* rxtx4 */
+ <&audio_ipg_clk>, /* rxtx5 */
+ <&clk_dummy>, /* rxtx6 */
+ <&clk_dummy>, /* rxtx7 */
+ <&clk_dummy>; /* spba */
+ clock-names = "core", "rxtx0", "rxtx1", "rxtx2", "rxtx3", "rxtx4",
+ "rxtx5", "rxtx6", "rxtx7", "spba";
+ dmas = <&edma0 8 0 (FSL_EDMA_MULTI_FIFO | FSL_EDMA_RX)>,
+ <&edma0 9 0 FSL_EDMA_MULTI_FIFO>;
+ dma-names = "rx", "tx";
+ power-domains = <&pd IMX_SC_R_SPDIF_0>;
+ status = "disabled";
+ };
+
sai0: sai@59040000 {
compatible = "fsl,imx8qm-sai";
reg = <0x59040000 0x10000>;
@@ -239,6 +323,40 @@ edma0: dma-controller@591f0000 {
<&pd IMX_SC_R_DMA_0_CH23>;
};
+ asrc0_lpcg: clock-controller@59400000 {
+ compatible = "fsl,imx8qxp-lpcg";
+ reg = <0x59400000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&audio_ipg_clk>;
+ clock-indices = <IMX_LPCG_CLK_4>;
+ clock-output-names = "asrc0_lpcg_ipg_clk";
+ power-domains = <&pd IMX_SC_R_ASRC_0>;
+ };
+
+ esai0_lpcg: clock-controller@59410000 {
+ compatible = "fsl,imx8qxp-lpcg";
+ reg = <0x59410000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&acm IMX_ADMA_ACM_ESAI0_MCLK_SEL>,
+ <&audio_ipg_clk>;
+ clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
+ clock-output-names = "esai0_lpcg_extal_clk",
+ "esai0_lpcg_ipg_clk";
+ power-domains = <&pd IMX_SC_R_ESAI_0>;
+ };
+
+ spdif0_lpcg: clock-controller@59420000 {
+ compatible = "fsl,imx8qxp-lpcg";
+ reg = <0x59420000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&acm IMX_ADMA_ACM_SPDIF0_TX_CLK_SEL>,
+ <&audio_ipg_clk>;
+ clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
+ clock-output-names = "spdif0_lpcg_tx_clk",
+ "spdif0_lpcg_gclkw";
+ power-domains = <&pd IMX_SC_R_SPDIF_0>;
+ };
+
sai0_lpcg: clock-controller@59440000 {
compatible = "fsl,imx8qxp-lpcg";
reg = <0x59440000 0x10000>;
@@ -333,6 +451,101 @@ dsp: dsp@596e8000 {
status = "disabled";
};
+ asrc1: asrc@59800000 {
+ compatible = "fsl,imx8qm-asrc";
+ reg = <0x59800000 0x10000>;
+ interrupts = <GIC_SPI 380 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&asrc1_lpcg IMX_LPCG_CLK_4>,
+ <&asrc1_lpcg IMX_LPCG_CLK_4>,
+ <&aud_pll_div0_lpcg IMX_LPCG_CLK_0>,
+ <&aud_pll_div1_lpcg IMX_LPCG_CLK_0>,
+ <&acm IMX_ADMA_ACM_AUD_CLK0_SEL>,
+ <&acm IMX_ADMA_ACM_AUD_CLK1_SEL>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>,
+ <&clk_dummy>;
+ clock-names = "mem", "ipg",
+ "asrck_0", "asrck_1", "asrck_2", "asrck_3",
+ "asrck_4", "asrck_5", "asrck_6", "asrck_7",
+ "asrck_8", "asrck_9", "asrck_a", "asrck_b",
+ "asrck_c", "asrck_d", "asrck_e", "asrck_f",
+ "spba";
+ dmas = <&edma1 0 0 0>,
+ <&edma1 1 0 0>,
+ <&edma1 2 0 0>,
+ <&edma1 3 0 FSL_EDMA_RX>,
+ <&edma1 4 0 FSL_EDMA_RX>,
+ <&edma1 5 0 FSL_EDMA_RX>;
+ /* tx* is output channel of asrc, it is rx channel for eDMA */
+ dma-names = "rxa", "rxb", "rxc", "txa", "txb", "txc";
+ fsl,asrc-rate = <8000>;
+ fsl,asrc-width = <16>;
+ fsl,asrc-clk-map = <1>;
+ power-domains = <&pd IMX_SC_R_ASRC_1>;
+ status = "disabled";
+ };
+
+ sai4: sai@59820000 {
+ compatible = "fsl,imx8qm-sai";
+ reg = <0x59820000 0x10000>;
+ interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sai4_lpcg IMX_LPCG_CLK_4>,
+ <&clk_dummy>,
+ <&sai4_lpcg IMX_LPCG_CLK_0>,
+ <&clk_dummy>,
+ <&clk_dummy>;
+ clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
+ dmas = <&edma1 8 0 FSL_EDMA_RX>, <&edma1 9 0 0>;
+ dma-names = "rx", "tx";
+ power-domains = <&pd IMX_SC_R_SAI_4>;
+ status = "disabled";
+ };
+
+ sai5: sai@59830000 {
+ compatible = "fsl,imx8qm-sai";
+ reg = <0x59830000 0x10000>;
+ interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sai5_lpcg IMX_LPCG_CLK_4>,
+ <&clk_dummy>,
+ <&sai5_lpcg IMX_LPCG_CLK_0>,
+ <&clk_dummy>,
+ <&clk_dummy>;
+ clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
+ dmas = <&edma1 10 0 0>;
+ dma-names = "tx";
+ power-domains = <&pd IMX_SC_R_SAI_5>;
+ status = "disabled";
+ };
+
+ amix: amix@59840000 {
+ compatible = "fsl,imx8qm-audmix";
+ reg = <0x59840000 0x10000>;
+ clocks = <&amix_lpcg IMX_LPCG_CLK_0>;
+ clock-names = "ipg";
+ power-domains = <&pd IMX_SC_R_AMIX>;
+ dais = <&sai4>, <&sai5>;
+ status = "disabled";
+ };
+
+ mqs: mqs@59850000 {
+ compatible = "fsl,imx8qm-mqs";
+ reg = <0x59850000 0x10000>;
+ clocks = <&mqs0_lpcg IMX_LPCG_CLK_4>, <&mqs0_lpcg IMX_LPCG_CLK_0>;
+ clock-names = "mclk", "core";
+ power-domains = <&pd IMX_SC_R_MQS_0>;
+ status = "disabled";
+ };
+
edma1: dma-controller@599f0000 {
compatible = "fsl,imx8qm-edma";
reg = <0x599f0000 0xc0000>;
@@ -481,4 +694,60 @@ acm: acm@59e00000 {
"sai3_rx_bclk",
"sai4_rx_bclk";
};
+
+ asrc1_lpcg: clock-controller@59c00000 {
+ compatible = "fsl,imx8qxp-lpcg";
+ reg = <0x59c00000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&audio_ipg_clk>;
+ clock-indices = <IMX_LPCG_CLK_4>;
+ clock-output-names = "asrc1_lpcg_ipg_clk";
+ power-domains = <&pd IMX_SC_R_ASRC_1>;
+ };
+
+ sai4_lpcg: clock-controller@59c20000 {
+ compatible = "fsl,imx8qxp-lpcg";
+ reg = <0x59c20000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&acm IMX_ADMA_ACM_SAI4_MCLK_SEL>,
+ <&audio_ipg_clk>;
+ clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
+ clock-output-names = "sai4_lpcg_mclk",
+ "sai4_lpcg_ipg_clk";
+ power-domains = <&pd IMX_SC_R_SAI_4>;
+ };
+
+ sai5_lpcg: clock-controller@59c30000 {
+ compatible = "fsl,imx8qxp-lpcg";
+ reg = <0x59c30000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&acm IMX_ADMA_ACM_SAI5_MCLK_SEL>,
+ <&audio_ipg_clk>;
+ clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
+ clock-output-names = "sai5_lpcg_mclk",
+ "sai5_lpcg_ipg_clk";
+ power-domains = <&pd IMX_SC_R_SAI_5>;
+ };
+
+ amix_lpcg: clock-controller@59c40000 {
+ compatible = "fsl,imx8qxp-lpcg";
+ reg = <0x59c40000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&audio_ipg_clk>;
+ clock-indices = <IMX_LPCG_CLK_0>;
+ clock-output-names = "amix_lpcg_ipg_clk";
+ power-domains = <&pd IMX_SC_R_AMIX>;
+ };
+
+ mqs0_lpcg: clock-controller@59c50000 {
+ compatible = "fsl,imx8qxp-lpcg";
+ reg = <0x59c50000 0x10000>;
+ #clock-cells = <1>;
+ clocks = <&acm IMX_ADMA_ACM_MQS_TX_CLK_SEL>,
+ <&audio_ipg_clk>;
+ clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
+ clock-output-names = "mqs0_lpcg_mclk",
+ "mqs0_lpcg_ipg_clk";
+ power-domains = <&pd IMX_SC_R_MQS_0>;
+ };
};
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 3/5] ASoC: dt-bindings: fsl-sai: allow only one dma-names
From: Frank Li @ 2024-03-28 14:51 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shengjiu Wang
Cc: linux-sound, devicetree, imx, linux-arm-kernel, linux-kernel,
Frank Li
In-Reply-To: <20240328-asrc_8qxp-v8-0-801cd6bb5be2@nxp.com>
Some sai only connect one direction dma (rx/tx) in SOC. For example:
imx8qxp sai5 only connect tx dma channel. So allow only one "rx" or "tx"
for dma-names.
Remove description under dmas because no user use index to get dma channel.
All user use 'dma-names' to get correct dma channel. dma-names already in
'required' list.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Documentation/devicetree/bindings/sound/fsl,sai.yaml | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/fsl,sai.yaml b/Documentation/devicetree/bindings/sound/fsl,sai.yaml
index 2456d958adeef..a5d9c246cc476 100644
--- a/Documentation/devicetree/bindings/sound/fsl,sai.yaml
+++ b/Documentation/devicetree/bindings/sound/fsl,sai.yaml
@@ -81,14 +81,12 @@ properties:
dmas:
minItems: 1
- items:
- - description: DMA controller phandle and request line for RX
- - description: DMA controller phandle and request line for TX
+ maxItems: 2
dma-names:
minItems: 1
items:
- - const: rx
+ - enum: [ rx, tx ]
- const: tx
interrupts:
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 1/5] ASoC: dt-bindings: fsl,imx-asrc/spdif: Add power-domains property
From: Frank Li @ 2024-03-28 14:51 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shengjiu Wang
Cc: linux-sound, devicetree, imx, linux-arm-kernel, linux-kernel,
Frank Li, Conor Dooley
In-Reply-To: <20240328-asrc_8qxp-v8-0-801cd6bb5be2@nxp.com>
Add power-domains property for asrc and spdif since fsl,imx8qm-asrc/spdif
and fsl,imx8qxp-asrc/spdif require 'power-domains'.
Set 'power-domains' as required property for compatible string
fsl,imx8qm-asrc/spdif and fsl,imx8qxp-asrc/spdif.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml | 14 ++++++++++++++
Documentation/devicetree/bindings/sound/fsl,spdif.yaml | 15 +++++++++++++++
2 files changed, 29 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml b/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml
index bfef2fcb75b14..76aa1f2484883 100644
--- a/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml
+++ b/Documentation/devicetree/bindings/sound/fsl,imx-asrc.yaml
@@ -74,6 +74,9 @@ properties:
- const: asrck_f
- const: spba
+ power-domains:
+ maxItems: 1
+
fsl,asrc-rate:
$ref: /schemas/types.yaml#/definitions/uint32
description: The mutual sample rate used by DPCM Back Ends
@@ -131,6 +134,17 @@ allOf:
properties:
fsl,asrc-clk-map: false
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-asrc
+ - fsl,imx8qxp-asrc
+ then:
+ required:
+ - power-domains
+
additionalProperties: false
examples:
diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml
index 1d64e8337aa4b..56f8c0c8afdea 100644
--- a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml
@@ -86,6 +86,9 @@ properties:
registers. Set this flag for HCDs with big endian descriptors and big
endian registers.
+ power-domains:
+ maxItems: 1
+
required:
- compatible
- reg
@@ -97,6 +100,18 @@ required:
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - fsl,imx8qm-spdif
+ - fsl,imx8qxp-spdif
+ then:
+ required:
+ - power-domains
+
examples:
- |
spdif@2004000 {
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 4/5] arm64: dts: imx8: fix audio lpcg index
From: Frank Li @ 2024-03-28 14:51 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shengjiu Wang
Cc: linux-sound, devicetree, imx, linux-arm-kernel, linux-kernel,
Frank Li
In-Reply-To: <20240328-asrc_8qxp-v8-0-801cd6bb5be2@nxp.com>
lpcg cell0 should be clock's 'indices' instead of 'index'.
imx_lpcg_of_clk_src_get(struct of_phandle_args *clkspec, void *data)
{
struct clk_hw_onecell_data *hw_data = data;
unsigned int idx = clkspec->args[0] / 4;
....
}
<@sai0_lpcg 1> will be the same as <@sai_lpcg 0>.
Replace 0 with IMX_LPCG_CLK_0 and replace 1 with IMX_LPCG_CLK_4.
It can work at iMX8QXP because IMX_LPCG_CLK_4 is ipg clock, which already
enabled. But for iMX8QM IMX_LPCG_CLK_4 is mclk, which trigger issue.
Fixes: 0a9279e9ae88 ("arm64: dts: imx8qxp: Add audio SAI nodes")
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
index 07afeb78ed564..d8bbe53320bce 100644
--- a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
@@ -123,9 +123,9 @@ sai0: sai@59040000 {
compatible = "fsl,imx8qm-sai";
reg = <0x59040000 0x10000>;
interrupts = <GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&sai0_lpcg 1>,
+ clocks = <&sai0_lpcg IMX_LPCG_CLK_4>,
<&clk_dummy>,
- <&sai0_lpcg 0>,
+ <&sai0_lpcg IMX_LPCG_CLK_0>,
<&clk_dummy>,
<&clk_dummy>;
clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
@@ -139,9 +139,9 @@ sai1: sai@59050000 {
compatible = "fsl,imx8qm-sai";
reg = <0x59050000 0x10000>;
interrupts = <GIC_SPI 316 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&sai1_lpcg 1>,
+ clocks = <&sai1_lpcg IMX_LPCG_CLK_4>,
<&clk_dummy>,
- <&sai1_lpcg 0>,
+ <&sai1_lpcg IMX_LPCG_CLK_0>,
<&clk_dummy>,
<&clk_dummy>;
clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
@@ -155,9 +155,9 @@ sai2: sai@59060000 {
compatible = "fsl,imx8qm-sai";
reg = <0x59060000 0x10000>;
interrupts = <GIC_SPI 318 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&sai2_lpcg 1>,
+ clocks = <&sai2_lpcg IMX_LPCG_CLK_4>,
<&clk_dummy>,
- <&sai2_lpcg 0>,
+ <&sai2_lpcg IMX_LPCG_CLK_0>,
<&clk_dummy>,
<&clk_dummy>;
clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
@@ -171,9 +171,9 @@ sai3: sai@59070000 {
compatible = "fsl,imx8qm-sai";
reg = <0x59070000 0x10000>;
interrupts = <GIC_SPI 323 IRQ_TYPE_LEVEL_HIGH>;
- clocks = <&sai3_lpcg 1>,
+ clocks = <&sai3_lpcg IMX_LPCG_CLK_4>,
<&clk_dummy>,
- <&sai3_lpcg 0>,
+ <&sai3_lpcg IMX_LPCG_CLK_0>,
<&clk_dummy>,
<&clk_dummy>;
clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 2/5] ASoC: dt-bindings: fsl,imx-asrc: update max interrupt numbers
From: Frank Li @ 2024-03-28 14:51 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shengjiu Wang
Cc: linux-sound, devicetree, imx, linux-arm-kernel, linux-kernel,
Frank Li
In-Reply-To: <20240328-asrc_8qxp-v8-0-801cd6bb5be2@nxp.com>
fsl,imx8qxp-spdif and fsl,imx8qm-spdif have 2 interrupts. Other platforms
have 1 interrupt.
Increase max interrupt number to 2 and add restriction for platforms except
i.MX8QXP and i.MX8QM.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
.../devicetree/bindings/sound/fsl,spdif.yaml | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml
index 56f8c0c8afdea..204f361cea27a 100644
--- a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml
@@ -31,7 +31,10 @@ properties:
maxItems: 1
interrupts:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: Combined or receive interrupt
+ - description: Transmit interrupt
dmas:
items:
@@ -101,6 +104,21 @@ required:
additionalProperties: false
allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - fsl,imx8qm-spdif
+ - fsl,imx8qxp-spdif
+ then:
+ properties:
+ interrupts:
+ minItems: 2
+ else:
+ properties:
+ interrupts:
+ maxItems: 1
+
- if:
properties:
compatible:
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v8 0/5] arm64: dts: imx8qxp add asrc and sai
From: Frank Li @ 2024-03-28 14:51 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shengjiu Wang
Cc: linux-sound, devicetree, imx, linux-arm-kernel, linux-kernel,
Frank Li, Conor Dooley
Update binding doc to avoid warning.
Change from v1 to v2
- Fixed dts DTB_CHECK warning
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
Changes in v8:
binding:
- Add rob's review tag
dts:
- Add fixed patch to fix sai0 lpcg index
- Update other node lpcg index
- Remove extra space after =
- Link to v7: https://lore.kernel.org/r/20240318-asrc_8qxp-v7-0-01ce5264a761@nxp.com
Changes in v7:
- Using rob method for dma-names
- Drop conor acked tag form dma-names and interrupt patches
- Fixed warning for interrupts
- Pass dt_bindng check
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 dt_binding_check DT_SCHEMA_FILES=fsl,sai.yaml
LINT Documentation/devicetree/bindings
DTEX Documentation/devicetree/bindings/sound/fsl,sai.example.dts
CHKDT Documentation/devicetree/bindings/processed-schema.json
SCHEMA Documentation/devicetree/bindings/processed-schema.json
DTC_CHK Documentation/devicetree/bindings/sound/fsl,sai.example.dtb
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 dt_binding_check DT_SCHEMA_FILES=fsl,spdif.yaml
LINT Documentation/devicetree/bindings
DTEX Documentation/devicetree/bindings/sound/fsl,spdif.example.dts
CHKDT Documentation/devicetree/bindings/processed-schema.json
SCHEMA Documentation/devicetree/bindings/processed-schema.json
DTC_CHK Documentation/devicetree/bindings/sound/fsl,spdif.example.dtb
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 dt_binding_check DT_SCHEMA_FILES=fsl,imx-asrc.yaml
LINT Documentation/devicetree/bindings
DTEX Documentation/devicetree/bindings/sound/fsl,imx-asrc.example.dts
CHKDT Documentation/devicetree/bindings/processed-schema.json
SCHEMA Documentation/devicetree/bindings/processed-schema.json
DTC_CHK Documentation/devicetree/bindings/sound/fsl,imx-asrc.example.dtb
- Pass DTB_CHECK, below warning exist because binding doc still be txt.
from schema $id: http://devicetree.org/schemas/dma/fsl,edma.yaml#
arch/arm64/boot/dts/freescale/imx8dxl-evk.dtb: /bus@59000000/amix@59840000: failed to match any schema with compatible: ['fsl,imx8qm-audmix']
- Link to v6: https://lore.kernel.org/r/20240308-asrc_8qxp-v6-0-e08f6d030e09@nxp.com
Changes in v6:
- Add interrupt description in binding doc according to rob suggestion
- Link to v5: https://lore.kernel.org/r/20240307-asrc_8qxp-v5-0-db363740368d@nxp.com
Changes in v5:
- using rob's suggest logic after fix maxItems.
- sort dts nodes.
- remove spdif1. Add later when do 8qm upstream
- Link to v4: https://lore.kernel.org/r/20240305-asrc_8qxp-v4-0-c61b98046591@nxp.com
Changes in v4:
Combine comments' from v2 and v3. I hope I address everythings.
- Krzysztof's comments
- add reson about why change
- rob's comments
using rob's suggest logic to restrict interrupt number
but for dma-names, still need use oneOf to cover 3 case
- [rx, tx]
- [rx]
- [tx]
oneOf
- items:
- tx
- rx
- enums: [rx, tx]
- Conor's comments
- add power-domains required for imx8qxp and imx8qm
- remove dmas descript, not allow use index to get dma-channel. Current
no user using this method.
- Link to v3: https://lore.kernel.org/r/20240228-asrc_8qxp-v3-0-d4d5935fd3aa@nxp.com
Changes in v3:
- Fixed dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/sound/fsl,spdif.example.dtb: spdif@2004000: interrupts: [[0, 52, 4]] is too short
from schema $id: http://devicetree.org/schemas/sound/fsl,spdif.yaml#
- Link to v2: https://lore.kernel.org/r/20240227-asrc_8qxp-v2-0-521bcc7eb1c0@nxp.com
---
Frank Li (5):
ASoC: dt-bindings: fsl,imx-asrc/spdif: Add power-domains property
ASoC: dt-bindings: fsl,imx-asrc: update max interrupt numbers
ASoC: dt-bindings: fsl-sai: allow only one dma-names
arm64: dts: imx8: fix audio lpcg index
arm64: dts: imx8qxp: add asrc[0,1], esai0, spdif0 and sai[4,5]
.../devicetree/bindings/sound/fsl,imx-asrc.yaml | 14 +
.../devicetree/bindings/sound/fsl,sai.yaml | 6 +-
.../devicetree/bindings/sound/fsl,spdif.yaml | 35 ++-
arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi | 285 ++++++++++++++++++++-
4 files changed, 327 insertions(+), 13 deletions(-)
---
base-commit: 8552c902efe7ef670b6961fb8885b67961aeb629
change-id: 20240227-asrc_8qxp-25aa6783840f
Best regards,
---
Frank Li <Frank.Li@nxp.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 01/11] staging: vc04_services: changen strncpy() to strscpy_pad()
From: Dan Carpenter @ 2024-03-28 14:42 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-kernel, Florian Fainelli, Greg Kroah-Hartman, Arnd Bergmann,
Broadcom internal kernel review list, linux-rpi-kernel,
linux-arm-kernel, linux-staging
In-Reply-To: <20240328140512.4148825-2-arnd@kernel.org>
On Thu, Mar 28, 2024 at 03:04:45PM +0100, Arnd Bergmann wrote:
> diff --git a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
> index 258aa0e37f55..6ca5797aeae5 100644
> --- a/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
> +++ b/drivers/staging/vc04_services/vchiq-mmal/mmal-vchiq.c
> @@ -937,8 +937,8 @@ static int create_component(struct vchiq_mmal_instance *instance,
> /* build component create message */
> m.h.type = MMAL_MSG_TYPE_COMPONENT_CREATE;
> m.u.component_create.client_component = component->client_component;
> - strncpy(m.u.component_create.name, name,
> - sizeof(m.u.component_create.name));
> + strscpy_pad(m.u.component_create.name, name,
> + sizeof(m.u.component_create.name));
You sent this earlier and we already applied it.
Btw, I just learned there is a new trick to write this when it's just
sizeof(dest).
strscpy_pad(m.u.component_create.name, name);
regards,
dan carpenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [External] Re: [PATCH bpf-next v2 1/9] bpf: tracing: add support to record and check the accessed args
From: 梦龙董 @ 2024-03-28 14:43 UTC (permalink / raw)
To: Alexei Starovoitov, Jiri Olsa
Cc: Andrii Nakryiko, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Eddy Z, Song Liu, Yonghong Song, John Fastabend,
KP Singh, Stanislav Fomichev, Hao Luo, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, David S. Miller,
David Ahern, Dave Hansen, X86 ML, Steven Rostedt,
Mathieu Desnoyers, Quentin Monnet, bpf, linux-arm-kernel, LKML,
linux-riscv, linux-s390, Network Development, linux-trace-kernel,
open list:KERNEL SELFTEST FRAMEWORK, linux-stm32
In-Reply-To: <CALz3k9g-U8ih=ycJPRbyU9x_9cp00fNkU3PGQ6jP0WJ+=uKmqQ@mail.gmail.com>
On Fri, Mar 15, 2024 at 4:00 PM 梦龙董 <dongmenglong.8@bytedance.com> wrote:
>
> On Thu, Mar 14, 2024 at 8:27 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Tue, Mar 12, 2024 at 6:53 PM 梦龙董 <dongmenglong.8@bytedance.com> wrote:
> [......]
> > > What does "a hundred attachments max" means? Can't I
> > > trace thousands of kernel functions with a bpf program of
> > > tracing multi-link?
> >
> > I mean what time does it take to attach one program
> > to 100 fentry-s ?
> > What is the time for 1k and for 10k ?
> >
> > The kprobe multi test attaches to pretty much all funcs in
> > /sys/kernel/tracing/available_filter_functions
> > and it's fast enough to run in test_progs on every commit in bpf CI.
> > See get_syms() in prog_tests/kprobe_multi_test.c
> >
> > Can this new multi fentry do that?
> > and at what speed?
> > The answer will decide how applicable this api is going to be.
> > Generating different trampolines for every attach point
> > is an approach as well. Pls benchmark it too.
>
> I see. Creating plenty of trampolines does take a lot of time,
> and I'll do testing on it.
>
I have done a simple benchmark on creating 1000
trampolines. It is slow, quite slow, which consume up to
60s. We can't do it this way.
Now, I have a bad idea. How about we introduce
a "dynamic trampoline"? The basic logic of it can be:
"""
save regs
bpfs = trampoline_lookup_ip(ip)
fentry = bpfs->fentries
while fentry:
fentry(ctx)
fentry = fentry->next
call origin
save return value
fexit = bpfs->fexits
while fexit:
fexit(ctx)
fexit = fexit->next
xxxxxx
"""
And we lookup the "bpfs" by the function ip in a hash map
in trampoline_lookup_ip. The type of "bpfs" is:
struct bpf_array {
struct bpf_prog *fentries;
struct bpf_prog *fexits;
struct bpf_prog *modify_returns;
}
When we need to attach the bpf progA to function A/B/C,
we only need to create the bpf_arrayA, bpf_arrayB, bpf_arrayC
and add the progA to them, and insert them to the hash map
"direct_call_bpfs", and attach the "dynamic trampoline" to
A/B/C. If bpf_arrayA exist, just add progA to the tail of
bpf_arrayA->fentries. When we need to attach progB to
B/C, just add progB to bpf_arrayB->fentries and
bpf_arrayB->fentries.
Compared to the trampoline, extra overhead is introduced
by the hash lookuping.
I have not begun to code yet, and I am not sure the overhead is
acceptable. Considering that we also need to do hash lookup
by the function in kprobe_multi, maybe the overhead is
acceptable?
Thanks!
Menglong Dong
> >
> > > >
> > > > Let's step back.
> [......]
> >
> > For one trampoline to handle all attach points we might
> > need some arch support, but we can start simple.
> > Make btf_func_model with MAX_BPF_FUNC_REG_ARGS
> > by calling btf_distill_func_proto() with func==NULL.
> > And use that to build a trampoline.
> >
> > The challenge is how to use minimal number of trampolines
> > when bpf_progA is attached for func1, func2, func3
> > and bpf_progB is attached to func3, func4, func5.
> > We'd still need 3 trampolines:
> > for func[12] to call bpf_progA,
> > for func3 to call bpf_progA and bpf_progB,
> > for func[45] to call bpf_progB.
> >
> > Jiri was trying to solve it in the past. His slides from LPC:
> > https://lpc.events/event/16/contributions/1350/attachments/1033/1983/plumbers.pdf
> >
> > Pls study them and his prior patchsets to avoid stepping on the same rakes.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] remoteproc: mediatek: Don't parse extraneous subnodes for multi-core
From: Mathieu Poirier @ 2024-03-28 14:38 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: andersson, matthias.bgg, tzungbi, tinghan.shen, linux-remoteproc,
linux-kernel, linux-arm-kernel, linux-mediatek, wenst, kernel
In-Reply-To: <9ef4e974-740e-4698-bb38-f236521a425c@collabora.com>
On Wed, Mar 27, 2024 at 01:49:58PM +0100, AngeloGioacchino Del Regno wrote:
> Il 21/03/24 16:27, Mathieu Poirier ha scritto:
> > On Thu, Mar 21, 2024 at 09:46:14AM +0100, AngeloGioacchino Del Regno wrote:
> > > When probing multi-core SCP, this driver is parsing all sub-nodes of
> > > the scp-cluster node, but one of those could be not an actual SCP core
> > > and that would make the entire SCP cluster to fail probing for no good
> > > reason.
> > >
> > > To fix that, in scp_add_multi_core() treat a subnode as a SCP Core by
> > > parsing only available subnodes having compatible "mediatek,scp-core".
> > >
> > > Fixes: 1fdbf0cdde98 ("remoteproc: mediatek: Probe SCP cluster on multi-core SCP")
> > > Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> > > ---
> > > drivers/remoteproc/mtk_scp.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
> > > index 67518291a8ad..fbe1c232dae7 100644
> > > --- a/drivers/remoteproc/mtk_scp.c
> > > +++ b/drivers/remoteproc/mtk_scp.c
> > > @@ -1096,6 +1096,9 @@ static int scp_add_multi_core(struct platform_device *pdev,
> > > cluster_of_data = (const struct mtk_scp_of_data **)of_device_get_match_data(dev);
> > > for_each_available_child_of_node(np, child) {
> > > + if (!of_device_is_compatible(child, "mediatek,scp-core"))
> > > + continue;
> > > +
> >
> > Interesting - what else gets stashed under the remote processor node? I don't
> > see anything specified in the bindings.
> >
>
> Sorry for the late reply - well, in this precise moment in time, upstream,
> nothing yet.
>
> I have noticed this while debugging some lockups and wanted to move the scp_adsp
> clock controller node as child of the SCP node (as some of those clocks are located
> *into the SCP's CFG register space*, and it's correct for that to be a child as one
> of those do depend on the SCP being up - and I'll spare you the rest) and noticed
> the unexpected behavior, as the SCP driver was treating those as an SCP core.
>
> There was no kernel panic, but the SCP would fail probing.
>
> This is anyway a missed requirement ... for platforms that want *both* two SCP
> cores *and* the AudioDSP, as that'd at least be two nodes with the same iostart
> (scp@1072000, clock-controller@1072000), other than the reasons I explained some
> lines back.
>
> ...and that's why this commit was sent :-)
>
Please update the bindings with the extra clock requirement in your next
revision.
> P.S.: The reason why platforms don't crash without the scp_adsp clock controller
> as a child of SCP is that the bootloader is actually doing basic init for
> the SCP, hence the block is powered on when booting ;-)
>
> Cheers,
> Angelo
>
> > Thanks,
> > Mathieu
> >
> > > if (!cluster_of_data[core_id]) {
> > > ret = -EINVAL;
> > > dev_err(dev, "Not support core %d\n", core_id);
> > > --
> > > 2.44.0
> > >
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] arch: Select fbdev helpers with CONFIG_VIDEO
From: Thomas Zimmermann @ 2024-03-28 13:21 UTC (permalink / raw)
To: Helge Deller, arnd, javierm, sui.jingfeng
Cc: linux-arch, dri-devel, linux-fbdev, sparclinux, linux-sh,
linuxppc-dev, linux-parisc, linux-mips, linux-m68k, loongarch,
linux-arm-kernel, linux-snps-arc, linux-kernel,
James E.J. Bottomley, David S. Miller, Andreas Larsson,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin
In-Reply-To: <70aefe08-b4c4-4738-a223-e4b04562cd56@gmx.de>
Hi
Am 28.03.24 um 13:39 schrieb Helge Deller:
> On 3/27/24 21:41, Thomas Zimmermann wrote:
>> Various Kconfig options selected the per-architecture helpers for
>> fbdev. But none of the contained code depends on fbdev. Standardize
>> on CONFIG_VIDEO, which will allow to add more general helpers for
>> video functionality.
>>
>> CONFIG_VIDEO protects each architecture's video/ directory.
>
> Your patch in general looks good.
> But is renaming the config option from CONFIG_FB_CORE to CONFIG_VIDEO
> the best choice?
> CONFIG_VIDEO might be mixed up with multimedia/video-streaming.
>
> Why not e.g. CONFIG_GRAPHICS_CORE?
> I'm fine with CONFIG_VIDEO as well, but if someone has a better idea
> we maybe should go with that instead now?
We already have CONFIG_VIDEO in drivers/video/Kconfig specifically for
such low-level graphics code. For generic multimedia, we could have
CONFIG_MEDIA, CONFIG_STREAMING, etc. rather than renaming an established
Kconfig symbol.
Best regards
Thomas
>
> Helge
>
>> This
>> allows for the use of more fine-grained control for each directory's
>> files, such as the use of CONFIG_STI_CORE on parisc.
>>
>> v2:
>> - sparc: rebased onto Makefile changes
>>
>> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
>> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
>> Cc: Helge Deller <deller@gmx.de>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: Andreas Larsson <andreas@gaisler.com>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Ingo Molnar <mingo@redhat.com>
>> Cc: Borislav Petkov <bp@alien8.de>
>> Cc: Dave Hansen <dave.hansen@linux.intel.com>
>> Cc: x86@kernel.org
>> Cc: "H. Peter Anvin" <hpa@zytor.com>
>> ---
>> arch/parisc/Makefile | 2 +-
>> arch/sparc/Makefile | 4 ++--
>> arch/sparc/video/Makefile | 2 +-
>> arch/x86/Makefile | 2 +-
>> arch/x86/video/Makefile | 3 ++-
>> 5 files changed, 7 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
>> index 316f84f1d15c8..21b8166a68839 100644
>> --- a/arch/parisc/Makefile
>> +++ b/arch/parisc/Makefile
>> @@ -119,7 +119,7 @@ export LIBGCC
>>
>> libs-y += arch/parisc/lib/ $(LIBGCC)
>>
>> -drivers-y += arch/parisc/video/
>> +drivers-$(CONFIG_VIDEO) += arch/parisc/video/
>>
>> boot := arch/parisc/boot
>>
>> diff --git a/arch/sparc/Makefile b/arch/sparc/Makefile
>> index 2a03daa68f285..757451c3ea1df 100644
>> --- a/arch/sparc/Makefile
>> +++ b/arch/sparc/Makefile
>> @@ -59,8 +59,8 @@ endif
>> libs-y += arch/sparc/prom/
>> libs-y += arch/sparc/lib/
>>
>> -drivers-$(CONFIG_PM) += arch/sparc/power/
>> -drivers-$(CONFIG_FB_CORE) += arch/sparc/video/
>> +drivers-$(CONFIG_PM) += arch/sparc/power/
>> +drivers-$(CONFIG_VIDEO) += arch/sparc/video/
>>
>> boot := arch/sparc/boot
>>
>> diff --git a/arch/sparc/video/Makefile b/arch/sparc/video/Makefile
>> index d4d83f1702c61..9dd82880a027a 100644
>> --- a/arch/sparc/video/Makefile
>> +++ b/arch/sparc/video/Makefile
>> @@ -1,3 +1,3 @@
>> # SPDX-License-Identifier: GPL-2.0-only
>>
>> -obj-$(CONFIG_FB_CORE) += fbdev.o
>> +obj-y += fbdev.o
>> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
>> index 15a5f4f2ff0aa..c0ea612c62ebe 100644
>> --- a/arch/x86/Makefile
>> +++ b/arch/x86/Makefile
>> @@ -265,7 +265,7 @@ drivers-$(CONFIG_PCI) += arch/x86/pci/
>> # suspend and hibernation support
>> drivers-$(CONFIG_PM) += arch/x86/power/
>>
>> -drivers-$(CONFIG_FB_CORE) += arch/x86/video/
>> +drivers-$(CONFIG_VIDEO) += arch/x86/video/
>>
>> ####
>> # boot loader support. Several targets are kept for legacy purposes
>> diff --git a/arch/x86/video/Makefile b/arch/x86/video/Makefile
>> index 5ebe48752ffc4..9dd82880a027a 100644
>> --- a/arch/x86/video/Makefile
>> +++ b/arch/x86/video/Makefile
>> @@ -1,2 +1,3 @@
>> # SPDX-License-Identifier: GPL-2.0-only
>> -obj-$(CONFIG_FB_CORE) += fbdev.o
>> +
>> +obj-y += fbdev.o
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: thermal: amlogic: add support for A1 thermal sensor
From: Dmitry Rokosov @ 2024-03-28 14:29 UTC (permalink / raw)
To: neil.armstrong
Cc: jbrunet, mturquette, khilman, martin.blumenstingl, glaroque,
rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt, kernel, rockosov, linux-amlogic,
linux-pm, linux-kernel, devicetree, linux-arm-kernel
In-Reply-To: <19897482-2fa1-4688-aeec-855123558374@linaro.org>
Hello Neil,
Thank you for quick feedback.
On Thu, Mar 28, 2024 at 03:07:52PM +0100, neil.armstrong@linaro.org wrote:
> Hi,
>
> On 28/03/2024 14:37, Dmitry Rokosov wrote:
> > Provide right compatible properties for Amlogic A1 Thermal Sensor
> > controller. A1 family supports only one thermal node - CPU thermal
> > sensor.
> >
> > Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> > ---
> > .../bindings/thermal/amlogic,thermal.yaml | 14 +++++++++-----
> > 1 file changed, 9 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> > index 20f8f9b3b971..0e7f6568d385 100644
> > --- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> > +++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> > @@ -13,11 +13,15 @@ description: Binding for Amlogic Thermal
> > properties:
> > compatible:
> > - items:
> > - - enum:
> > - - amlogic,g12a-cpu-thermal
> > - - amlogic,g12a-ddr-thermal
> > - - const: amlogic,g12a-thermal
> > + oneOf:
> > + - items:
> > + - enum:
> > + - amlogic,g12a-cpu-thermal
> > + - amlogic,g12a-ddr-thermal
> > + - const: amlogic,g12a-thermal
> > + - items:
> > + - const: amlogic,a1-cpu-thermal
> > + - const: amlogic,a1-thermal
>
> In this case you can just use "amlogic,a1-cpu-thermal" or "amlogic,a1-thermal", no need for a fallback.
Okay, I will send v2 with only one compatible w/o fallback.
--
Thank you,
Dmitry
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 1/1] dt-bindings: net: dwmac: Document STM32 property st,ext-phyclk
From: Marek Vasut @ 2024-03-28 14:19 UTC (permalink / raw)
To: Christophe Roullier, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Maxime Coquelin, Alexandre Torgue, Richard Cochran,
Jose Abreu, Liam Girdwood, Mark Brown
Cc: netdev, devicetree, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20240328140803.324141-2-christophe.roullier@foss.st.com>
On 3/28/24 3:08 PM, Christophe Roullier wrote:
[...]
> | RMII | - | eth-ck | eth-ck | n/a |
> | | | st,ext-phyclk | st,eth-ref-clk-sel | |
> | | | | or st,ext-phyclk | |
>
> ---------------------------------------------------------------------------
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com>
> ---
> Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> index fc8c96b08d7dc..b35eae80ed6ac 100644
> --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
> @@ -82,6 +82,13 @@ properties:
> Should be phandle/offset pair. The phandle to the syscon node which
> encompases the glue register, and the offset of the control register
>
> +st,ext-phyclk:
Don't you need two spaces in front of the 'st,' here ?
> + description:
> + set this property in RMII mode when you have PHY without crystal 50MHz and want to
> + select RCC clock instead of ETH_REF_CLK. OR in RGMII mode when you want to select
> + RCC clock instead of ETH_CLK125.
> + type: boolean
> +
With that fixed:
Reviewed-by: Marek Vasut <marex@denx.de>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] regset: use kvzalloc() for regset_get_alloc()
From: Doug Anderson @ 2024-03-28 14:16 UTC (permalink / raw)
To: Alexander Viro, Christian Brauner, Andrew Morton
Cc: Mark Brown, Catalin Marinas, Will Deacon, Dave Martin,
Oleg Nesterov, linux-arm-kernel, Matthew Wilcox, Eric Biederman,
Jan Kara, Kees Cook, linux-fsdevel, linux-kernel, linux-mm
In-Reply-To: <CAD=FV=WgGuJLBWmXBOU5oHMvWP2M1cSMS201K8HpyXSYiBPJXQ@mail.gmail.com>
Hi,
On Mon, Feb 26, 2024 at 3:55 PM Doug Anderson <dianders@chromium.org> wrote:
>
> Hi,
>
> On Mon, Feb 5, 2024 at 9:27 AM Douglas Anderson <dianders@chromium.org> wrote:
> >
> > While browsing through ChromeOS crash reports, I found one with an
> > allocation failure that looked like this:
> >
> > chrome: page allocation failure: order:7,
> > mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO),
> > nodemask=(null),cpuset=urgent,mems_allowed=0
> > CPU: 7 PID: 3295 Comm: chrome Not tainted
> > 5.15.133-20574-g8044615ac35c #1 (HASH:1162 1)
> > Hardware name: Google Lazor (rev3 - 8) with KB Backlight (DT)
> > Call trace:
> > ...
> > warn_alloc+0x104/0x174
> > __alloc_pages+0x5f0/0x6e4
> > kmalloc_order+0x44/0x98
> > kmalloc_order_trace+0x34/0x124
> > __kmalloc+0x228/0x36c
> > __regset_get+0x68/0xcc
> > regset_get_alloc+0x1c/0x28
> > elf_core_dump+0x3d8/0xd8c
> > do_coredump+0xeb8/0x1378
> > get_signal+0x14c/0x804
> > ...
> >
> > An order 7 allocation is (1 << 7) contiguous pages, or 512K. It's not
> > a surprise that this allocation failed on a system that's been running
> > for a while.
> >
> > More digging showed that it was fairly easy to see the order 7
> > allocation by just sending a SIGQUIT to chrome (or other processes) to
> > generate a core dump. The actual amount being allocated was 279,584
> > bytes and it was for "core_note_type" NT_ARM_SVE.
> >
> > There was quite a bit of discussion [1] on the mailing lists in
> > response to my v1 patch attempting to switch to vmalloc. The overall
> > conclusion was that we could likely reduce the 279,584 byte allocation
> > by quite a bit and Mark Brown has sent a patch to that effect [2].
> > However even with the 279,584 byte allocation gone there are still
> > 65,552 byte allocations. These are just barely more than the 65,536
> > bytes and thus would require an order 5 allocation.
> >
> > An order 5 allocation is still something to avoid unless necessary and
> > nothing needs the memory here to be contiguous. Change the allocation
> > to kvzalloc() which should still be efficient for small allocations
> > but doesn't force the memory subsystem to work hard (and maybe fail)
> > at getting a large contiguous chunk.
> >
> > [1] https://lore.kernel.org/r/20240201171159.1.Id9ad163b60d21c9e56c2d686b0cc9083a8ba7924@changeid
> > [2] https://lore.kernel.org/r/20240203-arm64-sve-ptrace-regset-size-v1-1-2c3ba1386b9e@kernel.org
> >
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> >
> > Changes in v2:
> > - Use kvzalloc() instead of vmalloc().
> > - Update description based on v1 discussion.
> >
> > fs/binfmt_elf.c | 2 +-
> > kernel/regset.c | 6 +++---
> > 2 files changed, 4 insertions(+), 4 deletions(-)
>
> Just wanted to check in to see if there's anything else that I need to
> do here. Mark's patch to avoid the order 7 allocations [1] has landed,
> but we still want this kvzalloc() because the order 5 allocations
> can't really be avoided. I'm happy to sit tight for longer but just
> wanted to make sure it was clear that we still want my patch _in
> addition_ to Mark's patch and to see if there was anything else you
> needed me to do.
>
> Thanks!
>
> [1] https://lore.kernel.org/r/20240213-arm64-sve-ptrace-regset-size-v2-1-c7600ca74b9b@kernel.org
I'm not trying to be a pest here, so if this is on someone's todo list
and they'll get to it eventually then feel free to tell me to go away
and I'll snooze this for another few months. I just want to make sure
it's not forgotten.
I've been assuming that someone like Al Viro or Christian Brauner
would land this patch eventually and I know Al responded rather
quickly to my v1 [2]. I think all of Al's issues were resolved by Mark
Brown's patch [1] (which has landed in the arm64 tree) and my updating
of the patch description in v2. I see that Al and Christian are
flagged as maintainers of "fs/binfmt_elf.c" which is one of the two
files I'm touching, so that's mostly why I was assuming they would
land it.
...but I realize that perhaps my assumptions are wrong and this needs
to go through a different maintainer. In this case (if I'm reading it
correctly) Al and Christian are listed because the file is under "fs"
even though this isn't _really_ much of a filesystem-related patch.
Perhaps this needs to go through something like Andrew Morton's tree
since he often picks up patches that have nowhere else to land? If
someone else has suggestions, I'm all ears. I'm also happy to repost
this patch in case it helps with a maintainer applying it.
Thanks!
-Doug
[1] https://lore.kernel.org/r/20240213-arm64-sve-ptrace-regset-size-v2-1-c7600ca74b9b@kernel.org
[2] https://lore.kernel.org/r/20240202012249.GU2087318@ZenIV/
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: imx8qxp: add asrc[0,1], esai0, spdif[0,1] and sai[4,5]
From: Shawn Guo @ 2024-03-28 14:10 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <20240226192130.259288-1-Frank.Li@nxp.com>
On Mon, Feb 26, 2024 at 02:21:29PM -0500, Frank Li wrote:
> Add asrc[0,1], esai0, spdif[0,1], sai[4,5] and related lpcg node for
> imx8 audio subsystem.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> .../boot/dts/freescale/imx8-ss-audio.dtsi | 306 ++++++++++++++++++
> 1 file changed, 306 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
> index 07afeb78ed564..6d78d6c0d9002 100644
> --- a/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8-ss-audio.dtsi
> @@ -6,6 +6,7 @@
>
> #include <dt-bindings/clock/imx8-clock.h>
> #include <dt-bindings/clock/imx8-lpcg.h>
> +#include <dt-bindings/dma/fsl-edma.h>
> #include <dt-bindings/firmware/imx/rsrc.h>
>
> audio_ipg_clk: clock-audio-ipg {
> @@ -481,4 +482,309 @@ acm: acm@59e00000 {
> "sai3_rx_bclk",
> "sai4_rx_bclk";
> };
> +
> + asrc0: asrc@59000000 {
We want to sort nodes in unit-address, right?
> + compatible = "fsl,imx8qm-asrc";
> + reg = <0x59000000 0x10000>;
> + interrupts = <GIC_SPI 372 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 373 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&asrc0_lpcg 0>,
> + <&asrc0_lpcg 0>,
> + <&aud_pll_div0_lpcg 0>,
> + <&aud_pll_div1_lpcg 0>,
> + <&acm IMX_ADMA_ACM_AUD_CLK0_SEL>,
> + <&acm IMX_ADMA_ACM_AUD_CLK1_SEL>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>;
> + clock-names = "ipg", "mem",
> + "asrck_0", "asrck_1", "asrck_2", "asrck_3",
> + "asrck_4", "asrck_5", "asrck_6", "asrck_7",
> + "asrck_8", "asrck_9", "asrck_a", "asrck_b",
> + "asrck_c", "asrck_d", "asrck_e", "asrck_f",
> + "spba";
> + dmas = <&edma0 0 0 0>,
> + <&edma0 1 0 0>,
> + <&edma0 2 0 0>,
> + <&edma0 3 0 FSL_EDMA_RX>,
> + <&edma0 4 0 FSL_EDMA_RX>,
> + <&edma0 5 0 FSL_EDMA_RX>;
> + /* tx* is output channel of asrc, it is rx channel for eDMA */
> + dma-names = "rxa", "rxb", "rxc", "txa", "txb", "txc";
> + fsl,asrc-rate = <8000>;
One space around =
> + fsl,asrc-width = <16>;
> + fsl,asrc-clk-map = <0>;
> + power-domains = <&pd IMX_SC_R_ASRC_0>;
> + status = "disabled";
> + };
> +
> + esai0: esai@59010000 {
> + compatible = "fsl,imx8qm-esai", "fsl,imx6ull-esai";
> + reg = <0x59010000 0x10000>;
> + interrupts = <GIC_SPI 409 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&esai0_lpcg 1>, <&esai0_lpcg 0>, <&esai0_lpcg 1>, <&clk_dummy>;
> + clock-names = "core", "extal", "fsys", "spba";
> + dmas = <&edma0 6 0 FSL_EDMA_RX>, <&edma0 7 0 0>;
> + dma-names = "rx", "tx";
> + power-domains = <&pd IMX_SC_R_ESAI_0>;
> + status = "disabled";
> + };
> +
> + spdif0: spdif@59020000 {
> + compatible = "fsl,imx8qm-spdif";
> + reg = <0x59020000 0x10000>;
> + interrupts = <GIC_SPI 456 IRQ_TYPE_LEVEL_HIGH>, /* rx */
Ditto
> + <GIC_SPI 458 IRQ_TYPE_LEVEL_HIGH>; /* tx */
> + clocks = <&spdif0_lpcg 1>, /* core */
> + <&clk_dummy>, /* rxtx0 */
> + <&spdif0_lpcg 0>, /* rxtx1 */
> + <&clk_dummy>, /* rxtx2 */
> + <&clk_dummy>, /* rxtx3 */
> + <&clk_dummy>, /* rxtx4 */
> + <&audio_ipg_clk>, /* rxtx5 */
> + <&clk_dummy>, /* rxtx6 */
> + <&clk_dummy>, /* rxtx7 */
> + <&clk_dummy>; /* spba */
> + clock-names = "core", "rxtx0", "rxtx1", "rxtx2", "rxtx3", "rxtx4",
> + "rxtx5", "rxtx6", "rxtx7", "spba";
> + dmas = <&edma0 8 0 (FSL_EDMA_MULTI_FIFO | FSL_EDMA_RX)>,
> + <&edma0 9 0 FSL_EDMA_MULTI_FIFO>;
> + dma-names = "rx", "tx";
> + power-domains = <&pd IMX_SC_R_SPDIF_0>;
> + status = "disabled";
> + };
> +
> + spdif1: spdif@59030000 {
> + compatible = "fsl,imx8qm-spdif";
> + reg = <0x59030000 0x10000>;
> + interrupts = <GIC_SPI 460 IRQ_TYPE_LEVEL_HIGH>, /* rx */
Ditto
Shawn
> + <GIC_SPI 462 IRQ_TYPE_LEVEL_HIGH>; /* tx */
> + clocks = <&spdif1_lpcg 1>, /* core */
> + <&clk_dummy>, /* rxtx0 */
> + <&spdif1_lpcg 0>, /* rxtx1 */
> + <&clk_dummy>, /* rxtx2 */
> + <&clk_dummy>, /* rxtx3 */
> + <&clk_dummy>, /* rxtx4 */
> + <&audio_ipg_clk>, /* rxtx5 */
> + <&clk_dummy>, /* rxtx6 */
> + <&clk_dummy>, /* rxtx7 */
> + <&clk_dummy>; /* spba */
> + clock-names = "core", "rxtx0", "rxtx1", "rxtx2", "rxtx3", "rxtx4",
> + "rxtx5", "rxtx6", "rxtx7", "spba";
> + dmas = <&edma0 10 0 (FSL_EDMA_MULTI_FIFO | FSL_EDMA_RX)>,
> + <&edma0 11 0 FSL_EDMA_MULTI_FIFO>;
> + dma-names = "rx", "tx";
> + power-domains = <&pd IMX_SC_R_SPDIF_1>;
> + status = "disabled";
> + };
> +
> + asrc1: asrc@59800000 {
> + compatible = "fsl,imx8qm-asrc";
> + reg = <0x59800000 0x10000>;
> + interrupts = <GIC_SPI 380 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 381 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&asrc1_lpcg 0>,
> + <&asrc1_lpcg 0>,
> + <&aud_pll_div0_lpcg 0>,
> + <&aud_pll_div1_lpcg 0>,
> + <&acm IMX_ADMA_ACM_AUD_CLK0_SEL>,
> + <&acm IMX_ADMA_ACM_AUD_CLK1_SEL>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>,
> + <&clk_dummy>;
> + clock-names = "ipg", "mem",
> + "asrck_0", "asrck_1", "asrck_2", "asrck_3",
> + "asrck_4", "asrck_5", "asrck_6", "asrck_7",
> + "asrck_8", "asrck_9", "asrck_a", "asrck_b",
> + "asrck_c", "asrck_d", "asrck_e", "asrck_f",
> + "spba";
> + dmas = <&edma1 0 0 0>,
> + <&edma1 1 0 0>,
> + <&edma1 2 0 0>,
> + <&edma1 3 0 FSL_EDMA_RX>,
> + <&edma1 4 0 FSL_EDMA_RX>,
> + <&edma1 5 0 FSL_EDMA_RX>;
> + /* tx* is output channel of asrc, it is rx channel for eDMA */
> + dma-names = "txa", "txb", "txc", "rxa", "rxb", "rxc";
> + fsl,asrc-rate = <8000>;
> + fsl,asrc-width = <16>;
> + fsl,asrc-clk-map = <1>;
> + power-domains = <&pd IMX_SC_R_ASRC_1>;
> + status = "disabled";
> + };
> +
> + sai4: sai@59820000 {
> + compatible = "fsl,imx8qm-sai";
> + reg = <0x59820000 0x10000>;
> + interrupts = <GIC_SPI 329 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&sai4_lpcg 1>,
> + <&clk_dummy>,
> + <&sai4_lpcg 0>,
> + <&clk_dummy>,
> + <&clk_dummy>;
> + clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
> + dmas = <&edma1 8 0 FSL_EDMA_RX>, <&edma1 9 0 0>;
> + dma-names = "rx", "tx";
> + power-domains = <&pd IMX_SC_R_SAI_4>;
> + status = "disabled";
> + };
> +
> + sai5: sai@59830000 {
> + compatible = "fsl,imx8qm-sai";
> + reg = <0x59830000 0x10000>;
> + interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&sai5_lpcg 1>,
> + <&clk_dummy>,
> + <&sai5_lpcg 0>,
> + <&clk_dummy>,
> + <&clk_dummy>;
> + clock-names = "bus", "mclk0", "mclk1", "mclk2", "mclk3";
> + dmas = <&edma1 10 0 0>;
> + dma-names = "tx";
> + power-domains = <&pd IMX_SC_R_SAI_5>;
> + status = "disabled";
> + };
> +
> + amix: amix@59840000 {
> + compatible = "fsl,imx8qm-audmix";
> + reg = <0x59840000 0x10000>;
> + clocks = <&amix_lpcg 0>;
> + clock-names = "ipg";
> + power-domains = <&pd IMX_SC_R_AMIX>;
> + dais = <&sai4>, <&sai5>;
> + status = "disabled";
> + };
> +
> + mqs: mqs@59850000 {
> + compatible = "fsl,imx8qm-mqs";
> + reg = <0x59850000 0x10000>;
> + clocks = <&mqs0_lpcg 1>,
> + <&mqs0_lpcg 0>;
> + clock-names = "core", "mclk";
> + power-domains = <&pd IMX_SC_R_MQS_0>;
> + status = "disabled";
> + };
> +
> + asrc0_lpcg: clock-controller@59400000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59400000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_4>;
> + clock-output-names = "asrc0_lpcg_ipg_clk";
> + power-domains = <&pd IMX_SC_R_ASRC_0>;
> + };
> +
> + esai0_lpcg: clock-controller@59410000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59410000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&acm IMX_ADMA_ACM_ESAI0_MCLK_SEL>,
> + <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> + clock-output-names = "esai0_lpcg_extal_clk",
> + "esai0_lpcg_ipg_clk";
> + power-domains = <&pd IMX_SC_R_ESAI_0>;
> + };
> +
> + spdif0_lpcg: clock-controller@59420000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59420000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&acm IMX_ADMA_ACM_SPDIF0_TX_CLK_SEL>,
> + <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> + clock-output-names = "spdif0_lpcg_tx_clk",
> + "spdif0_lpcg_gclkw";
> + power-domains = <&pd IMX_SC_R_SPDIF_0>;
> + };
> +
> + spdif1_lpcg: clock-controller@59430000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59430000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&acm IMX_ADMA_ACM_SPDIF1_TX_CLK_SEL>,
> + <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> + clock-output-names = "spdif1_lpcg_tx_clk",
> + "spdif1_lpcg_gclkw";
> + power-domains = <&pd IMX_SC_R_SPDIF_1>;
> + status = "disabled";
> + };
> +
> + asrc1_lpcg: clock-controller@59c00000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59c00000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_4>;
> + clock-output-names = "asrc1_lpcg_ipg_clk";
> + power-domains = <&pd IMX_SC_R_ASRC_1>;
> + };
> +
> + sai4_lpcg: clock-controller@59c20000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59c20000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&acm IMX_ADMA_ACM_SAI4_MCLK_SEL>,
> + <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> + clock-output-names = "sai4_lpcg_mclk",
> + "sai4_lpcg_ipg_clk";
> + power-domains = <&pd IMX_SC_R_SAI_4>;
> + };
> +
> + sai5_lpcg: clock-controller@59c30000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59c30000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&acm IMX_ADMA_ACM_SAI5_MCLK_SEL>,
> + <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> + clock-output-names = "sai5_lpcg_mclk",
> + "sai5_lpcg_ipg_clk";
> + power-domains = <&pd IMX_SC_R_SAI_5>;
> + };
> +
> + amix_lpcg: clock-controller@59c40000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59c40000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_0>;
> + clock-output-names = "amix_lpcg_ipg_clk";
> + power-domains = <&pd IMX_SC_R_AMIX>;
> + };
> +
> + mqs0_lpcg: clock-controller@59c50000 {
> + compatible = "fsl,imx8qxp-lpcg";
> + reg = <0x59c50000 0x10000>;
> + #clock-cells = <1>;
> + clocks = <&acm IMX_ADMA_ACM_MQS_TX_CLK_SEL>,
> + <&audio_ipg_clk>;
> + clock-indices = <IMX_LPCG_CLK_0>, <IMX_LPCG_CLK_4>;
> + clock-output-names = "mqs0_lpcg_mclk",
> + "mqs0_lpcg_ipg_clk";
> + power-domains = <&pd IMX_SC_R_MQS_0>;
> + };
> };
> --
> 2.34.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 0/1] Add property in dwmac-stm32 documentation
From: Christophe Roullier @ 2024-03-28 14:08 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Richard Cochran, Jose Abreu, Liam Girdwood,
Mark Brown, Christophe Roullier, Marek Vasut
Cc: netdev, devicetree, linux-stm32, linux-arm-kernel, linux-kernel
Introduce property in dwmac-stm32 documentation
- st,ext-phyclk: is present since 2020 in driver so need to explain
it and avoid dtbs check issue : views/kernel/upstream/net-next/arch/arm/boot/dts/st/stm32mp157c-dk2.dtb:
ethernet@5800a000: Unevaluated properties are not allowed
('st,ext-phyclk' was unexpected)
Furthermore this property will be use in upstream of MP13 dwmac glue. (next step)
V2: - Drop deprecated: property for st,eth-clk-sel and st,eth-ref-clk-sel
V3: - Rework commit message
V4: - Fix syntax issue in commit message
V5: - Remark from Andrew Lunn (remove documentation of PHY regulator, it will come in next step (with
implementation))
Christophe Roullier (1):
dt-bindings: net: dwmac: Document STM32 property st,ext-phyclk
Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 7 +++++++
1 file changed, 7 insertions(+)
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 1/1] dt-bindings: net: dwmac: Document STM32 property st,ext-phyclk
From: Christophe Roullier @ 2024-03-28 14:08 UTC (permalink / raw)
To: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Maxime Coquelin,
Alexandre Torgue, Richard Cochran, Jose Abreu, Liam Girdwood,
Mark Brown, Christophe Roullier, Marek Vasut
Cc: netdev, devicetree, linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <20240328140803.324141-1-christophe.roullier@foss.st.com>
The Linux kernel dwmac-stm32 driver currently supports three DT
properties used to configure whether PHY clock are generated by
the MAC or supplied to the MAC from the PHY.
Originally there were two properties, st,eth-clk-sel and
st,eth-ref-clk-sel, each used to configure MAC clocking in
different bus mode and for different MAC clock frequency.
Since it is possible to determine the MAC 'eth-ck' clock
frequency from the clock subsystem and PHY bus mode from
the 'phy-mode' property, two disparate DT properties are
no longer required to configure MAC clocking.
Linux kernel commit 1bb694e20839 ("net: ethernet: stmmac: simplify phy modes management for stm32")
introduced a third, unified, property st,ext-phyclk. This property
covers both use cases of st,eth-clk-sel and st,eth-ref-clk-sel DT
properties, as well as a new use case for 25 MHz clock generated
by the MAC.
The third property st,ext-phyclk is so far undocumented,
document it.
Below table summarizes the clock requirement and clock sources for
supported PHY interface modes.
__________________________________________________________________________
|PHY_MODE | Normal | PHY wo crystal| PHY wo crystal |No 125Mhz from PHY|
| | | 25MHz | 50MHz | |
---------------------------------------------------------------------------
| MII | - | eth-ck | n/a | n/a |
| | | st,ext-phyclk | | |
---------------------------------------------------------------------------
| GMII | - | eth-ck | n/a | n/a |
| | | st,ext-phyclk | | |
---------------------------------------------------------------------------
| RGMII | - | eth-ck | n/a | eth-ck |
| | | st,ext-phyclk | | st,eth-clk-sel or|
| | | | | st,ext-phyclk |
---------------------------------------------------------------------------
| RMII | - | eth-ck | eth-ck | n/a |
| | | st,ext-phyclk | st,eth-ref-clk-sel | |
| | | | or st,ext-phyclk | |
---------------------------------------------------------------------------
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Christophe Roullier <christophe.roullier@foss.st.com>
---
Documentation/devicetree/bindings/net/stm32-dwmac.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
index fc8c96b08d7dc..b35eae80ed6ac 100644
--- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
+++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml
@@ -82,6 +82,13 @@ properties:
Should be phandle/offset pair. The phandle to the syscon node which
encompases the glue register, and the offset of the control register
+st,ext-phyclk:
+ description:
+ set this property in RMII mode when you have PHY without crystal 50MHz and want to
+ select RCC clock instead of ETH_REF_CLK. OR in RGMII mode when you want to select
+ RCC clock instead of ETH_CLK125.
+ type: boolean
+
st,eth-clk-sel:
description:
set this property in RGMII PHY when you want to select RCC clock instead of ETH_CLK125.
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] ASoC: sun8i-codec: Fix build with CONFIG_SND_JACK_INPUT_DEV disabled
From: Mark Brown @ 2024-03-28 14:10 UTC (permalink / raw)
To: linux-kernel, Ondřej Jirman
Cc: kernel test robot, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Rob Herring,
AngeloGioacchino Del Regno, Claudiu Beznea, Arnaud Ferraris,
linux-sound, linux-arm-kernel, linux-sunxi
In-Reply-To: <20240327080542.3649840-1-megi@xff.cz>
On Wed, 27 Mar 2024 09:05:34 +0100, Ondřej Jirman wrote:
> When CONFIG_SND_JACK_INPUT_DEV is disabled, struct snd_jack doesn't
> have 'type' field. We can't rely on this field being always present,
> so store the jack_type in the codec driver itself.
>
>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: sun8i-codec: Fix build with CONFIG_SND_JACK_INPUT_DEV disabled
commit: 559aebe45a054a479fdbd2a3dfba999ffd73cc9d
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 1/3] arm64: dts: amlogic: a1: add cooling-cells for DVFS feature
From: neil.armstrong @ 2024-03-28 14:08 UTC (permalink / raw)
To: Dmitry Rokosov, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel
In-Reply-To: <20240328134459.18446-2-ddrokosov@salutedevices.com>
On 28/03/2024 14:44, Dmitry Rokosov wrote:
> It's used for CPU with DVFS feature to specify minimum and maximum
> cooling state used in the reference.
> Without these values DVFS will not work and dtbs_check will raise the
> error.
>
> Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> ---
> arch/arm64/boot/dts/amlogic/meson-a1.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
> index fbee986421f1..f65d4a77ee52 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-a1.dtsi
> @@ -32,6 +32,7 @@ cpu0: cpu@0 {
> reg = <0x0 0x0>;
> enable-method = "psci";
> next-level-cache = <&l2>;
> + #cooling-cells = <2>;
> };
>
> cpu1: cpu@1 {
> @@ -40,6 +41,7 @@ cpu1: cpu@1 {
> reg = <0x0 0x1>;
> enable-method = "psci";
> next-level-cache = <&l2>;
> + #cooling-cells = <2>;
> };
>
> l2: l2-cache0 {
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 2/2] thermal: amlogic: support A1 SoC family Thermal Sensor controller
From: neil.armstrong @ 2024-03-28 14:08 UTC (permalink / raw)
To: Dmitry Rokosov, jbrunet, mturquette, khilman, martin.blumenstingl,
glaroque, rafael, daniel.lezcano, rui.zhang, lukasz.luba, robh+dt,
krzysztof.kozlowski+dt, conor+dt
Cc: kernel, rockosov, linux-amlogic, linux-pm, linux-kernel,
devicetree, linux-arm-kernel
In-Reply-To: <20240328133802.15651-3-ddrokosov@salutedevices.com>
On 28/03/2024 14:37, Dmitry Rokosov wrote:
> In comparison to other Amlogic chips, there is one key difference.
> The offset for the sec_ao base, also known as u_efuse_off, is special,
> while other aspects remain the same.
>
> Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
> ---
> drivers/thermal/amlogic_thermal.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/thermal/amlogic_thermal.c b/drivers/thermal/amlogic_thermal.c
> index 5877cde25b79..1d23afd32013 100644
> --- a/drivers/thermal/amlogic_thermal.c
> +++ b/drivers/thermal/amlogic_thermal.c
> @@ -222,6 +222,12 @@ static const struct amlogic_thermal_data amlogic_thermal_g12a_ddr_param = {
> .regmap_config = &amlogic_thermal_regmap_config_g12a,
> };
>
> +static const struct amlogic_thermal_data amlogic_thermal_a1_cpu_param = {
> + .u_efuse_off = 0x114,
> + .calibration_parameters = &amlogic_thermal_g12a,
> + .regmap_config = &amlogic_thermal_regmap_config_g12a,
> +};
> +
> static const struct of_device_id of_amlogic_thermal_match[] = {
> {
> .compatible = "amlogic,g12a-ddr-thermal",
> @@ -231,6 +237,10 @@ static const struct of_device_id of_amlogic_thermal_match[] = {
> .compatible = "amlogic,g12a-cpu-thermal",
> .data = &amlogic_thermal_g12a_cpu_param,
> },
> + {
> + .compatible = "amlogic,a1-cpu-thermal",
> + .data = &amlogic_thermal_a1_cpu_param,
> + },
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, of_amlogic_thermal_match);
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Keep it even it you change the compatible,
Thanks,
Neil
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox