Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v1 0/3] Speed up boot with faster linear map creation
From: Ryan Roberts @ 2024-03-27 11:10 UTC (permalink / raw)
  To: Itaru Kitayama
  Cc: Catalin Marinas, Will Deacon, Mark Rutland, Ard Biesheuvel,
	David Hildenbrand, Donald Dutile, Eric Chanudet, linux-arm-kernel,
	linux-kernel
In-Reply-To: <ZgP9zfHz2NfiQqSZ@vm3>

On 27/03/2024 11:06, Itaru Kitayama wrote:
> On Tue, Mar 26, 2024 at 10:14:45AM +0000, Ryan Roberts wrote:
>> Hi All,
>>
>> It turns out that creating the linear map can take a significant proportion of
>> the total boot time, especially when rodata=full. And a large portion of the
>> time it takes to create the linear map is issuing TLBIs. This series reworks the
>> kernel pgtable generation code to significantly reduce the number of TLBIs. See
>> each patch for details.
>>
>> The below shows the execution time of map_mem() across a couple of different
>> systems with different RAM configurations. We measure after applying each patch
>> and show the improvement relative to base (v6.9-rc1):
>>
>>                | Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra
>>                | VM, 16G     | VM, 64G     | VM, 256G    | Metal, 512G
>> ---------------|-------------|-------------|-------------|-------------
>>                |   ms    (%) |   ms    (%) |   ms    (%) |    ms    (%)
>> ---------------|-------------|-------------|-------------|-------------
>> base           |  151   (0%) | 2191   (0%) | 8990   (0%) | 17443   (0%)
>> no-cont-remap  |   77 (-49%) |  429 (-80%) | 1753 (-80%) |  3796 (-78%)
>> no-alloc-remap |   77 (-49%) |  375 (-83%) | 1532 (-83%) |  3366 (-81%)
>> lazy-unmap     |   63 (-58%) |  330 (-85%) | 1312 (-85%) |  2929 (-83%)
>>
>> This series applies on top of v6.9-rc1. All mm selftests pass. I haven't yet
>> tested all VA size configs (although I don't anticipate any issues); I'll do
>> this as part of followup.
> 
> The series was applied cleanly on top of v6.9-rc1+ of Linus's master
> branch, and boots fine on M1 VM with 14GB of memory.
> 
> Just out of curiosity, how did you measure the boot time and obtain the
> breakdown of the execution times of each phase?

diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 495b732d5af3..8a9d47115784 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -792,7 +792,14 @@ static void __init create_idmap(void)

 void __init paging_init(void)
 {
+       u64 start, end;
+
+       start = __arch_counter_get_cntvct();
        map_mem(swapper_pg_dir);
+       end = __arch_counter_get_cntvct();
+
+       pr_err("map_mem: time=%llu us\n",
+               ((end - start) * 1000000) / arch_timer_get_cntfrq());

        memblock_allow_resize();

> 
> Tested-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>

Thanks!

> 
> Thanks,
> Itaru.
> 
>>
>> Thanks,
>> Ryan
>>
>>
>> Ryan Roberts (3):
>>   arm64: mm: Don't remap pgtables per- cont(pte|pmd) block
>>   arm64: mm: Don't remap pgtables for allocate vs populate
>>   arm64: mm: Lazily clear pte table mappings from fixmap
>>
>>  arch/arm64/include/asm/fixmap.h  |   5 +-
>>  arch/arm64/include/asm/mmu.h     |   8 +
>>  arch/arm64/include/asm/pgtable.h |   4 -
>>  arch/arm64/kernel/cpufeature.c   |  10 +-
>>  arch/arm64/mm/fixmap.c           |  11 +
>>  arch/arm64/mm/mmu.c              | 364 +++++++++++++++++++++++--------
>>  include/linux/pgtable.h          |   8 +
>>  7 files changed, 307 insertions(+), 103 deletions(-)
>>
>> --
>> 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 v1 0/3] Speed up boot with faster linear map creation
From: Itaru Kitayama @ 2024-03-27 11:06 UTC (permalink / raw)
  To: Ryan Roberts
  Cc: Catalin Marinas, Will Deacon, Mark Rutland, Ard Biesheuvel,
	David Hildenbrand, Donald Dutile, Eric Chanudet, linux-arm-kernel,
	linux-kernel
In-Reply-To: <20240326101448.3453626-1-ryan.roberts@arm.com>

On Tue, Mar 26, 2024 at 10:14:45AM +0000, Ryan Roberts wrote:
> Hi All,
> 
> It turns out that creating the linear map can take a significant proportion of
> the total boot time, especially when rodata=full. And a large portion of the
> time it takes to create the linear map is issuing TLBIs. This series reworks the
> kernel pgtable generation code to significantly reduce the number of TLBIs. See
> each patch for details.
> 
> The below shows the execution time of map_mem() across a couple of different
> systems with different RAM configurations. We measure after applying each patch
> and show the improvement relative to base (v6.9-rc1):
> 
>                | Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra
>                | VM, 16G     | VM, 64G     | VM, 256G    | Metal, 512G
> ---------------|-------------|-------------|-------------|-------------
>                |   ms    (%) |   ms    (%) |   ms    (%) |    ms    (%)
> ---------------|-------------|-------------|-------------|-------------
> base           |  151   (0%) | 2191   (0%) | 8990   (0%) | 17443   (0%)
> no-cont-remap  |   77 (-49%) |  429 (-80%) | 1753 (-80%) |  3796 (-78%)
> no-alloc-remap |   77 (-49%) |  375 (-83%) | 1532 (-83%) |  3366 (-81%)
> lazy-unmap     |   63 (-58%) |  330 (-85%) | 1312 (-85%) |  2929 (-83%)
> 
> This series applies on top of v6.9-rc1. All mm selftests pass. I haven't yet
> tested all VA size configs (although I don't anticipate any issues); I'll do
> this as part of followup.

The series was applied cleanly on top of v6.9-rc1+ of Linus's master
branch, and boots fine on M1 VM with 14GB of memory.

Just out of curiosity, how did you measure the boot time and obtain the
breakdown of the execution times of each phase?

Tested-by: Itaru Kitayama <itaru.kitayama@fujitsu.com>

Thanks,
Itaru.

> 
> Thanks,
> Ryan
> 
> 
> Ryan Roberts (3):
>   arm64: mm: Don't remap pgtables per- cont(pte|pmd) block
>   arm64: mm: Don't remap pgtables for allocate vs populate
>   arm64: mm: Lazily clear pte table mappings from fixmap
> 
>  arch/arm64/include/asm/fixmap.h  |   5 +-
>  arch/arm64/include/asm/mmu.h     |   8 +
>  arch/arm64/include/asm/pgtable.h |   4 -
>  arch/arm64/kernel/cpufeature.c   |  10 +-
>  arch/arm64/mm/fixmap.c           |  11 +
>  arch/arm64/mm/mmu.c              | 364 +++++++++++++++++++++++--------
>  include/linux/pgtable.h          |   8 +
>  7 files changed, 307 insertions(+), 103 deletions(-)
> 
> --
> 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

* Re: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Krzysztof Kozlowski @ 2024-03-27 11:04 UTC (permalink / raw)
  To: Yu-chang Lee (李禹璋),
	MandyJH Liu (劉人僖), conor+dt@kernel.org,
	robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	matthias.bgg@gmail.com, ulf.hansson@linaro.org,
	angelogioacchino.delregno@collabora.com
  Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
	devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
	Project_Global_Chrome_Upstream_Group,
	Xiufeng Li (李秀峰),
	linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <7f24ca2806a7199e4de6fad17b8dc1f127c82180.camel@mediatek.com>

On 27/03/2024 11:56, Yu-chang Lee (李禹璋) wrote:
> On Wed, 2024-03-27 at 11:43 +0100, Krzysztof Kozlowski wrote:
>>  	 
>> External email : Please do not click links or open attachments until
>> you have verified the sender or the content.
>>  On 27/03/2024 11:39, Yu-chang Lee (李禹璋) wrote:
>>>>>>
>>>>> Hi,
>>>>>
>>>>> I will double check the format of yaml for the next version,
>> sorry
>>>> for
>>>>> inconvenience. But I did test it on mt8188 chromebook, the reason
>>>> why
>>>>
>>>> How do you test a binding on chromebook?
>>>>
>>>>> power domain need larb node is that when mtcmos power on, signal
>>>> glitch
>>>>> may produce. Power domain driver must reset larb when this happen
>>>> to 
>>>>> prevent dummy transaction on bus. That why I need larb node in
>> dts.
>>>>
>>>> No one talks here about larb node...
>>>
>>> Sorry, May you elaborate on what information I need to provide to
>> you
>>> or it is just a syntax problem I need to fix?
>>
>> Please explain the purpose of this property (how is it going to be
>> used by drivers)and what does it represent.
>>
> 
> It represent SMI LARB(Local ARBitration). In power domain driver when
> power on power domain, It need to reset LARB to prevent potential power
> glitch which may cause dummy transaction on bus. Without taking care of
> this issue it often leads to camera hang in stress test.

That sounds rather like missing resets... or something else connecting
these devices. Maybe the explanation is just imprecise...

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [RFC PATCH] net: stmmac: Fix the problem about interrupt storm
From: Cathy Cai @ 2024-03-27 11:01 UTC (permalink / raw)
  To: cathycai0714, davem, edumazet, kuba, pabeni, mcoquelin.stm32,
	netdev, linux-kernel
  Cc: cathy.cai, xuewen.yan94, cixi.geng1, wade.shu, zhiguo.niu,
	alexandre.torgue, joabreu, linux-stm32, linux-arm-kernel

After I do seven days of MSR test (monkey sleep reboot test) in Android,
I can encounter below netdev watchdog timeout issue. Tx queue timed out
then reset adapter. There is a probability that an interruption storm will
occur and the system will crash.

When we do MSR test, there is a NETDEV WATCHDOG WARNING:
[  117.885804] ------------[ cut here ]------------
[  117.885818] NETDEV WATCHDOG: eth0 (stmmaceth): transmit queue 0 timed
               out
[  117.885873] WARNING: CPU: 1 PID: 4169 at net/sched/sch_generic.c:473
               dev_watchdog+0x2fc/0x41c
[  117.886070]  sprd_systimer sprd_sip_svc sprd_wdt_fiq sprd_wdt_pon
[  117.886082] CPU: 1 PID: 4169 Comm: RenderThread Tainted: G S       C O
               5.4.147-ab41313 #1
[  117.886085] Hardware name: Spreadtrum UIS6780 SoC (DT)
[  117.886090] pstate: 60400005 (nZCv daif +PAN -UAO)
[  117.886094] pc : dev_watchdog+0x2fc/0x41c
[  117.886098] lr : dev_watchdog+0x2fc/0x41c
[  117.886100] sp : ffffffc01000bcf0
[  117.886103] x29: ffffffc01000bcf0 x28: ffffffc011eafe28
[  117.886107] x27: ffffff80f97a5c40 x26: 00000000ffffffff
[  117.886111] x25: 0000000000000001 x24: 0000000000000008
[  117.886114] x23: ffffffc011ea6000 x22: ffffffc011e73020
[  117.886118] x21: 0000000000000000 x20: ffffff80f434841c
[  117.886122] x19: ffffff80f4348000 x18: ffffffc01000d048
[  117.886127] x17: ffffffc012050044 x16: 00000000000508d0
[  117.886130] x15: 0000000000000006 x14: 0000000000000058
[  117.886134] x13: 0000000000000008 x12: 0000000042d7d11b
[  117.886138] x11: 0000000000000015 x10: 0000000000000001
[  117.886141] x9 : a6fe08b7d867fd00 x8 : a6fe08b7d867fd00
[  117.886145] x7 : 0000000000000000 x6 : ffffffc0120a0899
[  117.886149] x5 : 0000000000000058 x4 : 0000000000000002
[  117.886152] x3 : ffffffc01000b980 x2 : 0000000000000007
[  117.886156] x1 : 0000000000000006 x0 : 000000000000003d
[  117.886164]

[  117.887028]
[  117.887030] Call trace:
[  117.887035]  dev_watchdog+0x2fc/0x41c
[  117.887043]  call_timer_fn+0x5c/0x274
[  117.887046]  expire_timers+0x74/0x1b4
[  117.887050]  __run_timers+0x250/0x2b0
[  117.887054]  run_timer_softirq+0x28/0x4c
[  117.887061]  __do_softirq+0x128/0x4dc
[  117.887067]  irq_exit+0xf8/0xfc
[  117.887072]  __handle_domain_irq+0xb0/0x108
[  117.887076]  gic_handle_irq+0x6c/0x124
[  117.887081]  el0_irq_naked+0x64/0x74
[  117.887084] ---[ end trace 1308772835db89f6 ]---
[  117.887188] stmmaceth 32600000.ethernet eth0: Reset adapter.

Tx queue time out then reset adapter. When reset the adapter, stmmac driver
sets the state to STMMAC_DOWN and calls dev_close() function. If an interrupt
is triggered at this instant after setting state to STMMAC_DOWN, before the
dev_close() call.

The scene is as follows:
stmmac_reset_subtask()
	set_bit(STMMAC_DOWN, &priv->state);
					--->interrupt
					  stmmac_interrupt()
					    return IRQ_HANDLED
	dev_close(priv->dev);

The interrupt handler stmmac_interrupt is executed, judging that the state is
STMMAC_DOWN and returning IRQ_HANDLED. Then the processing will not continue,
and it will not be able to clear the interrupt status.

Therefore, to avoid this, set STMMAC_DOWN after dev_close().

Signed-off-by: Cathy Cai <cathy.cai@unisoc.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 24cd80490d19..61690b68b6ad 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -7167,8 +7167,8 @@ static void stmmac_reset_subtask(struct stmmac_priv *priv)
 	while (test_and_set_bit(STMMAC_RESETING, &priv->state))
 		usleep_range(1000, 2000);
 
-	set_bit(STMMAC_DOWN, &priv->state);
 	dev_close(priv->dev);
+	set_bit(STMMAC_DOWN, &priv->state);
 	dev_open(priv->dev, NULL);
 	clear_bit(STMMAC_DOWN, &priv->state);
 	clear_bit(STMMAC_RESETING, &priv->state);
-- 
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

* Re: [PATCH v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Yu-chang Lee (李禹璋) @ 2024-03-27 10:39 UTC (permalink / raw)
  To: krzysztof.kozlowski@linaro.org,
	MandyJH Liu (劉人僖), conor+dt@kernel.org,
	robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	matthias.bgg@gmail.com, ulf.hansson@linaro.org,
	angelogioacchino.delregno@collabora.com
  Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
	devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
	Project_Global_Chrome_Upstream_Group,
	Xiufeng Li (李秀峰),
	linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <7ff9c4c7-3b56-4a5b-95b7-c37cbf8bcd6d@linaro.org>

On Wed, 2024-03-27 at 10:59 +0100, Krzysztof Kozlowski wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 27/03/2024 10:34, Yu-chang Lee (李禹璋) wrote:
> > On Wed, 2024-03-27 at 10:23 +0100, Krzysztof Kozlowski wrote:
> >>   
> >> External email : Please do not click links or open attachments
> until
> >> you have verified the sender or the content.
> >>  On 27/03/2024 09:39, Krzysztof Kozlowski wrote:
> >>> On 27/03/2024 06:57, yu-chang.lee wrote:
> >>>> Add Smart Multimedia Interface Local Arbiter to mediatek
> >>>> power domain.
> >>>>
> >>>> Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com>
> >>>> ---
> >>>>  .../devicetree/bindings/power/mediatek,power-controller.yaml  | 
> 4
> >> ++++
> >>>>  1 file changed, 4 insertions(+)
> >>>>
> >>>> diff --git
> >> a/Documentation/devicetree/bindings/power/mediatek,power-
> >> controller.yaml
> >> b/Documentation/devicetree/bindings/power/mediatek,power-
> >> controller.yaml
> >>>> index 8985e2df8a56..228c0dec5253 100644
> >>>> --- a/Documentation/devicetree/bindings/power/mediatek,power-
> >> controller.yaml
> >>>> +++ b/Documentation/devicetree/bindings/power/mediatek,power-
> >> controller.yaml
> >>>> @@ -125,6 +125,10 @@ $defs:
> >>>>          $ref: /schemas/types.yaml#/definitions/phandle
> >>>>          description: phandle to the device containing the SMI
> >> register range.
> >>>>  
> >>>> +     mediatek,larb:
> >>>> +        $ref: /schemas/types.yaml#/definitions/phandle
> >>>> +        description: phandle to the device containing the LARB
> >> register range.
> >>>
> >>> Why do you need it?
> >>>
> >>> Plus I also see mediatek,larbs and mediatek,larb-id... so now we
> >> have
> >>> third one similar.
> >>
> >> ... and not even tested!
> >>
> >> Best regards,
> >> Krzysztof
> >>
> > Hi,
> > 
> > I will double check the format of yaml for the next version, sorry
> for
> > inconvenience. But I did test it on mt8188 chromebook, the reason
> why
> 
> How do you test a binding on chromebook?
> 
> > power domain need larb node is that when mtcmos power on, signal
> glitch
> > may produce. Power domain driver must reset larb when this happen
> to 
> > prevent dummy transaction on bus. That why I need larb node in dts.
> 
> No one talks here about larb node...

Sorry, May you elaborate on what information I need to provide to you
or it is just a syntax problem I need to fix?

Thanks
Best Regards,

Yu-chang
> 
> Best regards,
> Krzysztof
> 
_______________________________________________
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] dt-bindings: power: Add mediatek larb definition
From: Yu-chang Lee (李禹璋) @ 2024-03-27 10:56 UTC (permalink / raw)
  To: krzysztof.kozlowski@linaro.org,
	MandyJH Liu (劉人僖), conor+dt@kernel.org,
	robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	matthias.bgg@gmail.com, ulf.hansson@linaro.org,
	angelogioacchino.delregno@collabora.com
  Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
	devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
	Project_Global_Chrome_Upstream_Group,
	Xiufeng Li (李秀峰),
	linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <038ccb20-71cb-40d2-9720-ce1a0d3eac8c@linaro.org>

On Wed, 2024-03-27 at 11:43 +0100, Krzysztof Kozlowski wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  On 27/03/2024 11:39, Yu-chang Lee (李禹璋) wrote:
> >>>>
> >>> Hi,
> >>>
> >>> I will double check the format of yaml for the next version,
> sorry
> >> for
> >>> inconvenience. But I did test it on mt8188 chromebook, the reason
> >> why
> >>
> >> How do you test a binding on chromebook?
> >>
> >>> power domain need larb node is that when mtcmos power on, signal
> >> glitch
> >>> may produce. Power domain driver must reset larb when this happen
> >> to 
> >>> prevent dummy transaction on bus. That why I need larb node in
> dts.
> >>
> >> No one talks here about larb node...
> > 
> > Sorry, May you elaborate on what information I need to provide to
> you
> > or it is just a syntax problem I need to fix?
> 
> Please explain the purpose of this property (how is it going to be
> used by drivers)and what does it represent.
> 

It represent SMI LARB(Local ARBitration). In power domain driver when
power on power domain, It need to reset LARB to prevent potential power
glitch which may cause dummy transaction on bus. Without taking care of
this issue it often leads to camera hang in stress test.

Best Regards,
Yu-chang
_______________________________________________
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/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards
From: Josua Mayer @ 2024-03-27 10:55 UTC (permalink / raw)
  To: Krzysztof Kozlowski, Andrew Lunn, Gregory Clement,
	Sebastian Hesselbarth, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley
  Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <62242f04-c18d-4da0-bd40-1be26886e41a@linaro.org>

Am 27.03.24 um 11:19 schrieb Krzysztof Kozlowski:
> On 26/03/2024 20:26, Josua Mayer wrote:
>> Am 26.03.24 um 07:41 schrieb Krzysztof Kozlowski:
>>> On 25/03/2024 21:12, Josua Mayer wrote:
>>>> Am 25.03.24 um 20:34 schrieb Krzysztof Kozlowski:
>>>>> On 22/03/2024 11:08, Josua Mayer wrote:
>>>>>> Am 21.03.24 um 22:47 schrieb Josua Mayer:
>>>>>>> Add bindings for SolidRun Clearfog boards, using a new SoM based on
>>>>>>> CN9130 SoC.
>>>>>>> The carrier boards are identical to the older Armada 388 based Clearfog
>>>>>>> boards. For consistency the carrier part of compatible strings are
>>>>>>> copied, including the established "-a1" suffix.
>>>>>>>
>>>>>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>>>>>> ---
>>>>>>>  .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml        | 12 ++++++++++++
>>>>>>>  1 file changed, 12 insertions(+)
>>>>>>>
>>>>>>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>>>>>> index 16d2e132d3d1..36bdfd1bedd9 100644
>>>>>>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>>>>>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>>>>>> @@ -82,4 +82,16 @@ properties:
>>>>>>>            - const: marvell,armada-ap807-quad
>>>>>>>            - const: marvell,armada-ap807
>>>>>>>  
>>>>>>> +      - description:
>>>>>>> +          SolidRun CN9130 clearfog family single-board computers
>>>>>>> +        items:
>>>>>>> +          - enum:
>>>>>>> +              - solidrun,clearfog-base-a1
>>>>>>> +              - solidrun,clearfog-pro-a1
>>>>>>> +          - const: solidrun,clearfog-a1
>>>>>>> +          - const: solidrun,cn9130-sr-som
>>>>>>> +          - const: marvell,cn9130
>>>>>>> +          - const: marvell,armada-ap807-quad
>>>>>>> +          - const: marvell,armada-ap807
>>>>>>> +
>>>>>>>  additionalProperties: true
>>>>>> Before merging I would like some feedback about adding
>>>>>> another product later, to ensure the compatibles above
>>>>>> are adequate? In particular:
>>>>>> - sequence of soc, cp, carrier compatibles
>>>>>> - name of som compatible
>>>>>>
>>>>>> Draft for future bindings:
>>>>>>       - description:
>>>>>>           SolidRun CN9130 SoM based single-board computers
>>>>>>           with 1 external CP on the Carrier.
>>>>>>         items:
>>>>>>           - enum:
>>>>>>               - solidrun,cn9131-solidwan
>>>>>>           - const: marvell,cn9131
>>>>>>           - const: solidrun,cn9130-sr-som
>>>>> This does not look correct. cn9131 is not compatible with your som.
>>>> This is partially my question.
>>>> I considered changing the som to "cn913x-sr-som".
>>>>
>>>> The SoM itself is always 9130, it contains the base SoC
>>>> with 1x AP and 1x CP in a single chip.
>>>> 9131 and 9132 <happen> on the carrier boards.
>>> No wildcards, but if the SoM name is 9130 then use 9130.
>>> The problem is that you use cn9130 SoC as fallback.
>>>
>>>>>>           - const: marvell,cn9130
>>>>> SoCs are compatible only in some cases, e.g. one is a subset of another
>>>>> like stripped out of modem. Are you sure this is your case?
>>>> This is more complex, CN9131 and CN9132 are not single SoCs.
>>>> A "9132" is instantiated by connecting two southbridge chips
>>>> via a Marvell defined bus, each providing additional IO
>>>> such as network, i2c, gpio.
>>>>
>>>> Note that even the first, "9130", while a single chip, contains two dies:
>>>> An "AP" (Application Processor I assume) with very limited IO (1xsdio, 1xi2c),
>>>> and a "CP" (Communication Processor I assume) with lots of IO.
>>>> This CP as far as I know today is identical to the southbridges
>>>> mentioned above.
>>> OK, but how does it affect compatibility between them? Which parts are
>>> the same? Or how much is shared?
>> 9130, 9131, 9132 belong together.
> I don't understand what it means.
>
>> 9130 is single chip including two dies: AP, CP.
>> The CP is available as an individual chip,
>> up to two can be connected to one 9130.
> And? How does it help me to decide? What is 9131 and 9132?
>
>> What does this mean for compatibility?
>> Which compatibility specifically?
>> Is there a definition we can refer to?
> Devicetree spec.
Let me fetch it for future reference:
https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.4
> The compatible property value consists of one or more strings that define the specific programming model for
> the device. This list of strings should be used by a client program for device driver selection. The property
> value consists of a concatenated list of null terminated strings, from most specific to most general. They allow
> a device to express its compatibility with a family of similar devices, potentially allowing a single device driver
> to match against several devices.
>
> The recommended format is "manufacturer,model", where manufacturer is a string describing the name
> of the manufacturer (such as a stock ticker symbol), and model specifies the model number.
>
> The compatible string should consist only of lowercase letters, digits and dashes, and should start with a letter.
> A single comma is typically only used following a vendor prefix. Underscores should not be used.
>
> Example:
> compatible = "fsl,mpc8641", "ns16550";
> In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641. If a
> driver was not found, it would then try to locate a driver that supported the more general ns16550 device type.

I think I understand this for individual components,
but with a SoM or complete product I get confused.

Can I understand a SoM or product as a composite device,
such as a usb to uart + i2c + gpio + spi adapter?

> Let me answer with a question, because you neither answer mine nor
> provide detailed information.
>
> Is Cortex-A15 compatible with Cortex-A7 in the Devicetree? No.
Curious! Actually I don't fully understand why that would be.
Based on the definition above, I would agree that
neither cortex-a7 nor cortex-a17 are specializations of each other.
They just happen to both support armv7-a instruction set.
> Now what
> does it mean to your case?
>
> I don't even understand what is your case.
I see :(
Yes there is a disconnect *somewhere*.

I shall try again:
Marvell is selling two chips:
1. CN9130, High-Performance Multi-Core CPU, System on Chip
(can be used alone)
2. 88F8215, SouthBridge Communication Processor, System on Chip
(only usable in combination with a CN9130)

Now, in terms of compatible string, what happens when a board
has multiples of these?

> What is 9131 and 9132?
I have no idea who came up with 9131 and 9132.
But explanation is given by Grzegorz Jaszczyk <jaz@semihalf.com>
when he submitted cn9131-db.dts (Marvell evaluation board):

Extend the support of the CN9130 by adding an external CP115.
The last number indicates how many external CP115 are used.

>
>
>> From software perspective we can always down-grade,
>> i.e. run software only aware of the AP on 9130, 9131 or 9132.
>> But we can't run software referencing the external CPs
>> if they are not connected.
> Same with Cortex A15 and A7, right?
Right.
>
>
>>>>>>           - const: marvell,armada-ap807-quad
>>>>>>           - const: marvell,armada-ap807
>>>>> Anyway, 6 compatibles is beyond useful amount. What are you expressing
>>>>> here?
>>>> I copied this part from the examples earlier in the file, such as:
>>>>       - description: Armada CN9132 SoC with two external CPs
>>>>         items:
>>>>           - const: marvell,cn9132
>>>>           - const: marvell,cn9131
>>>>           - const: marvell,cn9130
>>>>           - const: marvell,armada-ap807-quad
>>>>           - const: marvell,armada-ap807
>>>>>  Why is this even armada ap807?
>>>> We noticed ap807 != ap806 (cn913x != 8040),
>>>> because the thermal sensor coefficients converting
>>>> raw values to celsius differed.
>>> That's also not the best example.Might be correct but also looks
>>> over-complicated. The point of board-level compatibles is to identify
>>> machine and its common parts. It has little impact inside of kernel (at
>>> least should be almost no users inside!)
>> Indeed, the temperature coefficients are handled by the thermal device
>> compatible string, not board-level.
>>> , but there can be some users,
>>> e.g. firmware or user-space.
>>>
>>> This claims that cn9132 is compatible with ap807, so you have exactly
>>> the same base. The same base is not CPU! It's about the S in SoC, so
>>> "System".
>> I would think since the base is always a single chip combining 1x AP+CP,
>> the "system" is marvell,cn9130.
>> For Armada 8040, the system would be marvell,armada8040 by same
>> logic (also combining 1x AP+CP, different version, not extensible).
>>> Could firmware use marvell,armada-ap807 compatible to properly
>>> detect type of system and treat all these boards as ap807?
>> I have not looked into presence detection for CP's during initialization.
>> U-Boot support without spaghetti is a future Me task.
> ???
>
>> I suspect it is possible with asterisk *, because so far I have only seen
>> configuration with at least 1 CP, never with 0.
>> Presence of a boot-rom on each die e.g. supports this idea.
> I still don't understand.
>
> Best regards,
> Krzysztof
>
_______________________________________________
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 v6 3/4] firmware: arm_scmi: Add SCMI v3.2 pincontrol protocol basic support
From: Dan Carpenter @ 2024-03-27 10:46 UTC (permalink / raw)
  To: Peng Fan (OSS)
  Cc: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Linus Walleij, linux-arm-kernel, linux-kernel,
	devicetree, linux-gpio, Peng Fan, Oleksii Moisieiev
In-Reply-To: <20240323-pinctrl-scmi-v6-3-a895243257c0@nxp.com>

Looks really nice.  Just a few small comments below.

On Sat, Mar 23, 2024 at 08:15:16PM +0800, Peng Fan (OSS) wrote:
> +
> +struct scmi_msg_func_set {
> +	__le32 identifier;
> +	__le32 function_id;
> +	__le32 flags;
> +};

This scmi_msg_func_set struct is unused.  Delete.

> +static void
> +iter_pinctrl_settings_get_prepare_message(void *message, u32 desc_index,
> +					  const void *priv)
> +{
> +	struct scmi_msg_settings_get *msg = message;
> +	const struct scmi_settings_get_ipriv *p = priv;
> +	u32 attributes;
> +
> +	attributes = FIELD_PREP(CONFIG_FLAG_MASK, p->flag) |
> +		     FIELD_PREP(SELECTOR_MASK, p->type);
> +
> +	if (p->flag == 1)
> +		attributes |= FIELD_PREP(SKIP_CONFIGS_MASK, desc_index);
> +	else if (!p->flag)

This is a nit-pick but could you change these !p->flag conditions to
p->flag == 0?  It's a number zero, not a bool.

> +		attributes |= FIELD_PREP(CONFIG_TYPE_MASK, p->config_types[0]);
> +
> +	msg->attributes = cpu_to_le32(attributes);
> +	msg->identifier = cpu_to_le32(p->selector);
> +}
> +
> +static int
> +iter_pinctrl_settings_get_update_state(struct scmi_iterator_state *st,
> +				       const void *response, void *priv)
> +{
> +	const struct scmi_resp_settings_get *r = response;
> +	struct scmi_settings_get_ipriv *p = priv;
> +
> +	if (p->flag == 1) {
> +		st->num_returned = le32_get_bits(r->num_configs, GENMASK(7, 0));
> +		st->num_remaining = le32_get_bits(r->num_configs,
> +						  GENMASK(31, 24));
> +	} else {
> +		st->num_returned = 1;
> +		st->num_remaining = 0;
> +	}
> +
> +	return 0;
> +}
> +
> +static int
> +iter_pinctrl_settings_get_process_response(const struct scmi_protocol_handle *ph,
> +				       const void *response,
> +				       struct scmi_iterator_state *st,
> +				       void *priv)
> +{
> +	const struct scmi_resp_settings_get *r = response;
> +	struct scmi_settings_get_ipriv *p = priv;
> +
> +	if (!p->flag) {


if (p->flag == 0) {

> +		if (p->config_types[0] !=
> +		    le32_get_bits(r->configs[st->loop_idx * 2], GENMASK(7, 0)))
> +			return -EINVAL;
> +	} else if (p->flag == 1) {
> +		p->config_types[st->desc_index + st->loop_idx] =
> +			le32_get_bits(r->configs[st->loop_idx * 2],
> +				      GENMASK(7, 0));
> +	} else if (p->flag == 2) {
> +		return 0;
> +	}
> +
> +	p->config_values[st->desc_index + st->loop_idx] =
> +		le32_to_cpu(r->configs[st->loop_idx * 2 + 1]);
> +
> +	return 0;
> +}
> +
> +static int
> +scmi_pinctrl_settings_get(const struct scmi_protocol_handle *ph, u32 selector,
> +			  enum scmi_pinctrl_selector_type type,
> +			  enum scmi_pinctrl_conf_type config_type,
> +			  u32 *config_value)
> +{
> +	int ret;
> +	void *iter;
> +	struct scmi_iterator_ops ops = {
> +		.prepare_message = iter_pinctrl_settings_get_prepare_message,
> +		.update_state = iter_pinctrl_settings_get_update_state,
> +		.process_response = iter_pinctrl_settings_get_process_response,
> +	};
> +	struct scmi_settings_get_ipriv ipriv = {
> +		.selector = selector,
> +		.type = type,
> +		.flag = 0,

->flag should be 0-2.

> +		.config_types = &config_type,
> +		.config_values = config_value,
> +	};
> +
> +	if (!config_value || type == FUNCTION_TYPE)
             ^^^^^^^^^^^^
config_value should be optional for flag == 2.

regards,
dan carpenter

> +		return -EINVAL;
> +
> +	ret = scmi_pinctrl_validate_id(ph, selector, type);
> +	if (ret)
> +		return ret;
> +
> +	iter = ph->hops->iter_response_init(ph, &ops, 1, PINCTRL_SETTINGS_GET,
> +					    sizeof(struct scmi_msg_settings_get),
> +					    &ipriv);
> +
> +	if (IS_ERR(iter))
> +		return PTR_ERR(iter);
> +
> +	return ph->hops->iter_response_run(iter);
> +}
> +


_______________________________________________
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 RESEND v6 0/5] spmi: pmic-arb: Add support for multiple buses
From: Krzysztof Kozlowski @ 2024-03-27 10:44 UTC (permalink / raw)
  To: Abel Vesa
  Cc: Stephen Boyd, Matthias Brugger, Bjorn Andersson, Konrad Dybcio,
	Dmitry Baryshkov, Neil Armstrong, AngeloGioacchino Del Regno,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Srini Kandagatla,
	Johan Hovold, linux-kernel, linux-arm-kernel, linux-arm-msm,
	linux-mediatek, devicetree
In-Reply-To: <ZgP209t7IhdhcZIr@linaro.org>

On 27/03/2024 11:37, Abel Vesa wrote:
> On 24-03-27 10:23:51, Krzysztof Kozlowski wrote:
>> On 26/03/2024 17:28, Abel Vesa wrote:
>>> This RFC prepares for and adds support for 2 buses, which is supported
>>> in HW starting with version 7. Until now, none of the currently
>>> supported platforms in upstream have used the second bus. The X1E80100
>>> platform, on the other hand, needs the second bus for the USB2.0 to work
>>> as there are 3 SMB2360 PMICs which provide eUSB2 repeaters and they are
>>> all found on the second bus.
>>>
>>> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
>>> ---
>>> Changes in v6:
>>> - Changed the compatible to platform specific (X1E80100) along with the
>>>   schema. Fixed the spmi buses unit addresses and added the empty ranges
>>
>> Why resending after few days? And why without reviews?
>>
> 
> If you are referring to the initial v6 patchset, it was sent more than a
> month ago.
> 
> https://lore.kernel.org/all/20240222-spmi-multi-master-support-v6-0-bc34ea9561da@linaro.org/

Ykes, you are right.

Best regards,
Krzysztof


_______________________________________________
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] dt-bindings: power: Add mediatek larb definition
From: Krzysztof Kozlowski @ 2024-03-27 10:43 UTC (permalink / raw)
  To: Yu-chang Lee (李禹璋),
	MandyJH Liu (劉人僖), conor+dt@kernel.org,
	robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	matthias.bgg@gmail.com, ulf.hansson@linaro.org,
	angelogioacchino.delregno@collabora.com
  Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
	devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
	Project_Global_Chrome_Upstream_Group,
	Xiufeng Li (李秀峰),
	linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <b957b072d5d88ed315982e914a7f700e0ccafb83.camel@mediatek.com>

On 27/03/2024 11:39, Yu-chang Lee (李禹璋) wrote:
>>>>
>>> Hi,
>>>
>>> I will double check the format of yaml for the next version, sorry
>> for
>>> inconvenience. But I did test it on mt8188 chromebook, the reason
>> why
>>
>> How do you test a binding on chromebook?
>>
>>> power domain need larb node is that when mtcmos power on, signal
>> glitch
>>> may produce. Power domain driver must reset larb when this happen
>> to 
>>> prevent dummy transaction on bus. That why I need larb node in dts.
>>
>> No one talks here about larb node...
> 
> Sorry, May you elaborate on what information I need to provide to you
> or it is just a syntax problem I need to fix?

Please explain the purpose of this property (how is it going to be used
by drivers) and what does it represent.

Best regards,
Krzysztof


_______________________________________________
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 0/3] Speed up boot with faster linear map creation
From: Ryan Roberts @ 2024-03-27 10:43 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Catalin Marinas, Will Deacon, Mark Rutland, David Hildenbrand,
	Donald Dutile, Eric Chanudet, linux-arm-kernel, linux-kernel
