* Re: [PATCH 3/4] PM: EM: Add em_dev_update_chip_binning()
From: Lukasz Luba @ 2024-03-22 10:26 UTC (permalink / raw)
To: Christian Loehle
Cc: dietmar.eggemann, linux-pm, linux-kernel, linux-arm-kernel, sboyd,
nm, linux-samsung-soc, daniel.lezcano, rafael, viresh.kumar,
krzysztof.kozlowski, alim.akhtar, m.szyprowski, mhiramat
In-Reply-To: <aefbb61c-8e15-4e40-9459-30bbbcb8d6f5@arm.com>
Hi Christian,
On 3/14/24 14:32, Christian Loehle wrote:
> On 14/03/2024 14:04, Lukasz Luba wrote:
>> Add a function which allows to modify easily the EM after the new voltage
>> information is available. The device drivers for the chip can adjust
>> the voltage values after setup. The voltage for the same frequency in OPP
>> can be different due to chip binning. The voltage impacts the power usage
>> and the EM power values can be updated to reflect that.
>>
>> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
>> ---
>> include/linux/energy_model.h | 5 ++++
>> kernel/power/energy_model.c | 51 ++++++++++++++++++++++++++++++++++++
>> 2 files changed, 56 insertions(+)
>>
>> diff --git a/include/linux/energy_model.h b/include/linux/energy_model.h
>> index 770755df852f1..d30d67c2f07cf 100644
>> --- a/include/linux/energy_model.h
>> +++ b/include/linux/energy_model.h
>> @@ -172,6 +172,7 @@ struct em_perf_table __rcu *em_table_alloc(struct em_perf_domain *pd);
>> void em_table_free(struct em_perf_table __rcu *table);
>> int em_dev_compute_costs(struct device *dev, struct em_perf_state *table,
>> int nr_states);
>> +int em_dev_update_chip_binning(struct device *dev);
>>
>> /**
>> * em_pd_get_efficient_state() - Get an efficient performance state from the EM
>> @@ -387,6 +388,10 @@ int em_dev_compute_costs(struct device *dev, struct em_perf_state *table,
>> {
>> return -EINVAL;
>> }
>> +static inline int em_dev_update_chip_binning(struct device *dev)
>> +{
>> + return -EINVAL;
>> +}
>> #endif
>>
>> #endif
>> diff --git a/kernel/power/energy_model.c b/kernel/power/energy_model.c
>> index 6960dd7393b2d..1494a909844a4 100644
>> --- a/kernel/power/energy_model.c
>> +++ b/kernel/power/energy_model.c
>> @@ -808,3 +808,54 @@ static void em_update_workfn(struct work_struct *work)
>> {
>> em_check_capacity_update();
>> }
>> +
>> +/**
>> + * em_dev_update_chip_binning() - Update Energy Model with new values after
>> + * the new voltage information is present in the OPPs.
>> + * @dev : Device for which the Energy Model has to be updated.
>> + *
>> + * This function allows to update easily the EM with new values available in
>> + * the OPP framework and DT. It can be used after the chip has been properly
>> + * verified by device drivers and the voltages adjusted for the 'chip binning'.
>> + * It uses the "dynamic-power-coefficient" DT property to calculate the power
>> + * values for EM. For power calculation it uses the new adjusted voltage
>> + * values known for OPPs, which might be changed after boot.
>> + */
>> +int em_dev_update_chip_binning(struct device *dev)
>> +{
>> + struct em_perf_table __rcu *em_table;
>> + struct em_perf_domain *pd;
>> + int i, ret;
>> +
>> + if (IS_ERR_OR_NULL(dev))
>> + return -EINVAL;
>> +
>> + pd = em_pd_get(dev);
>> + if (!pd) {
>> + dev_warn(dev, "Couldn't find Energy Model %d\n", ret);
>
> ret is uninitialized at this point, I guess just
> + dev_warn(dev, "Couldn't find Energy Model\n");
> already contains everything relevant.
>
Good catch, thanks! Yes, I agree it contains enough. I'm going
to send v2 with this.
Regards,
Lukasz
_______________________________________________
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/4] dt-bindings: arm: qcom,coresight-funnel: Add label for multi-ouput
From: Tingwei Zhang @ 2024-03-22 10:22 UTC (permalink / raw)
To: Suzuki K Poulose, Rob Herring, Tao Zhang
Cc: Mathieu Poirier, Alexander Shishkin, Konrad Dybcio, Mike Leach,
Krzysztof Kozlowski, Jinlong Mao, Leo Yan, Greg Kroah-Hartman,
coresight, linux-arm-kernel, linux-kernel, devicetree,
Yuanfang Zhang, Trilok Soni, Song Chai, linux-arm-msm, andersson
In-Reply-To: <77fd8549-5e69-42a8-9e35-5d3de56a490f@arm.com>
On 3/22/2024 5:42 PM, Suzuki K Poulose wrote:
> On 22/03/2024 07:02, Tingwei Zhang wrote:
>> On 3/21/2024 10:42 PM, Rob Herring wrote:
>>> On Thu, Mar 21, 2024 at 04:32:04PM +0800, Tao Zhang wrote:
>>>> Add new property "label" to label the source corresponding to the
>>>> output connection. When the funnel supports multi-output, this
>>>> property needs to be introduced to mark which source component a
>>>> certain output connection corresponds to.
>>>>
>>>> Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
>>>> ---
>>>> .../arm/arm,coresight-dynamic-funnel.yaml | 34
>>>> ++++++++++++++++---
>>>> 1 file changed, 30 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git
>>>> a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>>>> index 44a1041cb0fc..cde62c286d29 100644
>>>> ---
>>>> a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>>>> +++
>>>> b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>>>> @@ -66,13 +66,39 @@ properties:
>>>> $ref: /schemas/graph.yaml#/properties/port
>>>> out-ports:
>>>> - $ref: /schemas/graph.yaml#/properties/ports
>>>> - additionalProperties: false
>>>> -
>>>> + type: object
>>>> properties:
>>>> + "#address-cells":
>>>> + const: 1
>>>> +
>>>> + "#size-cells":
>>>> + const: 0
>>>> +
>>>> port:
>>>> + type: object
>>>> +
>>>> + patternProperties:
>>>> + '^port(@[0-7])?$':
>>>> + type: object
>>>> description: Output connection to CoreSight Trace bus
>>>> - $ref: /schemas/graph.yaml#/properties/port
>>>
>>> Nope, now you have no constraints on port node properties. Please look
>>> at how other bindings are done to add properties on endpoint node.
>>>
>> Thanks for pointing this out, Rob. Shall we ref port-base and
>> endpoint-base then add new properties on endpoint? In this way, the
>> redundant code from port schema is not required.
>>>> +
>>>> + patternProperties:
>>>> + "^endpoint(@[0-9a-f]+)?$":
>>>> + type: object
>>>> + properties:
>>>> + remote-endpoint:
>>>> + description: |
>>>> + phandle to an 'endpoint' subnode of a remote
>>>> device node.
>>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>>
>>> Don't need this.
>>>
>>>> + label:
>>>> + description: Label the source corresponding to the
>>>> output connection
>>>> + $ref: /schemas/types.yaml#/definitions/string
>>>
>>> label already has a type.
>>>
>>> As this node is an output, aren't you labeling what the destination is,
>>> not the "source"?
>>>
>>> Why can't you look at the remote connection to identify what it is?
>>>
>> This funnel can route data stream from different trace source to
>> different output ports. This lable property is added to describe which
>> source is routed to this output port.
>>
>> For example, the graph is as below. Funnel3 routes trace data from
>> TPDM0 to output[0] and output[0] of funnel3 is connected to input[0]
>> of TPDA0.
>
> Funnel3 and Funnel4 are really Replicators ! How are they Funnels ?
> Again, my question still stands. Are Funnel(Replicator-renamed)3/4 and
> Funnel 0/1/2 programmable ?
Sorry for oversimplied the topology. Funnel3 and Funnel4 have multiple
input ports instead of just one input port. It can have multiple input
ports and multiple output ports. Unlike replicator, it won't replicate
same data trace to all the outputs.
Funnel3/funnel4 has same programing capability like standard coresight
funnel. It can enable input ports as requested. It can not be programed
to route which source to which output ports. Hardware staticlly defined
which source is routed to which output.
>
> Suzuki
>
>
>> While Funnels routes trace data from TPDM1 to output[1] which connects
>> to input[1] of TPDA0. Hope that clarifies this a little bit.
>>
>> |---------| |---------| |---------| |---------| |---------|
>> | TPDM0 | | TPDM1 | | TPDM2 | | TPDM3 | | TPDM4 |
>> |---------| |---------| |---------| |---------| |---------|
>> | | | | |
>> | | | | |
>> | | | | |
>> |-----| |-----| |-----| |-----| |
>> | | | | |
>> | | | | |
>> [0]| |[1] [0]| |[1] |
>> \-------------/ \-------------/ \------------/
>> \ FUNNEL0 / \ FUNNEL1 / \ FUNNEL2 /
>> ----------- ----------- -----------
>> | | |
>> \-------------/ \-------------/ |
>> \ FUNNEL3 / \ FUNNEL4 / |
>> ----------- ----------- |
>> | | | |
>> [0]| |[1] [0]| |[1] |
>> | |---------- | | |
>> | | | | |
>> |-------| | |------- | | |--------- |
>> | | | | |
>> | | | | |
>> [0]| |[1] |[2] |[3] |[4]
>> \ ---------------------------------------------------/
>> \ TPDA0 /
>> \ /
>> ------------------------------------------------
>>
>>>
>>>> + oneOf:
>>>> + - required:
>>>> + - port
>>>> + - required:
>>>> + - "#address-cells"
>>>> + - "#size-cells"
>>>
>>> The common schema that you removed handles this.
>>>
>>> Rob
>>
>
--
Thanks,
Tingwei
_______________________________________________
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 v3 1/5] arm64: mm: swap: support THP_SWAP on hardware with MTE
From: Ryan Roberts @ 2024-03-22 10:19 UTC (permalink / raw)
To: Barry Song
Cc: akpm, linux-mm, chengming.zhou, chrisl, david, hannes, kasong,
linux-arm-kernel, linux-kernel, mhocko, nphamcs, shy828301,
steven.price, surenb, wangkefeng.wang, willy, xiang, ying.huang,
yosryahmed, yuzhao, Barry Song, Catalin Marinas, Will Deacon,
Mark Rutland, Kemeng Shi, Anshuman Khandual, Peter Collingbourne,
Peter Xu, Lorenzo Stoakes, Mike Rapoport (IBM), Hugh Dickins,
Aneesh Kumar K.V, Rick Edgecombe
In-Reply-To: <CAGsJ_4wRNRbdXGV-2LUNNP2Dgi6JZ4fZbC2VGPS4ui8HdvuxnQ@mail.gmail.com>
On 22/03/2024 07:41, Barry Song wrote:
> On Fri, Mar 22, 2024 at 3:51 PM Barry Song <21cnbao@gmail.com> wrote:
>>
>> On Thu, Mar 21, 2024 at 11:31 PM Ryan Roberts <ryan.roberts@arm.com> wrote:
>>>
>>> On 21/03/2024 08:42, Barry Song wrote:
>>>> Hi Ryan,
>>>> Sorry for the late reply.
>>>
>>> No problem!
>>>
>>>>
>>>> On Tue, Mar 12, 2024 at 5:56 AM Ryan Roberts <ryan.roberts@arm.com> wrote:
>>>>>
>>>>> On 04/03/2024 08:13, Barry Song wrote:
>>>>>> From: Barry Song <v-songbaohua@oppo.com>
>>>>>>
>>>>>> Commit d0637c505f8a1 ("arm64: enable THP_SWAP for arm64") brings up
>>>>>> THP_SWAP on ARM64, but it doesn't enable THP_SWP on hardware with
>>>>>> MTE as the MTE code works with the assumption tags save/restore is
>>>>>> always handling a folio with only one page.
>>>>>>
>>>>>> The limitation should be removed as more and more ARM64 SoCs have
>>>>>> this feature. Co-existence of MTE and THP_SWAP becomes more and
>>>>>> more important.
>>>>>>
>>>>>> This patch makes MTE tags saving support large folios, then we don't
>>>>>> need to split large folios into base pages for swapping out on ARM64
>>>>>> SoCs with MTE any more.
>>>>>>
>>>>>> arch_prepare_to_swap() should take folio rather than page as parameter
>>>>>> because we support THP swap-out as a whole. It saves tags for all
>>>>>> pages in a large folio.
>>>>>>
>>>>>> As now we are restoring tags based-on folio, in arch_swap_restore(),
>>>>>> we may increase some extra loops and early-exitings while refaulting
>>>>>> a large folio which is still in swapcache in do_swap_page(). In case
>>>>>> a large folio has nr pages, do_swap_page() will only set the PTE of
>>>>>> the particular page which is causing the page fault.
>>>>>> Thus do_swap_page() runs nr times, and each time, arch_swap_restore()
>>>>>> will loop nr times for those subpages in the folio. So right now the
>>>>>> algorithmic complexity becomes O(nr^2).
>>>>>>
>>>>>> Once we support mapping large folios in do_swap_page(), extra loops
>>>>>> and early-exitings will decrease while not being completely removed
>>>>>> as a large folio might get partially tagged in corner cases such as,
>>>>>> 1. a large folio in swapcache can be partially unmapped, thus, MTE
>>>>>> tags for the unmapped pages will be invalidated;
>>>>>> 2. users might use mprotect() to set MTEs on a part of a large folio.
>>>>>>
>>>>>> arch_thp_swp_supported() is dropped since ARM64 MTE was the only one
>>>>>> who needed it.
>>>
>>> I think we should decouple this patch from your swap-in series. I suspect this
>>> one could be ready and go in sooner than the swap-in series based on the current
>>> discussions :)
>>>
>>>>>>
>>>>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>>>>> Cc: Will Deacon <will@kernel.org>
>>>>>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>>>>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>>>>> Cc: David Hildenbrand <david@redhat.com>
>>>>>> Cc: Kemeng Shi <shikemeng@huaweicloud.com>
>>>>>> Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>>>>>> Cc: Anshuman Khandual <anshuman.khandual@arm.com>
>>>>>> Cc: Peter Collingbourne <pcc@google.com>
>>>>>> Cc: Steven Price <steven.price@arm.com>
>>>>>> Cc: Yosry Ahmed <yosryahmed@google.com>
>>>>>> Cc: Peter Xu <peterx@redhat.com>
>>>>>> Cc: Lorenzo Stoakes <lstoakes@gmail.com>
>>>>>> Cc: "Mike Rapoport (IBM)" <rppt@kernel.org>
>>>>>> Cc: Hugh Dickins <hughd@google.com>
>>>>>> CC: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>
>>>>>> Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
>>>>>> Signed-off-by: Barry Song <v-songbaohua@oppo.com>
>>>>>> Reviewed-by: Steven Price <steven.price@arm.com>
>>>>>> Acked-by: Chris Li <chrisl@kernel.org>
>>>>>> ---
>>>>>> arch/arm64/include/asm/pgtable.h | 19 ++------------
>>>>>> arch/arm64/mm/mteswap.c | 43 ++++++++++++++++++++++++++++++++
>>>>>> include/linux/huge_mm.h | 12 ---------
>>>>>> include/linux/pgtable.h | 2 +-
>>>>>> mm/page_io.c | 2 +-
>>>>>> mm/swap_slots.c | 2 +-
>>>>>> 6 files changed, 48 insertions(+), 32 deletions(-)
>>>>>>
>>>>>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>>>>>> index 401087e8a43d..7a54750770b8 100644
>>>>>> --- a/arch/arm64/include/asm/pgtable.h
>>>>>> +++ b/arch/arm64/include/asm/pgtable.h
>>>>>> @@ -45,12 +45,6 @@
>>>>>> __flush_tlb_range(vma, addr, end, PUD_SIZE, false, 1)
>>>>>> #endif /* CONFIG_TRANSPARENT_HUGEPAGE */
>>>>>>
>>>>>> -static inline bool arch_thp_swp_supported(void)
>>>>>> -{
>>>>>> - return !system_supports_mte();
>>>>>> -}
>>>>>> -#define arch_thp_swp_supported arch_thp_swp_supported
>>>>>> -
>>>>>> /*
>>>>>> * Outside of a few very special situations (e.g. hibernation), we always
>>>>>> * use broadcast TLB invalidation instructions, therefore a spurious page
>>>>>> @@ -1095,12 +1089,7 @@ static inline pmd_t pmdp_establish(struct vm_area_struct *vma,
>>>>>> #ifdef CONFIG_ARM64_MTE
>>>>>>
>>>>>> #define __HAVE_ARCH_PREPARE_TO_SWAP
>>>>>> -static inline int arch_prepare_to_swap(struct page *page)
>>>>>> -{
>>>>>> - if (system_supports_mte())
>>>>>> - return mte_save_tags(page);
>>>>>> - return 0;
>>>>>> -}
>>>>>> +extern int arch_prepare_to_swap(struct folio *folio);
>>>>>>
>>>>>> #define __HAVE_ARCH_SWAP_INVALIDATE
>>>>>> static inline void arch_swap_invalidate_page(int type, pgoff_t offset)
>>>>>> @@ -1116,11 +1105,7 @@ static inline void arch_swap_invalidate_area(int type)
>>>>>> }
>>>>>>
>>>>>> #define __HAVE_ARCH_SWAP_RESTORE
>>>>>> -static inline void arch_swap_restore(swp_entry_t entry, struct folio *folio)
>>>>>> -{
>>>>>> - if (system_supports_mte())
>>>>>> - mte_restore_tags(entry, &folio->page);
>>>>>> -}
>>>>>> +extern void arch_swap_restore(swp_entry_t entry, struct folio *folio);
>>>>>>
>>>>>> #endif /* CONFIG_ARM64_MTE */
>>>>>>
>>>>>> diff --git a/arch/arm64/mm/mteswap.c b/arch/arm64/mm/mteswap.c
>>>>>> index a31833e3ddc5..295836fef620 100644
>>>>>> --- a/arch/arm64/mm/mteswap.c
>>>>>> +++ b/arch/arm64/mm/mteswap.c
>>>>>> @@ -68,6 +68,13 @@ void mte_invalidate_tags(int type, pgoff_t offset)
>>>>>> mte_free_tag_storage(tags);
>>>>>> }
>>>>>>
>>>>>> +static inline void __mte_invalidate_tags(struct page *page)
>>>>>> +{
>>>>>> + swp_entry_t entry = page_swap_entry(page);
>>>>>> +
>>>>>> + mte_invalidate_tags(swp_type(entry), swp_offset(entry));
>>>>>> +}
>>>>>> +
>>>>>> void mte_invalidate_tags_area(int type)
>>>>>> {
>>>>>> swp_entry_t entry = swp_entry(type, 0);
>>>>>> @@ -83,3 +90,39 @@ void mte_invalidate_tags_area(int type)
>>>>>> }
>>>>>> xa_unlock(&mte_pages);
>>>>>> }
>>>>>> +
>>>>>> +int arch_prepare_to_swap(struct folio *folio)
>>>>>> +{
>>>>>> + long i, nr;
>>>>>> + int err;
>>>>>> +
>>>>>> + if (!system_supports_mte())
>>>>>> + return 0;
>>>>>> +
>>>>>> + nr = folio_nr_pages(folio);
>>>>>> +
>>>>>> + for (i = 0; i < nr; i++) {
>>>>>> + err = mte_save_tags(folio_page(folio, i));
>>>>>> + if (err)
>>>>>> + goto out;
>>>>>> + }
>>>>>> + return 0;
>>>>>> +
>>>>>> +out:
>>>>>> + while (i--)
>>>>>> + __mte_invalidate_tags(folio_page(folio, i));
>>>>>> + return err;
>>>>>> +}
>>>>>> +
>>>>>> +void arch_swap_restore(swp_entry_t entry, struct folio *folio)
>>>>>
>>>>> I'm still not a fan of the fact that entry could be anywhere within folio.
>>>>>
>>>>>> +{
>>>>>> + if (system_supports_mte()) {
>>>>>
>>>>> nit: if you do:
>>>>>
>>>>> if (!system_supports_mte())
>>>>> return;
>>>>
>>>> Acked
>>>>
>>>>>
>>>>> It will be consistent with arch_prepare_to_swap() and reduce the indentation of
>>>>> the main body.
>>>>>
>>>>>> + long i, nr = folio_nr_pages(folio);
>>>>>> +
>>>>>> + entry.val -= swp_offset(entry) & (nr - 1);
>>>>>
>>>>> This assumes that folios are always stored in swap with natural alignment. Is
>>>>> that definitely a safe assumption? My swap-out series is currently ensuring that
>>>>> folios are swapped-out naturally aligned, but that is an implementation detail.
>>>>>
>>>>
>>>> I concur that this is an implementation detail. However, we should be
>>>> bold enough
>>>> to state that swap slots will be contiguous, considering we are
>>>> currently utilizing
>>>> folio->swap instead of subpage->swap ?
>>>
>>> Yes, I agree about contiguity. My objection is about assuming natural alignment
>>> though. It can still be contiguous while not naturally aligned in swap.
>>
>> Hi Ryan,
>>
>> While working on the new version of this patch, I've come to recognize
>> that, for the time being, it's
>> imperative to maintain a natural alignment. The following code
>> operates on the basis of this
>> assumption.
>>
>> /**
>> * folio_file_page - The page for a particular index.
>> * @folio: The folio which contains this index.
>> * @index: The index we want to look up.
>> *
>> * Sometimes after looking up a folio in the page cache, we need to
>> * obtain the specific page for an index (eg a page fault).
>> *
>> * Return: The page containing the file data for this index.
>> */
>> static inline struct page *folio_file_page(struct folio *folio, pgoff_t index)
>> {
>> return folio_page(folio, index & (folio_nr_pages(folio) - 1));
>> }
>>
>>
>> It's invoked everywhere, particularly within do_swap_page(). Nonetheless,
>> I remain confident that I can consistently pass the first entry to
>> arch_swap_restore().
>
> After grappling for a couple of hours, I've realized that the only
> viable approach
> is as follows: shifting the task of obtaining the first entry from the
> callee to the
> callers( looks silly). This is necessary due to various scenarios like
> swap cache,
> non-swap cache, and KSM, each presenting different cases. Since there's no
> assurance of folio->swap being present, forcibly setting folio->swap could pose
> risks (There might not even be any risk involved, but the associated
> task getting
> the first entry still cannot be overlooked by callers).
>
> diff --git a/mm/internal.h b/mm/internal.h
> index 7e486f2c502c..94d5b4b5a5da 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -76,6 +76,20 @@ static inline int folio_nr_pages_mapped(struct folio *folio)
> return atomic_read(&folio->_nr_pages_mapped) & FOLIO_PAGES_MAPPED;
> }
>
> +/*
> + * Retrieve the first entry of a folio based on a provided entry within the
> + * folio. We cannot rely on folio->swap as there is no guarantee that it has
> + * been initialized. Used by arch_swap_restore()
> + */
> +static inline swp_entry_t folio_swap(swp_entry_t entry, struct folio *folio)
> +{
> + swp_entry_t swap = {
> + .val = entry.val & (folio_nr_pages(folio) - 1),
> + };
> +
> + return swap;
> +}
> +
> static inline void *folio_raw_mapping(struct folio *folio)
> {
> unsigned long mapping = (unsigned long)folio->mapping;
> diff --git a/mm/memory.c b/mm/memory.c
> index f2bc6dd15eb8..b7cab8be8632 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4188,7 +4188,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> * when reading from swap. This metadata may be indexed by swap entry
> * so this must be called before swap_free().
> */
> - arch_swap_restore(entry, folio);
> + arch_swap_restore(folio_swap(entry, folio), folio);
>
> /*
> * Remove the swap entry and conditionally try to free up the swapcache.
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 0aad0d9a621b..82c9df4628f2 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -1913,7 +1913,7 @@ static int shmem_swapin_folio(struct inode
> *inode, pgoff_t index,
> * Some architectures may have to restore extra metadata to the
> * folio after reading from swap.
> */
> - arch_swap_restore(swap, folio);
> + arch_swap_restore(folio_swap(entry, folio), folio);
>
> if (shmem_should_replace_folio(folio, gfp)) {
> error = shmem_replace_folio(&folio, gfp, info, index);
> diff --git a/mm/swapfile.c b/mm/swapfile.c
> index 4919423cce76..5e6d2304a2a4 100644
> --- a/mm/swapfile.c
> +++ b/mm/swapfile.c
> @@ -1806,7 +1806,7 @@ static int unuse_pte(struct vm_area_struct *vma,
> pmd_t *pmd,
> * when reading from swap. This metadata may be indexed by swap entry
> * so this must be called before swap_free().
> */
> - arch_swap_restore(entry, folio);
> + arch_swap_restore(folio_swap(entry, folio), folio);
>
> dec_mm_counter(vma->vm_mm, MM_SWAPENTS);
> inc_mm_counter(vma->vm_mm, MM_ANONPAGES);
>
>
> Meanwhile, natural alignment is essential even during the execution of
> add_to_swap(), as failure to
> do so will trigger the VM_BUG_ON condition below.
>
> int add_to_swap_cache(struct folio *folio, swp_entry_t entry,
> gfp_t gfp, void **shadowp)
> {
> struct address_space *address_space = swap_address_space(entry);
> pgoff_t idx = swp_offset(entry);
> XA_STATE_ORDER(xas, &address_space->i_pages, idx, folio_order(folio));
> unsigned long i, nr = folio_nr_pages(folio);
> ...
> folio_set_swapcache(folio);
> folio->swap = entry;
>
> do {
> xas_lock_irq(&xas);
> xas_create_range(&xas);
> if (xas_error(&xas))
> goto unlock;
> for (i = 0; i < nr; i++) {
> VM_BUG_ON_FOLIO(xas.xa_index != idx + i, folio);
> if (shadowp) {
> old = xas_load(&xas);
> if (xa_is_value(old))
> *shadowp = old;
> }
> xas_store(&xas, folio);
> xas_next(&xas);
> }
> }
>
>
> Based on the information provided, Ryan, would it be feasible to retain the task
> of obtaining the first entry within the callee? Or, are you in favor
> of utilizing the
> new folio_swap() helper?
My opinion still remains that either:
- This should be a per-page interface - i.e. call it for each page to restore
tags. If we don't want to pass `struct page *` then perhaps we can pass a folio
and the index of the page we want to restore? In this case, entry refers the the
precise page we are operating on.
OR
- Make it a per-folio interface - i.e. it restores tags for all pages in the
folio. But in this case, entry must refer to the first page in the folio.
Anything else is confusing.
So if going for the latter approach, then I vote for fixing it up in the callee.
But I'm just one guy with one opinion!
>
>>
>>>
>>>>
>>>>> Your cover note for swap-in says that you could technically swap in a large
>>>>> folio without it having been swapped-out large. If you chose to do that in
>>>>> future, this would break, right? I don't think it's good to couple the swap
>>>>
>>>> Right. technically I agree. Given that we still have many tasks involving even
>>>> swapping in contiguous swap slots, it's unlikely that swapping in large folios
>>>> for non-contiguous entries will occur in the foreseeable future :-)
>>>>
>>>>> storage layout to the folio order that you want to swap into. Perhaps that's an
>>>>> argument for passing each *page* to this function with its exact, corresponding
>>>>> swap entry?
>>>>
>>>> I recall Matthew Wilcox strongly objected to using "page" as the
>>>> parameter, so I've
>>>> discarded that approach. Alternatively, it appears I can consistently pass
>>>> folio->swap to this function and ensure the function always retrieves
>>>> the first entry?
>>>
>>> Yes, if we must pass a folio here, I'd prefer that entry always corresponds to
>>> the first entry for the folio. That will remove the need for this function to do
>>> the alignment above too. So win-win.
>>>
>>>>
>>>>>
>>>>>> + for (i = 0; i < nr; i++) {
>>>>>> + mte_restore_tags(entry, folio_page(folio, i));
>>>>>> + entry.val++;
>>>>>> + }
>>>>>> + }
>>>>>> +}
>>>>>> diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h
>>>>>> index de0c89105076..e04b93c43965 100644
>>>>>> --- a/include/linux/huge_mm.h
>>>>>> +++ b/include/linux/huge_mm.h
>>>>>> @@ -535,16 +535,4 @@ static inline int split_folio_to_order(struct folio *folio, int new_order)
>>>>>> #define split_folio_to_list(f, l) split_folio_to_list_to_order(f, l, 0)
>>>>>> #define split_folio(f) split_folio_to_order(f, 0)
>>>>>>
>>>>>> -/*
>>>>>> - * archs that select ARCH_WANTS_THP_SWAP but don't support THP_SWP due to
>>>>>> - * limitations in the implementation like arm64 MTE can override this to
>>>>>> - * false
>>>>>> - */
>>>>>> -#ifndef arch_thp_swp_supported
>>>>>> -static inline bool arch_thp_swp_supported(void)
>>>>>> -{
>>>>>> - return true;
>>>>>> -}
>>>>>> -#endif
>>>>>> -
>>>>>> #endif /* _LINUX_HUGE_MM_H */
>>>>>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>>>>>> index e1b22903f709..bfcfe3386934 100644
>>>>>> --- a/include/linux/pgtable.h
>>>>>> +++ b/include/linux/pgtable.h
>>>>>> @@ -1106,7 +1106,7 @@ static inline int arch_unmap_one(struct mm_struct *mm,
>>>>>> * prototypes must be defined in the arch-specific asm/pgtable.h file.
>>>>>> */
>>>>>> #ifndef __HAVE_ARCH_PREPARE_TO_SWAP
>>>>>> -static inline int arch_prepare_to_swap(struct page *page)
>>>>>> +static inline int arch_prepare_to_swap(struct folio *folio)
>>>>>> {
>>>>>> return 0;
>>>>>> }
>>>>>> diff --git a/mm/page_io.c b/mm/page_io.c
>>>>>> index ae2b49055e43..a9a7c236aecc 100644
>>>>>> --- a/mm/page_io.c
>>>>>> +++ b/mm/page_io.c
>>>>>> @@ -189,7 +189,7 @@ int swap_writepage(struct page *page, struct writeback_control *wbc)
>>>>>> * Arch code may have to preserve more data than just the page
>>>>>> * contents, e.g. memory tags.
>>>>>> */
>>>>>> - ret = arch_prepare_to_swap(&folio->page);
>>>>>> + ret = arch_prepare_to_swap(folio);
>>>>>> if (ret) {
>>>>>> folio_mark_dirty(folio);
>>>>>> folio_unlock(folio);
>>>>>> diff --git a/mm/swap_slots.c b/mm/swap_slots.c
>>>>>> index 90973ce7881d..53abeaf1371d 100644
>>>>>> --- a/mm/swap_slots.c
>>>>>> +++ b/mm/swap_slots.c
>>>>>> @@ -310,7 +310,7 @@ swp_entry_t folio_alloc_swap(struct folio *folio)
>>>>>> entry.val = 0;
>>>>>>
>>>>>> if (folio_test_large(folio)) {
>>>>>> - if (IS_ENABLED(CONFIG_THP_SWAP) && arch_thp_swp_supported())
>>>>>> + if (IS_ENABLED(CONFIG_THP_SWAP))
>>>>>> get_swap_pages(1, &entry, folio_nr_pages(folio));
>>>>>> goto out;
>>>>>> }
>>>>>
>>>>
>>>> Thanks
>>>> Barry
>>>
_______________________________________________
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 v3 0/5] Add PSCI v1.3 SYSTEM_OFF2 support for hibernation
From: David Woodhouse @ 2024-03-22 10:17 UTC (permalink / raw)
To: Oliver Upton
Cc: linux-arm-kernel, kvm, Paolo Bonzini, Jonathan Corbet,
Marc Zyngier, James Morse, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Mark Rutland, Lorenzo Pieralisi,
Rafael J. Wysocki, Len Brown, Pavel Machek, Mostafa Saleh,
Jean-Philippe Brucker, linux-doc, linux-kernel, kvmarm, linux-pm
In-Reply-To: <Zfnpj2FShq05QZpf@linux.dev>
[-- Attachment #1.1: Type: text/plain, Size: 1155 bytes --]
On Tue, 2024-03-19 at 12:41 -0700, Oliver Upton wrote:
> On Tue, Mar 19, 2024 at 05:14:42PM +0000, David Woodhouse wrote:
> > On Tue, 2024-03-19 at 08:27 -0700, Oliver Upton wrote:
> > > If we're going down the route of having this PSCI call live in KVM, it
> > > really deserves a test. I think you can just pile on the existing
> > > psci_test selftest.
> >
> > Added to
> > https://git.infradead.org/users/dwmw2/linux.git/shortlog/refs/heads/psci-hibernate
> > for next time.
> >
> > From 8c72a78e6179bc8970edc66a85ab6bee26f581fb Mon Sep 17 00:00:00 2001
> > From: David Woodhouse <dwmw@amazon.co.uk>
> > Date: Tue, 19 Mar 2024 17:07:46 +0000
> > Subject: [PATCH 4/8] KVM: selftests: Add test for PSCI SYSTEM_OFF2
> >
> > Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
>
> Looks good, thanks!
Thanks.
Marc, I think I've also addressed your feedback? Is there anything else
to do other than wait for the spec to be published?
Shall I post a v4 with PSCI v1.3 as default and the self-test? Would
you apply that into a branch ready for merging when the spec is ready,
or should I just wait and repost it all then?
[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 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 v5 09/21] drivers: crypto: meson: process more than MAXDESCS descriptors
From: neil.armstrong @ 2024-03-22 10:14 UTC (permalink / raw)
To: Corentin Labbe, Alexey Romanov
Cc: clabbe, herbert, davem, robh+dt, krzysztof.kozlowski+dt, conor+dt,
khilman, jbrunet, martin.blumenstingl, vadim.fedorenko,
linux-crypto, linux-amlogic, linux-kernel, devicetree,
linux-arm-kernel, kernel
In-Reply-To: <Zf1BAlYtiwPOG-Os@Red>
On 22/03/2024 09:27, Corentin Labbe wrote:
> Le Fri, Mar 01, 2024 at 04:29:24PM +0300, Alexey Romanov a écrit :
>> 1. The old alhorithm was not designed to process a large
>> amount of memory, and therefore gave incorrect results.
>>
>> 2. Not all Amlogic SoC's use 3 KEY/IV descriptors.
>> Add keyiv descriptors count parameter to platform data.
>>
>> Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
>> ---
>> drivers/crypto/amlogic/amlogic-gxl-cipher.c | 441 ++++++++++++--------
>> drivers/crypto/amlogic/amlogic-gxl-core.c | 1 +
>> drivers/crypto/amlogic/amlogic-gxl.h | 2 +
>> 3 files changed, 280 insertions(+), 164 deletions(-)
>>
>
> Hello
>
> I have started to test by adding patch one by one and when testing this one I got:
> [ 21.674995] gxl-crypto c883e000.crypto: will run requests pump with realtime priority
> [ 21.679686] gxl-crypto c883e000.crypto: will run requests pump with realtime priority
> [ 21.704366] ------------[ cut here ]------------
> [ 21.704480] DMA-API: gxl-crypto c883e000.crypto: device driver tries to sync DMA memory it has not allocated [device address=0x000000000264c000] [size=48 bytes]
> [ 21.717684] WARNING: CPU: 1 PID: 263 at kernel/dma/debug.c:1105 check_sync+0x1d0/0x688
> [ 21.725512] Modules linked in: meson_rng meson_gxbb_wdt rng_core amlogic_gxl_crypto(+) meson_canvas libphy(+) watchdog ghash_generic gcm xctr xts cts essiv authenc cmac xcbc ccm
> [ 21.741211] CPU: 1 PID: 263 Comm: c883e000.crypto Not tainted 6.8.0-rc1-00052-g595d4248b127 #24
> [ 21.749834] Hardware name: Libre Computer AML-S905X-CC (DT)
> [ 21.755353] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 21.762252] pc : check_sync+0x1d0/0x688
> [ 21.766047] lr : check_sync+0x1d0/0x688
> [ 21.769842] sp : ffff8000820fbb40
> [ 21.773119] x29: ffff8000820fbb40 x28: 0000000000000000 x27: 0000000000000000
> [ 21.780192] x26: ffff800081d639d0 x25: 0000000000001327 x24: ffff00000288b010
> [ 21.787265] x23: 0000000000000050 x22: 0000000000001327 x21: ffff800081c23a20
> [ 21.794336] x20: ffff800080fe0bb8 x19: ffff8000820fbbc0 x18: 0000000000000006
> [ 21.801410] x17: 645b206465746163 x16: 6f6c6c6120746f6e x15: ffff8000820fb540
> [ 21.808482] x14: 000000000000000b x13: ffff800081002748 x12: 0000000000000249
> [ 21.815554] x11: 00000000000000c3 x10: ffff80008105a748 x9 : ffff800081002748
> [ 21.822626] x8 : 00000000ffffefff x7 : ffff80008105a748 x6 : 80000000fffff000
> [ 21.829700] x5 : ffff00007d9abb08 x4 : 0000000000000000 x3 : 0000000000000027
> [ 21.836772] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00000b314ec0
> [ 21.843844] Call trace:
> [ 21.846260] check_sync+0x1d0/0x688
> [ 21.849710] debug_dma_sync_single_for_device+0xb8/0xc0
> [ 21.854885] dma_sync_single_for_device+0xc0/0x11c
> [ 21.859628] meson_handle_cipher_request+0x49c/0x7c4 [amlogic_gxl_crypto]
> [ 21.866356] crypto_pump_work+0x160/0x2ac
> [ 21.870324] kthread_worker_fn+0xe4/0x300
> [ 21.874291] kthread+0x11c/0x120
> [ 21.877483] ret_from_fork+0x10/0x20
> [ 21.881020] irq event stamp: 9880
> [ 21.884296] hardirqs last enabled at (9879): [<ffff800080988834>] _raw_spin_unlock_irqrestore+0x6c/0x70
> [ 21.893698] hardirqs last disabled at (9880): [<ffff800080987ca0>] _raw_spin_lock_irqsave+0x84/0x88
> [ 21.902668] softirqs last enabled at (5638): [<ffff800080010674>] __do_softirq+0x494/0x4dc
> [ 21.910947] softirqs last disabled at (5627): [<ffff8000800161f0>] ____do_softirq+0x10/0x1c
> [ 21.919227] ---[ end trace 0000000000000000 ]---
I confirm I see the same starting with this change with DMA_API_DEBUG=1
[ 4.745240] ------------[ cut here ]------------
[ 4.745295] DMA-API: gxl-crypto c883e000.crypto: device driver tries to sync DMA memory it has not allocated [device address=0x000000000a816030] [size=16 bytes]
[ 4.758496] WARNING: CPU: 3 PID: 75 at kernel/dma/debug.c:1105 check_sync+0x1d8/0x690
[ 4.766242] Modules linked in:
[ 4.769258] CPU: 3 PID: 75 Comm: c883e000.crypto Not tainted 6.8.0-rc6-next-20240229-g99fbe5828431 #167
[ 4.778576] Hardware name: Libre Computer AML-S905X-CC (DT)
[ 4.784094] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 4.790993] pc : check_sync+0x1d8/0x690
[ 4.794786] lr : check_sync+0x1d8/0x690
[ 4.798581] sp : ffff800082563b90
[ 4.801859] x29: ffff800082563b90 x28: ffff8000816ef298 x27: 0000000000000000
[ 4.808934] x26: ffff0000041ed010 x25: 0000000000000018 x24: 0000000000004000
[ 4.816006] x23: ffff8000816d1190 x22: 0000000000004000 x21: ffff800081539b50
[ 4.823079] x20: ffff800082563c40 x19: ffff8000816ef2b0 x18: 0000000000000030
[ 4.830151] x17: 645b206465746163 x16: 6f6c6c6120746f6e x15: 0720072007200720
[ 4.837223] x14: ffff80008154f2c0 x13: 00000000000002a6 x12: 00000000000000e2
[ 4.844296] x11: 0720072007200720 x10: ffff8000815a72c0 x9 : 00000000fffff000
[ 4.851369] x8 : ffff80008154f2c0 x7 : ffff8000815a72c0 x6 : 0000000000000000
[ 4.858441] x5 : 80000000fffff000 x4 : 000000000000aff5 x3 : 0000000000000000
[ 4.865514] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000091a9100
[ 4.872587] Call trace:
[ 4.874999] check_sync+0x1d8/0x690
[ 4.878449] debug_dma_sync_single_for_cpu+0x84/0x8c
[ 4.883366] dma_sync_single_for_cpu+0x58/0x10c
[ 4.887851] meson_handle_cipher_request+0x3b0/0x780
[ 4.892767] crypto_pump_work+0x15c/0x2bc
[ 4.896734] kthread_worker_fn+0xcc/0x184
[ 4.900702] kthread+0x118/0x11c
[ 4.903893] ret_from_fork+0x10/0x20
[ 4.907430] ---[ end trace 0000000000000000 ]---
Thanks,
Neil
>
> Regards
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm64: marvell: add solidrun cn9130 clearfog boards
From: Josua Mayer @ 2024-03-22 10:08 UTC (permalink / raw)
To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: Yazan Shhady, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20240321-cn9130-som-v1-1-711127a409ae@solid-run.com>
Am 21.03.24 um 22:47 schrieb Josua Mayer:
> Add bindings for SolidRun Clearfog boards, using a new SoM based on
> CN9130 SoC.
> The carrier boards are identical to the older Armada 388 based Clearfog
> boards. For consistency the carrier part of compatible strings are
> copied, including the established "-a1" suffix.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> .../devicetree/bindings/arm/marvell/armada-7k-8k.yaml | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> index 16d2e132d3d1..36bdfd1bedd9 100644
> --- a/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> +++ b/Documentation/devicetree/bindings/arm/marvell/armada-7k-8k.yaml
> @@ -82,4 +82,16 @@ properties:
> - const: marvell,armada-ap807-quad
> - const: marvell,armada-ap807
>
> + - description:
> + SolidRun CN9130 clearfog family single-board computers
> + items:
> + - enum:
> + - solidrun,clearfog-base-a1
> + - solidrun,clearfog-pro-a1
> + - const: solidrun,clearfog-a1
> + - const: solidrun,cn9130-sr-som
> + - const: marvell,cn9130
> + - const: marvell,armada-ap807-quad
> + - const: marvell,armada-ap807
> +
> additionalProperties: true
Before merging I would like some feedback about adding
another product later, to ensure the compatibles above
are adequate? In particular:
- sequence of soc, cp, carrier compatibles
- name of som compatible
Draft for future bindings:
- description:
SolidRun CN9130 SoM based single-board computers
with 1 external CP on the Carrier.
items:
- enum:
- solidrun,cn9131-solidwan
- const: marvell,cn9131
- const: solidrun,cn9130-sr-som
- const: marvell,cn9130
- const: marvell,armada-ap807-quad
- const: marvell,armada-ap807
- description:
SolidRun CN9132 COM-Express Type 7 based single-board computers
with 2 external CPs on the COM.
items:
- enum:
- solidrun,cn9132-clearfog
- const: solidrun,cn9132-cex7
- const: marvell,cn9132
- const: marvell,cn9131
- const: marvell,cn9130
- const: marvell,armada-ap807-quad
- const: marvell,armada-ap807
_______________________________________________
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] dt-bindings: iio: adc: nxp,imx93-adc.yaml: Add calibration properties
From: Andrej Picej @ 2024-03-22 9:58 UTC (permalink / raw)
To: Krzysztof Kozlowski, haibo.chen, linux-iio, devicetree
Cc: jic23, lars, shawnguo, s.hauer, kernel, festevam, imx,
linux-arm-kernel, linux-kernel, robh, krzysztof.kozlowski+dt,
conor+dt, upstream
In-Reply-To: <a1b173c0-5120-40f6-9708-cd810b4a2406@linaro.org>
On 22. 03. 24 09:14, Krzysztof Kozlowski wrote:
> On 22/03/2024 08:39, Andrej Picej wrote:
>> On 20. 03. 24 13:15, Krzysztof Kozlowski wrote:
>>> On 20/03/2024 13:05, Andrej Picej wrote:
>>>> Hi Krzysztof,
>>>>
>>>> On 20. 03. 24 11:26, Krzysztof Kozlowski wrote:
>>>>> On 20/03/2024 11:04, Andrej Picej wrote:
>>>>>> Document calibration properties and how to set them.
>>>>>
>>>>> Bindings are before users.
>>>>
>>>> will change patch order when I send a v2.
>>>>
>>>>>
>>>>> Please use subject prefixes matching the subsystem. You can get them for
>>>>> example with `git log --oneline -- DIRECTORY_OR_FILE` on the directory
>>>>> your patch is touching.
>>>>> There is no file extension in prefixes.
>>>>
>>>> So: dt-bindings: iio/adc: nxp,imx93-adc: Add calibration properties?
>>>
>>> Did you run the command I proposed? I don't see much of "/", but except
>>> that looks good.
>>
>> Ok noted.
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>> Signed-off-by: Andrej Picej <andrej.picej@norik.com>
>>>>>> ---
>>>>>> .../bindings/iio/adc/nxp,imx93-adc.yaml | 15 +++++++++++++++
>>>>>> 1 file changed, 15 insertions(+)
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
>>>>>> index dacc526dc695..64958be62a6a 100644
>>>>>> --- a/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
>>>>>> +++ b/Documentation/devicetree/bindings/iio/adc/nxp,imx93-adc.yaml
>>>>>> @@ -46,6 +46,21 @@ properties:
>>>>>> "#io-channel-cells":
>>>>>> const: 1
>>>>>>
>>>>>> + nxp,calib-avg-en:
>>>>>> + description:
>>>>>> + Enable or disable averaging of calibration time.
>>>>>> + enum: [ 0, 1 ]
>>>>>> +
>>>>>> + nxp,calib-nr-samples:
>>>>>> + description:
>>>>>> + Selects the number of averaging samples to be used during calibration.
>>>>>> + enum: [ 16, 32, 128, 512 ]
>>>>>> +
>>>>>> + nxp,calib-t-samples:
>>>>>> + description:
>>>>>> + Specifies the sample time of calibration conversions.
>>>>>> + enum: [ 8, 16, 22, 32 ]
>>>>>
>>>>> No, use existing, generic properties. Open other bindings for this.
>>>>
>>>> You mean I should use generic properties for the ADC calibration
>>>> settings? Is there already something in place? Because as I understand
>>>> it, these calib-* values only effect the calibration process of the ADC.
>>>
>>> Please take a look at other devices and dtschema. We already have some
>>> properties for this... but maybe they cannot be used?
>>>
>>
>> I did look into other ADC devices, grep across iio/adc, adc bindings
>> folders and couldn't find anything closely related to what we are
>> looking for. Could you please point me to the properties that you think
>> should be used for this?
>
> Indeed, there are few device specific like qcom,avg-samples. We have
> though oversampling-ratio, settling-time-us and min-sample-time (which
> is not that good because does not use unit suffix).
Ok, these are examples but I think I should not use them, since these
are i.MX93 ADC specific settings, which are used for configuration of
calibration process, and are not related to the standard conversion
process during runtime. Calibration process is the first step that
should be done after every power-on reset.
>
> Then follow up questions:
> - nxp,calib-avg-en: Why is it a board-level decision? I would assume
> this depends on user choice and what kind of input you have (which could
> be board dependent or could be runtime decision).
Not really sure I get your question, so please elaborate if I missed the
point.
This is a user choice, to enable or disable the averaging function in
calibration, but this is a board-level decision, probably relates on
external ADC regulators and input connections. The same options are used
for every ADC channel and this can not be a runtime decision, since
calibration is done before the ADC is even registered.
> - nxp,calib-t-samples: what does it mean? Time is expressed in time
> units, but there is nothing about units in the property name.
>
You are right, basically this is "time" in cycles of AD_CLK. I should at
least add that to the property description.
Best regards,
Andrej Picej
_______________________________________________
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] arm64: dts: add description for solidrun cn9130 som and clearfog boards
From: Josua Mayer @ 2024-03-22 9:54 UTC (permalink / raw)
To: Andrew Lunn
Cc: Gregory Clement, Sebastian Hesselbarth, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Yazan Shhady,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <e24e78a6-852c-4458-987c-3601908a71f0@lunn.ch>
Am 21.03.24 um 22:59 schrieb Andrew Lunn:
> On Thu, Mar 21, 2024 at 10:47:12PM +0100, Josua Mayer wrote:
>> Add description for the SolidRun CN9130 SoM, and Clearfog Base / Pro
>> reference boards.
>>
>> The SoM has been designed as a pin-compatible replacement for the older
>> Armada 388 based SoM. Therefore it supports the same boards and a
>> similar feature set.
>>
>> Most notable upgrades:
>> - 4x Cortex-A72
>> - 10Gbps SFP
>> - Both eMMC and SD supported at the same time
>>
>> The developer first supporting this product at SolidRun decided to use
>> different filenames for the DTBs: Armada 388 uses the full
>> "clearfog" string while cn9130 uses the abbreviation "cf".
>> This name is already hard-coded in pre-installed vendor u-boot and can
>> not be changed easily.
>>
>> NOTICE IN CASE ANYBODY WANTS TO SELF-UPGRADE:
>> CN9130 SoM has a different footprint from Armada 388 SoM.
>> Components on the carrier board below the SoM may collide causing
>> damage, such as on Clearfog Base.
>>
>> Signed-off-by: Josua Mayer <josua@solid-run.com>
>> ---
>> arch/arm64/boot/dts/marvell/Makefile | 2 +
>> arch/arm64/boot/dts/marvell/cn9130-cf-base.dts | 138 ++++++++++++++
>> arch/arm64/boot/dts/marvell/cn9130-cf-pro.dts | 249 +++++++++++++++++++++++++
>> arch/arm64/boot/dts/marvell/cn9130-cf.dtsi | 198 ++++++++++++++++++++
>> arch/arm64/boot/dts/marvell/cn9130-sr-som.dtsi | 160 ++++++++++++++++
>> 5 files changed, 747 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/marvell/Makefile b/arch/arm64/boot/dts/marvell/Makefile
>> index 99b8cb3c49e1..019f2251d696 100644
>> --- a/arch/arm64/boot/dts/marvell/Makefile
>> +++ b/arch/arm64/boot/dts/marvell/Makefile
>> @@ -28,3 +28,5 @@ dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-A.dtb
>> dtb-$(CONFIG_ARCH_MVEBU) += cn9130-crb-B.dtb
>> dtb-$(CONFIG_ARCH_MVEBU) += ac5x-rd-carrier-cn9131.dtb
>> dtb-$(CONFIG_ARCH_MVEBU) += ac5-98dx35xx-rd.dtb
>> +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-base.dtb
>> +dtb-$(CONFIG_ARCH_MVEBU) += cn9130-cf-pro.dtb
>> diff --git a/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts
>> new file mode 100644
>> index 000000000000..b0067940d5e4
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/marvell/cn9130-cf-base.dts
>> @@ -0,0 +1,138 @@
>> +// SPDX-License-Identifier: GPL-2.0+
>> +/*
>> + * Copyright (C) 2024 Josua Mayer <josua@solid-run.com>
>> + *
>> + * DTS for SolidRun CN9130 Clearfog Base.
>> + *
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include <dt-bindings/input/input.h>
>> +
>> +#include "cn9130.dtsi"
>> +#include "cn9130-sr-som.dtsi"
>> +#include "cn9130-cf.dtsi"
>> +
>> +/ {
>> + model = "SolidRun CN9130 Clearfog Base";
>> + compatible = "solidrun,clearfog-base-a1", "solidrun,clearfog-a1",
>> + "solidrun,cn9130-sr-som","marvell,cn9130",
>> + "marvell,armada-ap807-quad", "marvell,armada-ap807";
>> +
>> + gpio-keys {
>> + compatible = "gpio-keys";
>> + pinctrl-0 = <&rear_button_pins>;
>> + pinctrl-names = "default";
>> +
>> + button-0 {
>> + /* The rear SW3 button */
>> + label = "Rear Button";
>> + gpios = <&cp0_gpio1 31 GPIO_ACTIVE_LOW>;
>> + linux,can-disable;
>> + linux,code = <BTN_0>;
>> + };
>> + };
>> +
>> + rfkill-m2-gnss {
>> + compatible = "rfkill-gpio";
>> + label = "m.2 GNSS";
>> + radio-type = "gps";
>> + /* rfkill-gpio inverts internally */
>> + shutdown-gpios = <&expander0 9 GPIO_ACTIVE_HIGH>;
>> + };
>> +
>> + /* M.2 is B-keyed, so w-disable is for WWAN */
>> + rfkill-m2-wwan {
>> + compatible = "rfkill-gpio";
>> + label = "m.2 WWAN";
>> + radio-type = "wwan";
>> + /* rfkill-gpio inverts internally */
>> + shutdown-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>;
>> + };
>> +};
>> +
>> +/* SRDS #3 - SGMII 1GE */
>> +&cp0_eth1 {
>> + phy = <&phy1>;
>> + phys = <&cp0_comphy3 1>;
>> + phy-mode = "sgmii";
>> + status = "okay";
>> +};
>> +
>> +&cp0_eth2_phy {
>> + /*
>> + * Configure LEDs:
>> + * - LED[0]: link/activity: On/blink (green)
>> + * - LED[1]: link is 100/1000Mbps: On (yellow)
>> + * - LED[2]: high impedance (floating)
>> + */
>> + marvell,reg-init = <3 16 0xf000 0x0a61>;
> Sorry, but no. List the LEDs in the PHY node, and they can then be
> controlled via /sys/class/leds.
May I ask more precisely the motivation?
Does this replace the phy's builtin automatic led control?
> arch/arm/boot/dts/marvell/armada-370-rd.dts is an example.
I will investigate it.
My main motivation for tweaking the led controls was to make them all consistent across the two boards:
- LEDs under control of PHYs on cpu mdio bus
- LEDs under control of ethernet switch on mdio bus
- LEDs under control of ethernet phy on external mdio bus behind ethernet switch
It looks as if the marvell phy driver supports led subnodes,
The switch driver does not.
Finally one phy can only be written to but not read,
the cpu can never know its link state.
So I prefer (for the Clearfog Pro) board to explicitly use the phys
autonomous management of LEDs.
Is that still possible if I added led subnodes?
_______________________________________________
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] ARM: unwind: improve unwinders for noreturn case
From: Russell King (Oracle) @ 2024-03-22 9:52 UTC (permalink / raw)
To: David Laight
Cc: Ard Biesheuvel, Jiangfeng Xiao, arnd@arndb.de,
keescook@chromium.org, haibo.li@mediatek.com,
angelogioacchino.delregno@collabora.com, amergnat@baylibre.com,
akpm@linux-foundation.org, dave.hansen@linux.intel.com,
douzhaolei@huawei.com, gustavoars@kernel.org, jpoimboe@kernel.org,
kepler.chenxin@huawei.com, kirill.shutemov@linux.intel.com,
linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
nixiaoming@huawei.com, peterz@infradead.org, wangbing6@huawei.com,
wangfangpeng1@huawei.com, jannh@google.com, willy@infradead.org
In-Reply-To: <2b2993fb215c4a5abd7d77ff1c984113@AcuMS.aculab.com>
On Fri, Mar 22, 2024 at 09:24:20AM +0000, David Laight wrote:
> From: Russell King
> > Sent: 22 March 2024 00:09
> >
> > On Thu, Mar 21, 2024 at 11:43:41PM +0100, Ard Biesheuvel wrote:
> > > Given that this particular issue would just disappear if the compiler
> > > would just insert a BRK after the BL, I'd prefer to explore first
> > > whether we can get this fixed on the compiler side.
> >
> > Arm32 doesn't have a BRK instruction. What would be appropriate after
> > the no-return BL would be OS specific.
>
> It would need to depend on what was being compiled.
Yes, but as for the rest...
> For the kernel it could be much the same as BUG().
> (Probably without any extra data.)
> I suspect that arm32 could use 'swi' in kernel space,
> but you wouldn't want to use that in userspace.
>
> Looks like armv5 has a bkpt instruction - could that be used?
> Or does the kernel need to support armv4?
>
> The last arm I wrote anything for was a strongarm.
Thank you David, but remember - I have programmed 32-bit Arm since 1992,
and wrote the majority of the 32-bit Arm kernel support. I think I know
what I'm walking about by now.
The compiler can't do the same as BUG() - that is a kernel specific
construct and not an architecture one. It is an undefined instruction
specifically chosen to be undefined on both 32-bit and 16-bit Arm ISAs.
As for your idea of using "swi" in kernel space, no that's never going
to happen - to shoe-horn that into the SWI exception path for the sake
of the compiler would be totally idiotic - it would cause userspace
performance regressions for something that never happens. Moreover,
with EABI the "comment" field in the "swi" instruction is ignored so
all SWIs under EABI are treated the same. So no, that's not going to
work without causing inefficiencies - again - for a case that will
likely never happen.
Whereas we already provide an abort() function because iirc the
compiler used to emit branches to that due to noreturn functions. If
correct, there's previous convention for doing this - and abort() is
still exists in the kernel and in userspace since it's part of ANSI
C. This would be a more reliable and portable solution, but probably
not for embedded platforms - and that's probably why it got removed.
There isn't going to be a single solution to this which satisfies
everyone, and I don't blame the compiler people for deciding to
basically give up with putting any instruction after a call to a
no-return function - because there isn't an instruction defined in
the architecture that _could_ be put there that would work everywhere.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 3/4] dt-bindings: mmc: fsl-imx-esdhc: add NXP S32G3 support
From: Wadim Mueller @ 2024-03-22 9:45 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Wadim Mueller, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Ulf Hansson, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, NXP Linux Team, Greg Kroah-Hartman, Jiri Slaby,
Chester Lin, Andreas Färber, Matthias Brugger,
NXP S32 Linux Team, Tim Harvey, Marco Felsch, Gregor Herburger,
Marek Vasut, Joao Paulo Goncalves, Markus Niebel,
Matthias Schiffer, Stefan Wahren, Bjorn Helgaas,
Philippe Schenker, Yannic Moog, Li Yang, devicetree, linux-kernel,
linux-mmc, linux-arm-kernel, linux-serial
In-Reply-To: <00174dc3-65a7-4a2e-b48d-a974336a3f18@linaro.org>
On Thu, Mar 21, 2024 at 06:53:34PM +0100, Krzysztof Kozlowski wrote:
> On 21/03/2024 16:41, Wadim Mueller wrote:
> > Add a compatible string for the SDHC binding of NXP S32G3 platforms. Here
> > we use "nxp,s32g2-usdhc" as fallback since the s32g2-usdhc
> > driver works also on S32G3 platforms.
> >
> > Signed-off-by: Wadim Mueller <wafgo01@gmail.com>
> > ---
> > Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> > index 82eb7a24c857..b42b4368fa4e 100644
> > --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> > +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
> > @@ -35,6 +35,7 @@ properties:
> > - fsl,imx8mm-usdhc
> > - fsl,imxrt1050-usdhc
> > - nxp,s32g2-usdhc
> > + - nxp,s32g3-usdhc
> > - items:
> > - const: fsl,imx50-esdhc
> > - const: fsl,imx53-esdhc
> > @@ -90,6 +91,9 @@ properties:
> > - enum:
> > - fsl,imxrt1170-usdhc
> > - const: fsl,imxrt1050-usdhc
> > + - items:
> > + - const: nxp,s32g3-usdhc
> > + - const: nxp,s32g2-usdhc
>
> No, that's just wrong. G3 is not and is compatible with G2? There is no
> dualism here. Either it is or it is not. Not both.
>
I am trying to understand your statement but I am not sure whether I get
it right.
Let me try to explain what I understand is wrong with this patch.
Having nxp,s32g2-usdhc and nxp,s32g2-usdhc in one enum
> > - nxp,s32g2-usdhc
> > + - nxp,s32g3-usdhc
would mean that those are
__not__ compatible with each other, whereas the anouther item
> > + - items:
> > + - const: nxp,s32g3-usdhc
> > + - const: nxp,s32g2-usdhc
>
where both const entries are side by side means that those are compatible. Which is
paradox. Is this undersanding correct?
So if I want to have the follwing im my DTS for the mmc node
usdhc0: mmc@402f0000 {
compatible = "nxp,s32g3-usdhc",
"nxp,s32g2-usdhc";
...
}
The schema update should contain just this part?
i@@ -90,6 +90,9 @@ properties:
- enum:
- fsl,imxrt1170-usdhc
- const: fsl,imxrt1050-usdhc
+ - items:
+ - const: nxp,s32g3-usdhc
+ - const: nxp,s32g2-usdhc
reg:
maxItems: 1
Is this correct?
With this patch in place I dont see any issues with an
"make CHECK_DTBS=y freescale/s32g399a-rdb3.dtb"
as well as "make dt_binding_check dtbs_check" seems to be OK with this.
Thanks for your guidence so far, much appreciated!
Best Regard
Wadim
> Best regards,
> Krzysztof
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 7/9] drm/atomic-helper: Add select_output_bus_format callback
From: Maxime Ripard @ 2024-03-22 9:44 UTC (permalink / raw)
To: Anatoliy Klymenko
Cc: Laurent Pinchart, Maarten Lankhorst, Thomas Zimmermann,
David Airlie, Daniel Vetter, Michal Simek, Andrzej Hajda,
Neil Armstrong, Robert Foss, Jonas Karlman, Jernej Skrabec,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Mauro Carvalho Chehab, Tomi Valkeinen, dri-devel,
linux-arm-kernel, linux-kernel, devicetree, linux-media
In-Reply-To: <20240321-dp-live-fmt-v3-7-d5090d796b7e@amd.com>
[-- Attachment #1.1: Type: text/plain, Size: 1982 bytes --]
On Thu, Mar 21, 2024 at 01:43:45PM -0700, Anatoliy Klymenko wrote:
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
> index 2dafc39a27cb..f2e12a3c4e5f 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -1055,3 +1055,39 @@ int drm_helper_force_disable_all(struct drm_device *dev)
> return ret;
> }
> EXPORT_SYMBOL(drm_helper_force_disable_all);
> +
> +/**
> + * drm_helper_crtc_select_output_bus_format - Select output media bus format
> + * @crtc: The CRTC to query
> + * @crtc_state: The new CRTC state
> + * @supported_fmts: List of media bus format options to pick from
> + * @num_supported_fmts: Number of media bus formats in @supported_fmts list
> + *
> + * Encoder drivers may call this helper to give the connected CRTC a chance to
> + * select compatible or preffered media bus format to use over the CRTC encoder
> + * link. Encoders should provide list of supported input MEDIA_BUS_FMT_* for
> + * CRTC to pick from. CRTC driver is expected to select preferred media bus
> + * format from the list and, once enabled, generate the signal accordingly.
> + *
> + * Returns:
> + * Selected preferred media bus format or 0 if CRTC does not support any from
> + * @supported_fmts list.
> + */
> +u32 drm_helper_crtc_select_output_bus_format(struct drm_crtc *crtc,
> + struct drm_crtc_state *crtc_state,
> + const u32 *supported_fmts,
> + unsigned int num_supported_fmts)
> +{
> + if (!crtc || !supported_fmts || !num_supported_fmts)
> + return 0;
> +
> + if (!crtc->helper_private ||
> + !crtc->helper_private->select_output_bus_format)
> + return supported_fmts[0];
> +
> + return crtc->helper_private->select_output_bus_format(crtc,
> + crtc_state,
> + supported_fmts,
> + num_supported_fmts);
> +}
Again, the output of that selection must be found in the CRTC state,
otherwise CRTCs have no way to know which have been selected.
Maxime
[-- 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
* Re: [PATCH 1/4] dt-bindings: arm: qcom,coresight-funnel: Add label for multi-ouput
From: Suzuki K Poulose @ 2024-03-22 9:42 UTC (permalink / raw)
To: Tingwei Zhang, Rob Herring, Tao Zhang
Cc: Mathieu Poirier, Alexander Shishkin, Konrad Dybcio, Mike Leach,
Krzysztof Kozlowski, Jinlong Mao, Leo Yan, Greg Kroah-Hartman,
coresight, linux-arm-kernel, linux-kernel, devicetree,
Yuanfang Zhang, Trilok Soni, Song Chai, linux-arm-msm, andersson
In-Reply-To: <443edf61-2a28-4ae7-ac88-2da2d29cebe3@quicinc.com>
On 22/03/2024 07:02, Tingwei Zhang wrote:
> On 3/21/2024 10:42 PM, Rob Herring wrote:
>> On Thu, Mar 21, 2024 at 04:32:04PM +0800, Tao Zhang wrote:
>>> Add new property "label" to label the source corresponding to the
>>> output connection. When the funnel supports multi-output, this
>>> property needs to be introduced to mark which source component a
>>> certain output connection corresponds to.
>>>
>>> Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
>>> ---
>>> .../arm/arm,coresight-dynamic-funnel.yaml | 34 ++++++++++++++++---
>>> 1 file changed, 30 insertions(+), 4 deletions(-)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>>> index 44a1041cb0fc..cde62c286d29 100644
>>> ---
>>> a/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>>> +++
>>> b/Documentation/devicetree/bindings/arm/arm,coresight-dynamic-funnel.yaml
>>> @@ -66,13 +66,39 @@ properties:
>>> $ref: /schemas/graph.yaml#/properties/port
>>> out-ports:
>>> - $ref: /schemas/graph.yaml#/properties/ports
>>> - additionalProperties: false
>>> -
>>> + type: object
>>> properties:
>>> + "#address-cells":
>>> + const: 1
>>> +
>>> + "#size-cells":
>>> + const: 0
>>> +
>>> port:
>>> + type: object
>>> +
>>> + patternProperties:
>>> + '^port(@[0-7])?$':
>>> + type: object
>>> description: Output connection to CoreSight Trace bus
>>> - $ref: /schemas/graph.yaml#/properties/port
>>
>> Nope, now you have no constraints on port node properties. Please look
>> at how other bindings are done to add properties on endpoint node.
>>
> Thanks for pointing this out, Rob. Shall we ref port-base and
> endpoint-base then add new properties on endpoint? In this way, the
> redundant code from port schema is not required.
>>> +
>>> + patternProperties:
>>> + "^endpoint(@[0-9a-f]+)?$":
>>> + type: object
>>> + properties:
>>> + remote-endpoint:
>>> + description: |
>>> + phandle to an 'endpoint' subnode of a remote
>>> device node.
>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>
>> Don't need this.
>>
>>> + label:
>>> + description: Label the source corresponding to the
>>> output connection
>>> + $ref: /schemas/types.yaml#/definitions/string
>>
>> label already has a type.
>>
>> As this node is an output, aren't you labeling what the destination is,
>> not the "source"?
>>
>> Why can't you look at the remote connection to identify what it is?
>>
> This funnel can route data stream from different trace source to
> different output ports. This lable property is added to describe which
> source is routed to this output port.
>
> For example, the graph is as below. Funnel3 routes trace data from TPDM0
> to output[0] and output[0] of funnel3 is connected to input[0] of TPDA0.
Funnel3 and Funnel4 are really Replicators ! How are they Funnels ?
Again, my question still stands. Are Funnel(Replicator-renamed)3/4 and
Funnel 0/1/2 programmable ?
Suzuki
> While Funnels routes trace data from TPDM1 to output[1] which connects
> to input[1] of TPDA0. Hope that clarifies this a little bit.
>
> |---------| |---------| |---------| |---------| |---------|
> | TPDM0 | | TPDM1 | | TPDM2 | | TPDM3 | | TPDM4 |
> |---------| |---------| |---------| |---------| |---------|
> | | | | |
> | | | | |
> | | | | |
> |-----| |-----| |-----| |-----| |
> | | | | |
> | | | | |
> [0]| |[1] [0]| |[1] |
> \-------------/ \-------------/ \------------/
> \ FUNNEL0 / \ FUNNEL1 / \ FUNNEL2 /
> ----------- ----------- -----------
> | | |
> \-------------/ \-------------/ |
> \ FUNNEL3 / \ FUNNEL4 / |
> ----------- ----------- |
> | | | |
> [0]| |[1] [0]| |[1] |
> | |---------- | | |
> | | | | |
> |-------| | |------- | | |--------- |
> | | | | |
> | | | | |
> [0]| |[1] |[2] |[3] |[4]
> \ ---------------------------------------------------/
> \ TPDA0 /
> \ /
> ------------------------------------------------
>
>>
>>> + oneOf:
>>> + - required:
>>> + - port
>>> + - required:
>>> + - "#address-cells"
>>> + - "#size-cells"
>>
>> The common schema that you removed handles this.
>>
>> Rob
>
_______________________________________________
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 4/4] clk: samsung: exynos850: fix propagation of SPI IPCLK rate
From: Tudor Ambarus @ 2024-03-22 9:39 UTC (permalink / raw)
To: Sam Protsenko, 김재원/JAEWON KIM
Cc: krzysztof.kozlowski, s.nawrocki, cw00.choi, alim.akhtar,
mturquette, sboyd, peter.griffin, andre.draszik,
linux-samsung-soc, linux-clk, linux-arm-kernel, linux-kernel,
willmcvicker, kernel-team
In-Reply-To: <CAPLW+4=jSr6ZsB7XekXsiUBm0SmVpVFnqpgjViuF3=HpT4gRAg@mail.gmail.com>
Hi, Sam!
On 3/1/24 00:13, Sam Protsenko wrote:
> I fail to see how this patch fixes anything. Instead it looks to me it
> replaces the (already) correctly implemented logic with incorrect one.
I opened another thread asking for feedback on whether it's safe to
re-parent the USI MUX to OSCCLK at run-time, find it here:
https://lore.kernel.org/linux-samsung-soc/71df1d6b-f40b-4896-a672-c5f0f526fb1f@linaro.org/T/#m588abb87eb5fd8817d71d06b94c91eb84928e06b
Jaewon came up with the idea on verifying what the downstream clock
driver does. I added some prints in the driver, and indeed the USI MUX
re-parents to OSCCLK on low SPI clock rates in the GS101 case.
Thus I'll respin this patch set fixing GS101 on low USI clock rates by
re-parenting the USI MUX to OSCCLK. I'll leave exynos850 out if I don't
hear back from you, but I think it deserves the same fix. Allowing SPI
to modify the clock rate of HSI2C/I3C at run-time is bad IMO.
Re-parenting the USI MUX to OSCCLK fixes this problem, HSI2C/I3C will no
longer be affected on low SPI clock rates.
Cheers,
ta
_______________________________________________
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 07/14] drm/mediatek: Support alpha blending in display driver
From: CK Hu (胡俊光) @ 2024-03-22 9:37 UTC (permalink / raw)
To: Shawn Sung (宋孝謙), chunkuang.hu@kernel.org,
angelogioacchino.delregno@collabora.com
Cc: linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
Bibby Hsieh (謝濟遠),
jason-ch.chen@mediatek.corp-partner.google.com,
Nancy Lin (林欣螢), daniel@ffwll.ch,
p.zabel@pengutronix.de, dri-devel@lists.freedesktop.org,
airlied@gmail.com, sean@poorly.run, matthias.bgg@gmail.com,
fshao@chromium.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20240322052829.9893-8-shawn.sung@mediatek.com>
Hi, Shawn:
On Fri, 2024-03-22 at 13:28 +0800, Shawn Sung wrote:
> From: Hsiao Chien Sung <shawn.sung@mediatek.com>
>
> Support "Pre-multiplied" and "None" blend mode on MediaTek's chips by
> adding correct blend mode property when the planes init.
> Before this patch, only the "Coverage" mode (default) is supported.
>
> For more information, there are three pixel blend modes in DRM
> driver:
> "None", "Pre-multiplied", and "Coverage".
>
> To understand the difference between these modes, let's take a look
> at
> the following two approaches to do alpha blending:
>
> 1. Straight:
> dst.RGB = src.RGB * src.A + dst.RGB * (1 - src.A)
> This is straightforward and easy to understand, when the source layer
> is
> compositing with the destination layer, it's alpha will affect the
> result. This is also known as "post-multiplied", or "Coverage" mode.
>
> 2. Pre-multiplied:
> dst.RGB = src.RGB + dst.RGB * (1 - src.A)
> Since the source RGB have already multiplied its alpha, only
> destination
> RGB need to multiply it. This is the "Pre-multiplied" mode in DRM.
>
> For the "None" blend mode in DRM, it means the pixel alpha is ignored
> when compositing the layers, only the constant alpha for the
> composited
> layer will take effects.
>
> Reviewed-by: AngeloGioacchino Del Regno <
> angelogioacchino.delregno@collabora.com>
> Reviewed-by: CK Hu <ck.hu@mediatek.com>
> Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_plane.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_plane.c
> b/drivers/gpu/drm/mediatek/mtk_plane.c
> index 1723d4333f371..5bf757a3ef202 100644
> --- a/drivers/gpu/drm/mediatek/mtk_plane.c
> +++ b/drivers/gpu/drm/mediatek/mtk_plane.c
> @@ -346,6 +346,17 @@ int mtk_plane_init(struct drm_device *dev,
> struct drm_plane *plane,
> DRM_INFO("Create rotation property failed\n");
> }
>
> + err = drm_plane_create_alpha_property(plane);
> + if (err)
> + DRM_ERROR("failed to create property: alpha\n");
> +
> + err = drm_plane_create_blend_mode_property(plane,
> + BIT(DRM_MODE_BLEND_P
> REMULTI) |
> + BIT(DRM_MODE_BLEND_C
> OVERAGE) |
> + BIT(DRM_MODE_BLEND_P
> IXEL_NONE));
After all sub driver support these function, then create blend
property. So move this patch after all sub driver support these blend
mode.
Regards,
CK
> + if (err)
> + DRM_ERROR("failed to create property: blend_mode\n");
> +
> drm_plane_helper_add(plane, &mtk_plane_helper_funcs);
>
> return 0;
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 10/14] drm/mediatek: Support "None" alpha blending in OVL
From: CK Hu (胡俊光) @ 2024-03-22 9:32 UTC (permalink / raw)
To: Shawn Sung (宋孝謙), chunkuang.hu@kernel.org,
angelogioacchino.delregno@collabora.com
Cc: linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
Bibby Hsieh (謝濟遠),
jason-ch.chen@mediatek.corp-partner.google.com,
Nancy Lin (林欣螢), daniel@ffwll.ch,
p.zabel@pengutronix.de, dri-devel@lists.freedesktop.org,
airlied@gmail.com, sean@poorly.run, matthias.bgg@gmail.com,
fshao@chromium.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20240322052829.9893-11-shawn.sung@mediatek.com>
Hi, Shawn:
On Fri, 2024-03-22 at 13:28 +0800, Shawn Sung wrote:
> From: Hsiao Chien Sung <shawn.sung@mediatek.com>
>
> Support "None" blend mode on MediaTek's chips.
>
> Please refer to the description of the commit
> "drm/mediatek: Support alpha blending in display driver"
> for more information.
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> index b1e5d453316cc..a936f338ab79d 100644
> --- a/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> +++ b/drivers/gpu/drm/mediatek/mtk_disp_ovl.c
> @@ -484,7 +484,8 @@ void mtk_ovl_layer_config(struct device *dev,
> unsigned int idx,
> con |= state->base.alpha & OVL_CON_ALPHA;
> }
>
> - if (state->base.fb && !state->base.fb->format->has_alpha)
> + if (blend_mode == DRM_MODE_BLEND_PIXEL_NONE ||
> + (state->base.fb && !state->base.fb->format->has_alpha))
> ignore_pixel_alpha = OVL_CONST_BLEND;
>
> if (pending->rotation & DRM_MODE_REFLECT_Y) {
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 09/14] drm/mediatek: Rename files "mtk_drm_ddp_comp.c" to "mtk_ddp_comp.c"
From: Shawn Sung @ 2024-03-22 9:12 UTC (permalink / raw)
To: Chun-Kuang Hu, AngeloGioacchino Del Regno
Cc: Philipp Zabel, David Airlie, Daniel Vetter, Matthias Brugger,
Sumit Semwal, Christian König, dri-devel, linux-mediatek,
linux-kernel, linux-arm-kernel, linux-media, linaro-mm-sig,
Hsiao Chien Sung
In-Reply-To: <20240322091232.26387-1-shawn.sung@mediatek.com>
From: Hsiao Chien Sung <shawn.sung@mediatek.corp-partner.google.com>
Rename files mtk_drm_ddp_comp.c to mtk_ddp_comp.c and
modify the Makefile accordingly.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.corp-partner.google.com>
---
drivers/gpu/drm/mediatek/Makefile | 2 +-
drivers/gpu/drm/mediatek/{mtk_drm_ddp_comp.c => mtk_ddp_comp.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename drivers/gpu/drm/mediatek/{mtk_drm_ddp_comp.c => mtk_ddp_comp.c} (100%)
diff --git a/drivers/gpu/drm/mediatek/Makefile b/drivers/gpu/drm/mediatek/Makefile
index 0198b50820d4c..bdb71738e1f31 100644
--- a/drivers/gpu/drm/mediatek/Makefile
+++ b/drivers/gpu/drm/mediatek/Makefile
@@ -1,6 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
mediatek-drm-y := mtk_crtc.o \
+ mtk_ddp_comp.o \
mtk_disp_aal.o \
mtk_disp_ccorr.o \
mtk_disp_color.o \
@@ -9,7 +10,6 @@ mediatek-drm-y := mtk_crtc.o \
mtk_disp_ovl.o \
mtk_disp_ovl_adaptor.o \
mtk_disp_rdma.o \
- mtk_drm_ddp_comp.o \
mtk_drm_drv.o \
mtk_drm_gem.o \
mtk_drm_plane.o \
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c b/drivers/gpu/drm/mediatek/mtk_ddp_comp.c
similarity index 100%
rename from drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
rename to drivers/gpu/drm/mediatek/mtk_ddp_comp.c
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 4/4] media: platform: mtk-mdp3: Add support for MT8188 MDP3 components
From: AngeloGioacchino Del Regno @ 2024-03-22 9:28 UTC (permalink / raw)
To: linux-media
Cc: mchehab, robh, krzysztof.kozlowski+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, amergnat, moudy.ho, hverkuil-cisco,
sebastian.fricke, u.kleine-koenig, chunkuang.hu, p.zabel,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
kernel
In-Reply-To: <20240322092845.381313-1-angelogioacchino.delregno@collabora.com>
MT8195 and MT8188 share a similar MDP3 macro-block, with minor
differences - as in, the latter supports a subset of the number
of components supported by the former, but are otherwise handled
in the same way.
Add driver data for MT8188, reusing the already present MT8195
data where possible.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../platform/mediatek/mdp3/mdp_cfg_data.c | 280 ++++++++++++++++++
.../platform/mediatek/mdp3/mtk-img-ipi.h | 1 +
.../platform/mediatek/mdp3/mtk-mdp3-cfg.h | 1 +
.../platform/mediatek/mdp3/mtk-mdp3-core.c | 3 +
4 files changed, 285 insertions(+)
diff --git a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
index ecca52b45307..0b4c50bc1776 100644
--- a/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
+++ b/drivers/media/platform/mediatek/mdp3/mdp_cfg_data.c
@@ -46,6 +46,53 @@ enum mt8183_mdp_comp_id {
MT8183_MDP_COMP_WROT1, /* 25 */
};
+enum mt8188_mdp_comp_id {
+ /* MT8188 Comp id */
+ /* ISP */
+ MT8188_MDP_COMP_WPEI = 0,
+ MT8188_MDP_COMP_WPEO, /* 1 */
+
+ /* MDP */
+ MT8188_MDP_COMP_CAMIN, /* 2 */
+ MT8188_MDP_COMP_RDMA0, /* 3 */
+ MT8188_MDP_COMP_RDMA2, /* 4 */
+ MT8188_MDP_COMP_RDMA3, /* 5 */
+ MT8188_MDP_COMP_FG0, /* 6 */
+ MT8188_MDP_COMP_FG2, /* 7 */
+ MT8188_MDP_COMP_FG3, /* 8 */
+ MT8188_MDP_COMP_TO_SVPP2MOUT, /* 9 */
+ MT8188_MDP_COMP_TO_SVPP3MOUT, /* 10 */
+ MT8188_MDP_COMP_TO_WARP0MOUT, /* 11 */
+ MT8188_MDP_COMP_VPP0_SOUT, /* 12 */
+ MT8188_MDP_COMP_VPP1_SOUT, /* 13 */
+ MT8188_MDP_COMP_PQ0_SOUT, /* 14 */
+ MT8188_MDP_COMP_HDR0, /* 15 */
+ MT8188_MDP_COMP_HDR2, /* 16 */
+ MT8188_MDP_COMP_HDR3, /* 17 */
+ MT8188_MDP_COMP_AAL0, /* 18 */
+ MT8188_MDP_COMP_AAL2, /* 19 */
+ MT8188_MDP_COMP_AAL3, /* 20 */
+ MT8188_MDP_COMP_RSZ0, /* 21 */
+ MT8188_MDP_COMP_RSZ2, /* 22 */
+ MT8188_MDP_COMP_RSZ3, /* 23 */
+ MT8188_MDP_COMP_TDSHP0, /* 24 */
+ MT8188_MDP_COMP_TDSHP2, /* 25 */
+ MT8188_MDP_COMP_TDSHP3, /* 26 */
+ MT8188_MDP_COMP_COLOR0, /* 27 */
+ MT8188_MDP_COMP_COLOR2, /* 28 */
+ MT8188_MDP_COMP_COLOR3, /* 29 */
+ MT8188_MDP_COMP_OVL0, /* 30 */
+ MT8188_MDP_COMP_PAD0, /* 31 */
+ MT8188_MDP_COMP_PAD2, /* 32 */
+ MT8188_MDP_COMP_PAD3, /* 33 */
+ MT8188_MDP_COMP_TCC0, /* 34 */
+ MT8188_MDP_COMP_WROT0, /* 35 */
+ MT8188_MDP_COMP_WROT2, /* 36 */
+ MT8188_MDP_COMP_WROT3, /* 37 */
+ MT8188_MDP_COMP_MERGE2, /* 38 */
+ MT8188_MDP_COMP_MERGE3, /* 39 */
+};
+
enum mt8195_mdp_comp_id {
/* MT8195 Comp id */
/* ISP */
@@ -123,6 +170,13 @@ static const struct of_device_id mt8183_mdp_probe_infra[MDP_INFRA_MAX] = {
[MDP_INFRA_SCP] = { .compatible = "mediatek,mt8183-scp" }
};
+static const struct of_device_id mt8188_mdp_probe_infra[MDP_INFRA_MAX] = {
+ [MDP_INFRA_MMSYS] = { .compatible = "mediatek,mt8188-vppsys0" },
+ [MDP_INFRA_MMSYS2] = { .compatible = "mediatek,mt8188-vppsys1" },
+ [MDP_INFRA_MUTEX] = { .compatible = "mediatek,mt8188-vpp-mutex" },
+ [MDP_INFRA_MUTEX2] = { .compatible = "mediatek,mt8188-vpp-mutex" },
+};
+
static const struct of_device_id mt8195_mdp_probe_infra[MDP_INFRA_MAX] = {
[MDP_INFRA_MMSYS] = { .compatible = "mediatek,mt8195-vppsys0" },
[MDP_INFRA_MMSYS2] = { .compatible = "mediatek,mt8195-vppsys1" },
@@ -167,6 +221,40 @@ static const u32 mt8183_mutex_idx[MDP_MAX_COMP_COUNT] = {
[MDP_COMP_CCORR0] = MUTEX_MOD_IDX_MDP_CCORR0,
};
+static const u32 mt8188_mutex_idx[MDP_MAX_COMP_COUNT] = {
+ [MDP_COMP_RDMA0] = MUTEX_MOD_IDX_MDP_RDMA0,
+ [MDP_COMP_RDMA2] = MUTEX_MOD_IDX_MDP_RDMA2,
+ [MDP_COMP_RDMA3] = MUTEX_MOD_IDX_MDP_RDMA3,
+ [MDP_COMP_FG0] = MUTEX_MOD_IDX_MDP_FG0,
+ [MDP_COMP_FG2] = MUTEX_MOD_IDX_MDP_FG2,
+ [MDP_COMP_FG3] = MUTEX_MOD_IDX_MDP_FG3,
+ [MDP_COMP_HDR0] = MUTEX_MOD_IDX_MDP_HDR0,
+ [MDP_COMP_HDR2] = MUTEX_MOD_IDX_MDP_HDR2,
+ [MDP_COMP_HDR3] = MUTEX_MOD_IDX_MDP_HDR3,
+ [MDP_COMP_AAL0] = MUTEX_MOD_IDX_MDP_AAL0,
+ [MDP_COMP_AAL2] = MUTEX_MOD_IDX_MDP_AAL2,
+ [MDP_COMP_AAL3] = MUTEX_MOD_IDX_MDP_AAL3,
+ [MDP_COMP_RSZ0] = MUTEX_MOD_IDX_MDP_RSZ0,
+ [MDP_COMP_RSZ2] = MUTEX_MOD_IDX_MDP_RSZ2,
+ [MDP_COMP_RSZ3] = MUTEX_MOD_IDX_MDP_RSZ3,
+ [MDP_COMP_MERGE2] = MUTEX_MOD_IDX_MDP_MERGE2,
+ [MDP_COMP_MERGE3] = MUTEX_MOD_IDX_MDP_MERGE3,
+ [MDP_COMP_TDSHP0] = MUTEX_MOD_IDX_MDP_TDSHP0,
+ [MDP_COMP_TDSHP2] = MUTEX_MOD_IDX_MDP_TDSHP2,
+ [MDP_COMP_TDSHP3] = MUTEX_MOD_IDX_MDP_TDSHP3,
+ [MDP_COMP_COLOR0] = MUTEX_MOD_IDX_MDP_COLOR0,
+ [MDP_COMP_COLOR2] = MUTEX_MOD_IDX_MDP_COLOR2,
+ [MDP_COMP_COLOR3] = MUTEX_MOD_IDX_MDP_COLOR3,
+ [MDP_COMP_OVL0] = MUTEX_MOD_IDX_MDP_OVL0,
+ [MDP_COMP_PAD0] = MUTEX_MOD_IDX_MDP_PAD0,
+ [MDP_COMP_PAD2] = MUTEX_MOD_IDX_MDP_PAD2,
+ [MDP_COMP_PAD3] = MUTEX_MOD_IDX_MDP_PAD3,
+ [MDP_COMP_TCC0] = MUTEX_MOD_IDX_MDP_TCC0,
+ [MDP_COMP_WROT0] = MUTEX_MOD_IDX_MDP_WROT0,
+ [MDP_COMP_WROT2] = MUTEX_MOD_IDX_MDP_WROT2,
+ [MDP_COMP_WROT3] = MUTEX_MOD_IDX_MDP_WROT3,
+};
+
static const u32 mt8195_mutex_idx[MDP_MAX_COMP_COUNT] = {
[MDP_COMP_RDMA0] = MUTEX_MOD_IDX_MDP_RDMA0,
[MDP_COMP_RDMA1] = MUTEX_MOD_IDX_MDP_RDMA1,
@@ -288,6 +376,171 @@ static const struct mdp_comp_data mt8183_mdp_comp_data[MDP_MAX_COMP_COUNT] = {
},
};
+static const struct mdp_comp_data mt8188_mdp_comp_data[MDP_MAX_COMP_COUNT] = {
+ [MDP_COMP_WPEI] = {
+ {MDP_COMP_TYPE_WPEI, 0, MT8188_MDP_COMP_WPEI, MDP_MM_SUBSYS_0},
+ {0, 0, 0}
+ },
+ [MDP_COMP_WPEO] = {
+ {MDP_COMP_TYPE_EXTO, 0, MT8188_MDP_COMP_WPEO, MDP_MM_SUBSYS_0},
+ {0, 0, 0}
+ },
+ [MDP_COMP_CAMIN] = {
+ {MDP_COMP_TYPE_DL_PATH, 0, MT8188_MDP_COMP_CAMIN, MDP_MM_SUBSYS_0},
+ {3, 3, 0}
+ },
+ [MDP_COMP_RDMA0] = {
+ {MDP_COMP_TYPE_RDMA, 0, MT8188_MDP_COMP_RDMA0, MDP_MM_SUBSYS_0},
+ {3, 0, 0}
+ },
+ [MDP_COMP_RDMA2] = {
+ {MDP_COMP_TYPE_RDMA, 1, MT8188_MDP_COMP_RDMA2, MDP_MM_SUBSYS_1},
+ {3, 0, 0}
+ },
+ [MDP_COMP_RDMA3] = {
+ {MDP_COMP_TYPE_RDMA, 2, MT8188_MDP_COMP_RDMA3, MDP_MM_SUBSYS_1},
+ {3, 0, 0}
+ },
+ [MDP_COMP_FG0] = {
+ {MDP_COMP_TYPE_FG, 0, MT8188_MDP_COMP_FG0, MDP_MM_SUBSYS_0},
+ {1, 0, 0}
+ },
+ [MDP_COMP_FG2] = {
+ {MDP_COMP_TYPE_FG, 1, MT8188_MDP_COMP_FG2, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_FG3] = {
+ {MDP_COMP_TYPE_FG, 2, MT8188_MDP_COMP_FG3, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_HDR0] = {
+ {MDP_COMP_TYPE_HDR, 0, MT8188_MDP_COMP_HDR0, MDP_MM_SUBSYS_0},
+ {1, 0, 0}
+ },
+ [MDP_COMP_HDR2] = {
+ {MDP_COMP_TYPE_HDR, 1, MT8188_MDP_COMP_HDR2, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_HDR3] = {
+ {MDP_COMP_TYPE_HDR, 2, MT8188_MDP_COMP_HDR3, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_AAL0] = {
+ {MDP_COMP_TYPE_AAL, 0, MT8188_MDP_COMP_AAL0, MDP_MM_SUBSYS_0},
+ {1, 0, 0}
+ },
+ [MDP_COMP_AAL2] = {
+ {MDP_COMP_TYPE_AAL, 1, MT8188_MDP_COMP_AAL2, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_AAL3] = {
+ {MDP_COMP_TYPE_AAL, 2, MT8188_MDP_COMP_AAL3, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_RSZ0] = {
+ {MDP_COMP_TYPE_RSZ, 0, MT8188_MDP_COMP_RSZ0, MDP_MM_SUBSYS_0},
+ {1, 0, 0}
+ },
+ [MDP_COMP_RSZ2] = {
+ {MDP_COMP_TYPE_RSZ, 1, MT8188_MDP_COMP_RSZ2, MDP_MM_SUBSYS_1},
+ {2, 0, 0},
+ {MDP_COMP_MERGE2, true, true}
+ },
+ [MDP_COMP_RSZ3] = {
+ {MDP_COMP_TYPE_RSZ, 2, MT8188_MDP_COMP_RSZ3, MDP_MM_SUBSYS_1},
+ {2, 0, 0},
+ {MDP_COMP_MERGE3, true, true}
+ },
+ [MDP_COMP_TDSHP0] = {
+ {MDP_COMP_TYPE_TDSHP, 0, MT8188_MDP_COMP_TDSHP0, MDP_MM_SUBSYS_0},
+ {1, 0, 0}
+ },
+ [MDP_COMP_TDSHP2] = {
+ {MDP_COMP_TYPE_TDSHP, 1, MT8188_MDP_COMP_TDSHP2, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_TDSHP3] = {
+ {MDP_COMP_TYPE_TDSHP, 2, MT8188_MDP_COMP_TDSHP3, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_COLOR0] = {
+ {MDP_COMP_TYPE_COLOR, 0, MT8188_MDP_COMP_COLOR0, MDP_MM_SUBSYS_0},
+ {1, 0, 0}
+ },
+ [MDP_COMP_COLOR2] = {
+ {MDP_COMP_TYPE_COLOR, 1, MT8188_MDP_COMP_COLOR2, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_COLOR3] = {
+ {MDP_COMP_TYPE_COLOR, 2, MT8188_MDP_COMP_COLOR3, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_OVL0] = {
+ {MDP_COMP_TYPE_OVL, 0, MT8188_MDP_COMP_OVL0, MDP_MM_SUBSYS_0},
+ {1, 0, 0}
+ },
+ [MDP_COMP_PAD0] = {
+ {MDP_COMP_TYPE_PAD, 0, MT8188_MDP_COMP_PAD0, MDP_MM_SUBSYS_0},
+ {1, 0, 0}
+ },
+ [MDP_COMP_PAD2] = {
+ {MDP_COMP_TYPE_PAD, 1, MT8188_MDP_COMP_PAD2, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_PAD3] = {
+ {MDP_COMP_TYPE_PAD, 2, MT8188_MDP_COMP_PAD3, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_TCC0] = {
+ {MDP_COMP_TYPE_TCC, 0, MT8188_MDP_COMP_TCC0, MDP_MM_SUBSYS_0},
+ {1, 0, 0}
+ },
+ [MDP_COMP_WROT0] = {
+ {MDP_COMP_TYPE_WROT, 0, MT8188_MDP_COMP_WROT0, MDP_MM_SUBSYS_0},
+ {1, 0, 0}
+ },
+ [MDP_COMP_WROT2] = {
+ {MDP_COMP_TYPE_WROT, 1, MT8188_MDP_COMP_WROT2, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_WROT3] = {
+ {MDP_COMP_TYPE_WROT, 2, MT8188_MDP_COMP_WROT3, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_MERGE2] = {
+ {MDP_COMP_TYPE_MERGE, 0, MT8188_MDP_COMP_MERGE2, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_MERGE3] = {
+ {MDP_COMP_TYPE_MERGE, 1, MT8188_MDP_COMP_MERGE3, MDP_MM_SUBSYS_1},
+ {1, 0, 0}
+ },
+ [MDP_COMP_PQ0_SOUT] = {
+ {MDP_COMP_TYPE_DUMMY, 0, MT8188_MDP_COMP_PQ0_SOUT, MDP_MM_SUBSYS_0},
+ {0, 0, 0}
+ },
+ [MDP_COMP_TO_WARP0MOUT] = {
+ {MDP_COMP_TYPE_DUMMY, 1, MT8188_MDP_COMP_TO_WARP0MOUT, MDP_MM_SUBSYS_0},
+ {0, 0, 0}
+ },
+ [MDP_COMP_TO_SVPP2MOUT] = {
+ {MDP_COMP_TYPE_DUMMY, 2, MT8188_MDP_COMP_TO_SVPP2MOUT, MDP_MM_SUBSYS_1},
+ {0, 0, 0}
+ },
+ [MDP_COMP_TO_SVPP3MOUT] = {
+ {MDP_COMP_TYPE_DUMMY, 3, MT8188_MDP_COMP_TO_SVPP3MOUT, MDP_MM_SUBSYS_1},
+ {0, 0, 0}
+ },
+ [MDP_COMP_VPP0_SOUT] = {
+ {MDP_COMP_TYPE_PATH, 0, MT8188_MDP_COMP_VPP0_SOUT, MDP_MM_SUBSYS_1},
+ {2, 6, 0}
+ },
+ [MDP_COMP_VPP1_SOUT] = {
+ {MDP_COMP_TYPE_PATH, 1, MT8188_MDP_COMP_VPP1_SOUT, MDP_MM_SUBSYS_0},
+ {2, 8, 0}
+ },
+};
+
static const struct mdp_comp_data mt8195_mdp_comp_data[MDP_MAX_COMP_COUNT] = {
[MDP_COMP_WPEI] = {
{MDP_COMP_TYPE_WPEI, 0, MT8195_MDP_COMP_WPEI, MDP_MM_SUBSYS_0},
@@ -1046,6 +1299,15 @@ static const struct mdp_pipe_info mt8183_pipe_info[] = {
[MDP_PIPE_RDMA0] = {MDP_PIPE_RDMA0, MDP_MM_SUBSYS_0, 3}
};
+static const struct mdp_pipe_info mt8188_pipe_info[] = {
+ [MDP_PIPE_WPEI] = {MDP_PIPE_WPEI, MDP_MM_SUBSYS_0, 0},
+ [MDP_PIPE_RDMA0] = {MDP_PIPE_RDMA0, MDP_MM_SUBSYS_0, 1},
+ [MDP_PIPE_RDMA2] = {MDP_PIPE_RDMA2, MDP_MM_SUBSYS_1, 0},
+ [MDP_PIPE_RDMA3] = {MDP_PIPE_RDMA3, MDP_MM_SUBSYS_1, 1},
+ [MDP_PIPE_VPP1_SOUT] = {MDP_PIPE_VPP1_SOUT, MDP_MM_SUBSYS_0, 2},
+ [MDP_PIPE_VPP0_SOUT] = {MDP_PIPE_VPP0_SOUT, MDP_MM_SUBSYS_1, 2},
+};
+
static const struct mdp_pipe_info mt8195_pipe_info[] = {
[MDP_PIPE_WPEI] = {MDP_PIPE_WPEI, MDP_MM_SUBSYS_0, 0},
[MDP_PIPE_WPEI2] = {MDP_PIPE_WPEI2, MDP_MM_SUBSYS_0, 1},
@@ -1082,6 +1344,24 @@ const struct mtk_mdp_driver_data mt8183_mdp_driver_data = {
.pp_used = MDP_PP_USED_1,
};
+const struct mtk_mdp_driver_data mt8188_mdp_driver_data = {
+ .mdp_plat_id = MT8188,
+ .mdp_con_res = 0x14001000,
+ .mdp_probe_infra = mt8188_mdp_probe_infra,
+ .mdp_sub_comp_dt_ids = mt8195_sub_comp_dt_ids,
+ .mdp_cfg = &mt8195_plat_cfg,
+ .mdp_mutex_table_idx = mt8188_mutex_idx,
+ .comp_data = mt8188_mdp_comp_data,
+ .comp_data_len = ARRAY_SIZE(mt8188_mdp_comp_data),
+ .format = mt8195_formats,
+ .format_len = ARRAY_SIZE(mt8195_formats),
+ .def_limit = &mt8195_mdp_def_limit,
+ .pipe_info = mt8188_pipe_info,
+ .pipe_info_len = ARRAY_SIZE(mt8188_pipe_info),
+ .pp_criteria = &mt8195_mdp_pp_criteria,
+ .pp_used = MDP_PP_USED_2,
+};
+
const struct mtk_mdp_driver_data mt8195_mdp_driver_data = {
.mdp_plat_id = MT8195,
.mdp_con_res = 0x14001000,
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-img-ipi.h b/drivers/media/platform/mediatek/mdp3/mtk-img-ipi.h
index f83ac408306e..4764c5b5107b 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-img-ipi.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-img-ipi.h
@@ -116,6 +116,7 @@ struct img_frameparam {
/* Platform config indicator */
#define MT8183 8183
+#define MT8188 8195
#define MT8195 8195
#define CFG_CHECK(plat, p_id) ((plat) == (p_id))
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h
index 49cdf45f6e59..7f7625299ce7 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-cfg.h
@@ -10,6 +10,7 @@
#include <linux/types.h>
extern const struct mtk_mdp_driver_data mt8183_mdp_driver_data;
+extern const struct mtk_mdp_driver_data mt8188_mdp_driver_data;
extern const struct mtk_mdp_driver_data mt8195_mdp_driver_data;
struct mdp_dev;
diff --git a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
index 5209f531ef8d..61a798f33041 100644
--- a/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
+++ b/drivers/media/platform/mediatek/mdp3/mtk-mdp3-core.c
@@ -21,6 +21,9 @@ static const struct of_device_id mdp_of_ids[] = {
{ .compatible = "mediatek,mt8183-mdp3-rdma",
.data = &mt8183_mdp_driver_data,
},
+ { .compatible = "mediatek,mt8188-mdp3-rdma",
+ .data = &mt8188_mdp_driver_data,
+ },
{ .compatible = "mediatek,mt8195-mdp3-rdma",
.data = &mt8195_mdp_driver_data,
},
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/4] soc: mediatek: mtk-mutex: Add support for MT8188 VPPSYS
From: AngeloGioacchino Del Regno @ 2024-03-22 9:28 UTC (permalink / raw)
To: linux-media
Cc: mchehab, robh, krzysztof.kozlowski+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, amergnat, moudy.ho, hverkuil-cisco,
sebastian.fricke, u.kleine-koenig, chunkuang.hu, p.zabel,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
kernel
In-Reply-To: <20240322092845.381313-1-angelogioacchino.delregno@collabora.com>
Add MT8188 VPPSYS0 and VPPSYS1 mutex info to driver data
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/soc/mediatek/mtk-mutex.c | 41 ++++++++++++++++++++++++++++++++
1 file changed, 41 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/soc/mediatek/mtk-mutex.c
index 73c256d3950b..b5af1fb5847e 100644
--- a/drivers/soc/mediatek/mtk-mutex.c
+++ b/drivers/soc/mediatek/mtk-mutex.c
@@ -496,6 +496,39 @@ static const unsigned int mt8188_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_MERGE5] = MT8188_MUTEX_MOD_DISP1_VPP_MERGE4,
};
+static const unsigned int mt8188_mdp_mutex_table_mod[MUTEX_MOD_IDX_MAX] = {
+ [MUTEX_MOD_IDX_MDP_RDMA0] = MT8195_MUTEX_MOD_MDP_RDMA0,
+ [MUTEX_MOD_IDX_MDP_RDMA2] = MT8195_MUTEX_MOD_MDP_RDMA2,
+ [MUTEX_MOD_IDX_MDP_RDMA3] = MT8195_MUTEX_MOD_MDP_RDMA3,
+ [MUTEX_MOD_IDX_MDP_FG0] = MT8195_MUTEX_MOD_MDP_FG0,
+ [MUTEX_MOD_IDX_MDP_FG2] = MT8195_MUTEX_MOD_MDP_FG2,
+ [MUTEX_MOD_IDX_MDP_FG3] = MT8195_MUTEX_MOD_MDP_FG3,
+ [MUTEX_MOD_IDX_MDP_HDR0] = MT8195_MUTEX_MOD_MDP_HDR0,
+ [MUTEX_MOD_IDX_MDP_HDR2] = MT8195_MUTEX_MOD_MDP_HDR2,
+ [MUTEX_MOD_IDX_MDP_HDR3] = MT8195_MUTEX_MOD_MDP_HDR3,
+ [MUTEX_MOD_IDX_MDP_AAL0] = MT8195_MUTEX_MOD_MDP_AAL0,
+ [MUTEX_MOD_IDX_MDP_AAL2] = MT8195_MUTEX_MOD_MDP_AAL2,
+ [MUTEX_MOD_IDX_MDP_AAL3] = MT8195_MUTEX_MOD_MDP_AAL3,
+ [MUTEX_MOD_IDX_MDP_RSZ0] = MT8195_MUTEX_MOD_MDP_RSZ0,
+ [MUTEX_MOD_IDX_MDP_RSZ2] = MT8195_MUTEX_MOD_MDP_RSZ2,
+ [MUTEX_MOD_IDX_MDP_RSZ3] = MT8195_MUTEX_MOD_MDP_RSZ3,
+ [MUTEX_MOD_IDX_MDP_MERGE2] = MT8195_MUTEX_MOD_MDP_MERGE2,
+ [MUTEX_MOD_IDX_MDP_MERGE3] = MT8195_MUTEX_MOD_MDP_MERGE3,
+ [MUTEX_MOD_IDX_MDP_TDSHP0] = MT8195_MUTEX_MOD_MDP_TDSHP0,
+ [MUTEX_MOD_IDX_MDP_TDSHP2] = MT8195_MUTEX_MOD_MDP_TDSHP2,
+ [MUTEX_MOD_IDX_MDP_TDSHP3] = MT8195_MUTEX_MOD_MDP_TDSHP3,
+ [MUTEX_MOD_IDX_MDP_COLOR0] = MT8195_MUTEX_MOD_MDP_COLOR0,
+ [MUTEX_MOD_IDX_MDP_COLOR2] = MT8195_MUTEX_MOD_MDP_COLOR2,
+ [MUTEX_MOD_IDX_MDP_COLOR3] = MT8195_MUTEX_MOD_MDP_COLOR3,
+ [MUTEX_MOD_IDX_MDP_OVL0] = MT8195_MUTEX_MOD_MDP_OVL0,
+ [MUTEX_MOD_IDX_MDP_PAD0] = MT8195_MUTEX_MOD_MDP_PAD0,
+ [MUTEX_MOD_IDX_MDP_PAD2] = MT8195_MUTEX_MOD_MDP_PAD2,
+ [MUTEX_MOD_IDX_MDP_PAD3] = MT8195_MUTEX_MOD_MDP_PAD3,
+ [MUTEX_MOD_IDX_MDP_WROT0] = MT8195_MUTEX_MOD_MDP_WROT0,
+ [MUTEX_MOD_IDX_MDP_WROT2] = MT8195_MUTEX_MOD_MDP_WROT2,
+ [MUTEX_MOD_IDX_MDP_WROT3] = MT8195_MUTEX_MOD_MDP_WROT3,
+};
+
static const unsigned int mt8192_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_AAL0] = MT8192_MUTEX_MOD_DISP_AAL0,
[DDP_COMPONENT_CCORR] = MT8192_MUTEX_MOD_DISP_CCORR0,
@@ -735,6 +768,13 @@ static const struct mtk_mutex_data mt8188_mutex_driver_data = {
.mutex_sof_reg = MT8183_MUTEX0_SOF0,
};
+static const struct mtk_mutex_data mt8188_vpp_mutex_driver_data = {
+ .mutex_sof = mt8188_mutex_sof,
+ .mutex_mod_reg = MT8183_MUTEX0_MOD0,
+ .mutex_sof_reg = MT8183_MUTEX0_SOF0,
+ .mutex_table_mod = mt8188_mdp_mutex_table_mod,
+};
+
static const struct mtk_mutex_data mt8192_mutex_driver_data = {
.mutex_mod = mt8192_mutex_mod,
.mutex_sof = mt8183_mutex_sof,
@@ -1089,6 +1129,7 @@ static const struct of_device_id mutex_driver_dt_match[] = {
{ .compatible = "mediatek,mt8186-disp-mutex", .data = &mt8186_mutex_driver_data },
{ .compatible = "mediatek,mt8186-mdp3-mutex", .data = &mt8186_mdp_mutex_driver_data },
{ .compatible = "mediatek,mt8188-disp-mutex", .data = &mt8188_mutex_driver_data },
+ { .compatible = "mediatek,mt8188-vpp-mutex", .data = &mt8188_vpp_mutex_driver_data },
{ .compatible = "mediatek,mt8192-disp-mutex", .data = &mt8192_mutex_driver_data },
{ .compatible = "mediatek,mt8195-disp-mutex", .data = &mt8195_mutex_driver_data },
{ .compatible = "mediatek,mt8195-vpp-mutex", .data = &mt8195_vpp_mutex_driver_data },
--
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 3/4] dt-bindings: media: mediatek: mdp3: Add support for MT8188 RDMA
From: AngeloGioacchino Del Regno @ 2024-03-22 9:28 UTC (permalink / raw)
To: linux-media
Cc: mchehab, robh, krzysztof.kozlowski+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, amergnat, moudy.ho, hverkuil-cisco,
sebastian.fricke, u.kleine-koenig, chunkuang.hu, p.zabel,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
kernel
In-Reply-To: <20240322092845.381313-1-angelogioacchino.delregno@collabora.com>
Add a compatible for MediaTek MT8188 RDMA, which supports only a
subset of the MDP3 components of its similar MT8195 counterpart.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
index 59db8306485b..18603f6c5e06 100644
--- a/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek,mdp3-rdma.yaml
@@ -23,6 +23,7 @@ properties:
oneOf:
- enum:
- mediatek,mt8183-mdp3-rdma
+ - mediatek,mt8188-mdp3-rdma
- mediatek,mt8195-mdp3-rdma
- mediatek,mt8195-vdo1-rdma
- items:
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: soc: mediatek: Add support for MT8188 VPPSYS
From: AngeloGioacchino Del Regno @ 2024-03-22 9:28 UTC (permalink / raw)
To: linux-media
Cc: mchehab, robh, krzysztof.kozlowski+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, amergnat, moudy.ho, hverkuil-cisco,
sebastian.fricke, u.kleine-koenig, chunkuang.hu, p.zabel,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
kernel
In-Reply-To: <20240322092845.381313-1-angelogioacchino.delregno@collabora.com>
Add compatible for MT8188 VPP mutex.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
.../devicetree/bindings/soc/mediatek/mediatek,mutex.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
index ba2014a8725c..a10326a9683d 100644
--- a/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
+++ b/Documentation/devicetree/bindings/soc/mediatek/mediatek,mutex.yaml
@@ -33,6 +33,7 @@ properties:
- mediatek,mt8186-disp-mutex
- mediatek,mt8186-mdp3-mutex
- mediatek,mt8188-disp-mutex
+ - mediatek,mt8188-vpp-mutex
- mediatek,mt8192-disp-mutex
- mediatek,mt8195-disp-mutex
- mediatek,mt8195-vpp-mutex
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 0/4] Support MediaTek MT8188 Media Data Path 3 (MDP3)
From: AngeloGioacchino Del Regno @ 2024-03-22 9:28 UTC (permalink / raw)
To: linux-media
Cc: mchehab, robh, krzysztof.kozlowski+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno, amergnat, moudy.ho, hverkuil-cisco,
sebastian.fricke, u.kleine-koenig, chunkuang.hu, p.zabel,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek,
kernel
This series adds code to support for the MDP3 block found in the
MediaTek MT8188 SoC, including the necessary bits for mtk-mutex
and platform data for the MDP3 driver.
This is mostly compatible with MT8195, with a few differences
"here and there", with the former having less instances of some
of the MDP3 IPs compared to the latter.
AngeloGioacchino Del Regno (4):
dt-bindings: soc: mediatek: Add support for MT8188 VPPSYS
soc: mediatek: mtk-mutex: Add support for MT8188 VPPSYS
dt-bindings: media: mediatek: mdp3: Add support for MT8188 RDMA
media: platform: mtk-mdp3: Add support for MT8188 MDP3 components
.../bindings/media/mediatek,mdp3-rdma.yaml | 1 +
.../bindings/soc/mediatek/mediatek,mutex.yaml | 1 +
.../platform/mediatek/mdp3/mdp_cfg_data.c | 280 ++++++++++++++++++
.../platform/mediatek/mdp3/mtk-img-ipi.h | 1 +
.../platform/mediatek/mdp3/mtk-mdp3-cfg.h | 1 +
.../platform/mediatek/mdp3/mtk-mdp3-core.c | 3 +
drivers/soc/mediatek/mtk-mutex.c | 41 +++
7 files changed, 328 insertions(+)
--
2.44.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 09/14] drm/mediatek: Support "Pre-multiplied" alpha blending in Mixer
From: CK Hu (胡俊光) @ 2024-03-22 9:26 UTC (permalink / raw)
To: Shawn Sung (宋孝謙), chunkuang.hu@kernel.org,
angelogioacchino.delregno@collabora.com
Cc: linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
Bibby Hsieh (謝濟遠),
jason-ch.chen@mediatek.corp-partner.google.com,
Nancy Lin (林欣螢), daniel@ffwll.ch,
p.zabel@pengutronix.de, dri-devel@lists.freedesktop.org,
airlied@gmail.com, sean@poorly.run, matthias.bgg@gmail.com,
fshao@chromium.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20240322052829.9893-10-shawn.sung@mediatek.com>
Hi, Shawn:
On Fri, 2024-03-22 at 13:28 +0800, Shawn Sung wrote:
> From: Hsiao Chien Sung <shawn.sung@mediatek.com>
>
> Support "Pre-multiplied" blend mode on MediaTek's chips.
> Before this patch, only the "Coverage" mode is supported.
>
> Please refer to the description of the commit
> "drm/mediatek: Support alpha blending in display driver"
> for more information.
>
> Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com>
> ---
> drivers/gpu/drm/mediatek/mtk_ethdr.c | 25 ++++++++++++++++++-------
> 1 file changed, 18 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_ethdr.c
> b/drivers/gpu/drm/mediatek/mtk_ethdr.c
> index 6bf398850e85f..4b12ca285e84b 100644
> --- a/drivers/gpu/drm/mediatek/mtk_ethdr.c
> +++ b/drivers/gpu/drm/mediatek/mtk_ethdr.c
> @@ -5,6 +5,7 @@
>
> #include <drm/drm_fourcc.h>
> #include <drm/drm_framebuffer.h>
> +#include <drm/drm_blend.h>
> #include <linux/clk.h>
> #include <linux/component.h>
> #include <linux/of.h>
> @@ -35,6 +36,7 @@
> #define MIX_SRC_L0_EN BIT(0)
> #define MIX_L_SRC_CON(n) (0x28 + 0x18 * (n))
> #define NON_PREMULTI_SOURCE (2 << 12)
> +#define PREMULTI_SOURCE (3 << 12)
> #define MIX_L_SRC_SIZE(n) (0x30 + 0x18 * (n))
> #define MIX_L_SRC_OFFSET(n) (0x34 + 0x18 * (n))
> #define MIX_FUNC_DCM0 0x120
> @@ -153,7 +155,8 @@ void mtk_ethdr_layer_config(struct device *dev,
> unsigned int idx,
> struct mtk_plane_pending_state *pending = &state->pending;
> unsigned int offset = (pending->x & 1) << 31 | pending->y << 16
> | pending->x;
> unsigned int align_width = ALIGN_DOWN(pending->width, 2);
> - unsigned int alpha_con = 0;
> + unsigned int mix_con = NON_PREMULTI_SOURCE;
I think you should not assign here. You should choose one of
PREMULTI_SOURCE or NON_PREMULTI_SOURCE later.
> + bool replace_src_a = false;
>
> dev_dbg(dev, "%s+ idx:%d", __func__, idx);
>
> @@ -170,19 +173,27 @@ void mtk_ethdr_layer_config(struct device *dev,
> unsigned int idx,
> return;
> }
>
> - if (state->base.fb && state->base.fb->format->has_alpha)
> - alpha_con = MIXER_ALPHA_AEN | MIXER_ALPHA;
> + mix_con |= MIXER_ALPHA_AEN | (state->base.alpha & MIXER_ALPHA);
Now support pixel alpha, and this seems to support plane alpha.
Separate this to another patch.
>
> - mtk_mmsys_mixer_in_config(priv->mmsys_dev, idx + 1, alpha_con ?
> false : true,
> - DEFAULT_9BIT_ALPHA,
> + if (state->base.pixel_blend_mode != DRM_MODE_BLEND_COVERAGE)
> + mix_con |= PREMULTI_SOURCE;
> +
> + if (state->base.fb && !state->base.fb->format->has_alpha) {
> + /*
> + * Mixer doesn't support CONST_BLD mode,
> + * use a trick to make the output equivalent
> + */
> + replace_src_a = true;
Ditto.
Regards,
CK
> + }
> +
> + mtk_mmsys_mixer_in_config(priv->mmsys_dev, idx + 1,
> replace_src_a, MIXER_ALPHA,
> pending->x & 1 ?
> MIXER_INX_MODE_EVEN_EXTEND :
> MIXER_INX_MODE_BYPASS, align_width /
> 2 - 1, cmdq_pkt);
>
> mtk_ddp_write(cmdq_pkt, pending->height << 16 | align_width,
> &mixer->cmdq_base,
> mixer->regs, MIX_L_SRC_SIZE(idx));
> mtk_ddp_write(cmdq_pkt, offset, &mixer->cmdq_base, mixer->regs,
> MIX_L_SRC_OFFSET(idx));
> - mtk_ddp_write_mask(cmdq_pkt, alpha_con, &mixer->cmdq_base,
> mixer->regs, MIX_L_SRC_CON(idx),
> - 0x1ff);
> + mtk_ddp_write(cmdq_pkt, mix_con, &mixer->cmdq_base, mixer-
> >regs, MIX_L_SRC_CON(idx));
> mtk_ddp_write_mask(cmdq_pkt, BIT(idx), &mixer->cmdq_base,
> mixer->regs, MIX_SRC_CON,
> BIT(idx));
> }
_______________________________________________
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] ARM: unwind: improve unwinders for noreturn case
From: David Laight @ 2024-03-22 9:24 UTC (permalink / raw)
To: 'Russell King', Ard Biesheuvel
Cc: Jiangfeng Xiao, arnd@arndb.de, keescook@chromium.org,
haibo.li@mediatek.com, angelogioacchino.delregno@collabora.com,
amergnat@baylibre.com, akpm@linux-foundation.org,
dave.hansen@linux.intel.com, douzhaolei@huawei.com,
gustavoars@kernel.org, jpoimboe@kernel.org,
kepler.chenxin@huawei.com, kirill.shutemov@linux.intel.com,
linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org,
nixiaoming@huawei.com, peterz@infradead.org, wangbing6@huawei.com,
wangfangpeng1@huawei.com, jannh@google.com, willy@infradead.org
In-Reply-To: <ZfzMFv3zmYY36l9u@shell.armlinux.org.uk>
From: Russell King
> Sent: 22 March 2024 00:09
>
> On Thu, Mar 21, 2024 at 11:43:41PM +0100, Ard Biesheuvel wrote:
> > Given that this particular issue would just disappear if the compiler
> > would just insert a BRK after the BL, I'd prefer to explore first
> > whether we can get this fixed on the compiler side.
>
> Arm32 doesn't have a BRK instruction. What would be appropriate after
> the no-return BL would be OS specific.
It would need to depend on what was being compiled.
For the kernel it could be much the same as BUG().
(Probably without any extra data.)
I suspect that arm32 could use 'swi' in kernel space,
but you wouldn't want to use that in userspace.
Looks like armv5 has a bkpt instruction - could that be used?
Or does the kernel need to support armv4?
The last arm I wrote anything for was a strongarm.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 04/14] drm/mediatek: Rename "mtk_drm_gem" to "mtk_gem"
From: Shawn Sung @ 2024-03-22 9:12 UTC (permalink / raw)
To: Chun-Kuang Hu, AngeloGioacchino Del Regno
Cc: Philipp Zabel, David Airlie, Daniel Vetter, Matthias Brugger,
Sumit Semwal, Christian König, dri-devel, linux-mediatek,
linux-kernel, linux-arm-kernel, linux-media, linaro-mm-sig,
Hsiao Chien Sung
In-Reply-To: <20240322091232.26387-1-shawn.sung@mediatek.com>
From: Hsiao Chien Sung <shawn.sung@mediatek.corp-partner.google.com>
Rename all "mtk_drm_gem" to "mtk_gem":
- To align the naming rule
- To reduce the code size
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: CK Hu <ck.hu@mediatek.com>
Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.corp-partner.google.com>
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 8 +--
drivers/gpu/drm/mediatek/mtk_drm_gem.c | 63 ++++++++++++------------
drivers/gpu/drm/mediatek/mtk_drm_gem.h | 23 +++++----
drivers/gpu/drm/mediatek/mtk_drm_plane.c | 2 +-
4 files changed, 47 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index c46773569b3c9..81e8aa65abd6d 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -576,8 +576,8 @@ DEFINE_DRM_GEM_FOPS(mtk_drm_fops);
* We need to override this because the device used to import the memory is
* not dev->dev, as drm_gem_prime_import() expects.
*/
-static struct drm_gem_object *mtk_drm_gem_prime_import(struct drm_device *dev,
- struct dma_buf *dma_buf)
+static struct drm_gem_object *mtk_gem_prime_import(struct drm_device *dev,
+ struct dma_buf *dma_buf)
{
struct mtk_drm_private *private = dev->dev_private;
@@ -587,9 +587,9 @@ static struct drm_gem_object *mtk_drm_gem_prime_import(struct drm_device *dev,
static const struct drm_driver mtk_drm_driver = {
.driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
- .dumb_create = mtk_drm_gem_dumb_create,
+ .dumb_create = mtk_gem_dumb_create,
- .gem_prime_import = mtk_drm_gem_prime_import,
+ .gem_prime_import = mtk_gem_prime_import,
.gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
.fops = &mtk_drm_fops,
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.c b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
index 4f2e3feabc0f8..445fd8a8b8988 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.c
@@ -14,26 +14,26 @@
#include "mtk_drm_drv.h"
#include "mtk_drm_gem.h"
-static int mtk_drm_gem_object_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
+static int mtk_gem_object_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma);
static const struct vm_operations_struct vm_ops = {
.open = drm_gem_vm_open,
.close = drm_gem_vm_close,
};
-static const struct drm_gem_object_funcs mtk_drm_gem_object_funcs = {
- .free = mtk_drm_gem_free_object,
+static const struct drm_gem_object_funcs mtk_gem_object_funcs = {
+ .free = mtk_gem_free_object,
.get_sg_table = mtk_gem_prime_get_sg_table,
- .vmap = mtk_drm_gem_prime_vmap,
- .vunmap = mtk_drm_gem_prime_vunmap,
- .mmap = mtk_drm_gem_object_mmap,
+ .vmap = mtk_gem_prime_vmap,
+ .vunmap = mtk_gem_prime_vunmap,
+ .mmap = mtk_gem_object_mmap,
.vm_ops = &vm_ops,
};
-static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct drm_device *dev,
- unsigned long size)
+static struct mtk_gem_obj *mtk_gem_init(struct drm_device *dev,
+ unsigned long size)
{
- struct mtk_drm_gem_obj *mtk_gem_obj;
+ struct mtk_gem_obj *mtk_gem_obj;
int ret;
size = round_up(size, PAGE_SIZE);
@@ -42,7 +42,7 @@ static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct drm_device *dev,
if (!mtk_gem_obj)
return ERR_PTR(-ENOMEM);
- mtk_gem_obj->base.funcs = &mtk_drm_gem_object_funcs;
+ mtk_gem_obj->base.funcs = &mtk_gem_object_funcs;
ret = drm_gem_object_init(dev, &mtk_gem_obj->base, size);
if (ret < 0) {
@@ -54,15 +54,15 @@ static struct mtk_drm_gem_obj *mtk_drm_gem_init(struct drm_device *dev,
return mtk_gem_obj;
}
-struct mtk_drm_gem_obj *mtk_drm_gem_create(struct drm_device *dev,
- size_t size, bool alloc_kmap)
+struct mtk_gem_obj *mtk_gem_create(struct drm_device *dev,
+ size_t size, bool alloc_kmap)
{
struct mtk_drm_private *priv = dev->dev_private;
- struct mtk_drm_gem_obj *mtk_gem;
+ struct mtk_gem_obj *mtk_gem;
struct drm_gem_object *obj;
int ret;
- mtk_gem = mtk_drm_gem_init(dev, size);
+ mtk_gem = mtk_gem_init(dev, size);
if (IS_ERR(mtk_gem))
return ERR_CAST(mtk_gem);
@@ -97,9 +97,9 @@ struct mtk_drm_gem_obj *mtk_drm_gem_create(struct drm_device *dev,
return ERR_PTR(ret);
}
-void mtk_drm_gem_free_object(struct drm_gem_object *obj)
+void mtk_gem_free_object(struct drm_gem_object *obj)
{
- struct mtk_drm_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
+ struct mtk_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
struct mtk_drm_private *priv = obj->dev->dev_private;
if (mtk_gem->sg)
@@ -114,10 +114,10 @@ void mtk_drm_gem_free_object(struct drm_gem_object *obj)
kfree(mtk_gem);
}
-int mtk_drm_gem_dumb_create(struct drm_file *file_priv, struct drm_device *dev,
- struct drm_mode_create_dumb *args)
+int mtk_gem_dumb_create(struct drm_file *file_priv, struct drm_device *dev,
+ struct drm_mode_create_dumb *args)
{
- struct mtk_drm_gem_obj *mtk_gem;
+ struct mtk_gem_obj *mtk_gem;
int ret;
args->pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
@@ -130,7 +130,7 @@ int mtk_drm_gem_dumb_create(struct drm_file *file_priv, struct drm_device *dev,
args->size = args->pitch;
args->size *= args->height;
- mtk_gem = mtk_drm_gem_create(dev, args->size, false);
+ mtk_gem = mtk_gem_create(dev, args->size, false);
if (IS_ERR(mtk_gem))
return PTR_ERR(mtk_gem);
@@ -148,16 +148,16 @@ int mtk_drm_gem_dumb_create(struct drm_file *file_priv, struct drm_device *dev,
return 0;
err_handle_create:
- mtk_drm_gem_free_object(&mtk_gem->base);
+ mtk_gem_free_object(&mtk_gem->base);
return ret;
}
-static int mtk_drm_gem_object_mmap(struct drm_gem_object *obj,
- struct vm_area_struct *vma)
+static int mtk_gem_object_mmap(struct drm_gem_object *obj,
+ struct vm_area_struct *vma)
{
int ret;
- struct mtk_drm_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
+ struct mtk_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
struct mtk_drm_private *priv = obj->dev->dev_private;
/*
@@ -188,7 +188,7 @@ static int mtk_drm_gem_object_mmap(struct drm_gem_object *obj,
*/
struct sg_table *mtk_gem_prime_get_sg_table(struct drm_gem_object *obj)
{
- struct mtk_drm_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
+ struct mtk_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
struct mtk_drm_private *priv = obj->dev->dev_private;
struct sg_table *sgt;
int ret;
@@ -212,7 +212,7 @@ struct sg_table *mtk_gem_prime_get_sg_table(struct drm_gem_object *obj)
struct drm_gem_object *mtk_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach, struct sg_table *sg)
{
- struct mtk_drm_gem_obj *mtk_gem;
+ struct mtk_gem_obj *mtk_gem;
/* check if the entries in the sg_table are contiguous */
if (drm_prime_get_contiguous_size(sg) < attach->dmabuf->size) {
@@ -220,7 +220,7 @@ struct drm_gem_object *mtk_gem_prime_import_sg_table(struct drm_device *dev,
return ERR_PTR(-EINVAL);
}
- mtk_gem = mtk_drm_gem_init(dev, attach->dmabuf->size);
+ mtk_gem = mtk_gem_init(dev, attach->dmabuf->size);
if (IS_ERR(mtk_gem))
return ERR_CAST(mtk_gem);
@@ -230,9 +230,9 @@ struct drm_gem_object *mtk_gem_prime_import_sg_table(struct drm_device *dev,
return &mtk_gem->base;
}
-int mtk_drm_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map)
+int mtk_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map)
{
- struct mtk_drm_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
+ struct mtk_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
struct sg_table *sgt = NULL;
unsigned int npages;
@@ -270,10 +270,9 @@ int mtk_drm_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map)
return 0;
}
-void mtk_drm_gem_prime_vunmap(struct drm_gem_object *obj,
- struct iosys_map *map)
+void mtk_gem_prime_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
{
- struct mtk_drm_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
+ struct mtk_gem_obj *mtk_gem = to_mtk_gem_obj(obj);
void *vaddr = map->vaddr;
if (!mtk_gem->pages)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_gem.h b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
index 78f23b07a02e2..66e5f154f6980 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_gem.h
+++ b/drivers/gpu/drm/mediatek/mtk_drm_gem.h
@@ -3,8 +3,8 @@
* Copyright (c) 2015 MediaTek Inc.
*/
-#ifndef _MTK_DRM_GEM_H_
-#define _MTK_DRM_GEM_H_
+#ifndef _MTK_GEM_H_
+#define _MTK_GEM_H_
#include <drm/drm_gem.h>
@@ -22,7 +22,7 @@
* P.S. this object would be transferred to user as kms_bo.handle so
* user can access the buffer through kms_bo.handle.
*/
-struct mtk_drm_gem_obj {
+struct mtk_gem_obj {
struct drm_gem_object base;
void *cookie;
void *kvaddr;
@@ -32,18 +32,17 @@ struct mtk_drm_gem_obj {
struct page **pages;
};
-#define to_mtk_gem_obj(x) container_of(x, struct mtk_drm_gem_obj, base)
+#define to_mtk_gem_obj(x) container_of(x, struct mtk_gem_obj, base)
-void mtk_drm_gem_free_object(struct drm_gem_object *gem);
-struct mtk_drm_gem_obj *mtk_drm_gem_create(struct drm_device *dev, size_t size,
- bool alloc_kmap);
-int mtk_drm_gem_dumb_create(struct drm_file *file_priv, struct drm_device *dev,
- struct drm_mode_create_dumb *args);
+void mtk_gem_free_object(struct drm_gem_object *gem);
+struct mtk_gem_obj *mtk_gem_create(struct drm_device *dev, size_t size,
+ bool alloc_kmap);
+int mtk_gem_dumb_create(struct drm_file *file_priv, struct drm_device *dev,
+ struct drm_mode_create_dumb *args);
struct sg_table *mtk_gem_prime_get_sg_table(struct drm_gem_object *obj);
struct drm_gem_object *mtk_gem_prime_import_sg_table(struct drm_device *dev,
struct dma_buf_attachment *attach, struct sg_table *sg);
-int mtk_drm_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map);
-void mtk_drm_gem_prime_vunmap(struct drm_gem_object *obj,
- struct iosys_map *map);
+int mtk_gem_prime_vmap(struct drm_gem_object *obj, struct iosys_map *map);
+void mtk_gem_prime_vunmap(struct drm_gem_object *obj, struct iosys_map *map);
#endif
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_plane.c b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
index 43137c46fc148..db63a32c407e3 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_plane.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_plane.c
@@ -135,7 +135,7 @@ static void mtk_plane_update_new_state(struct drm_plane_state *new_state,
{
struct drm_framebuffer *fb = new_state->fb;
struct drm_gem_object *gem;
- struct mtk_drm_gem_obj *mtk_gem;
+ struct mtk_gem_obj *mtk_gem;
unsigned int pitch, format;
u64 modifier;
dma_addr_t addr;
--
2.18.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: [v10,20/27] drm/connector: hdmi: Add Infoframes generation
From: Jani Nikula @ 2024-03-22 9:22 UTC (permalink / raw)
To: Sui Jingfeng, Maxime Ripard, Maarten Lankhorst, Thomas Zimmermann,
David Airlie, Daniel Vetter, Jonathan Corbet, Sandy Huang,
Heiko Stübner, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland
Cc: Hans Verkuil, Sebastian Wick, Ville Syrjälä, dri-devel,
linux-arm-kernel, linux-doc, linux-kernel, linux-media,
linux-rockchip, linux-sunxi
In-Reply-To: <07125064-2a78-4515-bb48-655f2aec140f@linux.dev>
On Fri, 22 Mar 2024, Sui Jingfeng <sui.jingfeng@linux.dev> wrote:
> Hi,
>
>
> On 2024/3/21 23:29, Maxime Ripard wrote:
>> Infoframes in KMS is usually handled by a bunch of low-level helpers
>> that require quite some boilerplate for drivers. This leads to
>> discrepancies with how drivers generate them, and which are actually
>> sent.
>>
>> Now that we have everything needed to generate them in the HDMI
>> connector state, we can generate them in our common logic so that
>> drivers can simply reuse what we precomputed.
>>
>> Signed-off-by: Maxime Ripard <mripard@kernel.org>
>> ---
>> drivers/gpu/drm/Kconfig | 1 +
>> drivers/gpu/drm/drm_atomic_state_helper.c | 338 +++++++++++++++++++++
>> drivers/gpu/drm/drm_connector.c | 14 +
>> .../gpu/drm/tests/drm_atomic_state_helper_test.c | 1 +
>> drivers/gpu/drm/tests/drm_connector_test.c | 12 +
>> include/drm/drm_atomic_state_helper.h | 8 +
>> include/drm/drm_connector.h | 109 +++++++
>> 7 files changed, 483 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>> index 16029435b750..3d3193c7aa5f 100644
>> --- a/drivers/gpu/drm/Kconfig
>> +++ b/drivers/gpu/drm/Kconfig
>> @@ -97,10 +97,11 @@ config DRM_KUNIT_TEST
>> If in doubt, say "N".
>>
>> config DRM_KMS_HELPER
>> tristate
>> depends on DRM
>> + select DRM_DISPLAY_HDMI_HELPER
>
> Should we select DRM_DISPLAY_HELPER here? Otherwise there will have some compile error
> emerged with default config.
Can we stop abusing select instead of adding more selects to paper over
the issues?
Use select only for non-visible symbols (no prompts anywhere) and for
symbols with no dependencies.
BR,
Jani.
>
>
> : drivers/gpu/drm/drm_atomic_state_helper.o: in function `drm_atomic_helper_connector_hdmi_check':
> drm_atomic_state_helper.c:(.text+0x15e4): undefined reference to `drm_hdmi_avi_infoframe_colorimetry'
> : drm_atomic_state_helper.c:(.text+0x15f0): undefined reference to `drm_hdmi_avi_infoframe_bars'
> : drm_atomic_state_helper.c:(.text+0x1638): undefined reference to `drm_hdmi_infoframe_set_hdr_metadata'
> make[2]: *** [scripts/Makefile.vmlinux:37: vmlinux] Error 1
>
> make[1]: *** [/home/suijingfeng/UpStream/drm-tip/Makefile:1162: vmlinux] Error 2
>
> make[1]: *** Waiting for unfinished jobs....
> make: *** [Makefile:240: __sub-make] Error 2
>
>> help
>> CRTC helpers for KMS drivers.
>>
>> config DRM_DEBUG_DP_MST_TOPOLOGY_REFS
>> bool "Enable refcount backtrace history in the DP MST helpers"
--
Jani Nikula, Intel
_______________________________________________
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