* [PATCH 1/2] dt-bindings: serial: add generic DT binding for announcing RTS/CTS lines
From: Erwan Le Ray @ 2020-05-20 13:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre Torgue, Sumit Semwal
Cc: linux-kernel, dri-devel, linaro-mm-sig, Erwan Le Ray,
linux-serial, Fabrice Gasnier, linux-stm32, linux-arm-kernel,
linux-media
In-Reply-To: <20200520133932.30441-1-erwan.leray@st.com>
Add support of generic DT binding for annoucing RTS/CTS lines. The initial
binding 'st,hw-flow-control' is not needed anymore since generic binding
is available, but is kept for backward compatibility.
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
index 75b8521eb7cb..06d5f251ec88 100644
--- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
+++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml
@@ -35,9 +35,11 @@ properties:
description: label associated with this uart
st,hw-flow-ctrl:
- description: enable hardware flow control
+ description: enable hardware flow control (deprecated)
$ref: /schemas/types.yaml#/definitions/flag
+ uart-has-rtscts: true
+
dmas:
minItems: 1
maxItems: 2
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] serial: stm32: Use generic DT binding for announcing RTS/CTS lines
From: Erwan Le Ray @ 2020-05-20 13:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Mark Rutland, Maxime Coquelin,
Alexandre Torgue, Sumit Semwal
Cc: linux-kernel, dri-devel, linaro-mm-sig, Erwan Le Ray,
linux-serial, Fabrice Gasnier, linux-stm32, linux-arm-kernel,
linux-media
In-Reply-To: <20200520133932.30441-1-erwan.leray@st.com>
Add support of generic DT binding for annoucing RTS/CTS lines. The initial
binding 'st,hw-flow-control' is not needed anymore since generic binding
is available, but is kept for backward compatibility.
Signed-off-by: Erwan Le Ray <erwan.leray@st.com>
diff --git a/drivers/tty/serial/stm32-usart.c b/drivers/tty/serial/stm32-usart.c
index 17c2f3276888..9cfcf355567a 100644
--- a/drivers/tty/serial/stm32-usart.c
+++ b/drivers/tty/serial/stm32-usart.c
@@ -1033,8 +1033,9 @@ static struct stm32_port *stm32_of_get_stm32_port(struct platform_device *pdev)
if (WARN_ON(id >= STM32_MAX_PORTS))
return NULL;
- stm32_ports[id].hw_flow_control = of_property_read_bool(np,
- "st,hw-flow-ctrl");
+ stm32_ports[id].hw_flow_control =
+ of_property_read_bool (np, "st,hw-flow-ctrl") /*deprecated*/ ||
+ of_property_read_bool (np, "uart-has-rtscts");
stm32_ports[id].port.line = id;
stm32_ports[id].cr1_irq = USART_CR1_RXNEIE;
stm32_ports[id].cr3_irq = 0;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [next] i2c: mediatek: Use div_u64 for 64-bit division to fix 32-bit kernels
From: Wolfram Sang @ 2020-05-20 13:29 UTC (permalink / raw)
To: qii.wang
Cc: devicetree, srv_heupstream, leilk.liu, linux-kernel,
linux-mediatek, linux-i2c, linux-arm-kernel
In-Reply-To: <1589970713-19944-1-git-send-email-qii.wang@mediatek.com>
[-- Attachment #1.1: Type: text/plain, Size: 440 bytes --]
On Wed, May 20, 2020 at 06:31:53PM +0800, qii.wang@mediatek.com wrote:
> From: Qii Wang <qii.wang@mediatek.com>
>
> Use div_u64 for 64-bit division, and change sample_ns type to
> unsigned int. Otherwise, the module will reference __udivdi3
> under 32-bit kernels, which is not allowed in kernel space.
>
> Signed-off-by: Qii Wang <qii.wang@mediatek.com>
Applied to for-next by squashing it into the relevant commit, thanks!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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
* [PATCH] hwrng: exynos - fix runtime pm imbalance on error
From: Dinghao Liu @ 2020-05-20 13:19 UTC (permalink / raw)
To: dinghao.liu, kjlu
Cc: linux-samsung-soc, Herbert Xu, Arnd Bergmann, Greg Kroah-Hartman,
Łukasz Stelmach, linux-kernel, Krzysztof Kozlowski,
Kukjin Kim, linux-crypto, Matt Mackall, linux-arm-kernel
pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a pairing decrement is needed
on the error handling path to keep the counter balanced.
Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn>
---
drivers/char/hw_random/exynos-trng.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/char/hw_random/exynos-trng.c b/drivers/char/hw_random/exynos-trng.c
index 8e1fe3f8dd2d..133e017db577 100644
--- a/drivers/char/hw_random/exynos-trng.c
+++ b/drivers/char/hw_random/exynos-trng.c
@@ -165,9 +165,8 @@ static int exynos_trng_probe(struct platform_device *pdev)
clk_disable_unprepare(trng->clk);
err_clock:
- pm_runtime_put_sync(&pdev->dev);
-
err_pm_get:
+ pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
return ret;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 3/4] arm64: cpufeature: Modify address authentication cpufeature to exact
From: Suzuki K Poulose @ 2020-05-20 13:20 UTC (permalink / raw)
To: amit.kachhap, catalin.marinas
Cc: mark.rutland, keescook, kristina.martsenko, broonie, james.morse,
Vincenzo.Frascino, will, dave.martin, linux-arm-kernel
In-Reply-To: <ba6de270-fd9c-d623-69a1-f3340898336f@arm.com>
On 05/13/2020 04:42 PM, Amit Kachhap wrote:
>
>
> On 5/12/20 11:03 PM, Catalin Marinas wrote:
>> On Fri, May 08, 2020 at 09:51:53PM +0530, Amit Kachhap wrote:
>>> On 5/6/20 10:43 PM, Catalin Marinas wrote:
>>>> On Tue, Apr 14, 2020 at 11:01:53AM +0530, Amit Daniel Kachhap wrote:
>>>>> This patch modifies the address authentication cpufeature type to
>>>>> EXACT
>>>>> from earlier LOWER_SAFE as the different configurations added for
>>>>> Armv8.6
>>>>> enhanced PAC have different behaviour and there is no tunable to
>>>>> enable the
>>>>> lower safe versions. The safe value is set as 0.
>>>>>
>>>>> After this change, if there is any variation in configurations in
>>>>> secondary
>>>>> cpus from boot cpu then those cpus are marked tainted. The KVM
>>>>> guests may
>>>>> completely disable address authentication if there is any such
>>>>> variations
>>>>> detected.
>>>>>
>>>>> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
>>>>> ---
>>>>> arch/arm64/kernel/cpufeature.c | 4 ++--
>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/arch/arm64/kernel/cpufeature.c
>>>>> b/arch/arm64/kernel/cpufeature.c
>>>>> index 08795025409c..599b03df2f93 100644
>>>>> --- a/arch/arm64/kernel/cpufeature.c
>>>>> +++ b/arch/arm64/kernel/cpufeature.c
>>>>> @@ -154,9 +154,9 @@ static const struct arm64_ftr_bits
>>>>> ftr_id_aa64isar1[] = {
>>>>> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
>>>>> ID_AA64ISAR1_FCMA_SHIFT, 4, 0),
>>>>> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
>>>>> ID_AA64ISAR1_JSCVT_SHIFT, 4, 0),
>>>>>
>>>>> ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
>>>>> - FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_API_SHIFT,
>>>>> 4, 0),
>>>>> + FTR_STRICT, FTR_EXACT, ID_AA64ISAR1_API_SHIFT, 4, 0),
>>>>>
>>>>> ARM64_FTR_BITS(FTR_VISIBLE_IF_IS_ENABLED(CONFIG_ARM64_PTR_AUTH),
>>>>> - FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR1_APA_SHIFT,
>>>>> 4, 0),
>>>>> + FTR_STRICT, FTR_EXACT, ID_AA64ISAR1_APA_SHIFT, 4, 0),
>>>>> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE,
>>>>> ID_AA64ISAR1_DPB_SHIFT, 4, 0),
>>>>> ARM64_FTR_END,
>>>>
>>>> Is this sufficient? If we have the boot CPU already enabling the
>>>> ptrauth
>>>> and we get a secondary CPU with a different ISAR1 field that matches
>>>> the
>>>> address auth in cpufeature.c, we still allow it to boot. We no longer
>>>> report the feature to the user system_supports_address_auth() is true
>>>> while system_supports_generic_auth() would be false as it checks the
>>>> sanitised feature registers.
>>>
>>> Yes agreed. Generic authentication also needs EXACT cpufeature type.
>>
>> I'm still not sure that's sufficient. If we boot the primary CPU with
>> ptrauth as detected in proc.S, we consider this a boot feature so all
>> secondary CPUs must have it. Subsequent CPUs are currently checked via
>> the arm64_features[] definitions and we allow them to boot if the ID is
>> at least that of the boot CPU. How does this interact with the above
>> FTR_EXACT changes?
>
> Unfortunately FTR_EXACT does not effect the bootflow directly but marks
> the cpu TAINTED and goes ahead.
>
>>
>> My concern is that we boot with PAC enabled on all CPUs but because of
>> the FTR_EXACT, the sanitised ID registers no longer report the feature.
>>
>
> You are right that PAC is enabled in hardware but un-reported to user in
> this case.
>
> The issue here is in feature_matches() which only validates with the
> entry->min_field_value. If we can modify this value to boot cpu value
> for FTR_EXACT type then this cpu will fail to online.
> May be we can introduce a new structure or make arm64_feature[] writable
> for this.
>
> Something like below code.
The has_cpuid_feature() is for features with "FTR_LOWER_SAFE". Hacking
it to support EXACT doesn't look ideal. You may simply add your own
"matches()" for ptr-auth.
something like :
static bool
has_addr_auth(const struct arm64_cpu_capabilities *entry, int scope)
{
static int boot_cpu_auth;
int local_cpu_auth;
u64 isar1;
/* We don't expect to be called with SCOPE_SYSTEM */
WARN_ON(scope == SCOPE_SYSTEM);
isar1 = read_sysreg_s(SYS_ID_AA64ISAR1_EL1);
local_cpu_auth = cpuid_feature_extract_unsigned_field(isar1, entry->shift);
/*
* The ptr-auth feature levels are not intercompatible with
* lower levels. Hence we must match all the CPUs with that
* of the boot CPU. So cache the level of boot CPU and compare
* it against the secondary CPUs.
*/
if (scope & SCOPE_BOOT_CPU) {
boot_cpu_auth = local_cpu_auth;
return boot_cpu_auth > 0;
} else if (scope & SCOPE_LOCAL_CPU) {
return local_cpu_auth == boot_cpu_auth;
}
}
Suzuki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/4] counter: Internalize sysfs interface code
From: kbuild test robot @ 2020-05-20 13:10 UTC (permalink / raw)
To: William Breathitt Gray, jic23
Cc: kamel.bouhara, gwendal, kbuild-all, david, linux-iio,
alexandre.belloni, linux-kernel, clang-built-linux, syednwaris,
linux-stm32, linux-arm-kernel
In-Reply-To: <733a915d9334c06bbe51928fb0f75d262d39bb02.1589654470.git.vilhelm.gray@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3280 bytes --]
Hi William,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.7-rc6 next-20200519]
[cannot apply to stm32/stm32-next linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/William-Breathitt-Gray/Introduce-the-Counter-character-device-interface/20200517-032530
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 12bf0b632ed090358cbf03e323e5342212d0b2e4
config: arm64-randconfig-r026-20200519 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 135b877874fae96b4372c8a3fbfaa8ff44ff86e3)
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm64 cross compiling tool for clang build
# apt-get install binutils-aarch64-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>, old ones prefixed by <<):
>> drivers/counter/counter-sysfs.c:850:5: warning: no previous prototype for function 'counter_sysfs_add' [-Wmissing-prototypes]
int counter_sysfs_add(struct counter_device *const counter)
^
drivers/counter/counter-sysfs.c:850:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
int counter_sysfs_add(struct counter_device *const counter)
^
static
>> drivers/counter/counter-sysfs.c:876:6: warning: no previous prototype for function 'counter_sysfs_free' [-Wmissing-prototypes]
void counter_sysfs_free(struct counter_device *const counter)
^
drivers/counter/counter-sysfs.c:876:1: note: declare 'static' if the function is not intended to be used outside of this translation unit
void counter_sysfs_free(struct counter_device *const counter)
^
static
2 warnings generated.
vim +/counter_sysfs_add +850 drivers/counter/counter-sysfs.c
849
> 850 int counter_sysfs_add(struct counter_device *const counter)
851 {
852 int err;
853
854 /* Initialize Synapse names list */
855 INIT_LIST_HEAD(&counter->dynamic_names_list);
856
857 /* Prepare device attributes */
858 err = counter_groups_list_prepare(counter);
859 if (err)
860 goto err_free_names;
861
862 /* Organize device attributes to groups and match to device */
863 err = counter_groups_prepare(counter);
864 if (err)
865 goto err_free_groups_list;
866
867 return 0;
868
869 err_free_groups_list:
870 counter_groups_list_free(counter);
871 err_free_names:
872 counter_dynamic_names_free(&counter->dynamic_names_list);
873 return err;
874 }
875
> 876 void counter_sysfs_free(struct counter_device *const counter)
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 38774 bytes --]
[-- Attachment #3: 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] iomm/arm-smmu: Add stall implementation hook
From: Will Deacon @ 2020-05-20 12:59 UTC (permalink / raw)
To: Sai Prakash Ranjan
Cc: linux-arm-msm, Joerg Roedel,
list@263.net:IOMMU DRIVERS , Joerg Roedel <joro@8bytes.org>, ,
Linux Kernel Mailing List, Rob Clark, Robin Murphy,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <a801e79a0a75092c28a6646ae7fa5e36@codeaurora.org>
On Wed, May 20, 2020 at 03:02:45PM +0530, Sai Prakash Ranjan wrote:
> On 2020-05-19 20:41, Rob Clark wrote:
> > On Tue, May 19, 2020 at 2:26 AM Sai Prakash Ranjan
> > <saiprakash.ranjan@codeaurora.org> wrote:
> > > On 2020-05-18 21:15, Will Deacon wrote:
> > > > So this sounds like an erratum to me, and I'm happy to set HUPCF if we
> > > > detect the broken implementation. However, it will need an entry in
> > > > Documentation/arm64/silicon-errata.rst and a decent comment in the
> > > > driver
> > > > to explain what we're doing and why.
> > > >
> > >
> > > AFAIK there is no erratum documented internally for this behaviour and
> > > this
> > > exists from MSM8996 SoC time and errata usually don't survive this
> > > long
> > > across generation of SoCs and there is no point for us in disguising
> > > it.
> >
> > possibly longer, qcom_iommu sets CFCFG..
> >
>
> Oh right, I was still in college when those SoCs were released ;)
>
> > > Is it OK if we clearly mention it as the "design limitation" or some
> > > other
> > > term which we can agree upon along with the description which Rob and
> > > Jordan
> > > provided for setting HUPCF in the driver when we add the set_hupcf
> > > callback?
> >
> > I'm not too picky on what we call it, but afaict it has been this way
> > since the beginning of time, rather than specific to a certain SoC or
> > generation of SoCs. So it doesn't seem like the hw designers consider
> > it a bug.
> >
> > (I'm not sure what the expected behavior is.. nor if any other SMMU
> > implementation encounters this sort of situation..)
>
> Yes, that was my point as well that its probably not counted as a bug
> by the hw designers. So I'm going to post setting HUPCF on QCOM
> implementation with clear comments based on yours and Jordan's description
> of this problem, but I wanted to have a way to set this only for GPU context
> bank and not GMU as Jordan mentioned earlier that GMU doesnt need HUPCF set.
> I was checking as to how do we map cb to device, if it was possible then we
> can have
> a compatibility thing like we did for identity mapping. Any ideas Robin?
Right, see my reply over at:
https://lore.kernel.org/r/20200520125700.GD25815@willie-the-truck
Hopefully something like that can be made to work.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4] ACPI/IORT: Fix PMCG node single ID mapping handling.
From: Lorenzo Pieralisi @ 2020-05-20 12:58 UTC (permalink / raw)
To: Tuan Phan
Cc: Neil Leeder, Hanjun Guo, Rafael J. Wysocki, linux-kernel,
Shameer Kolothum, linux-acpi, Sudeep Holla, patches, Robin Murphy,
linux-arm-kernel, Len Brown
In-Reply-To: <1589570686-5780-1-git-send-email-tuanphan@os.amperecomputing.com>
On Fri, May 15, 2020 at 12:24:46PM -0700, Tuan Phan wrote:
> An IORT PMCG node can have no ID mapping if its overflow interrupt is
> wire based therefore the code that parses the PMCG node can not assume
> the node will always have a single mapping present at index 0.
>
> Fix iort_get_id_mapping_index() by checking for an overflow interrupt
> and mapping count.
>
> Fixes: 24e516049360 ("ACPI/IORT: Add support for PMCG").
Remove these periods in the $SUBJECT and commit references, I
don't know why you keep adding them.
Anyway - I don't know if it is too late for v5.8 but this patch
is ready to be merged (minus the nits I have just mentioned).
Lorenzo
> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Reviewed-by: Hanjun Guo <guoahanjun@huawei.com>
> Signed-off-by: Tuan Phan <tuanphan@os.amperecomputing.com>
> ---
> v1 -> v2:
> - Use pmcg node to detect wired base overflow interrupt.
>
> v2 -> v3:
> - Address Hanjun and Robin's comments.
>
> v3 -> v4:
> - Update the title and description as mentioned by Lorenzo.
>
> drivers/acpi/arm64/iort.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index ed3d2d1..12bb70e 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -414,6 +414,7 @@ static struct acpi_iort_node *iort_node_get_id(struct acpi_iort_node *node,
> static int iort_get_id_mapping_index(struct acpi_iort_node *node)
> {
> struct acpi_iort_smmu_v3 *smmu;
> + struct acpi_iort_pmcg *pmcg;
>
> switch (node->type) {
> case ACPI_IORT_NODE_SMMU_V3:
> @@ -441,6 +442,10 @@ static int iort_get_id_mapping_index(struct acpi_iort_node *node)
>
> return smmu->id_mapping_index;
> case ACPI_IORT_NODE_PMCG:
> + pmcg = (struct acpi_iort_pmcg *)node->node_data;
> + if (pmcg->overflow_gsiv || node->mapping_count == 0)
> + return -EINVAL;
> +
> return 0;
> default:
> return -EINVAL;
> --
> 2.7.4
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v1 2/6] arm/smmu: Add auxiliary domain support for arm-smmuv2
From: Will Deacon @ 2020-05-20 12:57 UTC (permalink / raw)
To: Rob Clark
Cc: linux-arm-msm, Linux Kernel Mailing List,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Jordan Crouse, Robin Murphy,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAF6AEGswv3ZaJyy_kYv6FKAjO5=_juDwEtK+VE9TcVMLGvrdwA@mail.gmail.com>
On Mon, May 18, 2020 at 08:50:27AM -0700, Rob Clark wrote:
> On Mon, May 18, 2020 at 8:18 AM Will Deacon <will@kernel.org> wrote:
> > On Wed, Mar 18, 2020 at 04:43:07PM -0700, Rob Clark wrote:
> > > We do in fact need live domain switching, that is really the whole
> > > point. The GPU CP (command processor/parser) is directly updating
> > > TTBR0 and triggering TLB flush, asynchronously from the CPU.
> > >
> > > And I think the answer about ASID is easy (on current hw).. it must be zero[*].
> >
> > Using ASID zero is really bad, because it means that you will end up sharing
> > TLB entries with whichever device is using context bank 0.
> >
> > Is the SMMU only used by the GPU in your SoC?
> >
>
> yes, the snapdragon SoCs have two SMMU instances, one used by the GPU,
> where ASID0/cb0 is the gpu itself, and another cb is the GMU
> (basically power control for the gpu), and the second SMMU is
> everything else.
Right, in which case I'm starting to think that we should treat this GPU
SMMU instance specially. Give it its own compatible string (looks like you
need this for HUPCFG anyway) and hook in via arm_smmu_impl_init(). You can
then set IO_PGTABLE_QUIRK_ARM_TTBR1 when talking to the io-pgtable code
without having to add a domain attribute.
With that. you'll need to find a way to allow the GPU driver to call into
your own hooks for getting at the TTBR0 tables -- given that you're
programming these in the hardware, I don't think it makes sense to expose
that in the IOMMU API, since most devices won't be able to do anything with
that data. Perhaps you could install a couple of function pointers
(subdomain_alloc/subdomain_free) in the GPU device when you see it appear
from the SMMU driver? Alternatively, you could make an io_pgtable_cfg
available so that the GPU driver can interface with io-pgtable directly.
Yes, it's ugly, but I don't think it's worth trying to abstract this.
Thoughts? It's taken me a long time to figure out what's going on here,
so sorry if it feels like I'm leading you round the houses.
Will
_______________________________________________
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 3/4] kasan: add tests for call_rcu stack recording
From: Walter Wu @ 2020-05-20 12:37 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Matthias Brugger
Cc: Walter Wu, wsd_upstream, linux-kernel, kasan-dev, linux-mm,
linux-mediatek, linux-arm-kernel
Test call_rcu() call stack recording and verify whether it correctly
is printed in KASAN report.
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
---
lib/test_kasan.c | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index e3087d90e00d..6e5fb05d42d8 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -792,6 +792,35 @@ static noinline void __init vmalloc_oob(void)
static void __init vmalloc_oob(void) {}
#endif
+static struct kasan_rcu_info {
+ int i;
+ struct rcu_head rcu;
+} *global_ptr;
+
+static noinline void __init kasan_rcu_reclaim(struct rcu_head *rp)
+{
+ struct kasan_rcu_info *fp = container_of(rp,
+ struct kasan_rcu_info, rcu);
+
+ kfree(fp);
+ fp->i = 1;
+}
+
+static noinline void __init kasan_rcu_uaf(void)
+{
+ struct kasan_rcu_info *ptr;
+
+ pr_info("use-after-free in kasan_rcu_reclaim\n");
+ ptr = kmalloc(sizeof(struct kasan_rcu_info), GFP_KERNEL);
+ if (!ptr) {
+ pr_err("Allocation failed\n");
+ return;
+ }
+
+ global_ptr = rcu_dereference_protected(ptr, NULL);
+ call_rcu(&global_ptr->rcu, kasan_rcu_reclaim);
+}
+
static int __init kmalloc_tests_init(void)
{
/*
@@ -839,6 +868,7 @@ static int __init kmalloc_tests_init(void)
kasan_bitops();
kmalloc_double_kzfree();
vmalloc_oob();
+ kasan_rcu_uaf();
kasan_restore_multi_shot(multishot);
--
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 v5 4/4] kasan: update documentation for generic kasan
From: Walter Wu @ 2020-05-20 12:39 UTC (permalink / raw)
To: Andrey Ryabinin, Alexander Potapenko, Dmitry Vyukov,
Jonathan Corbet
Cc: Walter Wu, wsd_upstream, linux-kernel, kasan-dev, linux-mm,
linux-mediatek, linux-arm-kernel
Generic KASAN will support to record the last two call_rcu() call stacks
and print them in KASAN report. So that need to update documentation.
Signed-off-by: Walter Wu <walter-zh.wu@mediatek.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
---
Documentation/dev-tools/kasan.rst | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
index c652d740735d..fede42e6536b 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -193,6 +193,9 @@ function calls GCC directly inserts the code to check the shadow memory.
This option significantly enlarges kernel but it gives x1.1-x2 performance
boost over outline instrumented kernel.
+Generic KASAN prints up to 2 call_rcu() call stacks in reports, the last one
+and the second to last.
+
Software tag-based KASAN
~~~~~~~~~~~~~~~~~~~~~~~~
--
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 12/12] arm64: dts: k3-am65: Update the RM resource types
From: Lokesh Vutla @ 2020-05-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, Rob Herring
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Lokesh Vutla, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
In-Reply-To: <20200520124454.10532-1-lokeshvutla@ti.com>
Update the ringacc and udma dt nodes to use the latest RM resource types
similar to the ones used in k3-j721e dt nodes.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 12 ++++++------
arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 12 ++++++------
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 84fe71db7023..a3fb5c62d3bc 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -544,7 +544,7 @@
<0x0 0x33000000 0x0 0x40000>;
reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target";
ti,num-rings = <818>;
- ti,sci-rm-range-gp-rings = <0x2>; /* GP ring range */
+ ti,sci-rm-range-gp-rings = <0x1>; /* GP ring range */
ti,dma-ring-reset-quirk;
ti,sci = <&dmsc>;
ti,sci-dev-id = <187>;
@@ -564,11 +564,11 @@
ti,sci-dev-id = <188>;
ti,ringacc = <&ringacc>;
- ti,sci-rm-range-tchan = <0x1>, /* TX_HCHAN */
- <0x2>; /* TX_CHAN */
- ti,sci-rm-range-rchan = <0x4>, /* RX_HCHAN */
- <0x5>; /* RX_CHAN */
- ti,sci-rm-range-rflow = <0x6>; /* GP RFLOW */
+ ti,sci-rm-range-tchan = <0xf>, /* TX_HCHAN */
+ <0xd>; /* TX_CHAN */
+ ti,sci-rm-range-rchan = <0xb>, /* RX_HCHAN */
+ <0xa>; /* RX_CHAN */
+ ti,sci-rm-range-rflow = <0x0>; /* GP RFLOW */
};
};
diff --git a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
index 353d1e2532a7..adc7e19194fc 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi
@@ -134,7 +134,7 @@
<0x0 0x2a500000 0x0 0x40000>;
reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target";
ti,num-rings = <286>;
- ti,sci-rm-range-gp-rings = <0x2>; /* GP ring range */
+ ti,sci-rm-range-gp-rings = <0x1>; /* GP ring range */
ti,dma-ring-reset-quirk;
ti,sci = <&dmsc>;
ti,sci-dev-id = <195>;
@@ -154,11 +154,11 @@
ti,sci-dev-id = <194>;
ti,ringacc = <&mcu_ringacc>;
- ti,sci-rm-range-tchan = <0x1>, /* TX_HCHAN */
- <0x2>; /* TX_CHAN */
- ti,sci-rm-range-rchan = <0x3>, /* RX_HCHAN */
- <0x4>; /* RX_CHAN */
- ti,sci-rm-range-rflow = <0x5>; /* GP RFLOW */
+ ti,sci-rm-range-tchan = <0xf>, /* TX_HCHAN */
+ <0xd>; /* TX_CHAN */
+ ti,sci-rm-range-rchan = <0xb>, /* RX_HCHAN */
+ <0xa>; /* RX_CHAN */
+ ti,sci-rm-range-rflow = <0x0>; /* GP RFLOW */
};
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 11/12] arm64: dts: k3-am65: ti-sci-inta/intr: Update to latest bindings
From: Lokesh Vutla @ 2020-05-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, Rob Herring
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Lokesh Vutla, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Suman Anna,
Linux ARM Mailing List
In-Reply-To: <20200520124454.10532-1-lokeshvutla@ti.com>
Update the INTA and INTR dt nodes to the latest DT bindings.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 22 +++++++++----------
arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 8 +++----
.../arm64/boot/dts/ti/k3-am654-base-board.dts | 4 ++--
.../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 1 -
4 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
index 11887c72f23a..84fe71db7023 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi
@@ -372,10 +372,10 @@
ti,intr-trigger-type = <1>;
interrupt-controller;
interrupt-parent = <&gic500>;
- #interrupt-cells = <2>;
+ #interrupt-cells = <1>;
ti,sci = <&dmsc>;
- ti,sci-dst-id = <56>;
- ti,sci-rm-range-girq = <0x1>;
+ ti,sci-dev-id = <100>;
+ ti,interrupt-ranges = <0 392 32>;
};
main_navss {
@@ -393,10 +393,11 @@
ti,intr-trigger-type = <4>;
interrupt-controller;
interrupt-parent = <&gic500>;
- #interrupt-cells = <2>;
+ #interrupt-cells = <1>;
ti,sci = <&dmsc>;
- ti,sci-dst-id = <56>;
- ti,sci-rm-range-girq = <0x0>, <0x2>;
+ ti,sci-dev-id = <182>;
+ ti,interrupt-ranges = <0 64 64>,
+ <64 448 64>;
};
inta_main_udmass: interrupt-controller@33d00000 {
@@ -407,8 +408,7 @@
msi-controller;
ti,sci = <&dmsc>;
ti,sci-dev-id = <179>;
- ti,sci-rm-range-vint = <0x0>;
- ti,sci-rm-range-global-event = <0x1>;
+ ti,interrupt-ranges = <0 0 256>;
};
secure_proxy_main: mailbox@32c00000 {
@@ -578,8 +578,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&intr_main_gpio>;
- interrupts = <57 256>, <57 257>, <57 258>, <57 259>, <57 260>,
- <57 261>;
+ interrupts = <192>, <193>, <194>, <195>, <196>, <197>;
interrupt-controller;
#interrupt-cells = <2>;
ti,ngpio = <96>;
@@ -594,8 +593,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&intr_main_gpio>;
- interrupts = <58 256>, <58 257>, <58 258>, <58 259>, <58 260>,
- <58 261>;
+ interrupts = <200>, <201>, <202>, <203>, <204>, <205>;
interrupt-controller;
#interrupt-cells = <2>;
ti,ngpio = <90>;
diff --git a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
index f4227e2743f2..72295fa64f0e 100644
--- a/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi
@@ -69,10 +69,10 @@
ti,intr-trigger-type = <1>;
interrupt-controller;
interrupt-parent = <&gic500>;
- #interrupt-cells = <2>;
+ #interrupt-cells = <1>;
ti,sci = <&dmsc>;
- ti,sci-dst-id = <56>;
- ti,sci-rm-range-girq = <0x4>;
+ ti,sci-dev-id = <156>;
+ ti,interrupt-ranges = <0 712 16>;
};
wkup_gpio0: wkup_gpio0@42110000 {
@@ -81,7 +81,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&intr_wkup_gpio>;
- interrupts = <59 128>, <59 129>, <59 130>, <59 131>;
+ interrupts = <60>, <61>, <62>, <63>;
interrupt-controller;
#interrupt-cells = <2>;
ti,ngpio = <56>;
diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
index 2f3d3316a1cf..e58668f9fb59 100644
--- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts
@@ -359,7 +359,7 @@
};
&mailbox0_cluster0 {
- interrupts = <164 0>;
+ interrupts = <436>;
mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 {
ti,mbox-tx = <1 0 0>;
@@ -368,7 +368,7 @@
};
&mailbox0_cluster1 {
- interrupts = <165 0>;
+ interrupts = <432>;
mbox_mcu_r5fss0_core1: mbox-mcu-r5fss0-core1 {
ti,mbox-tx = <1 0 0>;
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
index a17074c8a172..cd1e782d08bd 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
@@ -100,7 +100,6 @@
ti,sci = <&dmsc>;
ti,sci-dev-id = <137>;
ti,interrupt-ranges = <16 960 16>;
- ti,sci-rm-range-girq = <0x5>;
};
wkup_gpio0: gpio@42110000 {
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 10/12] arm64: dts: k3-j721e: ti-sci-inta/intr: Update to latest bindings
From: Lokesh Vutla @ 2020-05-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, Rob Herring
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Lokesh Vutla, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
In-Reply-To: <20200520124454.10532-1-lokeshvutla@ti.com>
Update the INTA and INTR dt nodes to the latest DT bindings.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../dts/ti/k3-j721e-common-proc-board.dts | 10 ++---
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 41 ++++++++++---------
.../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 11 +++--
3 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
index 98e5e17e3ff7..022aa64d2911 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721e-common-proc-board.dts
@@ -223,7 +223,7 @@
};
&mailbox0_cluster0 {
- interrupts = <214 0>;
+ interrupts = <436>;
mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 {
ti,mbox-rx = <0 0 0>;
@@ -237,7 +237,7 @@
};
&mailbox0_cluster1 {
- interrupts = <215 0>;
+ interrupts = <432>;
mbox_main_r5fss0_core0: mbox-main-r5fss0-core0 {
ti,mbox-rx = <0 0 0>;
@@ -251,7 +251,7 @@
};
&mailbox0_cluster2 {
- interrupts = <216 0>;
+ interrupts = <428>;
mbox_main_r5fss1_core0: mbox-main-r5fss1-core0 {
ti,mbox-rx = <0 0 0>;
@@ -265,7 +265,7 @@
};
&mailbox0_cluster3 {
- interrupts = <217 0>;
+ interrupts = <424>;
mbox_c66_0: mbox-c66-0 {
ti,mbox-rx = <0 0 0>;
@@ -279,7 +279,7 @@
};
&mailbox0_cluster4 {
- interrupts = <218 0>;
+ interrupts = <420>;
mbox_c71_0: mbox-c71-0 {
ti,mbox-rx = <0 0 0>;
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
index 0b9d14b838a1..2c643190ce0b 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-main.dtsi
@@ -45,10 +45,10 @@
ti,intr-trigger-type = <1>;
interrupt-controller;
interrupt-parent = <&gic500>;
- #interrupt-cells = <2>;
+ #interrupt-cells = <1>;
ti,sci = <&dmsc>;
- ti,sci-dst-id = <14>;
- ti,sci-rm-range-girq = <0x1>;
+ ti,sci-dev-id = <131>;
+ ti,interrupt-ranges = <8 392 56>;
};
main_navss {
@@ -66,10 +66,12 @@
ti,intr-trigger-type = <4>;
interrupt-controller;
interrupt-parent = <&gic500>;
- #interrupt-cells = <2>;
+ #interrupt-cells = <1>;
ti,sci = <&dmsc>;
- ti,sci-dst-id = <14>;
- ti,sci-rm-range-girq = <0>, <2>;
+ ti,sci-dev-id = <213>;
+ ti,interrupt-ranges = <0 64 64>,
+ <64 448 64>,
+ <128 672 64>;
};
main_udmass_inta: interrupt-controller@33d00000 {
@@ -80,8 +82,7 @@
msi-controller;
ti,sci = <&dmsc>;
ti,sci-dev-id = <209>;
- ti,sci-rm-range-vint = <0xa>;
- ti,sci-rm-range-global-event = <0xd>;
+ ti,interrupt-ranges = <0 0 256>;
};
secure_proxy_main: mailbox@32c00000 {
@@ -401,8 +402,8 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&main_gpio_intr>;
- interrupts = <105 0>, <105 1>, <105 2>, <105 3>,
- <105 4>, <105 5>, <105 6>, <105 7>;
+ interrupts = <256>, <257>, <258>, <259>,
+ <260>, <261>, <262>, <263>;
interrupt-controller;
#interrupt-cells = <2>;
ti,ngpio = <128>;
@@ -418,7 +419,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&main_gpio_intr>;
- interrupts = <106 0>, <106 1>, <106 2>;
+ interrupts = <288>, <289>, <290>;
interrupt-controller;
#interrupt-cells = <2>;
ti,ngpio = <36>;
@@ -434,8 +435,8 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&main_gpio_intr>;
- interrupts = <107 0>, <107 1>, <107 2>, <107 3>,
- <107 4>, <107 5>, <107 6>, <107 7>;
+ interrupts = <264>, <265>, <266>, <267>,
+ <268>, <269>, <270>, <271>;
interrupt-controller;
#interrupt-cells = <2>;
ti,ngpio = <128>;
@@ -451,7 +452,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&main_gpio_intr>;
- interrupts = <108 0>, <108 1>, <108 2>;
+ interrupts = <292>, <293>, <294>;
interrupt-controller;
#interrupt-cells = <2>;
ti,ngpio = <36>;
@@ -467,8 +468,8 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&main_gpio_intr>;
- interrupts = <109 0>, <109 1>, <109 2>, <109 3>,
- <109 4>, <109 5>, <109 6>, <109 7>;
+ interrupts = <272>, <273>, <274>, <275>,
+ <276>, <277>, <278>, <279>;
interrupt-controller;
#interrupt-cells = <2>;
ti,ngpio = <128>;
@@ -484,7 +485,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&main_gpio_intr>;
- interrupts = <110 0>, <110 1>, <110 2>;
+ interrupts = <296>, <297>, <298>;
interrupt-controller;
#interrupt-cells = <2>;
ti,ngpio = <36>;
@@ -500,8 +501,8 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&main_gpio_intr>;
- interrupts = <111 0>, <111 1>, <111 2>, <111 3>,
- <111 4>, <111 5>, <111 6>, <111 7>;
+ interrupts = <280>, <281>, <282>, <283>,
+ <284>, <285>, <286>, <287>;
interrupt-controller;
#interrupt-cells = <2>;
ti,ngpio = <128>;
@@ -517,7 +518,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&main_gpio_intr>;
- interrupts = <112 0>, <112 1>, <112 2>;
+ interrupts = <300>, <301>, <302>;
interrupt-controller;
#interrupt-cells = <2>;
ti,ngpio = <36>;
diff --git a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
index 3d6064125b40..a17074c8a172 100644
--- a/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi
@@ -96,9 +96,10 @@
ti,intr-trigger-type = <1>;
interrupt-controller;
interrupt-parent = <&gic500>;
- #interrupt-cells = <2>;
+ #interrupt-cells = <1>;
ti,sci = <&dmsc>;
- ti,sci-dst-id = <14>;
+ ti,sci-dev-id = <137>;
+ ti,interrupt-ranges = <16 960 16>;
ti,sci-rm-range-girq = <0x5>;
};
@@ -108,8 +109,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&wkup_gpio_intr>;
- interrupts = <113 0>, <113 1>, <113 2>,
- <113 3>, <113 4>, <113 5>;
+ interrupts = <103>, <104>, <105>, <106>, <107>, <108>;
interrupt-controller;
#interrupt-cells = <2>;
ti,ngpio = <84>;
@@ -125,8 +125,7 @@
gpio-controller;
#gpio-cells = <2>;
interrupt-parent = <&wkup_gpio_intr>;
- interrupts = <114 0>, <114 1>, <114 2>,
- <114 3>, <114 4>, <114 5>;
+ interrupts = <112>, <113>, <114>, <115>, <116>, <117>;
interrupt-controller;
#interrupt-cells = <2>;
ti,ngpio = <84>;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 09/12] irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC
From: Lokesh Vutla @ 2020-05-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, Rob Herring
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Lokesh Vutla, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
In-Reply-To: <20200520124454.10532-1-lokeshvutla@ti.com>
Driver assumes that Interrupt parent to Interrupt Aggregator is always
Interrupt router. This is not true always and GIC can be a parent to
Interrupt Aggregator. Update the driver to detect the parent and request
the parent irqs accordingly.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/irqchip/irq-ti-sci-inta.c | 90 ++++++++++++++++++++++++++-----
1 file changed, 77 insertions(+), 13 deletions(-)
diff --git a/drivers/irqchip/irq-ti-sci-inta.c b/drivers/irqchip/irq-ti-sci-inta.c
index 7e3ebf6ed2cd..00c17ade118a 100644
--- a/drivers/irqchip/irq-ti-sci-inta.c
+++ b/drivers/irqchip/irq-ti-sci-inta.c
@@ -8,6 +8,7 @@
#include <linux/err.h>
#include <linux/io.h>
+#include <linux/irq.h>
#include <linux/irqchip.h>
#include <linux/irqdomain.h>
#include <linux/interrupt.h>
@@ -128,6 +129,37 @@ static void ti_sci_inta_irq_handler(struct irq_desc *desc)
chained_irq_exit(irq_desc_get_chip(desc), desc);
}
+/**
+ * ti_sci_inta_xlate_irq() - Translate hwirq to parent's hwirq.
+ * @inta: IRQ domain corresponding to Interrupt Aggregator
+ * @irq: Hardware irq corresponding to the above irq domain
+ *
+ * Return parent irq number if translation is available else -ENOENT.
+ */
+static int ti_sci_inta_xlate_irq(struct ti_sci_inta_irq_domain *inta,
+ u16 vint_id)
+{
+ struct device_node *np = dev_of_node(&inta->pdev->dev);
+ u32 base, parent_base, size;
+ const __be32 *range;
+ int len;
+
+ range = of_get_property(np, "ti,interrupt-ranges", &len);
+ if (!range)
+ return vint_id;
+
+ for (len /= sizeof(*range); len >= 3; len -= 3) {
+ base = be32_to_cpu(*range++);
+ parent_base = be32_to_cpu(*range++);
+ size = be32_to_cpu(*range++);
+
+ if (base <= vint_id && vint_id < base + size)
+ return vint_id - base + parent_base;
+ }
+
+ return -ENOENT;
+}
+
/**
* ti_sci_inta_alloc_parent_irq() - Allocate parent irq to Interrupt aggregator
* @domain: IRQ domain corresponding to Interrupt Aggregator
@@ -139,30 +171,55 @@ static struct ti_sci_inta_vint_desc *ti_sci_inta_alloc_parent_irq(struct irq_dom
struct ti_sci_inta_irq_domain *inta = domain->host_data;
struct ti_sci_inta_vint_desc *vint_desc;
struct irq_fwspec parent_fwspec;
+ struct device_node *parent_node;
unsigned int parent_virq;
- u16 vint_id;
+ u16 vint_id, p_hwirq;
+ int ret;
vint_id = ti_sci_get_free_resource(inta->vint);
if (vint_id == TI_SCI_RESOURCE_NULL)
return ERR_PTR(-EINVAL);
+ p_hwirq = ti_sci_inta_xlate_irq(inta, vint_id);
+ if (p_hwirq < 0) {
+ ret = p_hwirq;
+ goto free_vint;
+ }
+
vint_desc = kzalloc(sizeof(*vint_desc), GFP_KERNEL);
- if (!vint_desc)
- return ERR_PTR(-ENOMEM);
+ if (!vint_desc) {
+ ret = -ENOMEM;
+ goto free_vint;
+ }
vint_desc->domain = domain;
vint_desc->vint_id = vint_id;
INIT_LIST_HEAD(&vint_desc->list);
- parent_fwspec.fwnode = of_node_to_fwnode(of_irq_find_parent(dev_of_node(&inta->pdev->dev)));
- parent_fwspec.param_count = 2;
- parent_fwspec.param[0] = inta->pdev->id;
- parent_fwspec.param[1] = vint_desc->vint_id;
+ parent_node = of_irq_find_parent(dev_of_node(&inta->pdev->dev));
+ parent_fwspec.fwnode = of_node_to_fwnode(parent_node);
+ if (of_property_read_u32(parent_node, "#interrupt-cells",
+ &parent_fwspec.param_count)) {
+ ret = -EINVAL;
+ goto free_vint_desc;
+ }
+
+ if (of_device_is_compatible(parent_node, "arm,gic-v3")) {
+ /* Parent is GIC */
+ parent_fwspec.param[0] = 0;
+ parent_fwspec.param[1] = p_hwirq - 32;
+ parent_fwspec.param[2] = IRQ_TYPE_LEVEL_HIGH;
+ } else {
+ /* Parent is Interrupt Router */
+ parent_fwspec.param[0] = p_hwirq;
+ }
parent_virq = irq_create_fwspec_mapping(&parent_fwspec);
if (parent_virq == 0) {
- kfree(vint_desc);
- return ERR_PTR(-EINVAL);
+ dev_err(&inta->pdev->dev, "Parent IRQ allocation failed\n");
+ ret = -EINVAL;
+ goto free_vint_desc;
+
}
vint_desc->parent_virq = parent_virq;
@@ -171,6 +228,11 @@ static struct ti_sci_inta_vint_desc *ti_sci_inta_alloc_parent_irq(struct irq_dom
ti_sci_inta_irq_handler, vint_desc);
return vint_desc;
+free_vint_desc:
+ kfree(vint_desc);
+free_vint:
+ ti_sci_release_resource(inta->vint, vint_id);
+ return ERR_PTR(ret);
}
/**
@@ -555,15 +617,15 @@ static int ti_sci_inta_irq_domain_probe(struct platform_device *pdev)
return -EINVAL;
}
- inta->vint = devm_ti_sci_get_of_resource(inta->sci, dev, pdev->id,
- "ti,sci-rm-range-vint");
+ inta->vint = devm_ti_sci_get_resource(inta->sci, dev, pdev->id,
+ TI_SCI_RESASG_SUBTYPE_IA_VINT);
if (IS_ERR(inta->vint)) {
dev_err(dev, "VINT resource allocation failed\n");
return PTR_ERR(inta->vint);
}
- inta->global_event = devm_ti_sci_get_of_resource(inta->sci, dev, pdev->id,
- "ti,sci-rm-range-global-event");
+ inta->global_event = devm_ti_sci_get_resource(inta->sci, dev, pdev->id,
+ TI_SCI_RESASG_SUBTYPE_GLOBAL_EVENT_SEVT);
if (IS_ERR(inta->global_event)) {
dev_err(dev, "Global event resource allocation failed\n");
return PTR_ERR(inta->global_event);
@@ -594,6 +656,8 @@ static int ti_sci_inta_irq_domain_probe(struct platform_device *pdev)
INIT_LIST_HEAD(&inta->vint_list);
mutex_init(&inta->vint_mutex);
+ dev_info(dev, "Interrupt Aggregator domain %d created\n", pdev->id);
+
return 0;
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 08/12] dt-bindings: irqchip: Convert ti, sci-inta bindings to yaml
From: Lokesh Vutla @ 2020-05-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, Rob Herring
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Lokesh Vutla, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
In-Reply-To: <20200520124454.10532-1-lokeshvutla@ti.com>
In order to automate the verification of DT nodes convert
ti,sci-inta.txt ti,sci-inta.yaml.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../interrupt-controller/ti,sci-inta.txt | 66 -----------
.../interrupt-controller/ti,sci-inta.yaml | 104 ++++++++++++++++++
MAINTAINERS | 2 +-
3 files changed, 105 insertions(+), 67 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
deleted file mode 100644
index b14abec580a2..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
+++ /dev/null
@@ -1,66 +0,0 @@
-Texas Instruments K3 Interrupt Aggregator
-=========================================
-
-The Interrupt Aggregator (INTA) provides a centralized machine
-which handles the termination of system events to that they can
-be coherently processed by the host(s) in the system. A maximum
-of 64 events can be mapped to a single interrupt.
-
-
- Interrupt Aggregator
- +-----------------------------------------+
- | Intmap VINT |
- | +--------------+ +------------+ |
- m ------>| | vint | bit | | 0 |.....|63| vint0 |
- . | +--------------+ +------------+ | +------+
- . | . . | | HOST |
-Globalevents ------>| . . |------>| IRQ |
- . | . . | | CTRL |
- . | . . | +------+
- n ------>| +--------------+ +------------+ |
- | | vint | bit | | 0 |.....|63| vintx |
- | +--------------+ +------------+ |
- | |
- +-----------------------------------------+
-
-Configuration of these Intmap registers that maps global events to vint is done
-by a system controller (like the Device Memory and Security Controller on K3
-AM654 SoC). Driver should request the system controller to get the range
-of global events and vints assigned to the requesting host. Management
-of these requested resources should be handled by driver and requests
-system controller to map specific global event to vint, bit pair.
-
-Communication between the host processor running an OS and the system
-controller happens through a protocol called TI System Control Interface
-(TISCI protocol). For more details refer:
-Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
-
-TISCI Interrupt Aggregator Node:
--------------------------------
-- compatible: Must be "ti,sci-inta".
-- reg: Should contain registers location and length.
-- interrupt-controller: Identifies the node as an interrupt controller
-- msi-controller: Identifies the node as an MSI controller.
-- interrupt-parent: phandle of irq parent.
-- ti,sci: Phandle to TI-SCI compatible System controller node.
-- ti,sci-dev-id: TISCI device id of interrupt controller.
-- ti,interrupt-ranges: Set of triplets containing ranges that convert
- the INTA output interrupt numbers to parent's
- interrupt number. Each triplet has following entries:
- - First entry specifies the base for vint
- - Second entry specifies the base for parent irqs
- - Third entry specifies the limit
-
-
-Example:
---------
-main_udmass_inta: interrupt-controller@33d00000 {
- compatible = "ti,sci-inta";
- reg = <0x0 0x33d00000 0x0 0x100000>;
- interrupt-controller;
- msi-controller;
- interrupt-parent = <&main_navss_intr>;
- ti,sci = <&dmsc>;
- ti,sci-dev-id = <179>;
- interrupt-ranges = <0 0 256>;
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
new file mode 100644
index 000000000000..5e6cb76da45b
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
@@ -0,0 +1,104 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/ti,sci-inta.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 Interrupt Aggregator
+
+maintainers:
+ - Lokesh Vutla <lokeshvutla@ti.com>
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+description: |
+ The Interrupt Aggregator (INTA) provides a centralized machine
+ which handles the termination of system events to that they can
+ be coherently processed by the host(s) in the system. A maximum
+ of 64 events can be mapped to a single interrupt.
+
+ Interrupt Aggregator
+ +-----------------------------------------+
+ | Intmap VINT |
+ | +--------------+ +------------+ |
+ m ------>| | vint | bit | | 0 |.....|63| vint0 |
+ . | +--------------+ +------------+ | +------+
+ . | . . | | HOST |
+ Globalevents ------>| . . |----->| IRQ |
+ . | . . | | CTRL |
+ . | . . | +------+
+ n ------>| +--------------+ +------------+ |
+ | | vint | bit | | 0 |.....|63| vintx |
+ | +--------------+ +------------+ |
+ | |
+ +-----------------------------------------+
+
+ Configuration of these Intmap registers that maps global events to vint is
+ done by a system controller (like the Device Memory and Security Controller
+ on AM654 SoC). Driver should request the system controller to get the range
+ of global events and vints assigned to the requesting host. Management
+ of these requested resources should be handled by driver and requests
+ system controller to map specific global event to vint, bit pair.
+
+ Communication between the host processor running an OS and the system
+ controller happens through a protocol called TI System Control Interface
+ (TISCI protocol).
+
+properties:
+ compatible:
+ const: ti,sci-inta
+
+ reg:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ msi-controller: true
+
+ ti,sci:
+ description: phandle to TI-SCI compatible System controller node
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/phandle
+
+ ti,sci-dev-id:
+ description: TI-SCI device id of Interrupt Controller
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+
+ ti,interrupt-ranges:
+ description: |
+ Interrupt ranges that converts the INTR output hw irq numbers
+ to parents's input interrupt numbers.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ - items:
+ items:
+ - description: |
+ "output_irq" specifies the base for inta output irq
+ - description: |
+ "parent's input irq" specifies the base for parent irq
+ - description: |
+ "limit" specifies the limit for translation
+
+required:
+ - compatible
+ - reg
+ - interrupt-controller
+ - msi-controller
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,interrupt-ranges
+
+examples:
+ - |
+ main_udmass_inta: interrupt-controller@33d00000 {
+ compatible = "ti,sci-inta";
+ reg = <0x0 0x33d00000 0x0 0x100000>;
+ interrupt-controller;
+ msi-controller;
+ interrupt-parent = <&main_navss_intr>;
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <179>;
+ ti,interrupt-ranges = <0 0 256>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 56f69be90346..c0d65d1bc31f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16651,7 +16651,7 @@ L: linux-arm-kernel@lists.infradead.org
S: Maintained
F: Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
F: Documentation/devicetree/bindings/clock/ti,sci-clk.txt
-F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
+F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml
F: Documentation/devicetree/bindings/reset/ti,sci-reset.txt
F: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 07/12] dt-bindings: irqchip: ti, sci-inta: Update docs to support different parent.
From: Lokesh Vutla @ 2020-05-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, Rob Herring
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Lokesh Vutla, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
In-Reply-To: <20200520124454.10532-1-lokeshvutla@ti.com>
Drop the firmware related interrupt ranges and use the hardware specified
interrupt numbers within Interrupt Aggregator. This ensures interrupt
aggregator DT node need not assume any interrupt parent type.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../interrupt-controller/ti,sci-inta.txt | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
index 7841cb099e13..b14abec580a2 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
@@ -43,13 +43,14 @@ TISCI Interrupt Aggregator Node:
- msi-controller: Identifies the node as an MSI controller.
- interrupt-parent: phandle of irq parent.
- ti,sci: Phandle to TI-SCI compatible System controller node.
-- ti,sci-dev-id: TISCI device ID of the Interrupt Aggregator.
-- ti,sci-rm-range-vint: Array of TISCI subtype ids representing vints(inta
- outputs) range within this INTA, assigned to the
- requesting host context.
-- ti,sci-rm-range-global-event: Array of TISCI subtype ids representing the
- global events range reaching this IA and are assigned
- to the requesting host context.
+- ti,sci-dev-id: TISCI device id of interrupt controller.
+- ti,interrupt-ranges: Set of triplets containing ranges that convert
+ the INTA output interrupt numbers to parent's
+ interrupt number. Each triplet has following entries:
+ - First entry specifies the base for vint
+ - Second entry specifies the base for parent irqs
+ - Third entry specifies the limit
+
Example:
--------
@@ -61,6 +62,5 @@ main_udmass_inta: interrupt-controller@33d00000 {
interrupt-parent = <&main_navss_intr>;
ti,sci = <&dmsc>;
ti,sci-dev-id = <179>;
- ti,sci-rm-range-vint = <0x0>;
- ti,sci-rm-range-global-event = <0x1>;
+ interrupt-ranges = <0 0 256>;
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 06/12] irqchip/ti-sci-intr: Add support for INTR being a parent to INTR
From: Lokesh Vutla @ 2020-05-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, Rob Herring
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Lokesh Vutla, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
In-Reply-To: <20200520124454.10532-1-lokeshvutla@ti.com>
Driver assumes that Interrupt parent to Interrupt router is always GIC.
This is not true always and an Interrupt Router can be a parent to
Interrupt Router. Update the driver to detect the parent and request the
parent irqs accordingly.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/irqchip/irq-ti-sci-intr.c | 150 ++++++++++++++++++------------
1 file changed, 91 insertions(+), 59 deletions(-)
diff --git a/drivers/irqchip/irq-ti-sci-intr.c b/drivers/irqchip/irq-ti-sci-intr.c
index 59d51a20bbd8..0b73816e77fc 100644
--- a/drivers/irqchip/irq-ti-sci-intr.c
+++ b/drivers/irqchip/irq-ti-sci-intr.c
@@ -17,29 +17,18 @@
#include <linux/of_irq.h>
#include <linux/soc/ti/ti_sci_protocol.h>
-#define TI_SCI_DEV_ID_MASK 0xffff
-#define TI_SCI_DEV_ID_SHIFT 16
-#define TI_SCI_IRQ_ID_MASK 0xffff
-#define TI_SCI_IRQ_ID_SHIFT 0
-#define HWIRQ_TO_DEVID(hwirq) (((hwirq) >> (TI_SCI_DEV_ID_SHIFT)) & \
- (TI_SCI_DEV_ID_MASK))
-#define HWIRQ_TO_IRQID(hwirq) ((hwirq) & (TI_SCI_IRQ_ID_MASK))
-#define TO_HWIRQ(dev, index) ((((dev) & TI_SCI_DEV_ID_MASK) << \
- TI_SCI_DEV_ID_SHIFT) | \
- ((index) & TI_SCI_IRQ_ID_MASK))
-
/**
* struct ti_sci_intr_irq_domain - Structure representing a TISCI based
* Interrupt Router IRQ domain.
* @sci: Pointer to TISCI handle
- * @dst_irq: TISCI resource pointer representing GIC irq controller.
- * @dst_id: TISCI device ID of the GIC irq controller.
+ * @out_irqs: TISCI resource pointer representing INTR irqs.
+ * @pdev: Pointer to platform device.
* @type: Specifies the trigger type supported by this Interrupt Router
*/
struct ti_sci_intr_irq_domain {
const struct ti_sci_handle *sci;
- struct ti_sci_resource *dst_irq;
- u32 dst_id;
+ struct ti_sci_resource *out_irqs;
+ struct platform_device *pdev;
u32 type;
};
@@ -70,15 +59,44 @@ static int ti_sci_intr_irq_domain_translate(struct irq_domain *domain,
{
struct ti_sci_intr_irq_domain *intr = domain->host_data;
- if (fwspec->param_count != 2)
+ if (fwspec->param_count != 1)
return -EINVAL;
- *hwirq = TO_HWIRQ(fwspec->param[0], fwspec->param[1]);
+ *hwirq = fwspec->param[0];
*type = intr->type;
return 0;
}
+/**
+ * ti_sci_intr_xlate_irq() - Translate hwirq to parent's hwirq.
+ * @intr: IRQ domain corresponding to Interrupt Router
+ * @irq: Hardware irq corresponding to the above irq domain
+ *
+ * Return parent irq number if translation is available else -ENOENT.
+ */
+static int ti_sci_intr_xlate_irq(struct ti_sci_intr_irq_domain *intr, u32 irq)
+{
+ struct device_node *np = dev_of_node(&intr->pdev->dev);
+ u32 base, pbase, size, len;
+ const __be32 *range;
+
+ range = of_get_property(np, "ti,interrupt-ranges", &len);
+ if (!range)
+ return irq;
+
+ for (len /= sizeof(*range); len >= 3; len -= 3) {
+ base = be32_to_cpu(*range++);
+ pbase = be32_to_cpu(*range++);
+ size = be32_to_cpu(*range++);
+
+ if (base <= irq && irq < base + size)
+ return irq - base + pbase;
+ }
+
+ return -ENOENT;
+}
+
/**
* ti_sci_intr_irq_domain_free() - Free the specified IRQs from the domain.
* @domain: Domain to which the irqs belong
@@ -89,66 +107,77 @@ static void ti_sci_intr_irq_domain_free(struct irq_domain *domain,
unsigned int virq, unsigned int nr_irqs)
{
struct ti_sci_intr_irq_domain *intr = domain->host_data;
- struct irq_data *data, *parent_data;
- u16 dev_id, irq_index;
+ struct irq_data *data;
+ int out_irq;
- parent_data = irq_domain_get_irq_data(domain->parent, virq);
data = irq_domain_get_irq_data(domain, virq);
- irq_index = HWIRQ_TO_IRQID(data->hwirq);
- dev_id = HWIRQ_TO_DEVID(data->hwirq);
+ out_irq = (uintptr_t)data->chip_data;
- intr->sci->ops.rm_irq_ops.free_irq(intr->sci, dev_id, irq_index,
- intr->dst_id, parent_data->hwirq);
- ti_sci_release_resource(intr->dst_irq, parent_data->hwirq);
+ intr->sci->ops.rm_irq_ops.free_irq(intr->sci,
+ intr->pdev->id, data->hwirq,
+ intr->pdev->id, out_irq);
+ ti_sci_release_resource(intr->out_irqs, out_irq);
irq_domain_free_irqs_parent(domain, virq, 1);
irq_domain_reset_irq_data(data);
}
/**
- * ti_sci_intr_alloc_gic_irq() - Allocate GIC specific IRQ
+ * ti_sci_intr_alloc_parent_irq() - Allocate parent IRQ
* @domain: Pointer to the interrupt router IRQ domain
* @virq: Corresponding Linux virtual IRQ number
* @hwirq: Corresponding hwirq for the IRQ within this IRQ domain
*
- * Returns 0 if all went well else appropriate error pointer.
+ * Returns parent irq if all went well else appropriate error pointer.
*/
-static int ti_sci_intr_alloc_gic_irq(struct irq_domain *domain,
- unsigned int virq, u32 hwirq)
+static int ti_sci_intr_alloc_parent_irq(struct irq_domain *domain,
+ unsigned int virq, u32 hwirq)
{
struct ti_sci_intr_irq_domain *intr = domain->host_data;
+ struct device_node *parent_node;
struct irq_fwspec fwspec;
- u16 dev_id, irq_index;
- u16 dst_irq;
- int err;
-
- dev_id = HWIRQ_TO_DEVID(hwirq);
- irq_index = HWIRQ_TO_IRQID(hwirq);
+ u16 out_irq, p_hwirq;
+ int err = 0;
- dst_irq = ti_sci_get_free_resource(intr->dst_irq);
- if (dst_irq == TI_SCI_RESOURCE_NULL)
+ out_irq = ti_sci_get_free_resource(intr->out_irqs);
+ if (out_irq == TI_SCI_RESOURCE_NULL)
return -EINVAL;
- fwspec.fwnode = domain->parent->fwnode;
- fwspec.param_count = 3;
- fwspec.param[0] = 0; /* SPI */
- fwspec.param[1] = dst_irq - 32; /* SPI offset */
- fwspec.param[2] = intr->type;
+ p_hwirq = ti_sci_intr_xlate_irq(intr, out_irq);
+ if (p_hwirq < 0)
+ goto err_irqs;
+
+ parent_node = of_irq_find_parent(dev_of_node(&intr->pdev->dev));
+ fwspec.fwnode = of_node_to_fwnode(parent_node);
+ if (of_property_read_u32(parent_node, "#interrupt-cells",
+ &fwspec.param_count))
+ goto err_irqs;
+
+ if (of_device_is_compatible(parent_node, "arm,gic-v3")) {
+ /* Parent is GIC */
+ fwspec.param[0] = 0; /* SPI */
+ fwspec.param[1] = p_hwirq - 32; /* SPI offset */
+ fwspec.param[2] = intr->type;
+ } else {
+ /* Parent is Interrupt Router */
+ fwspec.param[0] = p_hwirq;
+ }
err = irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
if (err)
goto err_irqs;
- err = intr->sci->ops.rm_irq_ops.set_irq(intr->sci, dev_id, irq_index,
- intr->dst_id, dst_irq);
+ err = intr->sci->ops.rm_irq_ops.set_irq(intr->sci,
+ intr->pdev->id, hwirq,
+ intr->pdev->id, out_irq);
if (err)
goto err_msg;
- return 0;
+ return p_hwirq;
err_msg:
irq_domain_free_irqs_parent(domain, virq, 1);
err_irqs:
- ti_sci_release_resource(intr->dst_irq, dst_irq);
+ ti_sci_release_resource(intr->out_irqs, out_irq);
return err;
}
@@ -168,18 +197,19 @@ static int ti_sci_intr_irq_domain_alloc(struct irq_domain *domain,
struct irq_fwspec *fwspec = data;
unsigned long hwirq;
unsigned int flags;
- int err;
+ int err, p_hwirq;
err = ti_sci_intr_irq_domain_translate(domain, fwspec, &hwirq, &flags);
if (err)
return err;
- err = ti_sci_intr_alloc_gic_irq(domain, virq, hwirq);
- if (err)
- return err;
+ p_hwirq = ti_sci_intr_alloc_parent_irq(domain, virq, hwirq);
+ if (p_hwirq < 0)
+ return p_hwirq;
irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
- &ti_sci_intr_irq_chip, NULL);
+ &ti_sci_intr_irq_chip,
+ (void *)(uintptr_t)p_hwirq);
return 0;
}
@@ -214,6 +244,7 @@ static int ti_sci_intr_irq_domain_probe(struct platform_device *pdev)
if (!intr)
return -ENOMEM;
+ intr->pdev = pdev;
ret = of_property_read_u32(dev_of_node(dev), "ti,intr-trigger-type",
&intr->type);
if (ret) {
@@ -230,19 +261,18 @@ static int ti_sci_intr_irq_domain_probe(struct platform_device *pdev)
return ret;
}
- ret = of_property_read_u32(dev_of_node(dev), "ti,sci-dst-id",
- &intr->dst_id);
+ ret = of_property_read_u32(dev_of_node(dev), "ti,sci-dev-id",
+ &pdev->id);
if (ret) {
- dev_err(dev, "missing 'ti,sci-dst-id' property\n");
+ dev_err(dev, "missing 'ti,sci-dev-id' property\n");
return -EINVAL;
}
- intr->dst_irq = devm_ti_sci_get_of_resource(intr->sci, dev,
- intr->dst_id,
- "ti,sci-rm-range-girq");
- if (IS_ERR(intr->dst_irq)) {
+ intr->out_irqs = devm_ti_sci_get_resource(intr->sci, dev, pdev->id,
+ TI_SCI_RESASG_SUBTYPE_IR_OUTPUT);
+ if (IS_ERR(intr->out_irqs)) {
dev_err(dev, "Destination irq resource allocation failed\n");
- return PTR_ERR(intr->dst_irq);
+ return PTR_ERR(intr->out_irqs);
}
domain = irq_domain_add_hierarchy(parent_domain, 0, 0, dev_of_node(dev),
@@ -252,6 +282,8 @@ static int ti_sci_intr_irq_domain_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ dev_info(dev, "Interrupt Router %d domain created\n", pdev->id);
+
return 0;
}
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 05/12] dt-bindings: irqchip: Convert ti, sci-intr bindings to yaml
From: Lokesh Vutla @ 2020-05-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, Rob Herring
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Lokesh Vutla, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
In-Reply-To: <20200520124454.10532-1-lokeshvutla@ti.com>
In order to automate the verification of DT nodes convert
ti,sci-intr.txt ti,sci-intr.yaml.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../interrupt-controller/ti,sci-intr.txt | 83 -------------
.../interrupt-controller/ti,sci-intr.yaml | 113 ++++++++++++++++++
MAINTAINERS | 2 +-
3 files changed, 114 insertions(+), 84 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
deleted file mode 100644
index 8b56b2de1c73..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
+++ /dev/null
@@ -1,83 +0,0 @@
-Texas Instruments K3 Interrupt Router
-=====================================
-
-The Interrupt Router (INTR) module provides a mechanism to mux M
-interrupt inputs to N interrupt outputs, where all M inputs are selectable
-to be driven per N output. An Interrupt Router can either handle edge triggered
-or level triggered interrupts and that is fixed in hardware.
-
- Interrupt Router
- +----------------------+
- | Inputs Outputs |
- +-------+ | +------+ +-----+ |
- | GPIO |----------->| | irq0 | | 0 | | Host IRQ
- +-------+ | +------+ +-----+ | controller
- | . . | +-------+
- +-------+ | . . |----->| IRQ |
- | INTA |----------->| . . | +-------+
- +-------+ | . +-----+ |
- | +------+ | N | |
- | | irqM | +-----+ |
- | +------+ |
- | |
- +----------------------+
-
-There is one register per output (MUXCNTL_N) that controls the selection.
-Configuration of these MUXCNTL_N registers is done by a system controller
-(like the Device Memory and Security Controller on K3 AM654 SoC). System
-controller will keep track of the used and unused registers within the Router.
-Driver should request the system controller to get the range of GIC IRQs
-assigned to the requesting hosts. It is the drivers responsibility to keep
-track of Host IRQs.
-
-Communication between the host processor running an OS and the system
-controller happens through a protocol called TI System Control Interface
-(TISCI protocol). For more details refer:
-Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
-
-TISCI Interrupt Router Node:
-----------------------------
-Required Properties:
-- compatible: Must be "ti,sci-intr".
-- ti,intr-trigger-type: Should be one of the following:
- 1: If intr supports edge triggered interrupts.
- 4: If intr supports level triggered interrupts.
-- interrupt-controller: Identifies the node as an interrupt controller
-- #interrupt-cells: Specifies the number of cells needed to encode an
- interrupt source. The value should be 1.
- First cell should contain interrupt router input number
- as specified by hardware.
-- ti,sci: Phandle to TI-SCI compatible System controller node.
-- ti,sci-dev-id: TISCI device id of interrupt controller.
-- ti,interrupt-ranges: Set of triplets containing ranges that convert
- the INTR output interrupt numbers to parent's
- interrupt number. Each triplet has following entries:
- - First entry specifies the base for intr output irq
- - Second entry specifies the base for parent irqs
- - Third entry specifies the limit
-
-For more details on TISCI IRQ resource management refer:
-http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html
-
-Example:
---------
-The following example demonstrates both interrupt router node and the consumer
-node(main gpio) on the AM654 SoC:
-
-main_gpio_intr: interrupt-controller0 {
- compatible = "ti,sci-intr";
- ti,intr-trigger-type = <1>;
- interrupt-controller;
- interrupt-parent = <&gic500>;
- #interrupt-cells = <1>;
- ti,sci = <&dmsc>;
- ti,sci-dev-id = <131>;
- ti,interrupt-ranges = <0 360 32>;
-};
-
-main_gpio0: gpio@600000 {
- ...
- interrupt-parent = <&main_gpio_intr>;
- interrupts = <192>, <193>, <194>, <195>, <196>, <197>;
- ...
-};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml
new file mode 100644
index 000000000000..fbc1e8631d6f
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml
@@ -0,0 +1,113 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interrupt-controller/ti,sci-intr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments K3 Interrupt Router
+
+maintainers:
+ - Lokesh Vutla <lokeshvutla@ti.com>
+
+allOf:
+ - $ref: /schemas/interrupt-controller.yaml#
+
+description: |
+ The Interrupt Router (INTR) module provides a mechanism to mux M
+ interrupt inputs to N interrupt outputs, where all M inputs are selectable
+ to be driven per N output. An Interrupt Router can either handle edge
+ triggered or level triggered interrupts and that is fixed in hardware.
+
+ Interrupt Router
+ +----------------------+
+ | Inputs Outputs |
+ +-------+ | +------+ +-----+ |
+ | GPIO |----------->| | irq0 | | 0 | | Host IRQ
+ +-------+ | +------+ +-----+ | controller
+ | . . | +-------+
+ +-------+ | . . |----->| IRQ |
+ | INTA |----------->| . . | +-------+
+ +-------+ | . +-----+ |
+ | +------+ | N | |
+ | | irqM | +-----+ |
+ | +------+ |
+ | |
+ +----------------------+
+
+ There is one register per output (MUXCNTL_N) that controls the selection.
+ Configuration of these MUXCNTL_N registers is done by a system controller
+ (like the Device Memory and Security Controller on K3 AM654 SoC). System
+ controller will keep track of the used and unused registers within the Router.
+ Driver should request the system controller to get the range of GIC IRQs
+ assigned to the requesting hosts. It is the drivers responsibility to keep
+ track of Host IRQs.
+
+ Communication between the host processor running an OS and the system
+ controller happens through a protocol called TI System Control Interface
+ (TISCI protocol).
+
+properties:
+ compatible:
+ const: ti,sci-intr
+
+ ti,intr-trigger-type:
+ description: |
+ Should be one of the following.
+ 1 = If intr supports edge triggered interrupts.
+ 4 = If intr supports level triggered interrupts.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+
+ interrupt-controller: true
+
+ '#interrupt-cells':
+ const: 1
+ description: |
+ The 1st cell should contain interrupt router input hw number.
+
+ ti,sci:
+ description: phandle to TI-SCI compatible System controller node
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/phandle
+
+ ti,sci-dev-id:
+ description: TI-SCI device id of Interrupt Controller
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+
+ ti,interrupt-ranges:
+ description: |
+ Interrupt ranges that converts the INTR output hw irq numbers
+ to parents's input interrupt numbers.
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ - items:
+ items:
+ - description: |
+ "output_irq" specifies the base for intr output irq
+ - description: |
+ "parent's input irq" specifies the base for parent irq
+ - description: |
+ "limit" specifies the limit for translation
+
+required:
+ - compatible
+ - ti,intr-trigger-type
+ - interrupt-controller
+ - '#interrupt-cells'
+ - ti,sci
+ - ti,sci-dev-id
+ - ti,interrupt-ranges
+
+examples:
+ - |
+ main_gpio_intr: interrupt-controller0 {
+ compatible = "ti,sci-intr";
+ ti,intr-trigger-type = <1>;
+ interrupt-controller;
+ interrupt-parent = <&gic500>;
+ #interrupt-cells = <1>;
+ ti,sci = <&dmsc>;
+ ti,sci-dev-id = <131>;
+ ti,interrupt-ranges = <0 360 32>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 7b58ca29cc80..56f69be90346 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16652,7 +16652,7 @@ S: Maintained
F: Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
F: Documentation/devicetree/bindings/clock/ti,sci-clk.txt
F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
-F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
+F: Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml
F: Documentation/devicetree/bindings/reset/ti,sci-reset.txt
F: Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
F: drivers/clk/keystone/sci-clk.c
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 02/12] firmware: ti_sci: Drop unused structure ti_sci_rm_type_map
From: Lokesh Vutla @ 2020-05-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, Rob Herring
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Lokesh Vutla, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
In-Reply-To: <20200520124454.10532-1-lokeshvutla@ti.com>
struct ti_sci_rm_type_map is no longer used. Drop its definition and its
declarations.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/firmware/ti_sci.c | 56 +--------------------------------------
1 file changed, 1 insertion(+), 55 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 930a65ed78ad..a81ddec9e669 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -64,22 +64,6 @@ struct ti_sci_xfers_info {
spinlock_t xfer_lock;
};
-/**
- * struct ti_sci_rm_type_map - Structure representing TISCI Resource
- * management representation of dev_ids.
- * @dev_id: TISCI device ID
- * @type: Corresponding id as identified by TISCI RM.
- *
- * Note: This is used only as a work around for using RM range apis
- * for AM654 SoC. For future SoCs dev_id will be used as type
- * for RM range APIs. In order to maintain ABI backward compatibility
- * type is not being changed for AM654 SoC.
- */
-struct ti_sci_rm_type_map {
- u32 dev_id;
- u16 type;
-};
-
/**
* struct ti_sci_desc - Description of SoC integration
* @default_host_id: Host identifier representing the compute entity
@@ -87,14 +71,12 @@ struct ti_sci_rm_type_map {
* @max_msgs: Maximum number of messages that can be pending
* simultaneously in the system
* @max_msg_size: Maximum size of data per message that can be handled.
- * @rm_type_map: RM resource type mapping structure.
*/
struct ti_sci_desc {
u8 default_host_id;
int max_rx_timeout_ms;
int max_msgs;
int max_msg_size;
- struct ti_sci_rm_type_map *rm_type_map;
};
/**
@@ -1710,33 +1692,6 @@ static int ti_sci_cmd_core_reboot(const struct ti_sci_handle *handle)
return ret;
}
-static int ti_sci_get_resource_type(struct ti_sci_info *info, u16 dev_id,
- u16 *type)
-{
- struct ti_sci_rm_type_map *rm_type_map = info->desc->rm_type_map;
- bool found = false;
- int i;
-
- /* If map is not provided then assume dev_id is used as type */
- if (!rm_type_map) {
- *type = dev_id;
- return 0;
- }
-
- for (i = 0; rm_type_map[i].dev_id; i++) {
- if (rm_type_map[i].dev_id == dev_id) {
- *type = rm_type_map[i].type;
- found = true;
- break;
- }
- }
-
- if (!found)
- return -EINVAL;
-
- return 0;
-}
-
/**
* ti_sci_get_resource_range - Helper to get a range of resources assigned
* to a host. Resource is uniquely identified by
@@ -1760,7 +1715,6 @@ static int ti_sci_get_resource_range(const struct ti_sci_handle *handle,
struct ti_sci_xfer *xfer;
struct ti_sci_info *info;
struct device *dev;
- u16 type;
int ret = 0;
if (IS_ERR(handle))
@@ -1780,15 +1734,9 @@ static int ti_sci_get_resource_range(const struct ti_sci_handle *handle,
return ret;
}
- ret = ti_sci_get_resource_type(info, dev_id, &type);
- if (ret) {
- dev_err(dev, "rm type lookup failed for %u\n", dev_id);
- goto fail;
- }
-
req = (struct ti_sci_msg_req_get_resource_range *)xfer->xfer_buf;
req->secondary_host = s_host;
- req->type = type & MSG_RM_RESOURCE_TYPE_MASK;
+ req->type = dev_id & MSG_RM_RESOURCE_TYPE_MASK;
req->subtype = subtype & MSG_RM_RESOURCE_SUBTYPE_MASK;
ret = ti_sci_do_xfer(info, xfer);
@@ -3352,7 +3300,6 @@ static const struct ti_sci_desc ti_sci_pmmc_k2g_desc = {
/* Limited by MBOX_TX_QUEUE_LEN. K2G can handle upto 128 messages! */
.max_msgs = 20,
.max_msg_size = 64,
- .rm_type_map = NULL,
};
/* Description for AM654 */
@@ -3363,7 +3310,6 @@ static const struct ti_sci_desc ti_sci_pmmc_am654_desc = {
/* Limited by MBOX_TX_QUEUE_LEN. K2G can handle upto 128 messages! */
.max_msgs = 20,
.max_msg_size = 60,
- .rm_type_map = NULL,
};
static const struct of_device_id ti_sci_of_match[] = {
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 04/12] dt-bindings: irqchip: ti, sci-intr: Update bindings to drop the usage of gic as parent
From: Lokesh Vutla @ 2020-05-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, Rob Herring
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Lokesh Vutla, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
In-Reply-To: <20200520124454.10532-1-lokeshvutla@ti.com>
Drop the firmware related dt-bindings and use the hardware specified
interrupt numbers within Interrupt Router. This ensures interrupt router
DT node need not assume any interrupt parent type.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
.../interrupt-controller/ti,sci-intr.txt | 31 ++++++++++---------
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
index 1a8718f8855d..8b56b2de1c73 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
@@ -44,15 +44,17 @@ Required Properties:
4: If intr supports level triggered interrupts.
- interrupt-controller: Identifies the node as an interrupt controller
- #interrupt-cells: Specifies the number of cells needed to encode an
- interrupt source. The value should be 2.
- First cell should contain the TISCI device ID of source
- Second cell should contain the interrupt source offset
- within the device.
+ interrupt source. The value should be 1.
+ First cell should contain interrupt router input number
+ as specified by hardware.
- ti,sci: Phandle to TI-SCI compatible System controller node.
-- ti,sci-dst-id: TISCI device ID of the destination IRQ controller.
-- ti,sci-rm-range-girq: Array of TISCI subtype ids representing the host irqs
- assigned to this interrupt router. Each subtype id
- corresponds to a range of host irqs.
+- ti,sci-dev-id: TISCI device id of interrupt controller.
+- ti,interrupt-ranges: Set of triplets containing ranges that convert
+ the INTR output interrupt numbers to parent's
+ interrupt number. Each triplet has following entries:
+ - First entry specifies the base for intr output irq
+ - Second entry specifies the base for parent irqs
+ - Third entry specifies the limit
For more details on TISCI IRQ resource management refer:
http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/rm/rm_irq.html
@@ -62,21 +64,20 @@ Example:
The following example demonstrates both interrupt router node and the consumer
node(main gpio) on the AM654 SoC:
-main_intr: interrupt-controller0 {
+main_gpio_intr: interrupt-controller0 {
compatible = "ti,sci-intr";
ti,intr-trigger-type = <1>;
interrupt-controller;
interrupt-parent = <&gic500>;
- #interrupt-cells = <2>;
+ #interrupt-cells = <1>;
ti,sci = <&dmsc>;
- ti,sci-dst-id = <56>;
- ti,sci-rm-range-girq = <0x1>;
+ ti,sci-dev-id = <131>;
+ ti,interrupt-ranges = <0 360 32>;
};
main_gpio0: gpio@600000 {
...
- interrupt-parent = <&main_intr>;
- interrupts = <57 256>, <57 257>, <57 258>,
- <57 259>, <57 260>, <57 261>;
+ interrupt-parent = <&main_gpio_intr>;
+ interrupts = <192>, <193>, <194>, <195>, <196>, <197>;
...
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 00/12] irqchip: ti, sci-intr/inta: Update the dt bindings to accept different interrupt parents
From: Lokesh Vutla @ 2020-05-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, Rob Herring
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Lokesh Vutla, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
Hi Marc,
This is continuation of the RFC patches[0] regarding the driver
updates to support for following interrupt parent connection:
- INTR -> INTR
- INTA -> GICv3
The current existing driver assumes that INTR is always connected to
GICv3 and INTA is always connected to INTR.
As discussed this change breaks the DT backward compatibility but it
allows to not depend on TISCI firmware properties in DT node. IMHO, this
will ensure that any future changes will not effect DT properties.
[0] https://lore.kernel.org/linux-arm-kernel/20190923042405.26064-1-lokeshvutla@ti.com/
Thanks and regards,
Lokesh
Lokesh Vutla (12):
firmware: ti_sci: Drop the device id to resource type translation
firmware: ti_sci: Drop unused structure ti_sci_rm_type_map
firmware: ti_sci: Add support for getting resource with subtype
dt-bindings: irqchip: ti,sci-intr: Update bindings to drop the usage
of gic as parent
dt-bindings: irqchip: Convert ti,sci-intr bindings to yaml
irqchip/ti-sci-intr: Add support for INTR being a parent to INTR
dt-bindings: irqchip: ti,sci-inta: Update docs to support different
parent.
dt-bindings: irqchip: Convert ti,sci-inta bindings to yaml
irqchip/ti-sci-inta: Add support for INTA directly connecting to GIC
arm64: dts: k3-j721e: ti-sci-inta/intr: Update to latest bindings
arm64: dts: k3-am65: ti-sci-inta/intr: Update to latest bindings
arm64: dts: k3-am65: Update the RM resource types
.../interrupt-controller/ti,sci-inta.txt | 66 --------
.../interrupt-controller/ti,sci-inta.yaml | 104 ++++++++++++
.../interrupt-controller/ti,sci-intr.txt | 82 ---------
.../interrupt-controller/ti,sci-intr.yaml | 113 +++++++++++++
MAINTAINERS | 4 +-
arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 34 ++--
arch/arm64/boot/dts/ti/k3-am65-mcu.dtsi | 12 +-
arch/arm64/boot/dts/ti/k3-am65-wakeup.dtsi | 8 +-
.../arm64/boot/dts/ti/k3-am654-base-board.dts | 4 +-
.../dts/ti/k3-j721e-common-proc-board.dts | 10 +-
arch/arm64/boot/dts/ti/k3-j721e-main.dtsi | 41 ++---
.../boot/dts/ti/k3-j721e-mcu-wakeup.dtsi | 12 +-
drivers/firmware/ti_sci.c | 155 ++++++++----------
drivers/irqchip/irq-ti-sci-inta.c | 90 ++++++++--
drivers/irqchip/irq-ti-sci-intr.c | 150 ++++++++++-------
include/linux/soc/ti/ti_sci_protocol.h | 13 ++
16 files changed, 527 insertions(+), 371 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.txt
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml
delete mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.txt
create mode 100644 Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 01/12] firmware: ti_sci: Drop the device id to resource type translation
From: Lokesh Vutla @ 2020-05-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, Rob Herring
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Lokesh Vutla, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
In-Reply-To: <20200520124454.10532-1-lokeshvutla@ti.com>
With ABI 3.0, sysfw deprecated special resource types used for AM65x
SoC. Instead started using device id as resource type similar to the
convention used in J721E SOC.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/firmware/ti_sci.c | 12 +-----------
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index 4126be9e3216..930a65ed78ad 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -3355,16 +3355,6 @@ static const struct ti_sci_desc ti_sci_pmmc_k2g_desc = {
.rm_type_map = NULL,
};
-static struct ti_sci_rm_type_map ti_sci_am654_rm_type_map[] = {
- {.dev_id = 56, .type = 0x00b}, /* GIC_IRQ */
- {.dev_id = 179, .type = 0x000}, /* MAIN_NAV_UDMASS_IA0 */
- {.dev_id = 187, .type = 0x009}, /* MAIN_NAV_RA */
- {.dev_id = 188, .type = 0x006}, /* MAIN_NAV_UDMAP */
- {.dev_id = 194, .type = 0x007}, /* MCU_NAV_UDMAP */
- {.dev_id = 195, .type = 0x00a}, /* MCU_NAV_RA */
- {.dev_id = 0, .type = 0x000}, /* end of table */
-};
-
/* Description for AM654 */
static const struct ti_sci_desc ti_sci_pmmc_am654_desc = {
.default_host_id = 12,
@@ -3373,7 +3363,7 @@ static const struct ti_sci_desc ti_sci_pmmc_am654_desc = {
/* Limited by MBOX_TX_QUEUE_LEN. K2G can handle upto 128 messages! */
.max_msgs = 20,
.max_msg_size = 60,
- .rm_type_map = ti_sci_am654_rm_type_map,
+ .rm_type_map = NULL,
};
static const struct of_device_id ti_sci_of_match[] = {
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 03/12] firmware: ti_sci: Add support for getting resource with subtype
From: Lokesh Vutla @ 2020-05-20 12:44 UTC (permalink / raw)
To: Marc Zyngier, Rob Herring
Cc: Nishanth Menon, Peter Ujfalusi, Grygorii Strashko,
Device Tree Mailing List, Lokesh Vutla, Sekhar Nori, Tero Kristo,
Santosh Shilimkar, Thomas Gleixner, Linux ARM Mailing List
In-Reply-To: <20200520124454.10532-1-lokeshvutla@ti.com>
With SYSFW ABI 3.0 changes, interrupts coming out of an interrupt
controller is identified by a type and it is consistent across SoCs.
Similarly global events for Interrupt aggregator. So add an API to get
resource range using a resource type.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
drivers/firmware/ti_sci.c | 89 +++++++++++++++++++-------
include/linux/soc/ti/ti_sci_protocol.h | 13 ++++
2 files changed, 80 insertions(+), 22 deletions(-)
diff --git a/drivers/firmware/ti_sci.c b/drivers/firmware/ti_sci.c
index a81ddec9e669..918117be4a73 100644
--- a/drivers/firmware/ti_sci.c
+++ b/drivers/firmware/ti_sci.c
@@ -3208,61 +3208,50 @@ u32 ti_sci_get_num_resources(struct ti_sci_resource *res)
EXPORT_SYMBOL_GPL(ti_sci_get_num_resources);
/**
- * devm_ti_sci_get_of_resource() - Get a TISCI resource assigned to a device
+ * devm_ti_sci_get_resource_sets() - Get a TISCI resources assigned to a device
* @handle: TISCI handle
* @dev: Device pointer to which the resource is assigned
* @dev_id: TISCI device id to which the resource is assigned
- * @of_prop: property name by which the resource are represented
+ * @sub_types: Array of sub_types assigned corresponding to device
+ * @sets: Number of sub_types
*
* Return: Pointer to ti_sci_resource if all went well else appropriate
* error pointer.
*/
-struct ti_sci_resource *
-devm_ti_sci_get_of_resource(const struct ti_sci_handle *handle,
- struct device *dev, u32 dev_id, char *of_prop)
+static struct ti_sci_resource *
+devm_ti_sci_get_resource_sets(const struct ti_sci_handle *handle,
+ struct device *dev, u32 dev_id, u32 *sub_types,
+ u32 sets)
{
struct ti_sci_resource *res;
bool valid_set = false;
- u32 resource_subtype;
int i, ret;
res = devm_kzalloc(dev, sizeof(*res), GFP_KERNEL);
if (!res)
return ERR_PTR(-ENOMEM);
- ret = of_property_count_elems_of_size(dev_of_node(dev), of_prop,
- sizeof(u32));
- if (ret < 0) {
- dev_err(dev, "%s resource type ids not available\n", of_prop);
- return ERR_PTR(ret);
- }
- res->sets = ret;
-
+ res->sets = sets;
res->desc = devm_kcalloc(dev, res->sets, sizeof(*res->desc),
GFP_KERNEL);
if (!res->desc)
return ERR_PTR(-ENOMEM);
for (i = 0; i < res->sets; i++) {
- ret = of_property_read_u32_index(dev_of_node(dev), of_prop, i,
- &resource_subtype);
- if (ret)
- return ERR_PTR(-EINVAL);
-
ret = handle->ops.rm_core_ops.get_range(handle, dev_id,
- resource_subtype,
+ sub_types[i],
&res->desc[i].start,
&res->desc[i].num);
if (ret) {
dev_dbg(dev, "dev = %d subtype %d not allocated for this host\n",
- dev_id, resource_subtype);
+ dev_id, sub_types[i]);
res->desc[i].start = 0;
res->desc[i].num = 0;
continue;
}
dev_dbg(dev, "dev = %d, subtype = %d, start = %d, num = %d\n",
- dev_id, resource_subtype, res->desc[i].start,
+ dev_id, sub_types[i], res->desc[i].start,
res->desc[i].num);
valid_set = true;
@@ -3280,6 +3269,62 @@ devm_ti_sci_get_of_resource(const struct ti_sci_handle *handle,
return ERR_PTR(-EINVAL);
}
+/**
+ * devm_ti_sci_get_of_resource() - Get a TISCI resource assigned to a device
+ * @handle: TISCI handle
+ * @dev: Device pointer to which the resource is assigned
+ * @dev_id: TISCI device id to which the resource is assigned
+ * @of_prop: property name by which the resource are represented
+ *
+ * Return: Pointer to ti_sci_resource if all went well else appropriate
+ * error pointer.
+ */
+struct ti_sci_resource *
+devm_ti_sci_get_of_resource(const struct ti_sci_handle *handle,
+ struct device *dev, u32 dev_id, char *of_prop)
+{
+ struct ti_sci_resource *res;
+ u32 *sub_types;
+ int sets;
+
+ sets = of_property_count_elems_of_size(dev_of_node(dev), of_prop,
+ sizeof(u32));
+ if (sets < 0) {
+ dev_err(dev, "%s resource type ids not available\n", of_prop);
+ return ERR_PTR(sets);
+ }
+
+ sub_types = kcalloc(sets, sizeof(*sub_types), GFP_KERNEL);
+ if (!sub_types)
+ return ERR_PTR(-ENOMEM);
+
+ of_property_read_u32_array(dev_of_node(dev), of_prop, sub_types, sets);
+ res = devm_ti_sci_get_resource_sets(handle, dev, dev_id, sub_types,
+ sets);
+
+ kfree(sub_types);
+ return res;
+}
+EXPORT_SYMBOL_GPL(devm_ti_sci_get_of_resource);
+
+/**
+ * devm_ti_sci_get_resource() - Get a resource range assigned to the device
+ * @handle: TISCI handle
+ * @dev: Device pointer to which the resource is assigned
+ * @dev_id: TISCI device id to which the resource is assigned
+ * @suub_type: TISCI resource subytpe representing the resource.
+ *
+ * Return: Pointer to ti_sci_resource if all went well else appropriate
+ * error pointer.
+ */
+struct ti_sci_resource *
+devm_ti_sci_get_resource(const struct ti_sci_handle *handle, struct device *dev,
+ u32 dev_id, u32 sub_type)
+{
+ return devm_ti_sci_get_resource_sets(handle, dev, dev_id, &sub_type, 1);
+}
+EXPORT_SYMBOL_GPL(devm_ti_sci_get_resource);
+
static int tisci_reboot_handler(struct notifier_block *nb, unsigned long mode,
void *cmd)
{
diff --git a/include/linux/soc/ti/ti_sci_protocol.h b/include/linux/soc/ti/ti_sci_protocol.h
index 9531ec823298..68e47f6324be 100644
--- a/include/linux/soc/ti/ti_sci_protocol.h
+++ b/include/linux/soc/ti/ti_sci_protocol.h
@@ -220,6 +220,9 @@ struct ti_sci_rm_core_ops {
u16 *range_start, u16 *range_num);
};
+#define TI_SCI_RESASG_SUBTYPE_IR_OUTPUT 0
+#define TI_SCI_RESASG_SUBTYPE_IA_VINT 0xa
+#define TI_SCI_RESASG_SUBTYPE_GLOBAL_EVENT_SEVT 0xd
/**
* struct ti_sci_rm_irq_ops: IRQ management operations
* @set_irq: Set an IRQ route between the requested source
@@ -556,6 +559,9 @@ u32 ti_sci_get_num_resources(struct ti_sci_resource *res);
struct ti_sci_resource *
devm_ti_sci_get_of_resource(const struct ti_sci_handle *handle,
struct device *dev, u32 dev_id, char *of_prop);
+struct ti_sci_resource *
+devm_ti_sci_get_resource(const struct ti_sci_handle *handle, struct device *dev,
+ u32 dev_id, u32 sub_type);
#else /* CONFIG_TI_SCI_PROTOCOL */
@@ -609,6 +615,13 @@ devm_ti_sci_get_of_resource(const struct ti_sci_handle *handle,
{
return ERR_PTR(-EINVAL);
}
+
+static inline struct ti_sci_resource *
+devm_ti_sci_get_resource(const struct ti_sci_handle *handle, struct device *dev,
+ u32 dev_id, u32 sub_type);
+{
+ return ERR_PTR(-EINVAL);
+}
#endif /* CONFIG_TI_SCI_PROTOCOL */
#endif /* __TISCI_PROTOCOL_H */
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] perf/smmuv3: Allow sharing MMIO registers with the SMMU driver
From: Jean-Philippe Brucker @ 2020-05-20 12:44 UTC (permalink / raw)
To: Will Deacon
Cc: mark.rutland, iommu, lorenzo.pieralisi, robin.murphy,
linux-arm-kernel
In-Reply-To: <20200520122453.GB25815@willie-the-truck>
On Wed, May 20, 2020 at 01:24:53PM +0100, Will Deacon wrote:
> On Tue, Apr 21, 2020 at 05:57:46PM +0200, Jean-Philippe Brucker wrote:
> > Some Arm SMMUv3 implementations, for example Arm CoreLink MMU-600, embed
> > the PMCG registers into the SMMU MMIO regions. It currently causes probe
> > failure because the PMU and SMMU drivers request overlapping resources.
> >
> > Avoid the conflict by calling devm_ioremap() directly from the PMU
> > driver. We loose some sanity-checking of the memory map provided by
> > firmware, which doesn't seem catastrophic.
> >
> > Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
> > ---
> >
> > So this is the simplest solution, and I don't think we're missing much
> > by skipping the resource reservation. I've also been exploring a more
> > complex approach [1] which has the SMMU driver perform resource
> > reservation on behalf of the PMU driver, but I'm not sure it's
> > necessary.
> >
> > Please test, I've only tried the RevC FastModel using devicetree so far.
> >
> > [1] https://jpbrucker.net/git/linux/log/?h=smmu/pmu
> > ---
> > drivers/perf/arm_smmuv3_pmu.c | 28 +++++++++++++++++++++-------
> > 1 file changed, 21 insertions(+), 7 deletions(-)
>
> Is this patch still needed? I can't quite follow from the discussion.
No, it is superseded by "[PATCH v2] iommu/arm-smmu-v3: Don't reserve
implementation defined register space" that you applied yesterday
(Thanks!)
Jean
_______________________________________________
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