In-Reply-To: <CAMj1kXEEi2ZXs+1qwR97zod5Z+TerPKcKZBN8LGZ5XTRV0_-rg@mail.gmail.com>

On 27/03/2024 10:09, Ard Biesheuvel wrote:
> Hi Ryan,
> 
> On Tue, 26 Mar 2024 at 12:15, Ryan Roberts <ryan.roberts@arm.com> wrote:
>>
>> Hi All,
>>
>> It turns out that creating the linear map can take a significant proportion of
>> the total boot time, especially when rodata=full. And a large portion of the
>> time it takes to create the linear map is issuing TLBIs. This series reworks the
>> kernel pgtable generation code to significantly reduce the number of TLBIs. See
>> each patch for details.
>>
>> The below shows the execution time of map_mem() across a couple of different
>> systems with different RAM configurations. We measure after applying each patch
>> and show the improvement relative to base (v6.9-rc1):
>>
>>                | Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra
>>                | VM, 16G     | VM, 64G     | VM, 256G    | Metal, 512G
>> ---------------|-------------|-------------|-------------|-------------
>>                |   ms    (%) |   ms    (%) |   ms    (%) |    ms    (%)
>> ---------------|-------------|-------------|-------------|-------------
>> base           |  151   (0%) | 2191   (0%) | 8990   (0%) | 17443   (0%)
>> no-cont-remap  |   77 (-49%) |  429 (-80%) | 1753 (-80%) |  3796 (-78%)
>> no-alloc-remap |   77 (-49%) |  375 (-83%) | 1532 (-83%) |  3366 (-81%)
>> lazy-unmap     |   63 (-58%) |  330 (-85%) | 1312 (-85%) |  2929 (-83%)
>>
>> This series applies on top of v6.9-rc1. All mm selftests pass. I haven't yet
>> tested all VA size configs (although I don't anticipate any issues); I'll do
>> this as part of followup.
>>
> 
> These are very nice results!
> 
> Before digging into the details: do we still have a strong case for
> supporting contiguous PTEs and PMDs in these routines?

We are currently using contptes and pmds for the linear map when rodata=[on|off]
IIRC? I don't see a need to remove the capability personally.

Also I was talking with Mark R yesterday and he suggested that an even better
solution might be to create a temp pgtable that maps the linear map with pmds,
switch to it, then create the real pgtable that maps the linear map with ptes,
then switch to that. The benefit being that we can avoid the fixmap entirely
when creating the second pgtable - we think this would likely be significantly
faster still.

My second patch adds the infrastructure to make this possible. But your changes
for LPA2 make it significantly more effort; since that change we are now using
the swapper pgtable when we populate the linear map into it - the kernel is
already mapped and that isn't done in paging_init() anymore. So I'm not quite
sure how we can easily make that work at the moment.

Thanks,
Ryan


_______________________________________________
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 RESEND v6 0/5] spmi: pmic-arb: Add support for multiple buses
From: Abel Vesa @ 2024-03-27 10:37 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Stephen Boyd, Matthias Brugger, Bjorn Andersson, Konrad Dybcio,
	Dmitry Baryshkov, Neil Armstrong, AngeloGioacchino Del Regno,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley, Srini Kandagatla,
	Johan Hovold, linux-kernel, linux-arm-kernel, linux-arm-msm,
	linux-mediatek, devicetree
