* Re: [PATCH] leds: mt6360: Fix the second LED can not enable torch mode by V4L2
From: AngeloGioacchino Del Regno @ 2024-04-09 11:45 UTC (permalink / raw)
To: ChiaEn Wu, pavel, lee, matthias.bgg
Cc: linux-kernel, linux-leds, linux-arm-kernel, linux-mediatek,
peterwu.pub, cy_huang
In-Reply-To: <d1d1419bb322e2b0f40d34edd3a66979015b668c.1712657386.git.chiaen_wu@richtek.com>
Il 09/04/24 12:21, ChiaEn Wu ha scritto:
> V4L2 will disable strobe mode of the LED device when enable torch mode,
> but this logic will conflict with the "priv->fled_torch_used"
> in "mt6360_strobe_set()". So after enabling torch mode of the first
> LED, the second LED will not be able to enable torch mode correctly.
>
> Therefore, at the beginning of "mt6360_strobe_set()", check whether the
> state of the upcoming change and the current LED device state are the
> same, so as to avoid the above problem.
>
> Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com>
> ---
> drivers/leds/flash/leds-mt6360.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/leds/flash/leds-mt6360.c b/drivers/leds/flash/leds-mt6360.c
> index a90de82f4568..1b75b4d36834 100644
> --- a/drivers/leds/flash/leds-mt6360.c
> +++ b/drivers/leds/flash/leds-mt6360.c
> @@ -241,10 +241,20 @@ static int mt6360_strobe_set(struct led_classdev_flash *fl_cdev, bool state)
> u32 enable_mask = MT6360_STROBEN_MASK | MT6360_FLCSEN_MASK(led->led_no);
> u32 val = state ? MT6360_FLCSEN_MASK(led->led_no) : 0;
> u32 prev = priv->fled_strobe_used, curr;
> - int ret;
> + int ret = 0;
I prefer that you leave ret uninitialized here, and...
>
> mutex_lock(&priv->lock);
>
> + /*
> + * If the state of the upcoming change is the same as the current LED
> + * device state, then skip the subsequent code to avoid conflict
> + * with the flow of turning on LED torch mode in V4L2.
> + */
> + if (state == !!(BIT(led->led_no) & prev)) {
> + dev_info(lcdev->dev, "No change in strobe state [0x%x]\n", prev);
...that you do here, instead
ret = 0;
goto unlock;
With that addressed,
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collaobra.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 v2] iommu/arm-smmu-v3: Free MSIs in case of ENOMEM
From: Robin Murphy @ 2024-04-09 11:46 UTC (permalink / raw)
To: Mostafa Saleh
Cc: Aleksandr Aprelkov, Will Deacon, Joerg Roedel, Jason Gunthorpe,
Nicolin Chen, Michael Shavit, Lu Baolu, Marc Zyngier,
linux-arm-kernel, iommu, linux-kernel
In-Reply-To: <ZhUnK1-Pvcix5dyI@google.com>
On 09/04/2024 12:31 pm, Mostafa Saleh wrote:
> Hi Robin,
>
> On Tue, Apr 09, 2024 at 12:17:54PM +0100, Robin Murphy wrote:
>> On 09/04/2024 11:43 am, Mostafa Saleh wrote:
>>> Hi Aleksandr,
>>>
>>> On Wed, Apr 03, 2024 at 12:37:59PM +0700, Aleksandr Aprelkov wrote:
>>>> If devm_add_action() returns ENOMEM, then MSIs allocated but
>>>> not freed on teardown.
>>>>
>>>> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>>>>
>>>> Fixes: 166bdbd23161 ("iommu/arm-smmu: Add support for MSI on SMMUv3")
>>>> Signed-off-by: Aleksandr Aprelkov <aaprelkov@usergate.com>
>>>> ---
>>>> v2: Use appropriate function for registration failure as
>>>> Jonathan Cameron <Jonathan.Cameron@Huawei.com> suggested.
>>>>
>>>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 4 +++-
>>>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>>>> index 41f93c3ab160..8800af041e5f 100644
>>>> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>>>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>>>> @@ -3402,7 +3402,9 @@ static void arm_smmu_setup_msis(struct arm_smmu_device *smmu)
>>>> smmu->priq.q.irq = msi_get_virq(dev, PRIQ_MSI_INDEX);
>>>> /* Add callback to free MSIs on teardown */
>>>> - devm_add_action(dev, arm_smmu_free_msis, dev);
>>>> + ret = devm_add_action_or_reset(dev, arm_smmu_free_msis, dev);
>>>> + if (ret)
>>>> + dev_warn(dev, "failed to add free MSIs callback - falling back to wired irqs\n");
>>>
>>> I am not sure that is the right fix, as allowing the driver to probe
>>> without MSIs, seems worse than leaking MSI memory.
>>>
>>> IMHO, we can just add something like:
>>> dev_err(smmu->dev, “Can’t allocate devm action, MSIs are never freed! !\n”) ;
>>
>> Honestly I don't think this matters. If we ever really did fail to allocate
>> 16 bytes, SLUB would already be screaming and spewing stacktraces, and the
>> system is dead already.
>>
>>> Also, we can’t unconditionally fallback to wired irqs if MSI exists,
>>> according to the user manual:
>>> An implementation must support one of, or optionally both of,
>>> wired interrupts and MSIs
>>> ...
>>> The discovery of support for wired interrupts is IMPLEMENTATION DEFINED.
>>>
>>> We can add some logic, to check dt/acpi irqs and to choose to fallback
>>> or not based on that, but, if we get -ENOMEM, (especially early at
>>> probe) something really went wrong, so I am not sure it’s worth
>>> the complexity.
>>
>> That logic already exists in arm_smmu_setup_unique_irqs() - the messages
>> here are in the sense of "we're giving up on MSIs and falling back to trying
>> whatever wired IRQs we may or may not have." The critical point is that
>> we're not using MSIs for some potentially actionable reason, i.e. if the
>> user does expect the system to be MSI-capable, then it could be an
>> indication of perhaps a wrong or missing msi-parent, for which they may
>> pursue a firmware fix. In other cases it's normal and expected not to use
>> MSIs though (e.g. the system just doesn't have an ITS), so we don't want to
>> be *too* noisy about it.
>
> The case I am worried about in this patch, is for systems with
> MSIs only.
> With this patch, that means, we fallback to wired irqs which don't
> exist, so the driver will probe with no interrupts at all, which in my
> opinion worse than leaking the memory.
True, the logic looks a bit off at first glance - I was halfway through
writing a reply to that effect - but then if you look past the reality
that this is all academic since it's never really going to happen
anyway, if we *did* fail to allocate 16 bytes here, there's an
incredibly high chance that immediately proceeding into
iommu_device_sysfs_add() is also going to result in another (larger)
allocation failure which ends up aborting the whole probe anyway. Plus
the chance of subsequently being able to allocate any
domains/pagetables/etc. for any meaningful IOMMU usage would seem slim.
Honestly I'd be inclined to do nothing more than add the _or_reset to
shut the static checkers up, and not waste code and data on a useless
message for a theoretical condition at all.
Cheers,
Robin.
_______________________________________________
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 0/4] Speed up boot with faster linear map creation
From: David Hildenbrand @ 2024-04-09 11:51 UTC (permalink / raw)
To: Itaru Kitayama, Ryan Roberts
Cc: Catalin Marinas, Will Deacon, Mark Rutland, Ard Biesheuvel,
Donald Dutile, Eric Chanudet, Linux ARM,
linux-kernel@vger.kernel.org
In-Reply-To: <d02959bc-84d8-4c74-a0da-9ad1159502e1@redhat.com>
On 09.04.24 13:29, David Hildenbrand wrote:
> On 09.04.24 13:22, David Hildenbrand wrote:
>> On 09.04.24 12:13, Itaru Kitayama wrote:
>>>
>>>
>>>> On Apr 9, 2024, at 19:04, Ryan Roberts <ryan.roberts@arm.com> wrote:
>>>>
>>>> On 09/04/2024 01:10, Itaru Kitayama wrote:
>>>>> Hi Ryan,
>>>>>
>>>>>> On Apr 8, 2024, at 16:30, Ryan Roberts <ryan.roberts@arm.com> wrote:
>>>>>>
>>>>>> On 06/04/2024 11:31, Itaru Kitayama wrote:
>>>>>>> Hi Ryan,
>>>>>>>
>>>>>>> On Sat, Apr 06, 2024 at 09:32:34AM +0100, Ryan Roberts wrote:
>>>>>>>> Hi Itaru,
>>>>>>>>
>>>>>>>> On 05/04/2024 08:39, Itaru Kitayama wrote:
>>>>>>>>> On Thu, Apr 04, 2024 at 03:33:04PM +0100, 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 most of the time is spent
>>>>>>>>>> waiting on superfluous tlb invalidation and memory barriers. This series reworks
>>>>>>>>>> the kernel pgtable generation code to significantly reduce the number of those
>>>>>>>>>> TLBIs, ISBs and DSBs. 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-rc2):
>>>>>>>>>>
>>>>>>>>>> | Apple M2 VM | Ampere Altra| Ampere Altra| Ampere Altra
>>>>>>>>>> | VM, 16G | VM, 64G | VM, 256G | Metal, 512G
>>>>>>>>>> ---------------|-------------|-------------|-------------|-------------
>>>>>>>>>> | ms (%) | ms (%) | ms (%) | ms (%)
>>>>>>>>>> ---------------|-------------|-------------|-------------|-------------
>>>>>>>>>> base | 153 (0%) | 2227 (0%) | 8798 (0%) | 17442 (0%)
>>>>>>>>>> no-cont-remap | 77 (-49%) | 431 (-81%) | 1727 (-80%) | 3796 (-78%)
>>>>>>>>>> batch-barriers | 13 (-92%) | 162 (-93%) | 655 (-93%) | 1656 (-91%)
>>>>>>>>>> no-alloc-remap | 11 (-93%) | 109 (-95%) | 449 (-95%) | 1257 (-93%)
>>>>>>>>>> lazy-unmap | 6 (-96%) | 61 (-97%) | 257 (-97%) | 838 (-95%)
>>>>>>>>>>
>>>>>>>>>> This series applies on top of v6.9-rc2. All mm selftests pass. I've compile and
>>>>>>>>>> boot tested various PAGE_SIZE and VA size configs.
>>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>
>>>>>>>>>> Changes since v1 [1]
>>>>>>>>>> ====================
>>>>>>>>>>
>>>>>>>>>> - Added Tested-by tags (thanks to Eric and Itaru)
>>>>>>>>>> - Renamed ___set_pte() -> __set_pte_nosync() (per Ard)
>>>>>>>>>> - Reordered patches (biggest impact & least controversial first)
>>>>>>>>>> - Reordered alloc/map/unmap functions in mmu.c to aid reader
>>>>>>>>>> - pte_clear() -> __pte_clear() in clear_fixmap_nosync()
>>>>>>>>>> - Reverted generic p4d_index() which caused x86 build error. Replaced with
>>>>>>>>>> unconditional p4d_index() define under arm64.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [1] https://lore.kernel.org/linux-arm-kernel/20240326101448.3453626-1-ryan.roberts@arm.com/<https://lore.kernel.org/linux-arm-kernel/20240326101448.3453626-1-ryan.roberts@arm.com/>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Ryan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ryan Roberts (4):
>>>>>>>>>> arm64: mm: Don't remap pgtables per-cont(pte|pmd) block
>>>>>>>>>> arm64: mm: Batch dsb and isb when populating pgtables
>>>>>>>>>> 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 | 13 +-
>>>>>>>>>> arch/arm64/kernel/cpufeature.c | 10 +-
>>>>>>>>>> arch/arm64/mm/fixmap.c | 11 +
>>>>>>>>>> arch/arm64/mm/mmu.c | 377 +++++++++++++++++++++++--------
>>>>>>>>>> 6 files changed, 319 insertions(+), 105 deletions(-)
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 2.25.1
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've build and boot tested the v2 on FVP, base is taken from your
>>>>>>>>> linux-rr repo. Running run_vmtests.sh on v2 left some gup longterm not oks, would you take a look at it? The mm ksefltests used is from your linux-rr repo too.
>>>>>>>>
>>>>>>>> Thanks for taking a look at this.
>>>>>>>>
>>>>>>>> I can't reproduce your issue unfortunately; steps as follows on Apple M2 VM:
>>>>>>>>
>>>>>>>> Config: arm64 defconfig + the following:
>>>>>>>>
>>>>>>>> # Squashfs for snaps, xfs for large file folios.
>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_LZ4
>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_LZO
>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_XZ
>>>>>>>> ./scripts/config --enable CONFIG_SQUASHFS_ZSTD
>>>>>>>> ./scripts/config --enable CONFIG_XFS_FS
>>>>>>>>
>>>>>>>> # For general mm debug.
>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM
>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_MAPLE_TREE
>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_RB
>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_PGFLAGS
>>>>>>>> ./scripts/config --enable CONFIG_DEBUG_VM_PGTABLE
>>>>>>>> ./scripts/config --enable CONFIG_PAGE_TABLE_CHECK
>>>>>>>>
>>>>>>>> # For mm selftests.
>>>>>>>> ./scripts/config --enable CONFIG_USERFAULTFD
>>>>>>>> ./scripts/config --enable CONFIG_TEST_VMALLOC
>>>>>>>> ./scripts/config --enable CONFIG_GUP_TEST
>>>>>>>>
>>>>>>>> Running on VM with 12G memory, split across 2 (emulated) NUMA nodes (needed by
>>>>>>>> some mm selftests), with kernel command line to reserve hugetlbs and other
>>>>>>>> features required by some mm selftests:
>>>>>>>>
>>>>>>>> "
>>>>>>>> transparent_hugepage=madvise earlycon root=/dev/vda2 secretmem.enable
>>>>>>>> hugepagesz=1G hugepages=0:2,1:2 hugepagesz=32M hugepages=0:2,1:2
>>>>>>>> default_hugepagesz=2M hugepages=0:64,1:64 hugepagesz=64K hugepages=0:2,1:2
>>>>>>>> "
>>>>>>>>
>>>>>>>> Ubuntu userspace running off XFS rootfs. Build and run mm selftests from same
>>>>>>>> git tree.
>>>>>>>>
>>>>>>>>
>>>>>>>> Although I don't think any of this config should make a difference to gup_longterm.
>>>>>>>>
>>>>>>>> Looks like your errors are all "ftruncate() failed". I've seen this problem on
>>>>>>>> our CI system. There it is due to running the tests from NFS file system. What
>>>>>>>> filesystem are you using? Perhaps you are sharing into the FVP using 9p? That
>>>>>>>> might also be problematic.
>>>>>>>
>>>>>>> That was it. This time I booted up the kernel including your series on
>>>>>>> QEMU on my M1 and executed the gup_longterm program without the ftruncate
>>>>>>> failures. When testing your kernel on FVP, I was executing the script from the FVP's host filesystem using 9p.
>>>>>>
>>>>>> I'm not sure exactly what the root cause is. Perhaps there isn't enough space on
>>>>>> the disk? It might be worth enhancing the error log to provide the errno in
>>>>>> tools/testing/selftests/mm/gup_longterm.c.
>>>>>>
>>>>>
>>>>> Attached is the strace’d gup_longterm executiong log on your
>>>>> pgtable-boot-speedup-v2 kernel.
>>>>
>>>> Sorry are you saying that it only fails with the pgtable-boot-speedup-v2 patch
>>>> set applied? I thought we previously concluded that it was independent of that?
>>>> I was under the impression that it was filesystem related and not something that
>>>> I was planning to investigate.
>>>
>>> No, irrespective of the kernel, if using 9p on FVP the test program fails.
>>> It is indeed 9p filesystem related, as I switched to using NFS all the issues are gone.
>>
>> Did it never work on 9p? If so, we might have to SKIP that test.
>>
>> openat(AT_FDCWD, "gup_longterm.c_tmpfile_BLboOt", O_RDWR|O_CREAT|O_EXCL, 0600) = 3
>> unlinkat(AT_FDCWD, "gup_longterm.c_tmpfile_BLboOt", 0) = 0
>> fstatfs(3, 0xffffe505a840) = -1 EOPNOTSUPP (Operation not supported)
>> ftruncate(3, 4096) = -1 ENOENT (No such file or directory)
>
> Note: I'm wondering if the unlinkat here is the problem that makes
> ftruncate() with 9p result in weird errors (e.g., the hypervisor
> unlinked the file and cannot reopen it for the fstatfs/ftruncate. ...
> which gives us weird errors here).
>
> Then, we should lookup the fs type in run_with_local_tmpfile() before
> the unlink() and simply skip the test if it is 9p.
The unlink with 9p most certainly was a known issue in the past:
https://gitlab.com/qemu-project/qemu/-/issues/103
Maybe it's still an issue with older hypervisors (QEMU?)? Or it was
never completely resolved?
According to https://bugs.launchpad.net/qemu/+bug/1336794, QEMU v5.2.0
should contain a fix that is supposed to work with never kernels.
--
Cheers,
David / dhildenb
_______________________________________________
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] pinctrl: apple-gpio: Fix null pointer dereference in apple_gpio_pinctrl_probe()
From: Krzysztof Kozlowski @ 2024-04-09 11:53 UTC (permalink / raw)
To: Ma Ke, marcan, sven, alyssa, linus.walleij
Cc: asahi, linux-arm-kernel, linux-gpio, linux-kernel
In-Reply-To: <20240409110254.2201457-1-make_ruc2021@163.com>
On 09/04/2024 13:02, Ma Ke wrote:
> devm_kasprintf() returns a pointer to dynamically allocated memory which
> can be NULL upon failure. We add a check to ensure that failure does not
> occur.
>
Subject: I doubt that there is null pointer dereference... Don't just
copy existing commit msgs or subjects without adjusting to real case.
> Signed-off-by: Ma Ke <make_ruc2021@163.com>
> ---
> drivers/pinctrl/pinctrl-apple-gpio.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/pinctrl/pinctrl-apple-gpio.c b/drivers/pinctrl/pinctrl-apple-gpio.c
> index 3751c7de37aa..af2f90d1950f 100644
> --- a/drivers/pinctrl/pinctrl-apple-gpio.c
> +++ b/drivers/pinctrl/pinctrl-apple-gpio.c
> @@ -474,6 +474,8 @@ static int apple_gpio_pinctrl_probe(struct platform_device *pdev)
> for (i = 0; i < npins; i++) {
> pins[i].number = i;
> pins[i].name = devm_kasprintf(&pdev->dev, GFP_KERNEL, "PIN%u", i);
> + if (!pins[i].name)
> + return -ENOMEM;
> pins[i].drv_data = pctl;
The check is a bit later, so please be more precise how do you fix it
and how did you reproduced it.
Maybe checking earlier is reasonable, maybe is redundant. You did not
address it...
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 5/9] dt-bindings: rtc: rtc-aspeed: move to trivial-rtc
From: Andrew Jeffery @ 2024-04-09 11:53 UTC (permalink / raw)
To: Javier Carrasco, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Maxime Coquelin,
Alexandre Torgue
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, linux-stm32
In-Reply-To: <20240408-rtc_dtschema-v1-5-c447542fc362@gmail.com>
On Mon, 2024-04-08 at 17:53 +0200, Javier Carrasco wrote:
> The RTCs documented in this binding require a compatible, a reg
> and a single interrupt, which make them suitable for a direct
> conversion into trivial-rtc.
>
> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Reviewed-by: Andrew Jeffery <andrew@codeconstruct.com.au>
Thanks,
Andrew
_______________________________________________
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 v3] net: dsa: mt7530: fix enabling EEE on MT7531 switch on all boards
From: Paolo Abeni @ 2024-04-09 11:58 UTC (permalink / raw)
To: arinc.unal, Daniel Golle, DENG Qingfang, Sean Wang, Andrew Lunn,
Florian Fainelli, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Matthias Brugger, AngeloGioacchino Del Regno,
René van Dorst, Russell King, SkyLake Huang, Heiner Kallweit
Cc: Bartel Eerdekens, mithat.guner, erkin.bozoglu, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek, Florian Fainelli
In-Reply-To: <20240408-for-net-mt7530-fix-eee-for-mt7531-mt7988-v3-1-84fdef1f008b@arinc9.com>
On Mon, 2024-04-08 at 10:08 +0300, Arınç ÜNAL via B4 Relay wrote:
> 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 MACs. EEE is
> enabled on MT7531 switch MACs by pulling the LAN2LED0 pin low on the board
> (bootstrapping), unsetting the EEE_DIS bit on the trap register, or setting
> the internal EEE switch bit on the CORE_PLL_GROUP4 register. Thanks to
> SkyLake Huang (黃啟澤) from MediaTek for providing information on the
> internal EEE switch bit.
>
> There are existing boards that were not designed to pull the pin low.
> Because of that, the EEE status currently depends on the board design.
>
> The EEE_DIS 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.
>
> To not cause this unwanted behaviour whilst enabling EEE on all boards, set
> the internal EEE switch bit on the CORE_PLL_GROUP4 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. The mediatek-ge PHY driver already disables EEE
> advertisement on the switch PHYs but my testing shows that it is somehow
> enabled afterwards. Disabling EEE advertisement before the PHY driver
> initialises keeps it off.
>
> With this change, EEE can now be enabled using ethtool.
>
> 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>
> ---
> Here's some information for the record. EEE could not be enabled on MT7531
> on most boards using ethtool before this. On MT7988 SoC switch, EEE is
> disabled by default but can be turned on normally using ethtool. EEE is
> enabled by default on MT7530 and there's no need to make changes on the DSA
> subdriver for it.
> ---
> Changes in v3:
> - Remove patch 2, it was revealed that it doesn't fix a bug.
> - Patch 1
> - Use the internal EEE switch bit provided by SkyLake Huang (黃啟澤). It
> is a better method compared to unsetting the EEE_DIS bit of the trap as
> the latter method causes unwanted behaviour on the LED connected to the
> pin that pertains to the EEE_DIS bit.
Since this leverages something relatively obscure, it would be great if
someone in the CC list could independently test it. Let's wait a bit
more.
Cheers,
Paolo
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [v2 0/1] arm64: dts: rockchip: enable onboard spi flash for rock-3a
From: Chukun Pan @ 2024-04-09 12:00 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Conor Dooley, Krzysztof Kozlowski, Rob Herring, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree, Chukun Pan
Changes in v2:
Add missing cells count.
Increase spi max frequency to 104MHz.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [v2 1/1] arm64: dts: rockchip: enable onboard spi flash for rock-3a
From: Chukun Pan @ 2024-04-09 12:00 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Conor Dooley, Krzysztof Kozlowski, Rob Herring, linux-arm-kernel,
linux-rockchip, linux-kernel, devicetree, Chukun Pan
In-Reply-To: <20240409120003.309358-1-amadeus@jmu.edu.cn>
There is a mx25u12835f spi flash on this board, enable it.
[ 2.525805] spi-nor spi4.0: mx25u12835f (16384 Kbytes)
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
index a5e974ea659e..c62230308457 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3a.dts
@@ -757,6 +757,20 @@ &sdmmc2 {
status = "okay";
};
+&sfc {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0x0>;
+ spi-max-frequency = <104000000>;
+ spi-rx-bus-width = <4>;
+ spi-tx-bus-width = <1>;
+ };
+};
+
&tsadc {
rockchip,hw-tshut-mode = <1>;
rockchip,hw-tshut-polarity = <0>;
--
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 v2 1/6] dt-bindings: firmware: arm,scmi: set additionalProperties to true
From: Cristian Marussi @ 2024-04-09 12:01 UTC (permalink / raw)
To: Peng Fan
Cc: Krzysztof Kozlowski, Peng Fan (OSS), Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Sudeep Holla,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <AS1PR04MB9431BE4B2BFE05507A2D93F288072@AS1PR04MB9431.eurprd04.prod.outlook.com>
On Tue, Apr 09, 2024 at 09:25:10AM +0000, Peng Fan wrote:
> Hi Krzysztof,
>
> > Subject: RE: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > additionalProperties to true
> >
> > > Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > additionalProperties to true
> > >
> > > On 08/04/2024 08:08, Peng Fan wrote:
> > > >> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > >> additionalProperties to true
> > > >>
> > > >> On 08/04/2024 01:50, Peng Fan wrote:
> > > >>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi: set
> > > >>>> additionalProperties to true
> > > >>>>
> > > >>>> On 07/04/2024 12:04, Peng Fan wrote:
> > > >>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > >>>>>> set additionalProperties to true
> > > >>>>>>
> > > >>>>>> On 07/04/2024 02:37, Peng Fan wrote:
> > > >>>>>>>> Subject: Re: [PATCH v2 1/6] dt-bindings: firmware: arm,scmi:
> > > >>>>>>>> set additionalProperties to true
> > > >>>>>>>>
> > > >>>>>>>> On 05/04/2024 14:39, Peng Fan (OSS) wrote:
> > > >>>>>>>>> From: Peng Fan <peng.fan@nxp.com>
> > > >>>>>>>>>
> > > >>>>>>>>> When adding vendor extension protocols, there is dt-schema
> > > >> warning:
> > > >>>>>>>>> "
> > > >>>>>>>>> imx,scmi.example.dtb: scmi: 'protocol@81', 'protocol@84' do
> > > >>>>>>>>> not match any of the regexes: 'pinctrl-[0-9]+'
> > > >>>>>>>>> "
> > > >>>>>>>>>
> > > >>>>>>>>> Set additionalProperties to true to address the issue.
> > > >>>>>>>>
> > > >>>>>>>> I do not see anything addressed here, except making the
> > > >>>>>>>> binding accepting anything anywhere...
> > > >>>>>>>
> > > >>>>>>> I not wanna add vendor protocols in arm,scmi.yaml, so will
> > > >>>>>>> introduce a new yaml imx.scmi.yaml which add i.MX SCMI
> > > >>>>>>> protocol
> > > >> extension.
> > > >>>>>>>
> > > >>>>>>> With additionalProperties set to false, I not know how, please
> > > suggest.
> > > >>>>>>
> > > >>>>>> First of all, you cannot affect negatively existing devices
> > > >>>>>> (their
> > > >>>>>> bindings) and your patch does exactly that. This should make
> > > >>>>>> you thing what is the correct approach...
> > > >>>>>>
> > > >>>>>> Rob gave you the comment about missing compatible - you still
> > > >>>>>> did not address that.
> > > >>>>>
> > > >>>>> I added the compatible in patch 2/6 in the examples "compatible
> > > >>>>> =
> > > >>>> "arm,scmi";"
> > > >>>>
> > > >>>> So you claim that your vendor extensions are the same or fully
> > > >>>> compatible with arm,scmi and you add nothing... Are your
> > > >>>> extensions/protocol valid for arm,scmi?
> > > >>>
> > > >>> Yes. They are valid for arm,scmi.
> > > >>>
> > > >>> If yes, why is this in separate binding. If no, why you use
> > > >>> someone
> > > >>>> else's compatible?
> > > >>>
> > > >>> Per SCMI Spec
> > > >>> 0x80-0xFF: Reserved for vendor or platform-specific extensions to
> > > >>> this interface
> > > >>>
> > > >>> i.MX use 0x81 for BBM, 0x84 for MISC. But other vendors will use
> > > >>> the id for their own protocol.
> > > >>
> > > >> So how are they valid for arm,scmi? I don't understand.
> > > >
> > > > arm,scmi is a firmware compatible string. The protocol node is a sub-node.
> > > > I think the arm,scmi is that saying the firmware following SCMI spec
> > > > to implement the protocols.
> > > >
> > > > For vendor reserved ID, firmware also follow the SCMI spec to
> > > > implement their own usage, so from firmware level, it is ARM SCMI
> > > > spec
> > > compatible.
> > >
> > > That's not the point. It is obvious that your firmware is compatible
> > > with arm,scmi, but what you try to say in this and revised patch is
> > > that every arm,scmi is compatible with your implementation. What you
> > > are saying is that 0x84 is MISC protocol for every firmware, Qualcomm,
> > > NXP, Samsung, TI, Mediatek etc.
> > >
> > > I claim it is not true. 0x84 is not MISC for Qualcomm, for example.
> >
> > You are right. I am lost now on how to add vendor ID support, using
> > arm,scmi.yaml or adding a new imx,scmi.yaml or else.
>
Hi Peng,
I dont think in the following you will find the solution to the problem,
it is just to recap the situation and constraints around vendor protocol
bindings.
Describing SCMI vendors protocols is tricky because while on one side
the protocol node has to be rooted under the main scmi fw DT node (like
all the standard protocols) and be 'derived' from the arm,scmi.yaml
protocol-node definition, the optional additional properties of the a specific
vendor protocol nodes can be customized by each single vendor, and since,
as you said, you can have multiple protocols from different vendors sharing the
same protocol number, you could have multiple disjoint sets of valid properties
allowed under that same protocol node number; so on one side you have to stick
to some basic protocol-node defs and be rooted under the SCMI node, while on
the other side you will have multiple possibly allowed sets of additional
properties to check against, so IOW you cannot anyway just set
additionalProperties to false since that will result in no checks at all.
As a consequence, at runtime, in the final DTB shipped with a specific
platform you should have only one of the possible vendor nodes for each
of these overlapping protocols, and the SCMI core at probe time will
pick the proper protocol implementation based on the vendor/sub_vendor
IDs gathered from the running SCMI fw platform at init: this way you
can just build the usual "all-inclusive" defconfig without worrying
about vendor protocol clashes since the SCMI core can pick the right
protocol implementation, you should just had taken care to provide the
proper DTB for your protocol; BUT this also means that it is not possible
to add multiple DT bindings based on a 'if vendor' condition since the
vendor itself is NOT defined and not needed in the bindings since it is
discoverable at runtime.
So, after all of this blabbing of mine about this, I am wondering if it
is not possible that the solution is to handle each and every vendor
protocol node that appears with a block of addtional properties that
are picked via a oneOf statement from some external vendor specific
yaml.
(...in a similar way to how pinctrl additional properties are added...)
NOTE THAT the following is just an example of what I mean, it is certainly
wrong, incomplete annd maybe just not acceptable (and could cause DT
maintainers eyes to bleed :P)...
...so it is just fr the sake of explaining what I mean...
diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
index e9d3f043c4ed..3c38a1e3ffed 100644
--- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
+++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
@@ -278,6 +278,22 @@ properties:
required:
- reg
+ protocol@81:
+ $ref: '#/$defs/protocol-node'
+ unevaluatedProperties: false
+
+ properties:
+ reg:
+ const: 0x81
+
+ patternProperties:
+ '$':
+ type: object
+ oneOf:
+ - $ref: /schemas/vendor-A/scmi-protos.yaml#
+ - $ref: /schemas/vendor-B/protos.yaml#
+ unevaluatedProperties: false
+
additionalProperties: false
...with each new Vendor coming to the party adding a line under
oneOf...which would mean probably also having a protocol@NN for each new
protocol that appears...
Thanks,
Cristian
_______________________________________________
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 v2 0/3] drm/mediatek: Add support for OF graphs
From: AngeloGioacchino Del Regno @ 2024-04-09 12:02 UTC (permalink / raw)
To: chunkuang.hu
Cc: robh, krzysztof.kozlowski+dt, conor+dt, p.zabel, airlied, daniel,
maarten.lankhorst, mripard, tzimmermann, matthias.bgg,
angelogioacchino.delregno, shawn.sung, yu-chang.lee, ck.hu,
jitao.shi, devicetree, linux-kernel, dri-devel, linux-mediatek,
linux-arm-kernel, wenst, kernel
Changes in v2:
- Fixed wrong `required` block indentation in commit [2/3]
The display IPs in MediaTek SoCs are *VERY* flexible and those support
being interconnected with different instances of DDP IPs (for example,
merge0 or merge1) and/or with different DDP IPs (for example, rdma can
be connected with either color, dpi, dsi, merge, etc), forming a full
Display Data Path that ends with an actual display.
This series was born because of an issue that I've found while enabling
support for MT8195/MT8395 boards with DSI output as main display: the
current mtk_drm_route variations would not work as currently, the driver
hardcodes a display path for Chromebooks, which have a DisplayPort panel
with DSC support, instead of a DSI panel without DSC support.
There are other reasons for which I wrote this series, and I find that
hardcoding those paths - when a HW path is clearly board-specific - is
highly suboptimal. Also, let's not forget about keeping this driver from
becoming a huge list of paths for each combination of SoC->board->disp
and... this and that.
For more information, please look at the commit description for each of
the commits included in this series.
Please don't mind about the missing OVL_ADAPTOR support for OF graphs
in this series: that needs a bit more thinking and a bit more work, and
will come in a second series that will go on top of this a bit later,
as the OF graph support for *at least* the primary display is essential
*right now* to enable support for the MT8195/8395 EVK, Kontron SoM,
Radxa NIO-12L and all of the other non-Chromebook boards to co-exist
with Chromebooks.
Besides, this is also a valid option for MT8188 Chromebooks which might
have different DSI-or-eDP displays depending on the model (as far as I
can see from the mtk_drm_route attempt for this SoC that is already
present in this driver).
This series was tested on MT8195 Cherry Tomato and on MT8395 Radxa
NIO-12L with both hardcoded paths, OF graph support and partially
hardcoded paths (meaning main display through OF graph and external
display hardcoded, because of OVL_ADAPTOR).
AngeloGioacchino Del Regno (3):
dt-bindings: display: mediatek: Add OF graph support for board path
dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
drm/mediatek: Implement OF graphs support for display paths
.../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 ++
.../display/mediatek/mediatek,aal.yaml | 40 +++
.../display/mediatek/mediatek,ccorr.yaml | 21 ++
.../display/mediatek/mediatek,color.yaml | 22 ++
.../display/mediatek/mediatek,dither.yaml | 22 ++
.../display/mediatek/mediatek,dpi.yaml | 25 +-
.../display/mediatek/mediatek,dsc.yaml | 24 ++
.../display/mediatek/mediatek,dsi.yaml | 27 +-
.../display/mediatek/mediatek,ethdr.yaml | 22 ++
.../display/mediatek/mediatek,gamma.yaml | 19 ++
.../display/mediatek/mediatek,merge.yaml | 23 ++
.../display/mediatek/mediatek,od.yaml | 22 ++
.../display/mediatek/mediatek,ovl-2l.yaml | 22 ++
.../display/mediatek/mediatek,ovl.yaml | 22 ++
.../display/mediatek/mediatek,postmask.yaml | 21 ++
.../display/mediatek/mediatek,rdma.yaml | 22 ++
.../display/mediatek/mediatek,ufoe.yaml | 21 ++
drivers/gpu/drm/mediatek/mtk_dpi.c | 16 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 255 ++++++++++++++++--
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
21 files changed, 645 insertions(+), 36 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
* [PATCH v2 2/3] dt-bindings: arm: mediatek: mmsys: Add OF graph support for board path
From: AngeloGioacchino Del Regno @ 2024-04-09 12:02 UTC (permalink / raw)
To: chunkuang.hu
Cc: robh, krzysztof.kozlowski+dt, conor+dt, p.zabel, airlied, daniel,
maarten.lankhorst, mripard, tzimmermann, matthias.bgg,
angelogioacchino.delregno, shawn.sung, yu-chang.lee, ck.hu,
jitao.shi, devicetree, linux-kernel, dri-devel, linux-mediatek,
linux-arm-kernel, wenst, kernel
In-Reply-To: <20240409120211.321153-1-angelogioacchino.delregno@collabora.com>
Document OF graph on MMSYS/VDOSYS: this supports up to three DDP paths
per HW instance (so potentially up to six displays for multi-vdo SoCs).
The MMSYS or VDOSYS is always the first component in the DDP pipeline,
so it only supports an output port with multiple endpoints - where each
endpoint defines the starting point for one of the (currently three)
possible hardware paths.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../bindings/arm/mediatek/mediatek,mmsys.yaml | 23 +++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
index b3c6888c1457..4e9acd966aa5 100644
--- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
+++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml
@@ -93,6 +93,29 @@ properties:
'#reset-cells':
const: 1
+ port:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output port node. This port connects the MMSYS/VDOSYS output to
+ the first component of one display pipeline, for example one of
+ the available OVL or RDMA blocks.
+ Some MediaTek SoCs support up to three display outputs per MMSYS.
+ properties:
+ endpoint@0:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: Output to the primary display pipeline
+
+ endpoint@1:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: Output to the secondary display pipeline
+
+ endpoint@2:
+ $ref: /schemas/graph.yaml#/properties/endpoint
+ description: Output to the tertiary display pipeline
+
+ required:
+ - endpoint@0
+
required:
- compatible
- reg
--
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 v2 1/3] dt-bindings: display: mediatek: Add OF graph support for board path
From: AngeloGioacchino Del Regno @ 2024-04-09 12:02 UTC (permalink / raw)
To: chunkuang.hu
Cc: robh, krzysztof.kozlowski+dt, conor+dt, p.zabel, airlied, daniel,
maarten.lankhorst, mripard, tzimmermann, matthias.bgg,
angelogioacchino.delregno, shawn.sung, yu-chang.lee, ck.hu,
jitao.shi, devicetree, linux-kernel, dri-devel, linux-mediatek,
linux-arm-kernel, wenst, kernel
In-Reply-To: <20240409120211.321153-1-angelogioacchino.delregno@collabora.com>
The display IPs in MediaTek SoCs support being interconnected with
different instances of DDP IPs (for example, merge0 or merge1) and/or
with different DDP IPs (for example, rdma can be connected with either
color, dpi, dsi, merge, etc), forming a full Display Data Path that
ends with an actual display.
The final display pipeline is effectively board specific, as it does
depend on the display that is attached to it, and eventually on the
sensors supported by the board (for example, Adaptive Ambient Light
would need an Ambient Light Sensor, otherwise it's pointless!), other
than the output type.
Add support for OF graphs to most of the MediaTek DDP (display) bindings
to add flexibility to build custom hardware paths, hence enabling board
specific configuration of the display pipeline and allowing to finally
migrate away from using hardcoded paths.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../display/mediatek/mediatek,aal.yaml | 40 +++++++++++++++++++
.../display/mediatek/mediatek,ccorr.yaml | 21 ++++++++++
.../display/mediatek/mediatek,color.yaml | 22 ++++++++++
.../display/mediatek/mediatek,dither.yaml | 22 ++++++++++
.../display/mediatek/mediatek,dpi.yaml | 25 +++++++++++-
.../display/mediatek/mediatek,dsc.yaml | 24 +++++++++++
.../display/mediatek/mediatek,dsi.yaml | 27 ++++++++++++-
.../display/mediatek/mediatek,ethdr.yaml | 22 ++++++++++
.../display/mediatek/mediatek,gamma.yaml | 19 +++++++++
.../display/mediatek/mediatek,merge.yaml | 23 +++++++++++
.../display/mediatek/mediatek,od.yaml | 22 ++++++++++
.../display/mediatek/mediatek,ovl-2l.yaml | 22 ++++++++++
.../display/mediatek/mediatek,ovl.yaml | 22 ++++++++++
.../display/mediatek/mediatek,postmask.yaml | 21 ++++++++++
.../display/mediatek/mediatek,rdma.yaml | 22 ++++++++++
.../display/mediatek/mediatek,ufoe.yaml | 21 ++++++++++
16 files changed, 372 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
index b4c28e96dd55..623cf7e37fe3 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml
@@ -61,6 +61,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: AAL input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ AAL output to the next component's input, for example could be one
+ of many gamma, overdrive or other blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -88,5 +109,24 @@ examples:
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_DISP_AAL>;
mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ aal0_in: endpoint {
+ remote-endpoint = <&ccorr0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ aal0_out: endpoint {
+ remote-endpoint = <&gamma0_in>;
+ };
+ };
+ };
};
};
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
index 8c2a737237f2..71ea277a5d8e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml
@@ -54,6 +54,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: CCORR input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ CCORR output to the input of the next desired component in the
+ display pipeline, usually only one of the available AAL blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
index b886ca0d89ea..61d040a10c08 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml
@@ -64,6 +64,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: COLOR input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ COLOR output to the input of the next desired component in the
+ display pipeline, for example one of the available CCORR or AAL
+ blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
index 1588b3f7cec7..3d4ab3f86294 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml
@@ -55,6 +55,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DITHER input, usually from a POSTMASK or GAMMA block.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ DITHER output to the input of the next desired component in the
+ display pipeline, for example one of the available DSC compressors,
+ DP_INTF, DSI, LVDS or others.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
index 803c00f26206..6607cb1c6e0a 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml
@@ -64,13 +64,34 @@ properties:
Output port node. This port should be connected to the input port of an
attached HDMI, LVDS or DisplayPort encoder chip.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DPI input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DPI output to an HDMI, LVDS or DisplayPort encoder input
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- - port
+
+oneOf:
+ - required:
+ - port
+ - required:
+ - ports
additionalProperties: false
@@ -79,7 +100,7 @@ examples:
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/mt8173-clk.h>
- dpi0: dpi@1401d000 {
+ dpi: dpi@1401d000 {
compatible = "mediatek,mt8173-dpi";
reg = <0x1401d000 0x1000>;
interrupts = <GIC_SPI 194 IRQ_TYPE_LEVEL_LOW>;
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml
index 2cbdd9ee449d..846de6c17d93 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml
@@ -49,6 +49,30 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Display Stream Compression input, usually from one of the DITHER
+ or MERGE blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Display Stream Compression output to the input of the next desired
+ component in the display pipeline, for example to MERGE, DP_INTF,
+ DPI or DSI.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
index 8611319bed2e..2e9d3d23cbc1 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.yaml
@@ -76,6 +76,26 @@ properties:
Output port node. This port should be connected to the input
port of an attached DSI panel or DSI-to-eDP encoder chip.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input ports can have multiple endpoints, each of those connects
+ to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: DSI input port, usually from DITHER, DSC or MERGE
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ DSI output to an attached DSI panel, or a DSI-to-X encoder chip
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
@@ -85,7 +105,12 @@ required:
- clock-names
- phys
- phy-names
- - port
+
+oneOf:
+ - required:
+ - port
+ - required:
+ - ports
unevaluatedProperties: false
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
index 677882348ede..98db47894eeb 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml
@@ -110,6 +110,28 @@ properties:
include/dt-bindings/gce/<chip>-gce.h, mapping to the register of display
function block.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: ETHDR input, usually from one of the MERGE blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ ETHDR output to the input of the next desired component in the
+ display pipeline, for example one of the available MERGE blocks,
+ or others.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
index c6641acd75d6..e24287ec364e 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
@@ -59,6 +59,25 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: GAMMA input, usually from one of the AAL blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ GAMMA output to the input of the next desired component in the
+ display pipeline, for example one of the available DITHER or
+ POSTMASK blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
index dae839279950..0de9f64f3f84 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml
@@ -77,6 +77,29 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ MERGE input port, usually from DITHER, DPI, DSC, DSI, MDP_RDMA,
+ ETHDR or even from a different MERGE block
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ MERGE output to a DSC, DPI, DP_INTF, DSI, ETHDR, Write DMA, or
+ a different MERGE block, or others.
+
+ required:
+ - port@0
+ - port@1
+
resets:
description: reset controller
See Documentation/devicetree/bindings/reset/reset.txt for details.
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
index 831c653caffd..71534febd49c 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml
@@ -38,6 +38,28 @@ properties:
items:
- description: OD Clock
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OD input port, usually from an AAL block
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ OD output to the input of the next desired component in the
+ display pipeline, for example one of the available RDMA or
+ other blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
index c7dd0ef02dcf..bacdfe7d08a6 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml
@@ -57,6 +57,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OVL input port from MMSYS, VDOSYS or other OVLs
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ OVL output to the input of the next desired component in the
+ display pipeline, for example one of the available COLOR, RDMA
+ or WDMA blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
index c471a181d125..e93f0247bdcc 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml
@@ -74,6 +74,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: OVL input port from MMSYS or one of multiple VDOSYS
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ OVL output to the input of the next desired component in the
+ display pipeline, for example one of the available COLOR, RDMA
+ or WDMA blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
index 11fe32e50a59..fb6fe4742624 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml
@@ -52,6 +52,27 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: POSTMASK input port, usually from GAMMA
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ POSTMASK output to the input of the next desired component in the
+ display pipeline, for example one of the available DITHER blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
index 39dbb5c8bcf8..edb8d3b67025 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml
@@ -86,6 +86,28 @@ properties:
$ref: /schemas/types.yaml#/definitions/phandle-array
maxItems: 1
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: RDMA input port, usually from MMSYS, OD or OVL
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ RDMA output to the input of the next desired component in the
+ display pipeline, for example one of the available COLOR, DPI,
+ DSI, MERGE or UFOE blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
index 39e3e2d4a0db..61a5e22effbf 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml
@@ -43,6 +43,27 @@ properties:
items:
- description: UFOe Clock
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ description:
+ Input and output ports can have multiple endpoints, each of those
+ connects to either the primary, secondary, etc, display pipeline.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: UFOE input, usually from one of the RDMA blocks.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ UFOE output to the input of the next desired component in the
+ display pipeline, usually one of the available DSI blocks.
+
+ required:
+ - port@0
+ - port@1
+
required:
- compatible
- reg
--
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 v2 3/3] drm/mediatek: Implement OF graphs support for display paths
From: AngeloGioacchino Del Regno @ 2024-04-09 12:02 UTC (permalink / raw)
To: chunkuang.hu
Cc: robh, krzysztof.kozlowski+dt, conor+dt, p.zabel, airlied, daniel,
maarten.lankhorst, mripard, tzimmermann, matthias.bgg,
angelogioacchino.delregno, shawn.sung, yu-chang.lee, ck.hu,
jitao.shi, devicetree, linux-kernel, dri-devel, linux-mediatek,
linux-arm-kernel, wenst, kernel
In-Reply-To: <20240409120211.321153-1-angelogioacchino.delregno@collabora.com>
It is impossible to add each and every possible DDP path combination
for each and every possible combination of SoC and board: right now,
this driver hardcodes configuration for 10 SoCs and this is going to
grow larger and larger, and with new hacks like the introduction of
mtk_drm_route which is anyway not enough for all final routes as the
DSI cannot be connected to MERGE if it's not a dual-DSI, or enabling
DSC preventively doesn't work if the display doesn't support it, or
others.
Since practically all display IPs in MediaTek SoCs support being
interconnected with different instances of other, or the same, IPs
or with different IPs and in different combinations, the final DDP
pipeline is effectively a board specific configuration.
Implement OF graphs support to the mediatek-drm drivers, allowing to
stop hardcoding the paths, and preventing this driver to get a huge
amount of arrays for each board and SoC combination, also paving the
way to share the same mtk_mmsys_driver_data between multiple SoCs,
making it more straightforward to add support for new chips.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 16 +-
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 255 ++++++++++++++++++++++---
drivers/gpu/drm/mediatek/mtk_drm_drv.h | 2 +-
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 +-
4 files changed, 250 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index beb7d9d08e97..c47648d244fe 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -705,6 +705,15 @@ static int mtk_dpi_bridge_attach(struct drm_bridge *bridge,
{
struct mtk_dpi *dpi = bridge_to_dpi(bridge);
+ dpi->next_bridge = devm_drm_of_get_bridge(dpi->dev, dpi->dev->of_node, 1, -1);
+ if (IS_ERR(dpi->next_bridge)) {
+ /* Old devicetree has only one endpoint */
+ dpi->next_bridge = devm_drm_of_get_bridge(dpi->dev, dpi->dev->of_node, 0, 0);
+ if (IS_ERR(dpi->next_bridge))
+ return dev_err_probe(dpi->dev, PTR_ERR(dpi->next_bridge),
+ "Failed to get bridge\n");
+ }
+
return drm_bridge_attach(bridge->encoder, dpi->next_bridge,
&dpi->bridge, flags);
}
@@ -1055,13 +1064,6 @@ static int mtk_dpi_probe(struct platform_device *pdev)
if (dpi->irq < 0)
return dpi->irq;
- dpi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0);
- if (IS_ERR(dpi->next_bridge))
- return dev_err_probe(dev, PTR_ERR(dpi->next_bridge),
- "Failed to get bridge\n");
-
- dev_info(dev, "Found bridge node: %pOF\n", dpi->next_bridge->of_node);
-
platform_set_drvdata(pdev, dpi);
dpi->bridge.funcs = &mtk_dpi_bridge_funcs;
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 74832c213092..2baefa06ad16 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -796,12 +796,200 @@ static const struct of_device_id mtk_ddp_comp_dt_ids[] = {
{ }
};
+static int mtk_drm_of_get_ddp_comp_type(struct device_node *node, enum mtk_ddp_comp_type *ctype)
+{
+ const struct of_device_id *of_id = of_match_node(mtk_ddp_comp_dt_ids, node);
+
+ if (!of_id)
+ return -EINVAL;
+
+ *ctype = (enum mtk_ddp_comp_type)((uintptr_t)of_id->data);
+
+ return 0;
+}
+
+static int mtk_drm_of_get_ddp_ep_cid(struct device_node *node,
+ int output_port, enum mtk_drm_crtc_path crtc_path,
+ struct device_node **next, unsigned int *cid)
+{
+ struct device_node *ep_dev_node, *ep_out;
+ enum mtk_ddp_comp_type comp_type;
+ int ret;
+
+ ep_out = of_graph_get_endpoint_by_regs(node, output_port, crtc_path);
+ if (!ep_out)
+ return -ENOENT;
+
+ ep_dev_node = of_graph_get_remote_port_parent(ep_out);
+ if (!ep_dev_node)
+ return -EINVAL;
+
+ /*
+ * Pass the next node pointer regardless of failures in the later code
+ * so that if this function is called in a loop it will walk through all
+ * of the subsequent endpoints anyway.
+ */
+ *next = ep_dev_node;
+
+ if (!of_device_is_available(ep_dev_node))
+ return -ENODEV;
+
+ ret = mtk_drm_of_get_ddp_comp_type(ep_dev_node, &comp_type);
+ if (ret)
+ return ret;
+
+ ret = mtk_ddp_comp_get_id(ep_dev_node, comp_type);
+ if (ret < 0)
+ return ret;
+
+ /* All ok! Pass the Component ID to the caller. */
+ *cid = (unsigned int)ret;
+
+ return 0;
+}
+
+/**
+ * mtk_drm_of_ddp_path_build_one - Build a Display HW Pipeline for a CRTC Path
+ * @dev: The mediatek-drm device
+ * @cpath: CRTC Path relative to a VDO or MMSYS
+ * @out_path: Pointer to an array that will contain the new pipeline
+ * @out_path_len: Number of entries in the pipeline array
+ *
+ * MediaTek SoCs can use different DDP hardware pipelines (or paths) depending
+ * on the board-specific desired display configuration; this function walks
+ * through all of the output endpoints starting from a VDO or MMSYS hardware
+ * instance and builds the right pipeline as specified in device trees.
+ *
+ * Return:
+ * * %0 - Display HW Pipeline successfully built and validated
+ * * %-ENOENT - Display pipeline was not specified in device tree
+ * * %-EINVAL - Display pipeline built but validation failed
+ * * %-ENOMEM - Failure to allocate pipeline array to pass to the caller
+ */
+static int mtk_drm_of_ddp_path_build_one(struct device *dev, enum mtk_drm_crtc_path cpath,
+ const unsigned int **out_path,
+ unsigned int *out_path_len)
+{
+ struct device_node *next, *prev, *vdo = dev->parent->of_node;
+ unsigned int temp_path[DDP_COMPONENT_DRM_ID_MAX] = { 0 };
+ unsigned int *final_ddp_path;
+ unsigned short int idx = 0;
+ int ret;
+
+ /* Get the first entry for the temp_path array */
+ ret = mtk_drm_of_get_ddp_ep_cid(vdo, 0, cpath, &next, &temp_path[idx++]);
+ if (ret) {
+ if (next)
+ dev_err(dev, "Invalid component %pOF\n", next);
+ else
+ dev_err(dev, "Cannot find first endpoint for path %d\n", cpath);
+
+ return ret;
+ }
+
+ /*
+ * Walk through port outputs until we reach the last valid mediatek-drm component.
+ * To be valid, this must end with an "invalid" component that is a display node.
+ */
+ do {
+ prev = next;
+ ret = mtk_drm_of_get_ddp_ep_cid(next, 1, cpath, &next, &temp_path[idx]);
+ of_node_put(prev);
+ if (ret) {
+ of_node_put(next);
+ break;
+ }
+ } while (++idx < DDP_COMPONENT_DRM_ID_MAX);
+
+ /* If the last entry is not a final display output, the configuration is wrong */
+ switch (temp_path[idx - 1]) {
+ case DDP_COMPONENT_DP_INTF0:
+ case DDP_COMPONENT_DP_INTF1:
+ case DDP_COMPONENT_DPI0:
+ case DDP_COMPONENT_DPI1:
+ case DDP_COMPONENT_DSI0:
+ case DDP_COMPONENT_DSI1:
+ case DDP_COMPONENT_DSI2:
+ case DDP_COMPONENT_DSI3:
+ break;
+ default:
+ dev_err(dev, "Invalid display hw pipeline. Last component: %d (ret=%d)\n",
+ temp_path[idx - 1], ret);
+ return -EINVAL;
+ }
+
+ final_ddp_path = devm_kmemdup(dev, temp_path, idx * sizeof(temp_path[0]), GFP_KERNEL);
+ if (!final_ddp_path)
+ return -ENOMEM;
+
+ dev_dbg(dev, "Display HW Pipeline built with %d components.\n", idx);
+
+ /* Pipeline built! */
+ *out_path = final_ddp_path;
+ *out_path_len = idx;
+
+ return 0;
+}
+
+static int mtk_drm_of_ddp_path_build(struct device *dev, struct device_node *node,
+ struct mtk_mmsys_driver_data *data)
+{
+ struct device_node *ep_node;
+ struct of_endpoint of_ep;
+ bool output_present[MAX_CRTC] = { false };
+ int ret;
+
+ for_each_endpoint_of_node(node, ep_node) {
+ ret = of_graph_parse_endpoint(ep_node, &of_ep);
+ of_node_put(ep_node);
+ if (ret) {
+ dev_err_probe(dev, ret, "Cannot parse endpoint\n");
+ break;
+ }
+
+ if (of_ep.port >= MAX_CRTC) {
+ ret = dev_err_probe(dev, -EINVAL,
+ "Invalid endpoint%u number\n", of_ep.port);
+ break;
+ }
+
+ output_present[of_ep.port] = true;
+ }
+
+ if (ret)
+ return ret;
+
+ if (output_present[CRTC_MAIN]) {
+ ret = mtk_drm_of_ddp_path_build_one(dev, CRTC_MAIN,
+ &data->main_path, &data->main_len);
+ if (ret)
+ return ret;
+ }
+
+ if (output_present[CRTC_EXT]) {
+ ret = mtk_drm_of_ddp_path_build_one(dev, CRTC_EXT,
+ &data->ext_path, &data->ext_len);
+ if (ret)
+ return ret;
+ }
+
+ if (output_present[CRTC_THIRD]) {
+ ret = mtk_drm_of_ddp_path_build_one(dev, CRTC_THIRD,
+ &data->third_path, &data->third_len);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
static int mtk_drm_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct device_node *phandle = dev->parent->of_node;
const struct of_device_id *of_id;
struct mtk_drm_private *private;
+ struct mtk_mmsys_driver_data *mtk_drm_data;
struct device_node *node;
struct component_match *match = NULL;
struct platform_device *ovl_adaptor;
@@ -822,7 +1010,31 @@ static int mtk_drm_probe(struct platform_device *pdev)
if (!of_id)
return -ENODEV;
- private->data = of_id->data;
+ mtk_drm_data = (struct mtk_mmsys_driver_data *)of_id->data;
+ if (!mtk_drm_data)
+ return -EINVAL;
+
+ private->data = kmemdup(mtk_drm_data, sizeof(*mtk_drm_data), GFP_KERNEL);
+ if (!private->data)
+ return -ENOMEM;
+
+ /* Try to build the display pipeline from devicetree graphs */
+ if (of_graph_is_present(phandle)) {
+ dev_dbg(dev, "Building display pipeline for MMSYS %u\n",
+ mtk_drm_data->mmsys_id);
+ private->data = devm_kmemdup(dev, mtk_drm_data,
+ sizeof(*mtk_drm_data), GFP_KERNEL);
+ if (!private->data)
+ return -ENOMEM;
+
+ ret = mtk_drm_of_ddp_path_build(dev, phandle, private->data);
+ if (ret)
+ return ret;
+ } else {
+ /* No devicetree graphs support: go with hardcoded paths if present */
+ dev_dbg(dev, "Using hardcoded paths for MMSYS %u\n", mtk_drm_data->mmsys_id);
+ private->data = mtk_drm_data;
+ };
private->all_drm_private = devm_kmalloc_array(dev, private->data->mmsys_dev_num,
sizeof(*private->all_drm_private),
@@ -844,12 +1056,11 @@ static int mtk_drm_probe(struct platform_device *pdev)
/* Iterate over sibling DISP function blocks */
for_each_child_of_node(phandle->parent, node) {
- const struct of_device_id *of_id;
enum mtk_ddp_comp_type comp_type;
int comp_id;
- of_id = of_match_node(mtk_ddp_comp_dt_ids, node);
- if (!of_id)
+ ret = mtk_drm_of_get_ddp_comp_type(node, &comp_type);
+ if (ret)
continue;
if (!of_device_is_available(node)) {
@@ -858,8 +1069,6 @@ static int mtk_drm_probe(struct platform_device *pdev)
continue;
}
- comp_type = (enum mtk_ddp_comp_type)(uintptr_t)of_id->data;
-
if (comp_type == MTK_DISP_MUTEX) {
int id;
@@ -888,22 +1097,24 @@ static int mtk_drm_probe(struct platform_device *pdev)
* blocks have separate component platform drivers and initialize their own
* DDP component structure. The others are initialized here.
*/
- if (comp_type == MTK_DISP_AAL ||
- comp_type == MTK_DISP_CCORR ||
- comp_type == MTK_DISP_COLOR ||
- comp_type == MTK_DISP_GAMMA ||
- comp_type == MTK_DISP_MERGE ||
- comp_type == MTK_DISP_OVL ||
- comp_type == MTK_DISP_OVL_2L ||
- comp_type == MTK_DISP_OVL_ADAPTOR ||
- comp_type == MTK_DISP_RDMA ||
- comp_type == MTK_DP_INTF ||
- comp_type == MTK_DPI ||
- comp_type == MTK_DSI) {
- dev_info(dev, "Adding component match for %pOF\n",
- node);
- drm_of_component_match_add(dev, &match, component_compare_of,
- node);
+ switch (comp_type) {
+ default:
+ break;
+ case MTK_DISP_AAL:
+ case MTK_DISP_CCORR:
+ case MTK_DISP_COLOR:
+ case MTK_DISP_GAMMA:
+ case MTK_DISP_MERGE:
+ case MTK_DISP_OVL:
+ case MTK_DISP_OVL_2L:
+ case MTK_DISP_OVL_ADAPTOR:
+ case MTK_DISP_RDMA:
+ case MTK_DP_INTF:
+ case MTK_DPI:
+ case MTK_DSI:
+ dev_info(dev, "Adding component match for %pOF\n", node);
+ drm_of_component_match_add(dev, &match, component_compare_of, node);
+ break;
}
ret = mtk_ddp_comp_init(node, &private->ddp_comp[comp_id], comp_id);
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.h b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
index 33fadb08dc1c..9b2a7045e69d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.h
@@ -59,7 +59,7 @@ struct mtk_drm_private {
struct device *mmsys_dev;
struct device_node *comp_node[DDP_COMPONENT_DRM_ID_MAX];
struct mtk_ddp_comp ddp_comp[DDP_COMPONENT_DRM_ID_MAX];
- const struct mtk_mmsys_driver_data *data;
+ struct mtk_mmsys_driver_data *data;
struct drm_atomic_state *suspend_state;
unsigned int mbox_index;
struct mtk_drm_private **all_drm_private;
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 9501f4019199..1bdbe43e3888 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -903,9 +903,13 @@ static int mtk_dsi_host_attach(struct mipi_dsi_host *host,
dsi->lanes = device->lanes;
dsi->format = device->format;
dsi->mode_flags = device->mode_flags;
- dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0);
- if (IS_ERR(dsi->next_bridge))
- return PTR_ERR(dsi->next_bridge);
+ dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0);
+ if (IS_ERR(dsi->next_bridge)) {
+ /* Old devicetree has only one endpoint */
+ dsi->next_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 0, 0);
+ if (IS_ERR(dsi->next_bridge))
+ return PTR_ERR(dsi->next_bridge);
+ }
drm_bridge_add(&dsi->bridge);
--
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 0/9] rtc: convert multiple bindings into dtschema
From: Javier Carrasco @ 2024-04-09 12:02 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jiaxun Yang,
Vladimir Zapolskiy, Joel Stanley, Andrew Jeffery, Maxime Coquelin,
Alexandre Torgue, linux-rtc, devicetree, linux-kernel,
linux-arm-kernel, linux-aspeed, linux-stm32
In-Reply-To: <20240409102658d86fb2bd@mail.local>
On 4/9/24 12:26, Alexandre Belloni wrote:
> On 08/04/2024 17:53:00+0200, Javier Carrasco wrote:
>> This series converts the following bindings into dtschema, moving them
>> to trivial-rtc whenever possible:
>>
>> - orion-rtc: trival-rtc, referenced in arm arch.
>> - google,goldfish-rtc: trivial-rtc, referenced in mips arch.
>> - lpc32xx-rtc: trival-rtc, referenced in arm arch.
>> - maxim,ds1742: trivial-rtc, not referenced in arch, cheap conversion.
>> - rtc-aspeed: 3 devices to trivial-rtc, all referenced in arm arch.
>> - pxa-rtc: add missing properties and convert. Referenced in arm arch.
>> - st,spear600-rtc: trivial-rtc, referenced in arm arch.
>> - stmp3xxx-rtc: convert, referenced in arm arch.
>> - via,vt8500-rtc: trivial-rtc, referenced in arm arch.
>
> Probably all the moves to trivial-rtc can be squashed.
>
Sure, I will squash them for v2.
Best regards,
Javier Carrasco
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] clk: meson: axg: move reset controller's code to separate module
From: Conor Dooley @ 2024-04-09 12:05 UTC (permalink / raw)
To: Stephen Boyd
Cc: Jan Dakinevich, Jerome Brunet, Philipp Zabel, Neil Armstrong,
Michael Turquette, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Kevin Hilman, Martin Blumenstingl, linux-amlogic, linux-clk,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20240408-numerator-escargot-a642507a598e@spud>
[-- Attachment #1.1: Type: text/plain, Size: 8826 bytes --]
On Mon, Apr 08, 2024 at 06:05:51PM +0100, Conor Dooley wrote:
> > > Seconded, the clk-mpfs/reset-mpfs and clk-starfive-jh7110-sys/reset-
> > > starfive-jh7110 drivers are examples of this.
> > >
> > > > The auxiliary device creation function can also be in the
> > > > drivers/reset/ directory so that the clk driver calls some function
> > > > to create and register the device.
> > >
> > > I'm undecided about this, do you think mpfs_reset_controller_register()
> > > and jh7110_reset_controller_register() should rather live with the
> > > reset aux drivers in drivers/reset/ ?
> >
> > Yes, and also mpfs_reset_read() and friends. We should pass the base
> > iomem pointer and parent device to mpfs_reset_adev_alloc() instead and
> > then move all that code into drivers/reset with some header file
> > exported function to call. That way the clk driver hands over the data
> > without having to implement half the implementation.
>
> I'll todo list that :)
Something like the below?
-- >8 --
From a12f281d2cb869bcd9a6ffc45d0c6a0d3aa2e9e2 Mon Sep 17 00:00:00 2001
From: Conor Dooley <conor.dooley@microchip.com>
Date: Tue, 9 Apr 2024 11:54:34 +0100
Subject: [PATCH] clock, reset: microchip: move all mpfs reset code to the
reset subsystem
<insert something here>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
---
drivers/clk/microchip/clk-mpfs.c | 90 +-------------------------------
drivers/reset/reset-mpfs.c | 74 +++++++++++++++++++++++---
include/soc/microchip/mpfs.h | 10 ++--
3 files changed, 73 insertions(+), 101 deletions(-)
diff --git a/drivers/clk/microchip/clk-mpfs.c b/drivers/clk/microchip/clk-mpfs.c
index 22eab91a6712..432080c35cec 100644
--- a/drivers/clk/microchip/clk-mpfs.c
+++ b/drivers/clk/microchip/clk-mpfs.c
@@ -4,7 +4,6 @@
*
* Copyright (C) 2020-2022 Microchip Technology Inc. All rights reserved.
*/
-#include <linux/auxiliary_bus.h>
#include <linux/clk-provider.h>
#include <linux/io.h>
#include <linux/module.h>
@@ -361,93 +360,6 @@ static int mpfs_clk_register_periphs(struct device *dev, struct mpfs_periph_hw_c
return 0;
}
-/*
- * Peripheral clock resets
- */
-
-#if IS_ENABLED(CONFIG_RESET_CONTROLLER)
-
-u32 mpfs_reset_read(struct device *dev)
-{
- struct mpfs_clock_data *clock_data = dev_get_drvdata(dev->parent);
-
- return readl_relaxed(clock_data->base + REG_SUBBLK_RESET_CR);
-}
-EXPORT_SYMBOL_NS_GPL(mpfs_reset_read, MCHP_CLK_MPFS);
-
-void mpfs_reset_write(struct device *dev, u32 val)
-{
- struct mpfs_clock_data *clock_data = dev_get_drvdata(dev->parent);
-
- writel_relaxed(val, clock_data->base + REG_SUBBLK_RESET_CR);
-}
-EXPORT_SYMBOL_NS_GPL(mpfs_reset_write, MCHP_CLK_MPFS);
-
-static void mpfs_reset_unregister_adev(void *_adev)
-{
- struct auxiliary_device *adev = _adev;
-
- auxiliary_device_delete(adev);
- auxiliary_device_uninit(adev);
-}
-
-static void mpfs_reset_adev_release(struct device *dev)
-{
- struct auxiliary_device *adev = to_auxiliary_dev(dev);
-
- kfree(adev);
-}
-
-static struct auxiliary_device *mpfs_reset_adev_alloc(struct mpfs_clock_data *clk_data)
-{
- struct auxiliary_device *adev;
- int ret;
-
- adev = kzalloc(sizeof(*adev), GFP_KERNEL);
- if (!adev)
- return ERR_PTR(-ENOMEM);
-
- adev->name = "reset-mpfs";
- adev->dev.parent = clk_data->dev;
- adev->dev.release = mpfs_reset_adev_release;
- adev->id = 666u;
-
- ret = auxiliary_device_init(adev);
- if (ret) {
- kfree(adev);
- return ERR_PTR(ret);
- }
-
- return adev;
-}
-
-static int mpfs_reset_controller_register(struct mpfs_clock_data *clk_data)
-{
- struct auxiliary_device *adev;
- int ret;
-
- adev = mpfs_reset_adev_alloc(clk_data);
- if (IS_ERR(adev))
- return PTR_ERR(adev);
-
- ret = auxiliary_device_add(adev);
- if (ret) {
- auxiliary_device_uninit(adev);
- return ret;
- }
-
- return devm_add_action_or_reset(clk_data->dev, mpfs_reset_unregister_adev, adev);
-}
-
-#else /* !CONFIG_RESET_CONTROLLER */
-
-static int mpfs_reset_controller_register(struct mpfs_clock_data *clk_data)
-{
- return 0;
-}
-
-#endif /* !CONFIG_RESET_CONTROLLER */
-
static int mpfs_clk_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -499,7 +411,7 @@ static int mpfs_clk_probe(struct platform_device *pdev)
if (ret)
return ret;
- return mpfs_reset_controller_register(clk_data);
+ return mpfs_reset_controller_register(dev, clk_data->base + REG_SUBBLK_RESET_CR);
}
static const struct of_device_id mpfs_clk_of_match_table[] = {
diff --git a/drivers/reset/reset-mpfs.c b/drivers/reset/reset-mpfs.c
index 7f3fb2d472f4..27cd68b4ee81 100644
--- a/drivers/reset/reset-mpfs.c
+++ b/drivers/reset/reset-mpfs.c
@@ -8,6 +8,7 @@
*/
#include <linux/auxiliary_bus.h>
#include <linux/delay.h>
+#include <linux/io.h>
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
@@ -28,10 +29,11 @@
/* block concurrent access to the soft reset register */
static DEFINE_SPINLOCK(mpfs_reset_lock);
+static void __iomem *mpfs_reset_addr;
+
/*
* Peripheral clock resets
*/
-
static int mpfs_assert(struct reset_controller_dev *rcdev, unsigned long id)
{
unsigned long flags;
@@ -39,9 +41,9 @@ static int mpfs_assert(struct reset_controller_dev *rcdev, unsigned long id)
spin_lock_irqsave(&mpfs_reset_lock, flags);
- reg = mpfs_reset_read(rcdev->dev);
+ reg = readl(mpfs_reset_addr);
reg |= BIT(id);
- mpfs_reset_write(rcdev->dev, reg);
+ writel(reg, mpfs_reset_addr);
spin_unlock_irqrestore(&mpfs_reset_lock, flags);
@@ -55,9 +57,9 @@ static int mpfs_deassert(struct reset_controller_dev *rcdev, unsigned long id)
spin_lock_irqsave(&mpfs_reset_lock, flags);
- reg = mpfs_reset_read(rcdev->dev);
+ reg = readl(mpfs_reset_addr);
reg &= ~BIT(id);
- mpfs_reset_write(rcdev->dev, reg);
+ writel(reg, mpfs_reset_addr);
spin_unlock_irqrestore(&mpfs_reset_lock, flags);
@@ -66,7 +68,7 @@ static int mpfs_deassert(struct reset_controller_dev *rcdev, unsigned long id)
static int mpfs_status(struct reset_controller_dev *rcdev, unsigned long id)
{
- u32 reg = mpfs_reset_read(rcdev->dev);
+ u32 reg = readl(mpfs_reset_addr);
/*
* It is safe to return here as MPFS_NUM_RESETS makes sure the sign bit
@@ -137,9 +139,67 @@ static int mpfs_reset_probe(struct auxiliary_device *adev,
return devm_reset_controller_register(dev, rcdev);
}
+static void mpfs_reset_unregister_adev(void *_adev)
+{
+ struct auxiliary_device *adev = _adev;
+
+ auxiliary_device_delete(adev);
+ auxiliary_device_uninit(adev);
+}
+
+static void mpfs_reset_adev_release(struct device *dev)
+{
+ struct auxiliary_device *adev = to_auxiliary_dev(dev);
+
+ kfree(adev);
+}
+
+static struct auxiliary_device *mpfs_reset_adev_alloc(struct device *clk_dev)
+{
+ struct auxiliary_device *adev;
+ int ret;
+
+ adev = kzalloc(sizeof(*adev), GFP_KERNEL);
+ if (!adev)
+ return ERR_PTR(-ENOMEM);
+
+ adev->name = "reset-mpfs";
+ adev->dev.parent = clk_dev;
+ adev->dev.release = mpfs_reset_adev_release;
+ adev->id = 666u;
+
+ ret = auxiliary_device_init(adev);
+ if (ret) {
+ kfree(adev);
+ return ERR_PTR(ret);
+ }
+
+ return adev;
+}
+
+int mpfs_reset_controller_register(struct device *clk_dev, void __iomem *base)
+{
+ struct auxiliary_device *adev;
+ int ret;
+
+ mpfs_reset_addr = base;
+
+ adev = mpfs_reset_adev_alloc(clk_dev);
+ if (IS_ERR(adev))
+ return PTR_ERR(adev);
+
+ ret = auxiliary_device_add(adev);
+ if (ret) {
+ auxiliary_device_uninit(adev);
+ return ret;
+ }
+
+ return devm_add_action_or_reset(clk_dev, mpfs_reset_unregister_adev, adev);
+}
+
static const struct auxiliary_device_id mpfs_reset_ids[] = {
{
- .name = "clk_mpfs.reset-mpfs",
+ .name = "reset_mpfs.reset-mpfs",
},
{ }
};
diff --git a/include/soc/microchip/mpfs.h b/include/soc/microchip/mpfs.h
index 09722f83b0ca..0b756bf5e9bd 100644
--- a/include/soc/microchip/mpfs.h
+++ b/include/soc/microchip/mpfs.h
@@ -43,11 +43,11 @@ struct mtd_info *mpfs_sys_controller_get_flash(struct mpfs_sys_controller *mpfs_
#endif /* if IS_ENABLED(CONFIG_POLARFIRE_SOC_SYS_CTRL) */
#if IS_ENABLED(CONFIG_MCHP_CLK_MPFS)
-
-u32 mpfs_reset_read(struct device *dev);
-
-void mpfs_reset_write(struct device *dev, u32 val);
-
+#if IS_ENABLED(CONFIG_RESET_CONTROLLER)
+int mpfs_reset_controller_register(struct device *clk_dev, void __iomem *base);
+#else
+int mpfs_reset_controller_register(struct device *clk_dev, void* __iomem base) { return 0;}
+#endif /* if IS_ENABLED(CONFIG_RESET_CONTROLLER) */
#endif /* if IS_ENABLED(CONFIG_MCHP_CLK_MPFS) */
#endif /* __SOC_MPFS_H__ */
--
2.43.0
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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] soc: mediatek: mtk-socinfo: depends on CONFIG_SOC_BUS
From: AngeloGioacchino Del Regno @ 2024-04-09 12:06 UTC (permalink / raw)
To: Matthias Brugger, William-tw Lin, linux-kernel, linux-arm-kernel,
linux-mediatek, Daniel Golle
Cc: AngeloGioacchino Del Regno
In-Reply-To: <cc8f7f7da5bdccce514a320e0ae7468659cf7346.1707327680.git.daniel@makrotopia.org>
On Wed, 07 Feb 2024 17:42:41 +0000, Daniel Golle wrote:
> The mtk-socinfo driver uses symbols 'soc_device_register' and
> 'soc_device_unregister' which are part of the bus driver for
> System-on-Chip devices.
>
> Select SOC_BUS to make sure that driver is built and the symbols are
> available.
>
> [...]
Applied to v6.9-fixes/soc, thanks!
[1/1] soc: mediatek: mtk-socinfo: depends on CONFIG_SOC_BUS
commit: 2217fb42a6d0e062b0a11f90fe775651f73ed05f
Cheers,
Angelo
_______________________________________________
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 03/18] dt-bindings: mfd: mediatek: Add codec property for MT6357 PMIC
From: Rob Herring @ 2024-04-09 12:10 UTC (permalink / raw)
To: Alexandre Mergnat
Cc: dri-devel, linux-sound, linaro-mm-sig, Rob Herring, Conor Dooley,
Catalin Marinas, Krzysztof Kozlowski, linux-media,
Christian König, Flora Fu, Mark Brown, Lee Jones,
Takashi Iwai, Will Deacon, Sumit Semwal, linux-mediatek,
Liam Girdwood, AngeloGioacchino Del Regno, devicetree,
linux-arm-kernel, linux-kernel, Matthias Brugger, Jaroslav Kysela
In-Reply-To: <20240226-audio-i350-v2-3-3043d483de0d@baylibre.com>
On Tue, 09 Apr 2024 12:13:24 +0200, Alexandre Mergnat wrote:
> Add the audio codec sub-device. This sub-device is used to set required
> and optional voltage properties between the codec and the board.
>
> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
> ---
> Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml | 5 +++++
> 1 file changed, 5 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/mfd/mediatek,mt6357.yaml:
Error in referenced schema matching $id: http://devicetree.org/schemas/sound/mt6357.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240226-audio-i350-v2-3-3043d483de0d@baylibre.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
_______________________________________________
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 04/18] ASoC: dt-bindings: mt6357: Add audio codec document
From: Rob Herring @ 2024-04-09 12:10 UTC (permalink / raw)
To: Alexandre Mergnat
Cc: Rob Herring, Sumit Semwal, Flora Fu, AngeloGioacchino Del Regno,
dri-devel, Mark Brown, devicetree, Krzysztof Kozlowski,
Catalin Marinas, linux-media, Jaroslav Kysela,
Christian König, Takashi Iwai, Conor Dooley, linux-mediatek,
Lee Jones, linux-kernel, Will Deacon, linaro-mm-sig,
Matthias Brugger, linux-sound, linux-arm-kernel, Liam Girdwood
In-Reply-To: <20240226-audio-i350-v2-4-3043d483de0d@baylibre.com>
On Tue, 09 Apr 2024 12:13:25 +0200, Alexandre Mergnat wrote:
> Add MT8365 audio codec bindings to set required
> and optional voltage properties between the codec and the board.
> The properties are:
> - phandle of the requiered power supply.
> - Setup of microphone bias voltage.
> - Setup of the speaker pin pull-down.
>
> Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
> ---
> .../devicetree/bindings/sound/mt6357.yaml | 54 ++++++++++++++++++++++
> 1 file changed, 54 insertions(+)
>
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/sound/mt6357.yaml: properties:vaud28-supply: '$ref' is not one of ['description', 'deprecated']
from schema $id: http://devicetree.org/meta-schemas/core.yaml#
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240226-audio-i350-v2-4-3043d483de0d@baylibre.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
_______________________________________________
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] ARM: dts: qcom: msm8974: Use proper compatible for APCS syscon
From: AngeloGioacchino Del Regno @ 2024-04-09 12:11 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel, Jassi Brar,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Matthias Brugger, Jacky Huang, Shan-Chun Hung
Cc: linux-arm-msm, linux-kernel, devicetree, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20240408-msm8974-apcs-v1-2-90cb7368836e@z3ntu.xyz>
Il 08/04/24 21:32, Luca Weiss ha scritto:
> Use the apcs-kpss-global compatible for the APCS global mailbox block
> found on this SoC.
>
> This also resolves a dt-binding checker warning:
>
> arch/arm/boot/dts/qcom/qcom-msm8974pro-fairphone-fp2.dtb: syscon@f9011000: compatible: 'anyOf' conditional failed, one must be fixed:
> ['syscon'] is too short
> 'syscon' is not one of ['allwinner,sun8i-a83t-system-controller', 'allwinner,sun8i-h3-system-controller', 'allwinner,sun8i-v3s-system-controller', 'allwinner,sun50i-a64-system-controller', 'amd,pensando-elba-syscon', 'brcm,cru-clkset', 'freecom,fsg-cs2-system-controller', 'fsl,imx93-aonmix-ns-syscfg', 'fsl,imx93-wakeupmix-syscfg', 'hisilicon,dsa-subctrl', 'hisilicon,hi6220-sramctrl', 'hisilicon,pcie-sas-subctrl', 'hisilicon,peri-subctrl', 'hpe,gxp-sysreg', 'intel,lgm-syscon', 'loongson,ls1b-syscon', 'loongson,ls1c-syscon', 'marvell,armada-3700-usb2-host-misc', 'mediatek,mt8135-pctl-a-syscfg', 'mediatek,mt8135-pctl-b-syscfg', 'mediatek,mt8365-syscfg', 'microchip,lan966x-cpu-syscon', 'microchip,sparx5-cpu-syscon', 'mstar,msc313-pmsleep', 'nuvoton,ma35d1-sys', 'nuvoton,wpcm450-shm', 'rockchip,px30-qos', 'rockchip,rk3036-qos', 'rockchip,rk3066-qos', 'rockchip,rk3128-qos', 'rockchip,rk3228-qos', 'rockchip,rk3288-qos', 'rockchip,rk3368-qos', 'rockchip,rk3399-qos', 'rockchip,rk356
> 8-qos', 'rockchip,rk3588-qos', 'rockchip,rv1126-qos', 'starfive,jh7100-sysmain', 'ti,am62-usb-phy-ctrl', 'ti,am654-dss-oldi-io-ctrl', 'ti,am654-serdes-ctrl', 'ti,j784s4-pcie-ctrl']
> from schema $id: http://devicetree.org/schemas/mfd/syscon.yaml#
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.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 1/2] dt-bindings: mailbox: qcom: Add MSM8974 APCS compatible
From: AngeloGioacchino Del Regno @ 2024-04-09 12:11 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel, Jassi Brar,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Matthias Brugger, Jacky Huang, Shan-Chun Hung
Cc: linux-arm-msm, linux-kernel, devicetree, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20240408-msm8974-apcs-v1-1-90cb7368836e@z3ntu.xyz>
Il 08/04/24 21:32, Luca Weiss ha scritto:
> Add compatible for the Qualcomm MSM8974 APCS block.
>
> Signed-off-by: Luca Weiss <luca@z3ntu.xyz>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.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 3/9] dt-bindings: rtc: lpc32xx-rtc: move to trivial-rtc
From: Alexandre Belloni @ 2024-04-09 12:11 UTC (permalink / raw)
To: Javier Carrasco
Cc: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jiaxun Yang, Vladimir Zapolskiy, Joel Stanley,
Andrew Jeffery, Maxime Coquelin, Alexandre Torgue, linux-rtc,
devicetree, linux-kernel, linux-arm-kernel, linux-aspeed,
linux-stm32
In-Reply-To: <6dc808bf-682f-4e91-aac7-7ce6f05a0ab4@gmail.com>
On 09/04/2024 10:52:54+0200, Javier Carrasco wrote:
> On 4/9/24 09:34, Krzysztof Kozlowski wrote:
> > On 08/04/2024 17:53, Javier Carrasco wrote:
> >> This RTC requires a compatible, a reg and a single interrupt,
> >> which makes it suitable for a direct conversion into trivial-rtc.
> >>
> >> Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
> >> ---
> >> Documentation/devicetree/bindings/rtc/lpc32xx-rtc.txt | 15 ---------------
> >> Documentation/devicetree/bindings/rtc/trivial-rtc.yaml | 2 ++
> >> 2 files changed, 2 insertions(+), 15 deletions(-)
> >
> > This one no... and if you tested DTS you would see errors, although you
> > need to test specific lpc config, not multi_v7.
> >
> > It does not look like you tested the DTS against bindings. Please run
> > `make dtbs_check W=1` (see
> > Documentation/devicetree/bindings/writing-schema.rst or
> > https://www.linaro.org/blog/tips-and-tricks-for-validating-devicetree-sources-with-the-devicetree-schema/
> > for instructions).
> >
> > Anyway, you *must* check all DTS before moving anything to trivial.
> >
> > Does it mean all other bindings were not checked against DTS at all?
> >
> > Best regards,
> > Krzysztof
> >
> Hi,
>
> I did check the conversion against nxp/lpc/lpc3250-phy3250.dts, which
> throws a message about the 'clocks' property.
>
> That property is not documented in the original binding, and even though
> it could be missing, I could not find any function to get a clock (i.e.
> any form of clk_get()) in rtc-lpc32xx.c, which is the only file where
> the compatible can be found.
>
> Is therefore the property not useless in the dts? My apologies if I am
> missing something here.
The bindings doesn't document the driver but the hardware. In this case,
the only input clock seems to be a 32kHz crystal.
>
> Thanks and best regards,
> Javier Carrasco
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.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 2/2] ARM: dts: qcom: msm8974: Use proper compatible for APCS syscon
From: Krzysztof Kozlowski @ 2024-04-09 12:21 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel, Jassi Brar,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Matthias Brugger, AngeloGioacchino Del Regno,
Jacky Huang, Shan-Chun Hung
Cc: linux-arm-msm, linux-kernel, devicetree, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20240408-msm8974-apcs-v1-2-90cb7368836e@z3ntu.xyz>
On 08/04/2024 21:32, Luca Weiss wrote:
> Use the apcs-kpss-global compatible for the APCS global mailbox block
> found on this SoC.
>
> This also resolves a dt-binding checker warning:
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.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 1/9] arm64/sysreg: Add definitions for immediate versions of MSR ALLINT
From: Mark Brown @ 2024-04-09 12:28 UTC (permalink / raw)
To: Liao Chang
Cc: catalin.marinas, will, maz, oliver.upton, james.morse,
suzuki.poulose, yuzenghui, tglx, mark.rutland, ardb,
anshuman.khandual, miguel.luis, joey.gouly, ryan.roberts,
jeremy.linton, liwei391, daniel.thompson, sumit.garg,
kristina.martsenko, jpoimboe, ericchancf, robh, scott,
songshuaishuai, shijie, bhe, akpm, thunder.leizhen, horms,
rmk+kernel, takakura, dianders, swboyd, frederic, reijiw,
akihiko.odaki, ruanjinjie, linux-arm-kernel, linux-kernel, kvmarm
In-Reply-To: <20240409012344.3194724-2-liaochang1@huawei.com>
[-- Attachment #1.1: Type: text/plain, Size: 931 bytes --]
On Tue, Apr 09, 2024 at 01:23:36AM +0000, Liao Chang wrote:
> From: Mark Brown <broonie@kernel.org>
>
> Encodings are provided for ALLINT which allow setting of ALLINT.ALLINT
> using an immediate rather than requiring that a register be loaded with
> the value to write. Since these don't currently fit within the scheme we
> have for sysreg generation add manual encodings like we currently do for
> other similar registers such as SVCR.
>
> Since it is required that these immediate versions be encoded with xzr
> as the source register provide asm wrapper which ensure this is the
> case.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> arch/arm64/include/asm/nmi.h | 27 +++++++++++++++++++++++++++
You've not provided a Signed-off-by for this so people can't do anything
with it, please see Documentation/process/submitting-patches.rst for
details on what this is and why it's important.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
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 06/29] iommu/arm-smmu-v3: Add an ops indirection to the STE code
From: Will Deacon @ 2024-04-09 12:40 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: iommu, Joerg Roedel, linux-arm-kernel, Robin Murphy, Lu Baolu,
Eric Auger, Jean-Philippe Brucker, Joerg Roedel, Kevin Tian,
kernel test robot, Moritz Fischer, Moritz Fischer, Michael Shavit,
Nicolin Chen, patches, Shameer Kolothum, Mostafa Saleh, Tony Zhu,
Yi Liu, Zhangfei Gao
In-Reply-To: <6-v6-228e7adf25eb+4155-smmuv3_newapi_p2_jgg@nvidia.com>
On Wed, Mar 27, 2024 at 03:07:52PM -0300, Jason Gunthorpe wrote:
> Prepare to put the CD code into the same mechanism. Add an ops indirection
> around all the STE specific code and make the worker functions independent
> of the entry content being processed.
>
> get_used and sync ops are provided to hook the correct code.
>
> Signed-off-by: Michael Shavit <mshavit@google.com>
> Reviewed-by: Michael Shavit <mshavit@google.com>
> Tested-by: Nicolin Chen <nicolinc@nvidia.com>
> Tested-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 170 ++++++++++++--------
> 1 file changed, 102 insertions(+), 68 deletions(-)
Any chance we can pull the STE testing stuff forward from Michael once
we have the entry writing ops indirection, please? It would be nice to
land that before adding the CD support, I think.
> @@ -1102,17 +1111,14 @@ static bool entry_set(struct arm_smmu_device *smmu, ioasid_t sid,
> * V=0 process. This relies on the IGNORED behavior described in the
> * specification.
> */
> -static void arm_smmu_write_ste(struct arm_smmu_master *master, u32 sid,
> - struct arm_smmu_ste *entry,
> - const struct arm_smmu_ste *target)
> +static void arm_smmu_write_entry(struct arm_smmu_entry_writer *writer,
> + __le64 *entry, const __le64 *target)
> {
> - unsigned int num_entry_qwords = ARRAY_SIZE(target->data);
> - struct arm_smmu_device *smmu = master->smmu;
> - struct arm_smmu_ste unused_update;
> + __le64 unused_update[NUM_ENTRY_QWORDS];
> u8 used_qword_diff;
>
> used_qword_diff =
> - arm_smmu_entry_qword_diff(entry, target, &unused_update);
> + arm_smmu_entry_qword_diff(writer, entry, target, unused_update);
> if (hweight8(used_qword_diff) == 1) {
> /*
> * Only one qword needs its used bits to be changed. This is a
nit: This comment (lost in the diff context) refers to STEs a couple of
times. Please update to e.g. "STE/CD".
Will
_______________________________________________
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 3/6] firmware: arm_scmi: add initial support for i.MX BBM protocol
From: Sudeep Holla @ 2024-04-09 12:52 UTC (permalink / raw)
To: Peng Fan
Cc: Peng Fan (OSS), Cristian Marussi, Sudeep Holla, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <AS1PR04MB9431F99D49D6A777B09814FB88072@AS1PR04MB9431.eurprd04.prod.outlook.com>
On Tue, Apr 09, 2024 at 11:19:31AM +0000, Peng Fan wrote:
>
> ok, will add more comment in the patch for the commands.
>
No I meant add document/description similar to SCMI spec for each of these
commands. Not just one line comment. For std protocols, we can refer spec,
for these vendor protocols, just one like comment will not suffice. Describe
in more details and hence the request for separate TXT file for that.
Hope that is clear now, I have mentioned it several times already.
--
Regards,
Sudeep
_______________________________________________
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