In-Reply-To: <d213f262-ba0e-4cf8-af0e-66745ffea429@linaro.org>

On 24-03-27 10:23:51, Krzysztof Kozlowski wrote:
> On 26/03/2024 17:28, Abel Vesa wrote:
> > This RFC prepares for and adds support for 2 buses, which is supported
> > in HW starting with version 7. Until now, none of the currently
> > supported platforms in upstream have used the second bus. The X1E80100
> > platform, on the other hand, needs the second bus for the USB2.0 to work
> > as there are 3 SMB2360 PMICs which provide eUSB2 repeaters and they are
> > all found on the second bus.
> > 
> > Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
> > ---
> > Changes in v6:
> > - Changed the compatible to platform specific (X1E80100) along with the
> >   schema. Fixed the spmi buses unit addresses and added the empty ranges
> 
> Why resending after few days? And why without reviews?
> 

If you are referring to the initial v6 patchset, it was sent more than a
month ago.

https://lore.kernel.org/all/20240222-spmi-multi-master-support-v6-0-bc34ea9561da@linaro.org/

> Best regards,
> Krzysztof
> 

_______________________________________________
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 v3] staging: media: remove duplicate line
From: Sebastian Fricke @ 2024-03-27 10:34 UTC (permalink / raw)
  To: coolrrsh
  Cc: slongerbeam, p.zabel, mchehab, gregkh, shawnguo, s.hauer, kernel,
	festevam, linux-imx, linux-media, linux-staging, linux-arm-kernel,
	linux-kernel, linux-kernel-mentees
In-Reply-To: <20240327023340.3710-1-coolrrsh@gmail.com>

Hey Rajeshwar,

On 27.03.2024 08:03, coolrrsh@gmail.com wrote:
>From: Rajeshwar R Shinde <coolrrsh@gmail.com>
>
>The kernel configuration VIDEO_DEV is defined twice in Kconfig.
>Thus, the redundant code is removed.
>
>Signed-off-by: Rajeshwar R Shinde <coolrrsh@gmail.com>
>
>---
>v1->v2
>changed the commit message
>v2->v3
>changed the subject

The subject line isn't any better than before. Lets look at some
accepted examples together:

24d9cb143013 media: staging: imx: controls are from another device, mark this
67673ed55084 media: staging/imx: rearrange group id to take in account IPU
483fe862488f9 staging: media: imx: Merge VIDEO_IMX_CSI into VIDEO_IMX_MEDIA
9958d30f38b96 media: Kconfig: cleanup VIDEO_DEV dependencies

How did I find these? Simply by running git blame on one or more of the
files in the driver at drivers/staging/media/imx

As you can see there are slight variations on the first three but the
general theme is the same, the subject line describes to you that the
driver is found in staging/media and it tells you that the folder of the
driver is 'imx'. Generally, `staging: media: imx` would be preferred
however.
The 4th case shows you an example with a more general subject line and
it is justified in this case as the patch does changes on multiple files
on the whole subsystem (the media subsystem consists of all files found
in drivers/media, drivers/staging/media, Documentation/admin-guide/media
and a few header files).

Now if we take this into account for your subject line. You only change
a single driver, thus you need staging: media: imx:, and you to make
your subject a bit less ambigious you could call the whole thing:

staging: media: imx: Remove duplicate Kconfig dependency

I hope this helps.

Greetings,
Sebastian

>
>---
> drivers/staging/media/imx/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
>diff --git a/drivers/staging/media/imx/Kconfig b/drivers/staging/media/imx/Kconfig
>index 21fd79515042..772f49b1fe52 100644
>--- a/drivers/staging/media/imx/Kconfig
>+++ b/drivers/staging/media/imx/Kconfig
>@@ -4,7 +4,6 @@ config VIDEO_IMX_MEDIA
> 	depends on ARCH_MXC || COMPILE_TEST
> 	depends on HAS_DMA
> 	depends on VIDEO_DEV
>-	depends on VIDEO_DEV
> 	select MEDIA_CONTROLLER
> 	select V4L2_FWNODE
> 	select V4L2_MEM2MEM_DEV
>-- 
>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

* Re: [PATCH] arm64: dts: rockchip: quartzpro64: Enable the GPU
From: Heiko Stübner @ 2024-03-27 10:29 UTC (permalink / raw)
  To: linux-rockchip, Dragan Simic
  Cc: linux-arm-kernel, devicetree, robh+dt, krzysztof.kozlowski+dt,
	conor+dt, boris.brezillon, linux-kernel, kernel,
	sebastian.reichel
In-Reply-To: <0f3759ee390f245dac447bbee038445ddfecbec0.1711383286.git.dsimic@manjaro.org>

Hi,

Am Montag, 25. März 2024, 17:19:04 CET schrieb Dragan Simic:
> Following the approach used to enable the Mali GPU on the rk3588-evb1, [1]
> do the same for the Pine64 QuartzPro64, which uses nearly identical hardware
> design as the RK3588 EVB1.
> 
> The slight disadvantage is that the regulator coupling logic requires the
> regulators to be always on, which is also noted in the comments.  This is
> obviously something to be improved at some point in the future, but should
> be fine for now, especially because the QuartzPro64 isn't a battery-powered
> board, so low power consumption isn't paramount.
> 
> [1] https://lore.kernel.org/linux-rockchip/20240325153850.189128-5-sebastian.reichel@collabora.com/
> 
> Signed-off-by: Dragan Simic <dsimic@manjaro.org>

as lore.kernel.org and therefore b4 seems to be on vacation today, you
get a very personal "applied" message ;-) .

So, applied for 6.10 after the core rk3588-gpu-series from Sebastian.


Heiko



_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH 3/7] ARM: dts: microchip: sama5d2_icp: Update the node names from pmic-regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
  To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
	alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
	andrei.simion, devicetree, linux-arm-kernel, linux-kernel
  Cc: Mihai Sain
In-Reply-To: <20240327101724.2982-1-mihai.sain@microchip.com>

Update the node names from pmic-regulators in order to match
the datasheet and driver namings for buck regulators.
Using BUCK1-4 as node names is consistent with the node naming rules.

Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
---
 arch/arm/boot/dts/microchip/at91-sama5d2_icp.dts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/microchip/at91-sama5d2_icp.dts b/arch/arm/boot/dts/microchip/at91-sama5d2_icp.dts
index 999adeca6f33..f20de8180381 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d2_icp.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama5d2_icp.dts
@@ -194,7 +194,7 @@ mcp16502@5b {
 			lpm-gpios = <&pioBU 7 GPIO_ACTIVE_LOW>;
 
 			regulators {
-				vdd_io_reg: VDD_IO {
+				vdd_io_reg: BUCK1 {
 					regulator-name = "VDD_IO";
 					regulator-min-microvolt = <3300000>;
 					regulator-max-microvolt = <3300000>;
@@ -213,7 +213,7 @@ regulator-state-mem {
 					};
 				};
 
-				VDD_DDR {
+				BUCK2 {
 					regulator-name = "VDD_DDR";
 					regulator-min-microvolt = <1350000>;
 					regulator-max-microvolt = <1350000>;
@@ -232,7 +232,7 @@ regulator-state-mem {
 					};
 				};
 
-				VDD_CORE {
+				BUCK3 {
 					regulator-name = "VDD_CORE";
 					regulator-min-microvolt = <1250000>;
 					regulator-max-microvolt = <1250000>;
@@ -251,7 +251,7 @@ regulator-state-mem {
 					};
 				};
 
-				VDD_OTHER {
+				BUCK4 {
 					regulator-name = "VDD_OTHER";
 					regulator-min-microvolt = <600000>;
 					regulator-max-microvolt = <1850000>;
-- 
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 related

* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards
From: Krzysztof Kozlowski @ 2024-03-27 10:19 UTC (permalink / raw)
  To: Josua Mayer, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
	Rob Herring, Krzysztof Kozlowski, Conor Dooley
  Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <6af08a38-5239-4f5f-9e87-108e3400a6e6@solid-run.com>

On 26/03/2024 20:26, Josua Mayer wrote:
> Am 26.03.24 um 07:41 schrieb Krzysztof Kozlowski:
>> On 25/03/2024 21:12, Josua Mayer wrote:
>>> Am 25.03.24 um 20:34 schrieb Krzysztof Kozlowski:
>>>> On 22/03/2024 11:08, Josua Mayer wrote:
>>>>> Am 21.03.24 um 22:47 schrieb Josua Mayer:
>>>>>> Add bindings for SolidRun Clearfog boards, using a new SoM based on
>>>>>> CN9130 SoC.
>>>>>> The carrier boards are identical to the older Armada 388 based Clearfog
>>>>>> boards. For consistency the carrier part of compatible strings are
>>>>>> copied, including the established "-a1" suffix.
>>>>>>
>>>>>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>>>>>> ---
>>>>>>  .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml        | 12 ++++++++++++
>>>>>>  1 file changed, 12 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>>>>> index 16d2e132d3d1..36bdfd1bedd9 100644
>>>>>> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
>>>>>> @@ -82,4 +82,16 @@ properties:
>>>>>>            - const: marvell,armada-ap807-quad
>>>>>>            - const: marvell,armada-ap807
>>>>>>  
>>>>>> +      - description:
>>>>>> +          SolidRun CN9130 clearfog family single-board computers
>>>>>> +        items:
>>>>>> +          - enum:
>>>>>> +              - solidrun,clearfog-base-a1
>>>>>> +              - solidrun,clearfog-pro-a1
>>>>>> +          - const: solidrun,clearfog-a1
>>>>>> +          - const: solidrun,cn9130-sr-som
>>>>>> +          - const: marvell,cn9130
>>>>>> +          - const: marvell,armada-ap807-quad
>>>>>> +          - const: marvell,armada-ap807
>>>>>> +
>>>>>>  additionalProperties: true
>>>>> Before merging I would like some feedback about adding
>>>>> another product later, to ensure the compatibles above
>>>>> are adequate? In particular:
>>>>> - sequence of soc, cp, carrier compatibles
>>>>> - name of som compatible
>>>>>
>>>>> Draft for future bindings:
>>>>>       - description:
>>>>>           SolidRun CN9130 SoM based single-board computers
>>>>>           with 1 external CP on the Carrier.
>>>>>         items:
>>>>>           - enum:
>>>>>               - solidrun,cn9131-solidwan
>>>>>           - const: marvell,cn9131
>>>>>           - const: solidrun,cn9130-sr-som
>>>> This does not look correct. cn9131 is not compatible with your som.
>>> This is partially my question.
>>> I considered changing the som to "cn913x-sr-som".
>>>
>>> The SoM itself is always 9130, it contains the base SoC
>>> with 1x AP and 1x CP in a single chip.
>>> 9131 and 9132 <happen> on the carrier boards.
>> No wildcards, but if the SoM name is 9130 then use 9130.
>> The problem is that you use cn9130 SoC as fallback.
>>
>>>>>           - const: marvell,cn9130
>>>> SoCs are compatible only in some cases, e.g. one is a subset of another
>>>> like stripped out of modem. Are you sure this is your case?
>>> This is more complex, CN9131 and CN9132 are not single SoCs.
>>> A "9132" is instantiated by connecting two southbridge chips
>>> via a Marvell defined bus, each providing additional IO
>>> such as network, i2c, gpio.
>>>
>>> Note that even the first, "9130", while a single chip, contains two dies:
>>> An "AP" (Application Processor I assume) with very limited IO (1xsdio, 1xi2c),
>>> and a "CP" (Communication Processor I assume) with lots of IO.
>>> This CP as far as I know today is identical to the southbridges
>>> mentioned above.
>> OK, but how does it affect compatibility between them? Which parts are
>> the same? Or how much is shared?
> 9130, 9131, 9132 belong together.

I don't understand what it means.

> 9130 is single chip including two dies: AP, CP.
> The CP is available as an individual chip,
> up to two can be connected to one 9130.

And? How does it help me to decide? What is 9131 and 9132?

> 
> What does this mean for compatibility?
> Which compatibility specifically?
> Is there a definition we can refer to?

Devicetree spec.

Let me answer with a question, because you neither answer mine nor
provide detailed information.

Is Cortex-A15 compatible with Cortex-A7 in the Devicetree? No. Now what
does it mean to your case?

I don't even understand what is your case.

> 
> From software perspective we can always down-grade,
> i.e. run software only aware of the AP on 9130, 9131 or 9132.
> But we can't run software referencing the external CPs
> if they are not connected.

Same with Cortex A15 and A7, right?


> 
>>>>>           - const: marvell,armada-ap807-quad
>>>>>           - const: marvell,armada-ap807
>>>> Anyway, 6 compatibles is beyond useful amount. What are you expressing
>>>> here?
>>> I copied this part from the examples earlier in the file, such as:
>>>       - description: Armada CN9132 SoC with two external CPs
>>>         items:
>>>           - const: marvell,cn9132
>>>           - const: marvell,cn9131
>>>           - const: marvell,cn9130
>>>           - const: marvell,armada-ap807-quad
>>>           - const: marvell,armada-ap807
>>>>  Why is this even armada ap807?
>>> We noticed ap807 != ap806 (cn913x != 8040),
>>> because the thermal sensor coefficients converting
>>> raw values to celsius differed.
>> That's also not the best example.Might be correct but also looks
>> over-complicated. The point of board-level compatibles is to identify
>> machine and its common parts. It has little impact inside of kernel (at
>> least should be almost no users inside!)
> Indeed, the temperature coefficients are handled by the thermal device
> compatible string, not board-level.
>> , but there can be some users,
>> e.g. firmware or user-space.
>>
>> This claims that cn9132 is compatible with ap807, so you have exactly
>> the same base. The same base is not CPU! It's about the S in SoC, so
>> "System".
> I would think since the base is always a single chip combining 1x AP+CP,
> the "system" is marvell,cn9130.
> For Armada 8040, the system would be marvell,armada8040 by same
> logic (also combining 1x AP+CP, different version, not extensible).
>> Could firmware use marvell,armada-ap807 compatible to properly
>> detect type of system and treat all these boards as ap807?
> I have not looked into presence detection for CP's during initialization.
> U-Boot support without spaghetti is a future Me task.

???

> I suspect it is possible with asterisk *, because so far I have only seen
> configuration with at least 1 CP, never with 0.
> Presence of a boot-rom on each die e.g. supports this idea.

I still don't understand.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH 6/7] regulator: dt-bindings: microchip,mcp16502: Update the node names from buck regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
  To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
	alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
	andrei.simion, devicetree, linux-arm-kernel, linux-kernel
  Cc: Mihai Sain
In-Reply-To: <20240327101724.2982-1-mihai.sain@microchip.com>

Update the node names from buck regulators in order to match
the datasheet and driver namings for buck regulators.
Using BUCK1-4 as node names is consistent with the node naming rules.

Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
---
 .../bindings/regulator/microchip,mcp16502.yaml         | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml b/Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml
index 1aca3646789e..72a1f8a92949 100644
--- a/Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml
+++ b/Documentation/devicetree/bindings/regulator/microchip,mcp16502.yaml
@@ -34,7 +34,7 @@ properties:
     description: List of regulators and its properties.
 
     patternProperties:
-      "^(VDD_(IO|CORE|DDR|OTHER)|LDO[1-2])$":
+      "^(BUCK[1-4]|LDO[1-2])$":
         type: object
         $ref: regulator.yaml#
         unevaluatedProperties: false
@@ -70,7 +70,7 @@ examples:
             reg = <0x5b>;
 
             regulators {
-                VDD_IO {
+                BUCK1 {
                     regulator-name = "VDD_IO";
                     regulator-min-microvolt = <3300000>;
                     regulator-max-microvolt = <3300000>;
@@ -89,7 +89,7 @@ examples:
                     };
                 };
 
-                VDD_DDR {
+                BUCK2 {
                     regulator-name = "VDD_DDR";
                     regulator-min-microvolt = <1350000>;
                     regulator-max-microvolt = <1350000>;
@@ -108,7 +108,7 @@ examples:
                     };
                 };
 
-                VDD_CORE {
+                BUCK3 {
                     regulator-name = "VDD_CORE";
                     regulator-min-microvolt = <1150000>;
                     regulator-max-microvolt = <1150000>;
@@ -127,7 +127,7 @@ examples:
                     };
                 };
 
-                VDD_OTHER {
+                BUCK4 {
                     regulator-name = "VDD_OTHER";
                     regulator-min-microvolt = <1050000>;
                     regulator-max-microvolt = <1250000>;
-- 
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 related

* [PATCH 7/7] regulator: mcp16502: Update the names from buck regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
  To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
	alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
	andrei.simion, devicetree, linux-arm-kernel, linux-kernel
  Cc: Mihai Sain
In-Reply-To: <20240327101724.2982-1-mihai.sain@microchip.com>

Use generic names for buck regulators to avoid any confusion.
Update the names from buck regulators in order to match
the datasheet block diagram for the buck regulators.

Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
---
 drivers/regulator/mcp16502.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/regulator/mcp16502.c b/drivers/regulator/mcp16502.c
index 0c15a19fe83a..d6fc9f1afaef 100644
--- a/drivers/regulator/mcp16502.c
+++ b/drivers/regulator/mcp16502.c
@@ -468,13 +468,13 @@ static const struct linear_range b234_ranges[] = {
 
 static const struct regulator_desc mcp16502_desc[] = {
 	/* MCP16502_REGULATOR(_name, _id, ranges, regulator_ops, ramp_table) */
-	MCP16502_REGULATOR("VDD_IO", BUCK1, b1l12_ranges, mcp16502_buck_ops,
+	MCP16502_REGULATOR("BUCK1", BUCK1, b1l12_ranges, mcp16502_buck_ops,
 			   mcp16502_ramp_b1l12),
-	MCP16502_REGULATOR("VDD_DDR", BUCK2, b234_ranges, mcp16502_buck_ops,
+	MCP16502_REGULATOR("BUCK2", BUCK2, b234_ranges, mcp16502_buck_ops,
 			   mcp16502_ramp_b234),
-	MCP16502_REGULATOR("VDD_CORE", BUCK3, b234_ranges, mcp16502_buck_ops,
+	MCP16502_REGULATOR("BUCK3", BUCK3, b234_ranges, mcp16502_buck_ops,
 			   mcp16502_ramp_b234),
-	MCP16502_REGULATOR("VDD_OTHER", BUCK4, b234_ranges, mcp16502_buck_ops,
+	MCP16502_REGULATOR("BUCK4", BUCK4, b234_ranges, mcp16502_buck_ops,
 			   mcp16502_ramp_b234),
 	MCP16502_REGULATOR("LDO1", LDO1, b1l12_ranges, mcp16502_ldo_ops,
 			   mcp16502_ramp_b1l12),
-- 
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 related

* [PATCH 5/7] ARM: dts: microchip: sama7g5ek: Update the node names from pmic-regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
  To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
	alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
	andrei.simion, devicetree, linux-arm-kernel, linux-kernel
  Cc: Mihai Sain
In-Reply-To: <20240327101724.2982-1-mihai.sain@microchip.com>

Update the node names from pmic-regulators in order to match
the datasheet and driver namings for buck regulators.
Using BUCK1-4 as node names is consistent with the node naming rules.

Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
---
 arch/arm/boot/dts/microchip/at91-sama7g5ek.dts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/microchip/at91-sama7g5ek.dts b/arch/arm/boot/dts/microchip/at91-sama7g5ek.dts
index 217e9b96c61e..5a9b8b6dd0df 100644
--- a/arch/arm/boot/dts/microchip/at91-sama7g5ek.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama7g5ek.dts
@@ -242,7 +242,7 @@ mcp16502@5b {
 			status = "okay";
 
 			regulators {
-				vdd_3v3: VDD_IO {
+				vdd_3v3: BUCK1 {
 					regulator-name = "VDD_IO";
 					regulator-min-microvolt = <3300000>;
 					regulator-max-microvolt = <3300000>;
@@ -262,7 +262,7 @@ regulator-state-mem {
 					};
 				};
 
-				vddioddr: VDD_DDR {
+				vddioddr: BUCK2 {
 					regulator-name = "VDD_DDR";
 					regulator-min-microvolt = <1350000>;
 					regulator-max-microvolt = <1350000>;
@@ -283,7 +283,7 @@ regulator-state-mem {
 					};
 				};
 
-				vddcore: VDD_CORE {
+				vddcore: BUCK3 {
 					regulator-name = "VDD_CORE";
 					regulator-min-microvolt = <1150000>;
 					regulator-max-microvolt = <1150000>;
@@ -303,7 +303,7 @@ regulator-state-mem {
 					};
 				};
 
-				vddcpu: VDD_OTHER {
+				vddcpu: BUCK4 {
 					regulator-name = "VDD_OTHER";
 					regulator-min-microvolt = <1050000>;
 					regulator-max-microvolt = <1250000>;
-- 
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 related

* [PATCH 2/7] ARM: dts: microchip: sama5d29_curiosity: Update the node names from pmic-regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
  To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
	alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
	andrei.simion, devicetree, linux-arm-kernel, linux-kernel
  Cc: Mihai Sain
In-Reply-To: <20240327101724.2982-1-mihai.sain@microchip.com>

Update the node names from pmic-regulators in order to match
the datasheet and driver namings for buck regulators.
Using BUCK1-4 as node names is consistent with the node naming rules.

Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
---
 arch/arm/boot/dts/microchip/at91-sama5d29_curiosity.dts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/microchip/at91-sama5d29_curiosity.dts b/arch/arm/boot/dts/microchip/at91-sama5d29_curiosity.dts
index 6b02b7bcfd49..b1874ae8dfc2 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d29_curiosity.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama5d29_curiosity.dts
@@ -148,7 +148,7 @@ mcp16502@5b {
 		lpm-gpios = <&pioBU 0 GPIO_ACTIVE_LOW>;
 
 		regulators {
-			vdd_3v3: VDD_IO {
+			vdd_3v3: BUCK1 {
 				regulator-name = "VDD_IO";
 				regulator-min-microvolt = <3300000>;
 				regulator-max-microvolt = <3300000>;
@@ -167,7 +167,7 @@ regulator-state-mem {
 				};
 			};
 
-			vddio_ddr: VDD_DDR {
+			vddio_ddr: BUCK2 {
 				regulator-name = "VDD_DDR";
 				regulator-min-microvolt = <1200000>;
 				regulator-max-microvolt = <1200000>;
@@ -190,7 +190,7 @@ regulator-state-mem {
 				};
 			};
 
-			vdd_core: VDD_CORE {
+			vdd_core: BUCK3 {
 				regulator-name = "VDD_CORE";
 				regulator-min-microvolt = <1250000>;
 				regulator-max-microvolt = <1250000>;
@@ -209,7 +209,7 @@ regulator-state-mem {
 				};
 			};
 
-			vdd_ddr: VDD_OTHER {
+			vdd_ddr: BUCK4 {
 				regulator-name = "VDD_OTHER";
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <1800000>;
-- 
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 related

* [PATCH 4/7] ARM: dts: microchip: sama7g54_curiosity: Update the node names from pmic-regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
  To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
	alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
	andrei.simion, devicetree, linux-arm-kernel, linux-kernel
  Cc: Mihai Sain
In-Reply-To: <20240327101724.2982-1-mihai.sain@microchip.com>

Update the node names from pmic-regulators in order to match
the datasheet and driver namings for buck regulators.
Using BUCK1-4 as node names is consistent with the node naming rules.

Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
---
 arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts b/arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts
index 4f609e9e510e..a83a6fd3f5fa 100644
--- a/arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts
+++ b/arch/arm/boot/dts/microchip/at91-sama7g54_curiosity.dts
@@ -191,7 +191,7 @@ pmic@5b {
 			reg = <0x5b>;
 
 			regulators {
-				vdd_3v3: VDD_IO {
+				vdd_3v3: BUCK1 {
 					regulator-name = "VDD_IO";
 					regulator-min-microvolt = <3300000>;
 					regulator-max-microvolt = <3300000>;
@@ -211,7 +211,7 @@ regulator-state-mem {
 					};
 				};
 
-				vddioddr: VDD_DDR {
+				vddioddr: BUCK2 {
 					regulator-name = "VDD_DDR";
 					regulator-min-microvolt = <1350000>;
 					regulator-max-microvolt = <1350000>;
@@ -232,7 +232,7 @@ regulator-state-mem {
 					};
 				};
 
-				vddcore: VDD_CORE {
+				vddcore: BUCK3 {
 					regulator-name = "VDD_CORE";
 					regulator-min-microvolt = <1150000>;
 					regulator-max-microvolt = <1150000>;
@@ -252,7 +252,7 @@ regulator-state-mem {
 					};
 				};
 
-				vddcpu: VDD_OTHER {
+				vddcpu: BUCK4 {
 					regulator-name = "VDD_OTHER";
 					regulator-min-microvolt = <1050000>;
 					regulator-max-microvolt = <1250000>;
-- 
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 related

* [PATCH 1/7] ARM: dts: microchip: sama5d27_wlsom1: Update the node names from pmic-regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
  To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
	alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
	andrei.simion, devicetree, linux-arm-kernel, linux-kernel
  Cc: Mihai Sain
In-Reply-To: <20240327101724.2982-1-mihai.sain@microchip.com>

Update the node names from pmic-regulators in order to match
the datasheet and driver namings for buck regulators.
Using BUCK1-4 as node names is consistent with the node naming rules.

Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
---
 arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
index 4617805c7748..228382f630cc 100644
--- a/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
+++ b/arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi
@@ -74,7 +74,7 @@ mcp16502@5b {
 		lpm-gpios = <&pioBU 0 GPIO_ACTIVE_LOW>;
 
 		regulators {
-			vdd_3v3: VDD_IO {
+			vdd_3v3: BUCK1 {
 				regulator-name = "VDD_IO";
 				regulator-min-microvolt = <3300000>;
 				regulator-max-microvolt = <3300000>;
@@ -93,7 +93,7 @@ regulator-state-mem {
 				};
 			};
 
-			vddio_ddr: VDD_DDR {
+			vddio_ddr: BUCK2 {
 				regulator-name = "VDD_DDR";
 				regulator-min-microvolt = <1200000>;
 				regulator-max-microvolt = <1200000>;
@@ -116,7 +116,7 @@ regulator-state-mem {
 				};
 			};
 
-			vdd_core: VDD_CORE {
+			vdd_core: BUCK3 {
 				regulator-name = "VDD_CORE";
 				regulator-min-microvolt = <1250000>;
 				regulator-max-microvolt = <1250000>;
@@ -135,7 +135,7 @@ regulator-state-mem {
 				};
 			};
 
-			vdd_ddr: VDD_OTHER {
+			vdd_ddr: BUCK4 {
 				regulator-name = "VDD_OTHER";
 				regulator-min-microvolt = <1800000>;
 				regulator-max-microvolt = <1800000>;
-- 
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 related

* [PATCH 0/7] regulator: mcp16502: Update the names from buck regulators
From: Mihai Sain @ 2024-03-27 10:17 UTC (permalink / raw)
  To: robh, krzysztof.kozlowski+dt, conor+dt, nicolas.ferre,
	alexandre.belloni, claudiu.beznea, lgirdwood, broonie,
	andrei.simion, devicetree, linux-arm-kernel, linux-kernel
  Cc: Mihai Sain

Use generic names for buck regulators to avoid any confusion.
Update the names from buck regulators in order to match
the datasheet block diagram for the buck regulators.
Using BUCK1-4 as node names is consistent with the node naming rules.

Link: https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MCP16502-Data-Sheet-DS20006275.pdf

Mihai Sain (7):
  ARM: dts: microchip: sama5d27_wlsom1: Update the node names from pmic-regulators
  ARM: dts: microchip: sama5d29_curiosity: Update the node names from pmic-regulators
  ARM: dts: microchip: sama5d2_icp: Update the node names from pmic-regulators
  ARM: dts: microchip: sama7g54_curiosity: Update the node names from pmic-regulators
  ARM: dts: microchip: sama7g5ek: Update the node names from pmic-regulators
  regulator: dt-bindings: microchip,mcp16502: Update the node names from buck regulators
  regulator: mcp16502: Update the names from buck regulators

 .../bindings/regulator/microchip,mcp16502.yaml         | 10 +++++-----
 arch/arm/boot/dts/microchip/at91-sama5d27_wlsom1.dtsi  |  8 ++++----
 .../arm/boot/dts/microchip/at91-sama5d29_curiosity.dts |  8 ++++----
 arch/arm/boot/dts/microchip/at91-sama5d2_icp.dts       |  8 ++++----
 .../arm/boot/dts/microchip/at91-sama7g54_curiosity.dts |  8 ++++----
 arch/arm/boot/dts/microchip/at91-sama7g5ek.dts         |  8 ++++----
 drivers/regulator/mcp16502.c                           |  8 ++++----
 7 files changed, 29 insertions(+), 29 deletions(-)

-- 
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 net v2 1/2] net: dsa: mt7530: fix enabling EEE on MT7531 switch on all boards
From: SkyLake Huang (黃啟澤) @ 2024-03-27  9:51 UTC (permalink / raw)
  To: olteanv@gmail.com, andrew@lunn.ch, arinc.unal@arinc9.com,
	linux@armlinux.org.uk, f.fainelli@gmail.com,
	opensource@vdorst.com, Sean Wang, kuba@kernel.org,
	edumazet@google.com, pabeni@redhat.com, dqfext@gmail.com,
	matthias.bgg@gmail.com, davem@davemloft.net,
	daniel@makrotopia.org, hkallweit1@gmail.com,
	angelogioacchino.delregno@collabora.com
  Cc: bartel.eerdekens@constell8.be, linux-kernel@vger.kernel.org,
	linux-mediatek@lists.infradead.org, florian.fainelli@broadcom.com,
	linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org,
	mithat.guner@xeront.com, erkin.bozoglu@xeront.com
In-Reply-To: <20240321-for-net-mt7530-fix-eee-for-mt7531-mt7988-v2-1-9af9d5041bfe@arinc9.com>

On Thu, 2024-03-21 at 19:29 +0300, Arınç ÜNAL via B4 Relay wrote:
>  	 
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  From: Arınç ÜNAL <arinc.unal@arinc9.com>
> 
> The commit 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE
> features")
> brought EEE support but did not enable EEE on MT7531 switch MACs. EEE
> is
> enabled on MT7531 switch MACs either by pulling the LAN2LED0 pin low
> on the
> board (bootstrapping), or unsetting the EEE_DIS bit on the trap
> register.
> 
> There are existing boards that were not designed to pull the pin low.
> Therefore, unset the EEE_DIS bit on the trap register.
> 
> Unlike MT7530, the modifiable trap register won't be populated
> identical to
> the trap status register after reset. Therefore, read from the trap
> status
> register, modify the bits, then write to the modifiable trap
> register.
> 
> My testing on MT7531 shows a certain amount of traffic loss when EEE
> is
> enabled. That said, I haven't come across a board that enables EEE.
> So
> enable EEE on the switch MACs but disable EEE advertisement on the
> switch
> PHYs. This way, we don't change the behaviour of the majority of the
> boards
> that have this switch.
> 
> With this change, EEE can now be enabled using ethtool.
> 
> The disable EEE bit on the trap pertains to the LAN2LED0 pin which is
> usually used to control an LED. Once the bit is unset, the pin will
> be low.
> That will make the active low LED turn on.
> 
> The pin is controlled by the switch PHY. It seems that the PHY
> controls the
> pin in the way that it inverts the pin state. That means depending on
> the
> wiring of the LED connected to LAN2LED0 on the board, the LED may be
> on
> without an active link.
> 
> Fixes: 40b5d2f15c09 ("net: dsa: mt7530: Add support for EEE
> features")
> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
> Signed-off-by: Arınç ÜNAL <arinc.unal@arinc9.com>
> ---
>  drivers/net/dsa/mt7530.c | 14 ++++++++++++++
>  drivers/net/dsa/mt7530.h |  1 +
>  2 files changed, 15 insertions(+)
> 
> diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
> index 678b51f9cea6..6aa99b590329 100644
> --- a/drivers/net/dsa/mt7530.c
> +++ b/drivers/net/dsa/mt7530.c
> @@ -2458,6 +2458,20 @@ mt7531_setup(struct dsa_switch *ds)
>  /* Reset the switch through internal reset */
>  mt7530_write(priv, MT7530_SYS_CTRL, SYS_CTRL_SW_RST |
> SYS_CTRL_REG_RST);
>  
> +/* Allow modifying the trap and enable Energy-Efficient Ethernet
> (EEE).
> + */
> +val = mt7530_read(priv, MT7531_HWTRAP);
> +val |= CHG_STRAP;
> +val &= ~EEE_DIS;
> +mt7530_write(priv, MT7530_MHWTRAP, val);
You may try to set bit 6 of CL45 register dev=0x1f,
reg=0x403(PLL_GROUP_CTL_REG), which is an internal EEE switch called
RG_SYSPLL_DMY2.

Read it out first with "switch command", if you have it:
root@OpenWrt:/# switch phy cl45 r 0 0x1f 0x403
  Phy read dev_num=0x1f, reg=0x403, value=0x1091

And then set bit 6:
root@OpenWrt:/# $ switch phy cl45 w 0 0x1f 0x403 0x10d1
root@OpenWrt:/# ethtool --set-eee lan1 eee on tx-lpi on tx-timer 0x1e
advertise 0x28
root@OpenWrt:/# switch phy cl45 r 0 0x7 0x3c
 Phy read dev_num=0x7, reg=0x3c, value=0x6

Then you should be able to enable EEE via ethtool without clearing
EEE_DIS bit of MT7530_HWTRAP.
If above CL45 command is good for you, I think this can be moved to
mtk_gephy_config_init() @ mediatek-ge.c, which will lead to cleaner
implementation.
> +
> +/* Disable EEE advertisement on the switch PHYs. */
> +for (i = MT753X_CTRL_PHY_ADDR;
> +     i < MT753X_CTRL_PHY_ADDR + MT7530_NUM_PHYS; i++) {
> +mt7531_ind_c45_phy_write(priv, i, MDIO_MMD_AN, MDIO_AN_EEE_ADV,
> + 0);
> +}
Sorry, I still can't figure out why this is needed since we disable
MDIO_AN_EEE_ADV in mediatek-ge.c after reading previous threads. Would
you please provide something else (like dmesg log?) to show that
settings in mtk_gephy_config_init() may fail?
> +
>  if (!priv->p5_sgmii) {
>  mt7531_pll_setup(priv);
>  } else {
> diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
> index a71166e0a7fc..509ed5362236 100644
> --- a/drivers/net/dsa/mt7530.h
> +++ b/drivers/net/dsa/mt7530.h
> @@ -457,6 +457,7 @@ enum mt7531_clk_skew {
>  #define  XTAL_FSEL_MBIT(7)
>  #define  PHY_ENBIT(6)
>  #define  CHG_STRAPBIT(8)
> +#define  EEE_DISBIT(4)
>  
>  /* Register for hw trap modification */
>  #define MT7530_MHWTRAP0x7804
> 
> -- 
> 2.40.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 v2 2/3] dt-bindings: power: Add mediatek larb definition
From: Krzysztof Kozlowski @ 2024-03-27 10:10 UTC (permalink / raw)
  To: Yu-chang Lee (李禹璋),
	MandyJH Liu (劉人僖), conor+dt@kernel.org,
	robh@kernel.org, krzysztof.kozlowski+dt@linaro.org,
	matthias.bgg@gmail.com, ulf.hansson@linaro.org,
	angelogioacchino.delregno@collabora.com
  Cc: linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
	devicetree@vger.kernel.org, linux-pm@vger.kernel.org,
	Project_Global_Chrome_Upstream_Group,
	Xiufeng Li (李秀峰),
	linux-arm-kernel@lists.infradead.org, Fan Chen (陳凡)
In-Reply-To: <f25b4d913a584d753888e7a3c32502eae1f7fbf0.camel@mediatek.com>

On 27/03/2024 11:01, Yu-chang Lee (李禹璋) wrote:
> On Wed, 2024-03-27 at 09:39 +0100, Krzysztof Kozlowski wrote:
>>  	 
>> External email : Please do not click links or open attachments until
>> you have verified the sender or the content.
>>  On 27/03/2024 06:57, yu-chang.lee wrote:
>>> Add Smart Multimedia Interface Local Arbiter to mediatek
>>> power domain.
>>>
>>> Signed-off-by: yu-chang.lee <yu-chang.lee@mediatek.com>
>>> ---
>>>  .../devicetree/bindings/power/mediatek,power-controller.yaml  | 4
>> ++++
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git
>> a/Documentation/devicetree/bindings/power/mediatek,power-
>> controller.yaml
>> b/Documentation/devicetree/bindings/power/mediatek,power-
>> controller.yaml
>>> index 8985e2df8a56..228c0dec5253 100644
>>> --- a/Documentation/devicetree/bindings/power/mediatek,power-
>> controller.yaml
>>> +++ b/Documentation/devicetree/bindings/power/mediatek,power-
>> controller.yaml
>>> @@ -125,6 +125,10 @@ $defs:
>>>          $ref: /schemas/types.yaml#/definitions/phandle
>>>          description: phandle to the device containing the SMI
>> register range.
>>>  
>>> +     mediatek,larb:
>>> +        $ref: /schemas/types.yaml#/definitions/phandle
>>> +        description: phandle to the device containing the LARB
>> register range.
>>
>> Why do you need it?
>>
>> Plus I also see mediatek,larbs and mediatek,larb-id... so now we have
>> third one similar.
>>
> MM driver used "mediatek,larbs" for it larb node.
> Power domain driver used "mediatek,larb".
> "mediatek,larb-id" is for larb in dts.
> 
> The naming is no related to each other.

Then it is just confusing.

Best regards,
Krzysztof


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox