* [PATCH] clk: scpi: don't add cpufreq device if the scpi dvfs node is disabled
From: Sudeep Holla @ 2017-01-06 12:34 UTC (permalink / raw)
To: linux-arm-kernel
Currently we add the virtual cpufreq device unconditionally even when
the SCPI DVFS clock provider node is disabled. This will cause cpufreq
driver to throw errors when it gets initailised on boot/modprobe and
also when the CPUs are hot-plugged back in.
This patch fixes the issue by adding the virtual cpufreq device only if
the SCPI DVFS clock provider is available and registered.
Fixes: 9490f01e2471 ("clk: scpi: add support for cpufreq virtual device")
Reported-by: Micha? Zegan <webczat_200@poczta.onet.pl>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
---
drivers/clk/clk-scpi.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/clk-scpi.c b/drivers/clk/clk-scpi.c
index 2a3e9d8e88b0..96d37175d0ad 100644
--- a/drivers/clk/clk-scpi.c
+++ b/drivers/clk/clk-scpi.c
@@ -290,13 +290,15 @@ static int scpi_clocks_probe(struct platform_device *pdev)
of_node_put(child);
return ret;
}
- }
- /* Add the virtual cpufreq device */
- cpufreq_dev = platform_device_register_simple("scpi-cpufreq",
- -1, NULL, 0);
- if (IS_ERR(cpufreq_dev))
- pr_warn("unable to register cpufreq device");
+ if (match->data != &scpi_dvfs_ops)
+ continue;
+ /* Add the virtual cpufreq device if it's DVFS clock provider */
+ cpufreq_dev = platform_device_register_simple("scpi-cpufreq",
+ -1, NULL, 0);
+ if (IS_ERR(cpufreq_dev))
+ pr_warn("unable to register cpufreq device");
+ }
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH v4 2/5] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Javier Martinez Canillas @ 2017-01-06 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106114114.19321-3-andi.shyti@samsung.com>
Hello Andi,
On 01/06/2017 08:41 AM, Andi Shyti wrote:
> Currently tm2e dts includes tm2 but there are some differences
> between the two boards and tm2 has some properties that tm2e
> doesn't have.
>
> That's why it's important to keep the two dts files independent
> and put all the commonalities in a tm2-common.dtsi file.
>
> At the current status the only two differences between the two
> dts files (besides the board name) are ldo31 and ldo38.
>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
Patch looks good to me.
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
I've some comments though:
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> dissimilarity index 98%
> index e8971f4a5977..d30b45a9c0d4 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -1,1120 +1,33 @@
[snip]
> -
> -/ {
> - model = "Samsung TM2 board";
> - compatible = "samsung,tm2", "samsung,exynos5433";
> -
[snip]
> +
> +/ {
> + model = "Samsung TM2E board";
> + compatible = "samsung,tm2e", "samsung,exynos5433";
> +};
> +
You ended with the wrong model and compatible for TM2.
Speaking about these, I noticed that the common .dtsi has the TM2 model and
compatible. I think those don't belong to .dtsi files and instead should be
defined on each .dts file.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
^ permalink raw reply
* [PATCH v6 08/18] iommu/vt-d: Implement reserved region get/put callbacks
From: Joerg Roedel @ 2017-01-06 12:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <36bac0a9-89a6-ff7b-1870-a795a4f57700@redhat.com>
On Fri, Jan 06, 2017 at 12:45:54PM +0100, Auger Eric wrote:
> On 06/01/2017 12:01, Joerg Roedel wrote:
> > On Thu, Jan 05, 2017 at 07:04:36PM +0000, Eric Auger wrote:
> > That is different from what AMD does, can you also report the RMRR
> > regions for the device here (as direct-map regions)?
>
> if I return RMRR regions as direct mapped regions,
> iommu_group_create_direct_mappings will perform the 1-1 mapping.
No, this will not happen until the Intel IOMMU driver returns valid
IOMMU_DOMAIN_DMA type domains.
> I am not familiar with the intel-iommu code but I guess this job
> currently is done in the intel driver:
> iommu_prepare_rmrr_dev -> iommu_prepare_identity_map
> ->domain_prepare_identity_map -> iommu_domain_identity_map?
Right, this is done in the Intel driver atm.
Joerg
^ permalink raw reply
* [PATCH v6 07/18] iommu: Implement reserved_regions iommu-group sysfs file
From: Joerg Roedel @ 2017-01-06 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <888d3750-817c-77d1-8154-e77cf8c3ad4b@redhat.com>
On Fri, Jan 06, 2017 at 12:46:05PM +0100, Auger Eric wrote:
> On 06/01/2017 12:00, Joerg Roedel wrote:
> > I think it also makes sense to report the type of the reserved region.
>
> What is the best practice in that case? Shall we put the type enum
> values as strings such as:
> - direct
> - nomap
> - msi
>
> and document that in Documentation/ABI/testing/sysfs-kernel-iommu_groups
Yes, a string would be good. An probably 'reserved' is a better name
than nomap?
Joerg
^ permalink raw reply
* [PATCHv2 net-next 02/11] net: mvpp2: handle too large value in mvpp2_rx_time_coal_set()
From: Russell King - ARM Linux @ 2017-01-06 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482943567-12483-3-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Dec 28, 2016 at 05:45:58PM +0100, Thomas Petazzoni wrote:
> When configuring the MVPP2_ISR_RX_THRESHOLD_REG with the RX coalescing
> time threshold, we do not check for the maximum allowed value supported
> by the driver, which means we might overflow and use a bogus value. This
> commit adds a check for this situation, and if a value higher than what
> is supported by the hardware is provided, then we use the maximum value
> supported by the hardware.
>
> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> ---
> drivers/net/ethernet/marvell/mvpp2.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/net/ethernet/marvell/mvpp2.c b/drivers/net/ethernet/marvell/mvpp2.c
> index 02d91e4..a1ba89f 100644
> --- a/drivers/net/ethernet/marvell/mvpp2.c
> +++ b/drivers/net/ethernet/marvell/mvpp2.c
> @@ -154,6 +154,7 @@
>
> /* Interrupt Cause and Mask registers */
> #define MVPP2_ISR_RX_THRESHOLD_REG(rxq) (0x5200 + 4 * (rxq))
> +#define MVPP2_MAX_ISR_RX_THRESHOLD 0xfffff0
> #define MVPP2_ISR_RXQ_GROUP_REG(rxq) (0x5400 + 4 * (rxq))
> #define MVPP2_ISR_ENABLE_REG(port) (0x5420 + 4 * (port))
> #define MVPP2_ISR_ENABLE_INTERRUPT(mask) ((mask) & 0xffff)
> @@ -4397,6 +4398,12 @@ static void mvpp2_rx_time_coal_set(struct mvpp2_port *port,
> u32 val;
>
> val = (port->priv->tclk / USEC_PER_SEC) * usec;
> +
> + if (val > MVPP2_MAX_ISR_RX_THRESHOLD) {
> + val = MVPP2_MAX_ISR_RX_THRESHOLD;
> + usec = (val * USEC_PER_SEC) / port->priv->tclk;
> + }
> +
Beware of rounding and overflow errors. usec and val are u32's.
MVPP2_MAX_ISR_RX_THRESHOLD = 16777200
USEC_PER_SEC = 1000000
This equates to 0xF423F0BDC00 for the multiplication, which is a little
larger than 32-bit. Assuming tclk is 166.666666MHz (as it was on Dove
- I don't know what it would be here) and 64-bit arithmetic, the maximum
value gives 100663us.
Passing that back into the function gives... 16710058, so the second time
around, we end up with a different setting (even though a change wasn't
requested.)
However, 100664 won't trigger your check, neither will values all the way
up to 101067 - the reason being that you're losing so much precision by
dividling the clock by USEC_PER_SEC first. Only if it's a whole number
of MHz will you get away with that.
So, I'd suggest you switch to using 64 bit math here - it's not a fast
path. Using bc to evaluate val = port->priv->tclk * usec / USEC_PER_SEC
gives:
(166666666 * 100663 / 1000000)
16777166
which is as close as you can come to the limit.
So, I'd suggest (these variants round down, which is acceptable for
this implementation):
static u32 usec_to_cycles(u32 usec, unsigned long clock_rate_hz)
{
u64 tmp = clock_rate_hz * usec;
do_div(tmp, USEC_PER_SEC);
return tmp > 0xffffffff ? 0xffffffff : tmp;
}
static u32 cycles_to_usec(u32 cycles, unsigned long clock_rate_hz)
{
u64 tmp = cycles * USEC_PER_SEC;
do_div(tmp, clock_rate_hz);
return tmp > 0xffffffff ? 0xffffffff : tmp;
}
and:
u32 val = usec_to_cycles(usec, port->priv->tclk);
if (val > MVPP2_MAX_ISR_RX_THRESHOLD) {
usec = cycles_to_usec(MVPP2_MAX_ISR_RX_THRESHOLD,
port->priv->tclk);
/* re-evaluate to get actual register value for usec */
val = usec_to_cycles(usec, port->priv->tclk);
}
> mvpp2_write(port->priv, MVPP2_ISR_RX_THRESHOLD_REG(rxq->id), val);
>
> rxq->time_coal = usec;
This function appears to be called from two places:
mvpp2_rxq_init():
mvpp2_rx_time_coal_set(port, rxq, rxq->time_coal);
mvpp2_ethtool_set_coalesce():
rxq->time_coal = c->rx_coalesce_usecs;
mvpp2_rx_time_coal_set(port, rxq, rxq->time_coal);
It seems rather pointless to pass in rxq->time_coal when you're also
passing in rxq.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v6 08/18] iommu/vt-d: Implement reserved region get/put callbacks
From: Auger Eric @ 2017-01-06 13:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106124631.GP17255@8bytes.org>
Hi Joerg,
On 06/01/2017 13:46, Joerg Roedel wrote:
> On Fri, Jan 06, 2017 at 12:45:54PM +0100, Auger Eric wrote:
>> On 06/01/2017 12:01, Joerg Roedel wrote:
>>> On Thu, Jan 05, 2017 at 07:04:36PM +0000, Eric Auger wrote:
>
>>> That is different from what AMD does, can you also report the RMRR
>>> regions for the device here (as direct-map regions)?
>>
>> if I return RMRR regions as direct mapped regions,
>> iommu_group_create_direct_mappings will perform the 1-1 mapping.
>
> No, this will not happen until the Intel IOMMU driver returns valid
> IOMMU_DOMAIN_DMA type domains.
Hum OK thanks!
Best Regards
Eric
>
>> I am not familiar with the intel-iommu code but I guess this job
>> currently is done in the intel driver:
>> iommu_prepare_rmrr_dev -> iommu_prepare_identity_map
>> ->domain_prepare_identity_map -> iommu_domain_identity_map?
>
> Right, this is done in the Intel driver atm.
>
>
>
> Joerg
>
^ permalink raw reply
* [PATCH v6 07/18] iommu: Implement reserved_regions iommu-group sysfs file
From: Auger Eric @ 2017-01-06 13:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106124816.GQ17255@8bytes.org>
Hi,
On 06/01/2017 13:48, Joerg Roedel wrote:
> On Fri, Jan 06, 2017 at 12:46:05PM +0100, Auger Eric wrote:
>> On 06/01/2017 12:00, Joerg Roedel wrote:
>
>>> I think it also makes sense to report the type of the reserved region.
>>
>> What is the best practice in that case? Shall we put the type enum
>> values as strings such as:
>> - direct
>> - nomap
>> - msi
>>
>> and document that in Documentation/ABI/testing/sysfs-kernel-iommu_groups
>
> Yes, a string would be good. An probably 'reserved' is a better name
> than nomap?
OK that's equal to me.
Thanks
Eric
>
>
> Joerg
>
^ permalink raw reply
* [PATCH v6 01/18] iommu/dma: Allow MSI-only cookies
From: Auger Eric @ 2017-01-06 13:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ae222579-6939-b89a-80c2-9ee8f147299e@arm.com>
Hi Robin,
On 06/01/2017 13:12, Robin Murphy wrote:
> On 06/01/17 11:46, Auger Eric wrote:
>>
>>
>> On 06/01/2017 11:59, Joerg Roedel wrote:
>>> On Thu, Jan 05, 2017 at 07:04:29PM +0000, Eric Auger wrote:
>>>> struct iommu_dma_cookie {
>>>> - struct iova_domain iovad;
>>>> - struct list_head msi_page_list;
>>>> - spinlock_t msi_lock;
>>>> + union {
>>>> + struct iova_domain iovad;
>>>> + dma_addr_t msi_iova;
>>>> + };
>>>> + struct list_head msi_page_list;
>>>> + spinlock_t msi_lock;
>>>> + enum iommu_dma_cookie_type type;
>>>
>>> Please move the type to the beginning of the struct and add a comment
>>> how the type relates to the union.
>>
>> Sure
>>
>> Thank you for the review.
>
> FWIW I already had a cleaned up version of this patch, I just hadn't
> mentioned it. I've pushed out an update with that change added too[1].
>
> Robin.
>
> [1]:http://linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/misc
Great, thanks!
Eric
>
>>
>> Best regards
>>
>> Eric
>>>
>>>
>>>
>>> Joerg
>>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCHv2 net-next 09/11] net: mvpp2: simplify MVPP2_PRS_RI_* definitions
From: Russell King - ARM Linux @ 2017-01-06 13:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1482943567-12483-10-git-send-email-thomas.petazzoni@free-electrons.com>
On Wed, Dec 28, 2016 at 05:46:05PM +0100, Thomas Petazzoni wrote:
> Some of the MVPP2_PRS_RI_* definitions use the ~(value) syntax, which
> doesn't compile nicely on 64-bit. Moreover, those definitions are in
> fact unneeded, since they are always used in combination with a bit
> mask that ensures only the appropriate bits are modified.
>
> Therefore, such definitions should just be set to 0x0. For example:
>
> #define MVPP2_PRS_RI_L2_CAST_MASK 0x600
> #define MVPP2_PRS_RI_L2_UCAST ~(BIT(9) | BIT(10))
> #define MVPP2_PRS_RI_L2_MCAST BIT(9)
> #define MVPP2_PRS_RI_L2_BCAST BIT(10)
>
> becomes
>
> #define MVPP2_PRS_RI_L2_CAST_MASK 0x600
> #define MVPP2_PRS_RI_L2_UCAST 0x0
> #define MVPP2_PRS_RI_L2_MCAST BIT(9)
> #define MVPP2_PRS_RI_L2_BCAST BIT(10)
So this is a two-bit field in a register with three defined states - I'm
not sure that using BIT() here is really a good idea. BIT() is fine for
single-bit controls, but I think it adds an additional level of confusion
for multi-bit controls.
Also, the combination of the mask being defined as hex and the controls
using BIT() is particularly not nice. I think either use one style or
the other, don't mix them. So either:
#define MVPP2_PRS_RI_L2_CAST_MASK 0x600
#define MVPP2_PRS_RI_L2_UCAST 0x000
#define MVPP2_PRS_RI_L2_MCAST 0x200
#define MVPP2_PRS_RI_L2_BCAST 0x400
or:
#define MVPP2_PRS_RI_L2_CAST_MASK (BIT(10) | BIT(9))
#define MVPP2_PRS_RI_L2_UCAST 0
#define MVPP2_PRS_RI_L2_MCAST BIT(9)
#define MVPP2_PRS_RI_L2_BCAST BIT(10)
It then becomes obvious that the mask and the settings are changing the
same bits.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM64: dts: meson-gxbb-odroidc2: Disable SCPI DVFS
From: Michał Zegan @ 2017-01-06 13:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <83fd9b61-dbff-68e0-82e5-8e01058d04a9@arm.com>
Yes, I meant what you think I meant. :) thanks
W dniu 06.01.2017 o 12:54, Sudeep Holla pisze:
> Hi Micha?,
>
> On 05/01/17 19:04, Micha? Zegan wrote:
>> Hello.
>>
>> The patch causes cpufreq module (scpi-cpufreq) not to detect cpufreq, so
>> it actually works, but...
>> Loading the module causes few errors because of not found frequencies or
>> something, then it is all okay. However after loading scpi-cpufreq you
>> cannot actually power the cpu off and on. You will power it off
>> successfully, but when trying to power it on, the cpufreq driver will
>> error out,
>
> Yes I had noticed this in past, this needs to be fixed. I had a patch
> and seems like it slipped through the cracks. I will fins and post it.
>
>> and then after it happens, the cpu that was trying to go
>> online will be offline again, and that is a little... unfortunate. The
>
> IIUC, you mean the cpufreq drive spits error on every hotplug event ?
> If so yes, otherwise I think I didn't understand you concern above.
>
>> question is, and I cannot really test that: will the module actually
>> autoload after this change?
>>
>
> It should work, I had tested this in past.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 525 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170106/37f9d743/attachment.sig>
^ permalink raw reply
* [PATCH V9 3/3] irqchip: qcom: Add IRQ combiner driver
From: Agustin Vega-Frias @ 2017-01-06 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ded278ef-a0a2-811a-f362-70555f74d6fc@arm.com>
Hey Marc,
On 2017-01-05 11:48, Marc Zyngier wrote:
> Hi Agustin,
>
> On 14/12/16 22:10, Agustin Vega-Frias wrote:
>> Driver for interrupt combiners in the Top-level Control and Status
>> Registers (TCSR) hardware block in Qualcomm Technologies chips.
>>
>> An interrupt combiner in this block combines a set of interrupts by
>> OR'ing the individual interrupt signals into a summary interrupt
>> signal routed to a parent interrupt controller, and provides read-
>> only, 32-bit registers to query the status of individual interrupts.
>> The status bit for IRQ n is bit (n % 32) within register (n / 32)
>> of the given combiner. Thus, each combiner can be described as a set
>> of register offsets and the number of IRQs managed.
>>
>> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
>> ---
>> drivers/irqchip/Kconfig | 9 +
>> drivers/irqchip/Makefile | 1 +
>> drivers/irqchip/qcom-irq-combiner.c | 322
>> ++++++++++++++++++++++++++++++++++++
>> 3 files changed, 332 insertions(+)
>> create mode 100644 drivers/irqchip/qcom-irq-combiner.c
>>
>> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
>> index bc0af33..3e3430c 100644
>> --- a/drivers/irqchip/Kconfig
>> +++ b/drivers/irqchip/Kconfig
>> @@ -279,3 +279,12 @@ config EZNPS_GIC
>> config STM32_EXTI
>> bool
>> select IRQ_DOMAIN
>> +
>> +config QCOM_IRQ_COMBINER
>> + bool "QCOM IRQ combiner support"
>> + depends on ARCH_QCOM && ACPI
>> + select IRQ_DOMAIN
>> + select IRQ_DOMAIN_HIERARCHY
>> + help
>> + Say yes here to add support for the IRQ combiner devices embedded
>> + in Qualcomm Technologies chips.
>> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
>> index e4dbfc8..1818a0b 100644
>> --- a/drivers/irqchip/Makefile
>> +++ b/drivers/irqchip/Makefile
>> @@ -74,3 +74,4 @@ obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o
>> obj-$(CONFIG_EZNPS_GIC) += irq-eznps.o
>> obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o
>> obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
>> +obj-$(CONFIG_QCOM_IRQ_COMBINER) += qcom-irq-combiner.o
>> diff --git a/drivers/irqchip/qcom-irq-combiner.c
>> b/drivers/irqchip/qcom-irq-combiner.c
>> new file mode 100644
>> index 0000000..0055e08
>> --- /dev/null
>> +++ b/drivers/irqchip/qcom-irq-combiner.c
>> @@ -0,0 +1,322 @@
>> +/* Copyright (c) 2015-2016, The Linux Foundation. All rights
>> reserved.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> modify
>> + * it under the terms of the GNU General Public License version 2 and
>> + * only version 2 as published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + */
>> +
>> +/*
>> + * Driver for interrupt combiners in the Top-level Control and Status
>> + * Registers (TCSR) hardware block in Qualcomm Technologies chips.
>> + * An interrupt combiner in this block combines a set of interrupts
>> by
>> + * OR'ing the individual interrupt signals into a summary interrupt
>> + * signal routed to a parent interrupt controller, and provides read-
>> + * only, 32-bit registers to query the status of individual
>> interrupts.
>> + * The status bit for IRQ n is bit (n % 32) within register (n / 32)
>> + * of the given combiner. Thus, each combiner can be described as a
>> set
>> + * of register offsets and the number of IRQs managed.
>> + */
>> +
>> +#include <linux/acpi.h>
>> +#include <linux/irqchip/chained_irq.h>
>> +#include <linux/irqdomain.h>
>> +#include <linux/platform_device.h>
>> +
>> +#define REG_SIZE 32
>> +
>> +struct combiner_reg {
>> + void __iomem *addr;
>> + unsigned long mask;
>> +};
>> +
>> +struct combiner {
>> + struct irq_domain *domain;
>> + int parent_irq;
>> + u32 nirqs;
>> + u32 nregs;
>> + struct combiner_reg regs[0];
>> +};
>> +
>> +static inline u32 irq_register(int irq)
>> +{
>> + return irq / REG_SIZE;
>> +}
>> +
>> +static inline u32 irq_bit(int irq)
>> +{
>> + return irq % REG_SIZE;
>> +
>> +}
>> +
>> +static inline int irq_nr(u32 reg, u32 bit)
>> +{
>> + return reg * REG_SIZE + bit;
>> +}
>> +
>> +/*
>> + * Handler for the cascaded IRQ.
>> + */
>> +static void combiner_handle_irq(struct irq_desc *desc)
>> +{
>> + struct combiner *combiner = irq_desc_get_handler_data(desc);
>> + struct irq_chip *chip = irq_desc_get_chip(desc);
>> + u32 reg;
>> +
>> + chained_irq_enter(chip, desc);
>> +
>> + for (reg = 0; reg < combiner->nregs; reg++) {
>> + int virq;
>> + int hwirq;
>> + u32 bit;
>> + u32 status;
>> +
>> + if (combiner->regs[reg].mask == 0)
>> + continue;
>
> I'm a bit worried by this. If I understand it well, this is a pure
> software construct (controlled from combiner_irq_chip_{un,}mask_irq)
> and
> there is nothing that actually masks the interrupt at the HW level.
>
> So if a device asserts its interrupt line, what mechanism do we have to
> make sure that we don't end-up with the CPU pegged in interrupt
> context?
>
Yes, unfortunately this is a dumb hardware combiner; however, the real
use
of mask here is to optimize IRQ handling if the combiner instance has
its
IRQ statuses across more than one register. Currently all active
instances
only use one register, but we are getting close to 32 in one case, so I
wanted to accommodate a general case where an instance can combine more
than 32 IRQs.
Having said that, what I'm inclined to do is to remove the use of mask
on the status read form the register on the next two lines, and then let
irq_find_mapping fail if we are getting an unexpected IRQ, then call
handle_bad_irq(desc).
Do you have any other suggestions to handle the scenario? E.g., can we
safely disable the parent IRQ from this context if we see too many
spurious interrupts?
>> +
>> + status = readl_relaxed(combiner->regs[reg].addr);
>> + status &= combiner->regs[reg].mask;
>> +
>> + while (status) {
>> + bit = __ffs(status);
>> + status &= ~(1 << bit);
>> + hwirq = irq_nr(reg, bit);
>> + virq = irq_find_mapping(combiner->domain, hwirq);
>> + if (virq >= 0)
>
> Small bug: virq == 0 shouldn't happen, since this would be an
> indication
> that the hwirq doesn't have a mapping.
>
Will fix this on V10.
>> + generic_handle_irq(virq);
>> +
>> + }
>> + }
>> +
>> + chained_irq_exit(chip, desc);
>> +}
>> +
>> +/*
>> + * irqchip callbacks
>> + */
>> +
>> +static void combiner_irq_chip_mask_irq(struct irq_data *data)
>> +{
>> + struct combiner *combiner = irq_data_get_irq_chip_data(data);
>> + struct combiner_reg *reg = combiner->regs +
>> irq_register(data->hwirq);
>> +
>> + clear_bit(irq_bit(data->hwirq), ®->mask);
>> +}
>> +
>> +static void combiner_irq_chip_unmask_irq(struct irq_data *data)
>> +{
>> + struct combiner *combiner = irq_data_get_irq_chip_data(data);
>> + struct combiner_reg *reg = combiner->regs +
>> irq_register(data->hwirq);
>> +
>> + set_bit(irq_bit(data->hwirq), ®->mask);
>> +}
>> +
>> +static struct irq_chip irq_chip = {
>> + .irq_mask = combiner_irq_chip_mask_irq,
>> + .irq_unmask = combiner_irq_chip_unmask_irq,
>> + .name = "qcom-irq-combiner"
>> +};
>> +
>> +/*
>> + * irq_domain_ops callbacks
>> + */
>> +
>> +static int combiner_irq_map(struct irq_domain *domain, unsigned int
>> irq,
>> + irq_hw_number_t hwirq)
>> +{
>> + struct combiner *combiner = domain->host_data;
>> +
>> + if (hwirq >= combiner->nirqs)
>> + return -EINVAL;
>
> Given that this should have come from the translate function, can we
> move the check there instead, so that we validate everything early?
>
Will fix this on V10.
>> +
>> + irq_set_chip_and_handler(irq, &irq_chip, handle_level_irq);
>> + irq_set_chip_data(irq, combiner);
>> + irq_set_noprobe(irq);
>> + return 0;
>> +}
>> +
>> +static void combiner_irq_unmap(struct irq_domain *domain, unsigned
>> int irq)
>> +{
>> + struct irq_data *data = irq_get_irq_data(irq);
>> +
>> + if (WARN_ON(!data))
>> + return;
>
> Can this happen?
>
I will remove this check on V10 given that irq_domain_disassociate
already
has a check for a NULL irq_data.
>> + irq_domain_reset_irq_data(data);
>> +}
>> +
>> +static int combiner_irq_translate(struct irq_domain *d, struct
>> irq_fwspec *fws,
>> + unsigned long *hwirq, unsigned int *type)
>> +{
>> + if (is_acpi_node(fws->fwnode)) {
>> + if (WARN_ON((fws->param_count != 2) ||
>> + (fws->param[1] & IORESOURCE_IRQ_LOWEDGE) ||
>> + (fws->param[1] & IORESOURCE_IRQ_HIGHEDGE)))
>> + return -EINVAL;
>> +
>> + *hwirq = fws->param[0];
>> + *type = fws->param[1];
>> + return 0;
>> + }
>> +
>> + return -EINVAL;
>> +}
>> +
>> +static const struct irq_domain_ops domain_ops = {
>> + .map = combiner_irq_map,
>> + .unmap = combiner_irq_unmap,
>> + .translate = combiner_irq_translate
>> +};
>> +
>> +/*
>> + * Device probing
>> + */
>> +
>> +static acpi_status count_registers_cb(struct acpi_resource *ares,
>> void *context)
>> +{
>> + int *count = context;
>> +
>> + if (ares->type == ACPI_RESOURCE_TYPE_GENERIC_REGISTER)
>> + ++(*count);
>> + return AE_OK;
>> +}
>> +
>> +static int count_registers(struct platform_device *pdev)
>> +{
>> + struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
>> + acpi_status status;
>> + int count = 0;
>> +
>> + if (!acpi_has_method(adev->handle, METHOD_NAME__CRS))
>> + return -EINVAL;
>> +
>> + status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
>> + count_registers_cb, &count);
>> + if (ACPI_FAILURE(status))
>> + return -EINVAL;
>> + return count;
>> +}
>> +
>> +struct get_registers_context {
>> + struct device *dev;
>> + struct combiner *combiner;
>> + int err;
>> +};
>> +
>> +static acpi_status get_registers_cb(struct acpi_resource *ares, void
>> *context)
>> +{
>> + struct get_registers_context *ctx = context;
>> + struct acpi_resource_generic_register *reg;
>> + phys_addr_t paddr;
>> + void __iomem *vaddr;
>> +
>> + if (ares->type != ACPI_RESOURCE_TYPE_GENERIC_REGISTER)
>> + return AE_OK;
>> +
>> + reg = &ares->data.generic_reg;
>> + paddr = reg->address;
>> + if ((reg->space_id != ACPI_SPACE_MEM) ||
>> + (reg->bit_offset != 0) ||
>> + (reg->bit_width > REG_SIZE)) {
>> + dev_err(ctx->dev, "Bad register resource @%pa\n", &paddr);
>> + ctx->err = -EINVAL;
>> + return AE_ERROR;
>> + }
>> +
>> + vaddr = devm_ioremap(ctx->dev, reg->address, REG_SIZE);
>> + if (IS_ERR(vaddr)) {
>> + dev_err(ctx->dev, "Can't map register @%pa\n", &paddr);
>> + ctx->err = PTR_ERR(vaddr);
>> + return AE_ERROR;
>> + }
>> +
>> + ctx->combiner->regs[ctx->combiner->nregs].addr = vaddr;
>> + ctx->combiner->nirqs += reg->bit_width;
>> + ctx->combiner->nregs++;
>> + return AE_OK;
>> +}
>> +
>> +static int get_registers(struct platform_device *pdev, struct
>> combiner *comb)
>> +{
>> + struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
>> + acpi_status status;
>> + struct get_registers_context ctx;
>> +
>> + if (!acpi_has_method(adev->handle, METHOD_NAME__CRS))
>> + return -EINVAL;
>> +
>> + ctx.dev = &pdev->dev;
>> + ctx.combiner = comb;
>> + ctx.err = 0;
>> +
>> + status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
>> + get_registers_cb, &ctx);
>> + if (ACPI_FAILURE(status))
>> + return ctx.err;
>> + return 0;
>> +}
>> +
>> +static int __init combiner_probe(struct platform_device *pdev)
>> +{
>> + struct combiner *combiner;
>> + size_t alloc_sz;
>> + u32 nregs;
>> + int err;
>> +
>> + nregs = count_registers(pdev);
>> + if (nregs <= 0) {
>> + dev_err(&pdev->dev, "Error reading register resources\n");
>> + return -EINVAL;
>> + }
>> +
>> + alloc_sz = sizeof(*combiner) + sizeof(struct combiner_reg) * nregs;
>> + combiner = devm_kzalloc(&pdev->dev, alloc_sz, GFP_KERNEL);
>> + if (!combiner)
>> + return -ENOMEM;
>> +
>> + err = get_registers(pdev, combiner);
>> + if (err < 0)
>> + return err;
>> +
>> + combiner->parent_irq = platform_get_irq(pdev, 0);
>> + if (combiner->parent_irq <= 0) {
>> + dev_err(&pdev->dev, "Error getting IRQ resource\n");
>> + return -EPROBE_DEFER;
>> + }
>> +
>> + combiner->domain = irq_domain_create_linear(pdev->dev.fwnode,
>> combiner->nirqs,
>> + &domain_ops, combiner);
>> + if (!combiner->domain)
>> + /* Errors printed by irq_domain_create_linear */
>> + return -ENODEV;
>> +
>> + irq_set_chained_handler_and_data(combiner->parent_irq,
>> + combiner_handle_irq, combiner);
>> +
>> + dev_info(&pdev->dev, "Initialized with [p=%d,n=%d,r=%p]\n",
>> + combiner->parent_irq, combiner->nirqs, combiner->regs[0].addr);
>> + return 0;
>> +}
>> +
>> +static const struct acpi_device_id qcom_irq_combiner_acpi_match[] = {
>> + { "QCOM80B1", },
>> + { }
>> +};
>> +
>> +static struct platform_driver qcom_irq_combiner_probe = {
>> + .driver = {
>> + .name = "qcom-irq-combiner",
>> + .owner = THIS_MODULE,
>> + .acpi_match_table = ACPI_PTR(qcom_irq_combiner_acpi_match),
>> + },
>> + .probe = combiner_probe,
>> +};
>> +
>> +static int __init register_qcom_irq_combiner(void)
>> +{
>> + return platform_driver_register(&qcom_irq_combiner_probe);
>> +}
>> +device_initcall(register_qcom_irq_combiner);
>>
>
> Other than the questions I have above, this now looks in a much better
> shape. Hopefully Rafael will soon come back will his conclusions on the
> first two patches, as I'd like to see this code to get some -next for a
> while.
Yes, hopefully we can get to that in the following weeks.
Thanks,
Agustin
>
> Thanks,
>
> M.
> --
> Jazz is not dead. It just smells funny...
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a
Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH V9 0/9] Add support for privileged mappings
From: Sricharan R @ 2017-01-06 13:28 UTC (permalink / raw)
To: linux-arm-kernel
This series is a resend of the V5 that Mitch sent sometime back [2]
All the patches are the same and i have just rebased. Redid patch [3],
as it does not apply in this code base. Added a couple of more patches
[4], [5] from Robin for adding the privileged attributes to armv7s format
and arm-smmuv3 revert. Added a patch for passing in the privileged
attributes from arm32 dma-mapping apis as well.
The following patch to the ARM SMMU driver:
commit d346180e70b91b3d5a1ae7e5603e65593d4622bc
Author: Robin Murphy <robin.murphy@arm.com>
Date: Tue Jan 26 18:06:34 2016 +0000
iommu/arm-smmu: Treat all device transactions as unprivileged
started forcing all SMMU transactions to come through as "unprivileged".
The rationale given was that:
(1) There is no way in the IOMMU API to even request privileged
mappings.
(2) It's difficult to implement a DMA mapper that correctly models the
ARM VMSAv8 behavior of unprivileged-writeable =>
privileged-execute-never.
This series rectifies (1) by introducing an IOMMU API for privileged
mappings and implements it in io-pgtable-arm.
This series rectifies (2) by introducing a new dma attribute
(DMA_ATTR_PRIVILEGED) for users of the DMA API that need privileged
mappings which are inaccessible to lesser-privileged execution levels, and
implements it in the arm64 IOMMU DMA mapper. The one known user (pl330.c)
is converted over to the new attribute.
Jordan and Jeremy can provide more info on the use case if needed, but the
high level is that it's a security feature to prevent attacks such as [1].
Note that, i tested this on arm64 with arm-smmuv2, short descriptor changes,
tested this on arm32 platform as well and do not have an platform to test
this with arm-smmuv3.
[1] https://github.com/robclark/kilroy
[2] https://lkml.org/lkml/2016/7/27/590
[3] https://patchwork.kernel.org/patch/9250493/
[4] http://www.linux-arm.org/git?p=linux-rm.git;a=commit;h=1291bd74f05d31da1dab3df02987cba5bd25849b
[5] http://www.linux-arm.org/git?p=linux-rm.git;a=commit;h=a79c1c6333f26849dba418cd92de26b60f5954f3
Changelog:
v8..v9
- Added additional comment in patch 1 and added tag for patch 6.
v7..v8
- Added a patch for passing in the privileged attributes from arm32
dma-mapping apis as well.
v6..v7
- Added couple of more patches, picked up acks, updated commit log
v5..v6
- Rebased all the patches and redid 6/6 as it does not apply in
this code base.
v4..v5
- Simplified patch 4/6 (suggested by Robin Murphy).
v3..v4
- Rebased and reworked on linux next due to the dma attrs rework going
on over there. Patches changed: 3/6, 4/6, and 5/6.
v2..v3
- Incorporated feedback from Robin:
* Various comments and re-wordings.
* Use existing bit definitions for IOMMU_PRIV implementation
in io-pgtable-arm.
* Renamed and redocumented dma_direction_to_prot.
* Don't worry about executability in new DMA attr.
v1..v2
- Added a new DMA attribute to make executable privileged mappings
work, and use that in the pl330 driver (suggested by Will).
Jeremy Gebben (1):
iommu/io-pgtable-arm: add support for the IOMMU_PRIV flag
Mitchel Humpherys (4):
iommu: add IOMMU_PRIV attribute
common: DMA-mapping: add DMA_ATTR_PRIVILEGED attribute
arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED
dmaengine: pl330: Make sure microcode is privileged
Robin Murphy (2):
iommu/io-pgtable-arm-v7s: Add support for the IOMMU_PRIV flag
Revert "iommu/arm-smmu: Set PRIVCFG in stage 1 STEs"
Sricharan R (2):
arm/dma-mapping: Implement DMA_ATTR_PRIVILEGED
iommu/arm-smmu: Set privileged attribute to 'default' instead of
'unprivileged'
Documentation/DMA-attributes.txt | 10 +++++++
arch/arm/mm/dma-mapping.c | 60 +++++++++++++++++++-------------------
arch/arm64/mm/dma-mapping.c | 6 ++--
drivers/dma/pl330.c | 5 ++--
drivers/iommu/arm-smmu-v3.c | 7 +----
drivers/iommu/arm-smmu.c | 2 +-
drivers/iommu/dma-iommu.c | 12 ++++++--
drivers/iommu/io-pgtable-arm-v7s.c | 6 +++-
drivers/iommu/io-pgtable-arm.c | 5 +++-
include/linux/dma-iommu.h | 3 +-
include/linux/dma-mapping.h | 7 +++++
include/linux/iommu.h | 7 +++++
12 files changed, 82 insertions(+), 48 deletions(-)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* [PATCH V9 1/9] iommu: add IOMMU_PRIV attribute
From: Sricharan R @ 2017-01-06 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483709296-32761-1-git-send-email-sricharan@codeaurora.org>
From: Mitchel Humpherys <mitchelh@codeaurora.org>
Add the IOMMU_PRIV attribute, which is used to indicate privileged
mappings.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
Acked-by: Will Deacon <will.deacon@arm.com>
---
include/linux/iommu.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 0ff5111..69e2417 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -31,6 +31,13 @@
#define IOMMU_CACHE (1 << 2) /* DMA cache coherency */
#define IOMMU_NOEXEC (1 << 3)
#define IOMMU_MMIO (1 << 4) /* e.g. things like MSI doorbells */
+/*
+ * This is to make the IOMMU API setup privileged
+ * mapppings accessible by the master only@higher
+ * privileged execution level and inaccessible at
+ * less privileged levels.
+ */
+#define IOMMU_PRIV (1 << 5)
struct iommu_ops;
struct iommu_group;
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH V9 2/9] iommu/io-pgtable-arm: add support for the IOMMU_PRIV flag
From: Sricharan R @ 2017-01-06 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483709296-32761-1-git-send-email-sricharan@codeaurora.org>
From: Jeremy Gebben <jgebben@codeaurora.org>
Allow the creation of privileged mode mappings, for stage 1 only.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jeremy Gebben <jgebben@codeaurora.org>
---
drivers/iommu/io-pgtable-arm.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index a40ce34..feacc54 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -350,11 +350,14 @@ static arm_lpae_iopte arm_lpae_prot_to_pte(struct arm_lpae_io_pgtable *data,
if (data->iop.fmt == ARM_64_LPAE_S1 ||
data->iop.fmt == ARM_32_LPAE_S1) {
- pte = ARM_LPAE_PTE_AP_UNPRIV | ARM_LPAE_PTE_nG;
+ pte = ARM_LPAE_PTE_nG;
if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ))
pte |= ARM_LPAE_PTE_AP_RDONLY;
+ if (!(prot & IOMMU_PRIV))
+ pte |= ARM_LPAE_PTE_AP_UNPRIV;
+
if (prot & IOMMU_MMIO)
pte |= (ARM_LPAE_MAIR_ATTR_IDX_DEV
<< ARM_LPAE_PTE_ATTRINDX_SHIFT);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH V9 3/9] iommu/io-pgtable-arm-v7s: Add support for the IOMMU_PRIV flag
From: Sricharan R @ 2017-01-06 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483709296-32761-1-git-send-email-sricharan@codeaurora.org>
From: Robin Murphy <robin.murphy@arm.com>
The short-descriptor format also allows privileged-only mappings, so
let's wire it up.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Sricharan R <sricharan@codeaurora.org>
---
drivers/iommu/io-pgtable-arm-v7s.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c b/drivers/iommu/io-pgtable-arm-v7s.c
index 0769276..1c049e2 100644
--- a/drivers/iommu/io-pgtable-arm-v7s.c
+++ b/drivers/iommu/io-pgtable-arm-v7s.c
@@ -265,7 +265,9 @@ static arm_v7s_iopte arm_v7s_prot_to_pte(int prot, int lvl,
if (!(prot & IOMMU_MMIO))
pte |= ARM_V7S_ATTR_TEX(1);
if (ap) {
- pte |= ARM_V7S_PTE_AF | ARM_V7S_PTE_AP_UNPRIV;
+ pte |= ARM_V7S_PTE_AF;
+ if (!(prot & IOMMU_PRIV))
+ pte |= ARM_V7S_PTE_AP_UNPRIV;
if (!(prot & IOMMU_WRITE))
pte |= ARM_V7S_PTE_AP_RDONLY;
}
@@ -288,6 +290,8 @@ static int arm_v7s_pte_to_prot(arm_v7s_iopte pte, int lvl)
if (!(attr & ARM_V7S_PTE_AP_RDONLY))
prot |= IOMMU_WRITE;
+ if (!(attr & ARM_V7S_PTE_AP_UNPRIV))
+ prot |= IOMMU_PRIV;
if ((attr & (ARM_V7S_TEX_MASK << ARM_V7S_TEX_SHIFT)) == 0)
prot |= IOMMU_MMIO;
else if (pte & ARM_V7S_ATTR_C)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH V9 4/9] common: DMA-mapping: add DMA_ATTR_PRIVILEGED attribute
From: Sricharan R @ 2017-01-06 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483709296-32761-1-git-send-email-sricharan@codeaurora.org>
From: Mitchel Humpherys <mitchelh@codeaurora.org>
This patch adds the DMA_ATTR_PRIVILEGED attribute to the DMA-mapping
subsystem.
Some advanced peripherals such as remote processors and GPUs perform
accesses to DMA buffers in both privileged "supervisor" and unprivileged
"user" modes. This attribute is used to indicate to the DMA-mapping
subsystem that the buffer is fully accessible at the elevated privilege
level (and ideally inaccessible or at least read-only at the
lesser-privileged levels).
Cc: linux-doc at vger.kernel.org
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
---
Documentation/DMA-attributes.txt | 10 ++++++++++
include/linux/dma-mapping.h | 7 +++++++
2 files changed, 17 insertions(+)
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index 98bf7ac..44c6bc4 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -143,3 +143,13 @@ So, this provides a way for drivers to avoid those error messages on calls
where allocation failures are not a problem, and shouldn't bother the logs.
NOTE: At the moment DMA_ATTR_NO_WARN is only implemented on PowerPC.
+
+DMA_ATTR_PRIVILEGED
+------------------------------
+
+Some advanced peripherals such as remote processors and GPUs perform
+accesses to DMA buffers in both privileged "supervisor" and unprivileged
+"user" modes. This attribute is used to indicate to the DMA-mapping
+subsystem that the buffer is fully accessible at the elevated privilege
+level (and ideally inaccessible or at least read-only at the
+lesser-privileged levels).
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 10c5a17b1..c24721a 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -63,6 +63,13 @@
#define DMA_ATTR_NO_WARN (1UL << 8)
/*
+ * DMA_ATTR_PRIVILEGED: used to indicate that the buffer is fully
+ * accessible at an elevated privilege level (and ideally inaccessible or
+ * at least read-only@lesser-privileged levels).
+ */
+#define DMA_ATTR_PRIVILEGED (1UL << 9)
+
+/*
* A dma_addr_t can hold any valid DMA or bus address for the platform.
* It can be given to a device to use as a DMA source or target. A CPU cannot
* reference a dma_addr_t directly because there may be translation between
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH V9 5/9] arm64/dma-mapping: Implement DMA_ATTR_PRIVILEGED
From: Sricharan R @ 2017-01-06 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483709296-32761-1-git-send-email-sricharan@codeaurora.org>
From: Mitchel Humpherys <mitchelh@codeaurora.org>
The newly added DMA_ATTR_PRIVILEGED is useful for creating mappings that
are only accessible to privileged DMA engines. Implement it in
dma-iommu.c so that the ARM64 DMA IOMMU mapper can make use of it.
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
---
arch/arm64/mm/dma-mapping.c | 6 +++---
drivers/iommu/dma-iommu.c | 12 +++++++++---
include/linux/dma-iommu.h | 3 ++-
3 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 290a84f..49c6f75 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -557,7 +557,7 @@ static void *__iommu_alloc_attrs(struct device *dev, size_t size,
unsigned long attrs)
{
bool coherent = is_device_dma_coherent(dev);
- int ioprot = dma_direction_to_prot(DMA_BIDIRECTIONAL, coherent);
+ int ioprot = dma_info_to_prot(DMA_BIDIRECTIONAL, coherent, attrs);
size_t iosize = size;
void *addr;
@@ -711,7 +711,7 @@ static dma_addr_t __iommu_map_page(struct device *dev, struct page *page,
unsigned long attrs)
{
bool coherent = is_device_dma_coherent(dev);
- int prot = dma_direction_to_prot(dir, coherent);
+ int prot = dma_info_to_prot(dir, coherent, attrs);
dma_addr_t dev_addr = iommu_dma_map_page(dev, page, offset, size, prot);
if (!iommu_dma_mapping_error(dev, dev_addr) &&
@@ -769,7 +769,7 @@ static int __iommu_map_sg_attrs(struct device *dev, struct scatterlist *sgl,
__iommu_sync_sg_for_device(dev, sgl, nelems, dir);
return iommu_dma_map_sg(dev, sgl, nelems,
- dma_direction_to_prot(dir, coherent));
+ dma_info_to_prot(dir, coherent, attrs));
}
static void __iommu_unmap_sg_attrs(struct device *dev,
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 2db0d64..3006eee 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -181,16 +181,22 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
EXPORT_SYMBOL(iommu_dma_init_domain);
/**
- * dma_direction_to_prot - Translate DMA API directions to IOMMU API page flags
+ * dma_info_to_prot - Translate DMA API directions and attributes to IOMMU API
+ * page flags.
* @dir: Direction of DMA transfer
* @coherent: Is the DMA master cache-coherent?
+ * @attrs: DMA attributes for the mapping
*
* Return: corresponding IOMMU API page protection flags
*/
-int dma_direction_to_prot(enum dma_data_direction dir, bool coherent)
+int dma_info_to_prot(enum dma_data_direction dir, bool coherent,
+ unsigned long attrs)
{
int prot = coherent ? IOMMU_CACHE : 0;
+ if (attrs & DMA_ATTR_PRIVILEGED)
+ prot |= IOMMU_PRIV;
+
switch (dir) {
case DMA_BIDIRECTIONAL:
return prot | IOMMU_READ | IOMMU_WRITE;
@@ -633,7 +639,7 @@ dma_addr_t iommu_dma_map_resource(struct device *dev, phys_addr_t phys,
size_t size, enum dma_data_direction dir, unsigned long attrs)
{
return __iommu_dma_map(dev, phys, size,
- dma_direction_to_prot(dir, false) | IOMMU_MMIO);
+ dma_info_to_prot(dir, false, attrs) | IOMMU_MMIO);
}
void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 7f7e9a7..c5511e1 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -34,7 +34,8 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
u64 size, struct device *dev);
/* General helpers for DMA-API <-> IOMMU-API interaction */
-int dma_direction_to_prot(enum dma_data_direction dir, bool coherent);
+int dma_info_to_prot(enum dma_data_direction dir, bool coherent,
+ unsigned long attrs);
/*
* These implement the bulk of the relevant DMA mapping callbacks, but require
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH V9 6/9] arm/dma-mapping: Implement DMA_ATTR_PRIVILEGED
From: Sricharan R @ 2017-01-06 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483709296-32761-1-git-send-email-sricharan@codeaurora.org>
The newly added DMA_ATTR_PRIVILEGED is useful for creating mappings that
are only accessible to privileged DMA engines. Adding it to the
arm dma-mapping.c so that the ARM32 DMA IOMMU mapper can make use of it.
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
Reviewed-by: Will Deacon <will.deacon@arm.com>
---
arch/arm/mm/dma-mapping.c | 60 +++++++++++++++++++++++------------------------
1 file changed, 30 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index ab77100..82d3e79 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1171,6 +1171,25 @@ static int __init dma_debug_do_init(void)
#ifdef CONFIG_ARM_DMA_USE_IOMMU
+static int __dma_info_to_prot(enum dma_data_direction dir, unsigned long attrs)
+{
+ int prot = 0;
+
+ if (attrs & DMA_ATTR_PRIVILEGED)
+ prot |= IOMMU_PRIV;
+
+ switch (dir) {
+ case DMA_BIDIRECTIONAL:
+ return prot | IOMMU_READ | IOMMU_WRITE;
+ case DMA_TO_DEVICE:
+ return prot | IOMMU_READ;
+ case DMA_FROM_DEVICE:
+ return prot | IOMMU_WRITE;
+ default:
+ return prot;
+ }
+}
+
/* IOMMU */
static int extend_iommu_mapping(struct dma_iommu_mapping *mapping);
@@ -1394,7 +1413,8 @@ static int __iommu_free_buffer(struct device *dev, struct page **pages,
* Create a mapping in device IO address space for specified pages
*/
static dma_addr_t
-__iommu_create_mapping(struct device *dev, struct page **pages, size_t size)
+__iommu_create_mapping(struct device *dev, struct page **pages, size_t size,
+ unsigned long attrs)
{
struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev);
unsigned int count = PAGE_ALIGN(size) >> PAGE_SHIFT;
@@ -1419,7 +1439,7 @@ static int __iommu_free_buffer(struct device *dev, struct page **pages,
len = (j - i) << PAGE_SHIFT;
ret = iommu_map(mapping->domain, iova, phys, len,
- IOMMU_READ|IOMMU_WRITE);
+ __dma_info_to_prot(DMA_BIDIRECTIONAL, attrs));
if (ret < 0)
goto fail;
iova += len;
@@ -1476,7 +1496,8 @@ static struct page **__iommu_get_pages(void *cpu_addr, unsigned long attrs)
}
static void *__iommu_alloc_simple(struct device *dev, size_t size, gfp_t gfp,
- dma_addr_t *handle, int coherent_flag)
+ dma_addr_t *handle, int coherent_flag,
+ unsigned long attrs)
{
struct page *page;
void *addr;
@@ -1488,7 +1509,7 @@ static void *__iommu_alloc_simple(struct device *dev, size_t size, gfp_t gfp,
if (!addr)
return NULL;
- *handle = __iommu_create_mapping(dev, &page, size);
+ *handle = __iommu_create_mapping(dev, &page, size, attrs);
if (*handle == DMA_ERROR_CODE)
goto err_mapping;
@@ -1522,7 +1543,7 @@ static void *__arm_iommu_alloc_attrs(struct device *dev, size_t size,
if (coherent_flag == COHERENT || !gfpflags_allow_blocking(gfp))
return __iommu_alloc_simple(dev, size, gfp, handle,
- coherent_flag);
+ coherent_flag, attrs);
/*
* Following is a work-around (a.k.a. hack) to prevent pages
@@ -1537,7 +1558,7 @@ static void *__arm_iommu_alloc_attrs(struct device *dev, size_t size,
if (!pages)
return NULL;
- *handle = __iommu_create_mapping(dev, pages, size);
+ *handle = __iommu_create_mapping(dev, pages, size, attrs);
if (*handle == DMA_ERROR_CODE)
goto err_buffer;
@@ -1672,27 +1693,6 @@ static int arm_iommu_get_sgtable(struct device *dev, struct sg_table *sgt,
GFP_KERNEL);
}
-static int __dma_direction_to_prot(enum dma_data_direction dir)
-{
- int prot;
-
- switch (dir) {
- case DMA_BIDIRECTIONAL:
- prot = IOMMU_READ | IOMMU_WRITE;
- break;
- case DMA_TO_DEVICE:
- prot = IOMMU_READ;
- break;
- case DMA_FROM_DEVICE:
- prot = IOMMU_WRITE;
- break;
- default:
- prot = 0;
- }
-
- return prot;
-}
-
/*
* Map a part of the scatter-gather list into contiguous io address space
*/
@@ -1722,7 +1722,7 @@ static int __map_sg_chunk(struct device *dev, struct scatterlist *sg,
if (!is_coherent && (attrs & DMA_ATTR_SKIP_CPU_SYNC) == 0)
__dma_page_cpu_to_dev(sg_page(s), s->offset, s->length, dir);
- prot = __dma_direction_to_prot(dir);
+ prot = __dma_info_to_prot(dir, attrs);
ret = iommu_map(mapping->domain, iova, phys, len, prot);
if (ret < 0)
@@ -1930,7 +1930,7 @@ static dma_addr_t arm_coherent_iommu_map_page(struct device *dev, struct page *p
if (dma_addr == DMA_ERROR_CODE)
return dma_addr;
- prot = __dma_direction_to_prot(dir);
+ prot = __dma_info_to_prot(dir, attrs);
ret = iommu_map(mapping->domain, dma_addr, page_to_phys(page), len, prot);
if (ret < 0)
@@ -2036,7 +2036,7 @@ static dma_addr_t arm_iommu_map_resource(struct device *dev,
if (dma_addr == DMA_ERROR_CODE)
return dma_addr;
- prot = __dma_direction_to_prot(dir) | IOMMU_MMIO;
+ prot = __dma_info_to_prot(dir, attrs) | IOMMU_MMIO;
ret = iommu_map(mapping->domain, dma_addr, addr, len, prot);
if (ret < 0)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH V9 7/9] dmaengine: pl330: Make sure microcode is privileged
From: Sricharan R @ 2017-01-06 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483709296-32761-1-git-send-email-sricharan@codeaurora.org>
From: Mitchel Humpherys <mitchelh@codeaurora.org>
The PL330 is hard-wired such that instruction fetches on both the
manager and channel threads go out onto the bus with the "privileged"
bit set. This can become troublesome once there is an IOMMU or other
form of memory protection downstream, since those will typically be
programmed by the DMA mapping subsystem in the expectation of normal
unprivileged transactions (such as the PL330 channel threads' own data
accesses as currently configured by this driver).
To avoid the case of, say, an IOMMU blocking an unexpected privileged
transaction with a permission fault, use the newly-introduced
DMA_ATTR_PRIVILEGED attribute for the mapping of our microcode buffer.
That way the DMA layer can do whatever it needs to do to make things
continue to work as expected on more complex systems.
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Tested-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
[rm: remove now-redundant local variable, clarify commit message]
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/dma/pl330.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 87fd015..5a90d0c 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -1864,9 +1864,10 @@ static int dmac_alloc_resources(struct pl330_dmac *pl330)
* Alloc MicroCode buffer for 'chans' Channel threads.
* A channel's buffer offset is (Channel_Id * MCODE_BUFF_PERCHAN)
*/
- pl330->mcode_cpu = dma_alloc_coherent(pl330->ddma.dev,
+ pl330->mcode_cpu = dma_alloc_attrs(pl330->ddma.dev,
chans * pl330->mcbufsz,
- &pl330->mcode_bus, GFP_KERNEL);
+ &pl330->mcode_bus, GFP_KERNEL,
+ DMA_ATTR_PRIVILEGED);
if (!pl330->mcode_cpu) {
dev_err(pl330->ddma.dev, "%s:%d Can't allocate memory!\n",
__func__, __LINE__);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH V9 8/9] iommu/arm-smmu: Set privileged attribute to 'default' instead of 'unprivileged'
From: Sricharan R @ 2017-01-06 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483709296-32761-1-git-send-email-sricharan@codeaurora.org>
Currently the driver sets all the device transactions privileges
to UNPRIVILEGED, but there are cases where the iommu masters wants
to isolate privileged supervisor and unprivileged user.
So don't override the privileged setting to unprivileged, instead
set it to default as incoming and let it be controlled by the pagetable
settings.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
---
drivers/iommu/arm-smmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index a60cded..73a0a25 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1214,7 +1214,7 @@ static int arm_smmu_domain_add_master(struct arm_smmu_domain *smmu_domain,
continue;
s2cr[idx].type = type;
- s2cr[idx].privcfg = S2CR_PRIVCFG_UNPRIV;
+ s2cr[idx].privcfg = S2CR_PRIVCFG_DEFAULT;
s2cr[idx].cbndx = cbndx;
arm_smmu_write_s2cr(smmu, idx);
}
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [PATCH V9 9/9] Revert "iommu/arm-smmu: Set PRIVCFG in stage 1 STEs"
From: Sricharan R @ 2017-01-06 13:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483709296-32761-1-git-send-email-sricharan@codeaurora.org>
From: Robin Murphy <robin.murphy@arm.com>
This reverts commit df5e1a0f2a2d779ad467a691203bcbc74d75690e.
Now that proper privileged mappings can be requested via IOMMU_PRIV,
unconditionally overriding the incoming PRIVCFG becomes the wrong thing
to do, so stop it.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu-v3.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 4d6ec44..7d45d8b 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -269,9 +269,6 @@
#define STRTAB_STE_1_SHCFG_INCOMING 1UL
#define STRTAB_STE_1_SHCFG_SHIFT 44
-#define STRTAB_STE_1_PRIVCFG_UNPRIV 2UL
-#define STRTAB_STE_1_PRIVCFG_SHIFT 48
-
#define STRTAB_STE_2_S2VMID_SHIFT 0
#define STRTAB_STE_2_S2VMID_MASK 0xffffUL
#define STRTAB_STE_2_VTCR_SHIFT 32
@@ -1073,9 +1070,7 @@ static void arm_smmu_write_strtab_ent(struct arm_smmu_device *smmu, u32 sid,
#ifdef CONFIG_PCI_ATS
STRTAB_STE_1_EATS_TRANS << STRTAB_STE_1_EATS_SHIFT |
#endif
- STRTAB_STE_1_STRW_NSEL1 << STRTAB_STE_1_STRW_SHIFT |
- STRTAB_STE_1_PRIVCFG_UNPRIV <<
- STRTAB_STE_1_PRIVCFG_SHIFT);
+ STRTAB_STE_1_STRW_NSEL1 << STRTAB_STE_1_STRW_SHIFT);
if (smmu->features & ARM_SMMU_FEAT_STALLS)
dst[1] |= cpu_to_le64(STRTAB_STE_1_S1STALLD);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply related
* [GIT PULL] ARM: OXNAS SoC DT updates for 4.11
From: Neil Armstrong @ 2017-01-06 13:39 UTC (permalink / raw)
To: linux-arm-kernel
Dear arm-soc maintainers,
The following changes since commit 0c744ea4f77d72b3dcebb7a8f2684633ec79be88:
Linux 4.10-rc2 (2017-01-01 14:31:53 -0800)
are available in the git repository at:
https://github.com/OXNAS/linux.git tags/oxnas-arm-soc-dt-for-4.11
for you to fetch changes up to 0c5987d3e3c5bf7fb861230ee6d2a0f17a1dcd3b:
ARM: dts: OX820: Update with dt-bindings includes (2017-01-04 10:31:34 +0100)
----------------------------------------------------------------
- Add dt-bindings includes for OX820 and OX810SE dtsi
- Replace reset and clock magic numbers for OX820 and OX810SE
----------------------------------------------------------------
Neil Armstrong (2):
ARM: dts: OX810: Update with dt-bindings includes
ARM: dts: OX820: Update with dt-bindings includes
arch/arm/boot/dts/ox810se.dtsi | 10 ++++++----
arch/arm/boot/dts/ox820.dtsi | 14 ++++++++------
2 files changed, 14 insertions(+), 10 deletions(-)
Thanks,
Neil
^ permalink raw reply
* [PATCH v5 0/5] Add touch key driver support for TM2
From: Andi Shyti @ 2017-01-06 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20170106134355epcas1p171f1f3b3c20c6a92e7736c1639ea2dd8@epcas1p1.samsung.com>
Hi,
I'll send this patch on behalf of Jaechul Lee
<jcsing.lee@samsung.com> becasue I don't want to block
anyone who wants to make changes to the exynos5433-tm2*dts*
files.
This patches are based on Krzysztof's branch for-next [1] and
this was the original Jaechul's mail:
"This patchset adds support for the tm2 touchkey device.
The driver has been ported from Tizen Kernel,
originally written
by Beomho. I ported it to the latest mainline Kernel."
Thanks and hopefully I got it right :)
Andi
[1] https://git.kernel.org/cgit/linux/kernel/git/krzk/linux.git/log/?h=for-next
Changes in v5:
- patch 1: removed a spurious regulator-always-off inherited from
a different patch. Thanks Krzysztof.
- patch 2: fixed a slip on the model, thanks Javier (this patch
confuses me quite a lot, this was all right some patches ago
and re appeared on this one).
- patch 2: removed 'regulator' label and used the original ldo3x
labels. Krzysztof: it looks better indeed.
- added Javier's reviews and Krzysztof's acks on the related
patches.
Changes in v4:
- patch 1 has been rebased on top of 7c294e002641 (arm64: dts:
exynos: Remove unsupported regulator-always-off property from
TM2E)
- patch 2 has been generated with -B50% diff option using git
2.11
Changes in v3:
- Changed the commit ordering, the tm2-touchkey related patches
are the last 3.
- Added Chanwoo's patch which fixes the wrong voltage of ldo23
and ldo25.
- Andi (patch 3) moves the ldo31 and ldo38 in the tm2 and tm2e
files as they have different values.
Changes in v2:
- fixed reviews from Javier, Dmitry
- refactored power enable/disable functions.
- reordered signed-offs in patch 2, while patch 4 is left as it
was as Andi copy pasted the node to the new tm2.dts file
- added Jarvier's (patch 1,2,4) and Krzysztof's (patch 4)
reviews
and Rob's Ack
- patch 3 diff has been generated with -B50%
Andi Shyti (1):
arm64: dts: exynos: make tm2 and tm2e independent from each other
Andi Shyti (1):
arm64: dts: exynos: make tm2 and tm2e independent from each other
Chanwoo Choi (1):
arm64: dts: exynos5433: TM2/E: Fix wrong values for ldo23 and ldo25
Jaechul Lee (3):
input: Add support for the tm2 touchkey device driver
input: tm2-touchkey: Add touchkey driver support for TM2
arm64: dts: exynos: Add tm2 touchkey node
.../bindings/input/samsung,tm2-touchkey.txt | 27 +
...ynos5433-tm2.dts => exynos5433-tm2-common.dtsi} | 27 +-
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1163 +-------------------
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 11 +-
drivers/input/keyboard/Kconfig | 11 +
drivers/input/keyboard/Makefile | 1 +
drivers/input/keyboard/tm2-touchkey.c | 280 +++++
7 files changed, 377 insertions(+), 1143 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/samsung,tm2-touchkey.txt
copy arch/arm64/boot/dts/exynos/{exynos5433-tm2.dts => exynos5433-tm2-common.dtsi} (97%)
rewrite arch/arm64/boot/dts/exynos/exynos5433-tm2.dts (97%)
create mode 100644 drivers/input/keyboard/tm2-touchkey.c
--
2.11.0
^ permalink raw reply
* [PATCH v5 1/5] arm64: dts: exynos5433: TM2/E: Fix wrong values for ldo23 and ldo25
From: Andi Shyti @ 2017-01-06 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106134350.32428-1-andi.shyti@samsung.com>
From: Chanwoo Choi <cw00.choi@samsung.com>
This patch fixes wrong values assigned to ldo23 and ldo25 on both TM2 and TM2E.
Fixes: 01e5d2352152 ("arm64: dts: exynos: Add dts file for Exynos5433-based TM2 board")
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
---
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 6 +++---
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 9 ---------
2 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
index 3b5215c40fcd..640e4b9910ae 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -504,9 +504,9 @@
};
ldo23_reg: LDO23 {
- regulator-name = "CAM_SEN_CORE_1.2V_AP";
+ regulator-name = "CAM_SEN_CORE_1.05V_AP";
regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1200000>;
+ regulator-max-microvolt = <1050000>;
};
ldo24_reg: LDO24 {
@@ -516,7 +516,7 @@
};
ldo25_reg: LDO25 {
- regulator-name = "CAM_SEN_A2.8V_AP";
+ regulator-name = "UNUSED_LDO25";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
};
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
index 398f5e092b02..854c583092d5 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -18,15 +18,6 @@
compatible = "samsung,tm2e", "samsung,exynos5433";
};
-&ldo23_reg {
- regulator-name = "CAM_SEN_CORE_1.025V_AP";
- regulator-max-microvolt = <1050000>;
-};
-
-&ldo25_reg {
- regulator-name = "UNUSED_LDO25";
-};
-
&ldo31_reg {
regulator-name = "TSP_VDD_1.8V_AP";
regulator-min-microvolt = <1800000>;
--
2.11.0
^ permalink raw reply related
* [PATCH v5 2/5] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Andi Shyti @ 2017-01-06 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106134350.32428-1-andi.shyti@samsung.com>
Currently tm2e dts includes tm2 but there are some differences
between the two boards and tm2 has some properties that tm2e
doesn't have.
That's why it's important to keep the two dts files independent
and put all the commonalities in a tm2-common.dtsi file.
At the current status the only two differences between the two
dts files (besides the board name) are ldo31 and ldo38.
Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
---
...ynos5433-tm2.dts => exynos5433-tm2-common.dtsi} | 21 +-
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 1150 +-------------------
arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts | 2 +-
3 files changed, 42 insertions(+), 1131 deletions(-)
copy arch/arm64/boot/dts/exynos/{exynos5433-tm2.dts => exynos5433-tm2-common.dtsi} (98%)
rewrite arch/arm64/boot/dts/exynos/exynos5433-tm2.dts (98%)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
similarity index 98%
copy from arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
copy to arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
index 640e4b9910ae..cc6701b3bce4 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2-common.dtsi
@@ -3,8 +3,8 @@
*
* Copyright (c) 2016 Samsung Electronics Co., Ltd.
*
- * Device tree source file for Samsung's TM2 board which is based on
- * Samsung Exynos5433 SoC.
+ * Common device tree source file for Samsung's TM2 and TM2E boards
+ * which are based on Samsung Exynos5433 SoC.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -19,9 +19,6 @@
#include <dt-bindings/interrupt-controller/irq.h>
/ {
- model = "Samsung TM2 board";
- compatible = "samsung,tm2", "samsung,exynos5433";
-
aliases {
gsc0 = &gsc_0;
gsc1 = &gsc_1;
@@ -552,9 +549,10 @@
};
ldo31_reg: LDO31 {
- regulator-name = "TSP_VDD_1.85V_AP";
- regulator-min-microvolt = <1850000>;
- regulator-max-microvolt = <1850000>;
+ /*
+ * LDO31 differs from target to target,
+ * its definition is in the .dts
+ */
};
ldo32_reg: LDO32 {
@@ -595,9 +593,10 @@
};
ldo38_reg: LDO38 {
- regulator-name = "VCC_3.0V_MOTOR_AP";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
+ /*
+ * LDO38 differs from target to target,
+ * its definition is in the .dts
+ */
};
ldo39_reg: LDO39 {
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
dissimilarity index 98%
index 640e4b9910ae..2449266b268f 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
@@ -1,1119 +1,31 @@
-/*
- * SAMSUNG Exynos5433 TM2 board device tree source
- *
- * Copyright (c) 2016 Samsung Electronics Co., Ltd.
- *
- * Device tree source file for Samsung's TM2 board which is based on
- * Samsung Exynos5433 SoC.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-/dts-v1/;
-#include "exynos5433.dtsi"
-#include <dt-bindings/clock/samsung,s2mps11.h>
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/input/input.h>
-#include <dt-bindings/interrupt-controller/irq.h>
-
-/ {
- model = "Samsung TM2 board";
- compatible = "samsung,tm2", "samsung,exynos5433";
-
- aliases {
- gsc0 = &gsc_0;
- gsc1 = &gsc_1;
- gsc2 = &gsc_2;
- pinctrl0 = &pinctrl_alive;
- pinctrl1 = &pinctrl_aud;
- pinctrl2 = &pinctrl_cpif;
- pinctrl3 = &pinctrl_ese;
- pinctrl4 = &pinctrl_finger;
- pinctrl5 = &pinctrl_fsys;
- pinctrl6 = &pinctrl_imem;
- pinctrl7 = &pinctrl_nfc;
- pinctrl8 = &pinctrl_peric;
- pinctrl9 = &pinctrl_touch;
- serial0 = &serial_0;
- serial1 = &serial_1;
- serial2 = &serial_2;
- serial3 = &serial_3;
- spi0 = &spi_0;
- spi1 = &spi_1;
- spi2 = &spi_2;
- spi3 = &spi_3;
- spi4 = &spi_4;
- mshc0 = &mshc_0;
- mshc2 = &mshc_2;
- };
-
- chosen {
- stdout-path = &serial_1;
- };
-
- memory at 20000000 {
- device_type = "memory";
- reg = <0x0 0x20000000 0x0 0xc0000000>;
- };
-
- gpio-keys {
- compatible = "gpio-keys";
-
- power-key {
- gpios = <&gpa2 7 GPIO_ACTIVE_LOW>;
- linux,code = <KEY_POWER>;
- label = "power key";
- debounce-interval = <10>;
- };
-
- volume-up-key {
- gpios = <&gpa2 0 GPIO_ACTIVE_LOW>;
- linux,code = <KEY_VOLUMEUP>;
- label = "volume-up key";
- debounce-interval = <10>;
- };
-
- volume-down-key {
- gpios = <&gpa2 1 GPIO_ACTIVE_LOW>;
- linux,code = <KEY_VOLUMEDOWN>;
- label = "volume-down key";
- debounce-interval = <10>;
- };
-
- homepage-key {
- gpios = <&gpa0 3 GPIO_ACTIVE_LOW>;
- linux,code = <KEY_MENU>;
- label = "homepage key";
- debounce-interval = <10>;
- };
- };
-
- i2c_max98504: i2c-gpio-0 {
- compatible = "i2c-gpio";
- gpios = <&gpd0 1 GPIO_ACTIVE_HIGH /* SPK_AMP_SDA */
- &gpd0 0 GPIO_ACTIVE_HIGH /* SPK_AMP_SCL */ >;
- i2c-gpio,delay-us = <2>;
- #address-cells = <1>;
- #size-cells = <0>;
- status = "okay";
-
- max98504: max98504 at 31 {
- compatible = "maxim,max98504";
- reg = <0x31>;
- maxim,rx-path = <1>;
- maxim,tx-path = <1>;
- maxim,tx-channel-mask = <3>;
- maxim,tx-channel-source = <2>;
- };
- };
-
- sound {
- compatible = "samsung,tm2-audio";
- audio-codec = <&wm5110>;
- i2s-controller = <&i2s0>;
- audio-amplifier = <&max98504>;
- mic-bias-gpios = <&gpr3 2 GPIO_ACTIVE_HIGH>;
- model = "wm5110";
- samsung,audio-routing =
- /* Headphone */
- "HP", "HPOUT1L",
- "HP", "HPOUT1R",
-
- /* Speaker */
- "SPK", "SPKOUT",
- "SPKOUT", "HPOUT2L",
- "SPKOUT", "HPOUT2R",
-
- /* Receiver */
- "RCV", "HPOUT3L",
- "RCV", "HPOUT3R";
- status = "okay";
- };
-};
-
-&adc {
- vdd-supply = <&ldo3_reg>;
- status = "okay";
-
- thermistor-ap {
- compatible = "murata,ncp03wf104";
- pullup-uv = <1800000>;
- pullup-ohm = <100000>;
- pulldown-ohm = <0>;
- io-channels = <&adc 0>;
- };
-
- thermistor-battery {
- compatible = "murata,ncp03wf104";
- pullup-uv = <1800000>;
- pullup-ohm = <100000>;
- pulldown-ohm = <0>;
- io-channels = <&adc 1>;
- #thermal-sensor-cells = <0>;
- };
-
- thermistor-charger {
- compatible = "murata,ncp03wf104";
- pullup-uv = <1800000>;
- pullup-ohm = <100000>;
- pulldown-ohm = <0>;
- io-channels = <&adc 2>;
- };
-};
-
-&bus_g2d_400 {
- devfreq-events = <&ppmu_event0_d0_general>, <&ppmu_event0_d1_general>;
- vdd-supply = <&buck4_reg>;
- exynos,saturation-ratio = <10>;
- status = "okay";
-};
-
-&bus_g2d_266 {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_gscl {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_hevc {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_jpeg {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_mfc {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_mscl {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_noc0 {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_noc1 {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&bus_noc2 {
- devfreq = <&bus_g2d_400>;
- status = "okay";
-};
-
-&cmu_aud {
- assigned-clocks = <&cmu_aud CLK_MOUT_AUD_PLL_USER>;
- assigned-clock-parents = <&cmu_top CLK_FOUT_AUD_PLL>;
-};
-
-&cmu_fsys {
- assigned-clocks = <&cmu_top CLK_MOUT_SCLK_USBDRD30>,
- <&cmu_top CLK_MOUT_SCLK_USBHOST30>,
- <&cmu_fsys CLK_MOUT_SCLK_USBDRD30_USER>,
- <&cmu_fsys CLK_MOUT_SCLK_USBHOST30_USER>,
- <&cmu_fsys CLK_MOUT_PHYCLK_USBDRD30_UDRD30_PIPE_PCLK_USER>,
- <&cmu_fsys CLK_MOUT_PHYCLK_USBHOST30_UHOST30_PIPE_PCLK_USER>,
- <&cmu_fsys CLK_MOUT_PHYCLK_USBDRD30_UDRD30_PHYCLOCK_USER>,
- <&cmu_fsys CLK_MOUT_PHYCLK_USBHOST30_UHOST30_PHYCLOCK_USER>,
- <&cmu_top CLK_DIV_SCLK_USBDRD30>,
- <&cmu_top CLK_DIV_SCLK_USBHOST30>;
- assigned-clock-parents = <&cmu_top CLK_MOUT_BUS_PLL_USER>,
- <&cmu_top CLK_MOUT_BUS_PLL_USER>,
- <&cmu_top CLK_SCLK_USBDRD30_FSYS>,
- <&cmu_top CLK_SCLK_USBHOST30_FSYS>,
- <&cmu_fsys CLK_PHYCLK_USBDRD30_UDRD30_PIPE_PCLK_PHY>,
- <&cmu_fsys CLK_PHYCLK_USBHOST30_UHOST30_PIPE_PCLK_PHY>,
- <&cmu_fsys CLK_PHYCLK_USBDRD30_UDRD30_PHYCLOCK_PHY>,
- <&cmu_fsys CLK_PHYCLK_USBHOST30_UHOST30_PHYCLOCK_PHY>;
- assigned-clock-rates = <0>, <0>, <0>, <0>, <0>, <0>, <0>, <0>,
- <66700000>, <66700000>;
-};
-
-&cmu_gscl {
- assigned-clocks = <&cmu_gscl CLK_MOUT_ACLK_GSCL_111_USER>,
- <&cmu_gscl CLK_MOUT_ACLK_GSCL_333_USER>;
- assigned-clock-parents = <&cmu_top CLK_ACLK_GSCL_111>,
- <&cmu_top CLK_ACLK_GSCL_333>;
-};
-
-&cmu_mfc {
- assigned-clocks = <&cmu_mfc CLK_MOUT_ACLK_MFC_400_USER>;
- assigned-clock-parents = <&cmu_top CLK_ACLK_MFC_400>;
-};
-
-&cmu_mscl {
- assigned-clocks = <&cmu_mscl CLK_MOUT_ACLK_MSCL_400_USER>,
- <&cmu_mscl CLK_MOUT_SCLK_JPEG_USER>,
- <&cmu_mscl CLK_MOUT_SCLK_JPEG>,
- <&cmu_top CLK_MOUT_SCLK_JPEG_A>;
- assigned-clock-parents = <&cmu_top CLK_ACLK_MSCL_400>,
- <&cmu_top CLK_SCLK_JPEG_MSCL>,
- <&cmu_mscl CLK_MOUT_SCLK_JPEG_USER>,
- <&cmu_top CLK_MOUT_BUS_PLL_USER>;
-};
-
-&cpu0 {
- cpu-supply = <&buck3_reg>;
-};
-
-&cpu4 {
- cpu-supply = <&buck2_reg>;
-};
-
-&decon {
- status = "okay";
-
- i80-if-timings {
- };
-};
-
-&dsi {
- status = "okay";
- vddcore-supply = <&ldo6_reg>;
- vddio-supply = <&ldo7_reg>;
- samsung,pll-clock-frequency = <24000000>;
- pinctrl-names = "default";
- pinctrl-0 = <&te_irq>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port at 1 {
- reg = <1>;
-
- dsi_out: endpoint {
- samsung,burst-clock-frequency = <512000000>;
- samsung,esc-clock-frequency = <16000000>;
- };
- };
- };
-};
-
-&hsi2c_0 {
- status = "okay";
- clock-frequency = <2500000>;
-
- s2mps13-pmic at 66 {
- compatible = "samsung,s2mps13-pmic";
- interrupt-parent = <&gpa0>;
- interrupts = <7 IRQ_TYPE_NONE>;
- reg = <0x66>;
- samsung,s2mps11-wrstbi-ground;
-
- s2mps13_osc: clocks {
- compatible = "samsung,s2mps13-clk";
- #clock-cells = <1>;
- clock-output-names = "s2mps13_ap", "s2mps13_cp",
- "s2mps13_bt";
- };
-
- regulators {
- ldo1_reg: LDO1 {
- regulator-name = "VDD_ALIVE_0.9V_AP";
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <900000>;
- regulator-always-on;
- };
-
- ldo2_reg: LDO2 {
- regulator-name = "VDDQ_MMC2_2.8V_AP";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo3_reg: LDO3 {
- regulator-name = "VDD1_E_1.8V_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- };
-
- ldo4_reg: LDO4 {
- regulator-name = "VDD10_MIF_PLL_1.0V_AP";
- regulator-min-microvolt = <1300000>;
- regulator-max-microvolt = <1300000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo5_reg: LDO5 {
- regulator-name = "VDD10_DPLL_1.0V_AP";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1000000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo6_reg: LDO6 {
- regulator-name = "VDD10_MIPI2L_1.0V_AP";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1000000>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo7_reg: LDO7 {
- regulator-name = "VDD18_MIPI2L_1.8V_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo8_reg: LDO8 {
- regulator-name = "VDD18_LLI_1.8V_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo9_reg: LDO9 {
- regulator-name = "VDD18_ABB_ETC_1.8V_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo10_reg: LDO10 {
- regulator-name = "VDD33_USB30_3.0V_AP";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo11_reg: LDO11 {
- regulator-name = "VDD_INT_M_1.0V_AP";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1000000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo12_reg: LDO12 {
- regulator-name = "VDD_KFC_M_1.1V_AP";
- regulator-min-microvolt = <800000>;
- regulator-max-microvolt = <1350000>;
- regulator-always-on;
- };
-
- ldo13_reg: LDO13 {
- regulator-name = "VDD_G3D_M_0.95V_AP";
- regulator-min-microvolt = <950000>;
- regulator-max-microvolt = <950000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo14_reg: LDO14 {
- regulator-name = "VDDQ_M1_LDO_1.2V_AP";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo15_reg: LDO15 {
- regulator-name = "VDDQ_M2_LDO_1.2V_AP";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- ldo16_reg: LDO16 {
- regulator-name = "VDDQ_EFUSE";
- regulator-min-microvolt = <1400000>;
- regulator-max-microvolt = <3400000>;
- regulator-always-on;
- };
-
- ldo17_reg: LDO17 {
- regulator-name = "V_TFLASH_2.8V_AP";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- };
-
- ldo18_reg: LDO18 {
- regulator-name = "V_CODEC_1.8V_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo19_reg: LDO19 {
- regulator-name = "VDDA_1.8V_COMP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- };
-
- ldo20_reg: LDO20 {
- regulator-name = "VCC_2.8V_AP";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- regulator-always-on;
- };
-
- ldo21_reg: LDO21 {
- regulator-name = "VT_CAM_1.8V";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo22_reg: LDO22 {
- regulator-name = "CAM_IO_1.8V_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo23_reg: LDO23 {
- regulator-name = "CAM_SEN_CORE_1.05V_AP";
- regulator-min-microvolt = <1050000>;
- regulator-max-microvolt = <1050000>;
- };
-
- ldo24_reg: LDO24 {
- regulator-name = "VT_CAM_1.2V";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- };
-
- ldo25_reg: LDO25 {
- regulator-name = "UNUSED_LDO25";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- };
-
- ldo26_reg: LDO26 {
- regulator-name = "CAM_AF_2.8V_AP";
- regulator-min-microvolt = <2800000>;
- regulator-max-microvolt = <2800000>;
- };
-
- ldo27_reg: LDO27 {
- regulator-name = "VCC_3.0V_LCD_AP";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- };
-
- ldo28_reg: LDO28 {
- regulator-name = "VCC_1.8V_LCD_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo29_reg: LDO29 {
- regulator-name = "VT_CAM_2.8V";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- };
-
- ldo30_reg: LDO30 {
- regulator-name = "TSP_AVDD_3.3V_AP";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- ldo31_reg: LDO31 {
- regulator-name = "TSP_VDD_1.85V_AP";
- regulator-min-microvolt = <1850000>;
- regulator-max-microvolt = <1850000>;
- };
-
- ldo32_reg: LDO32 {
- regulator-name = "VTOUCH_1.8V_AP";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo33_reg: LDO33 {
- regulator-name = "VTOUCH_LED_3.3V";
- regulator-min-microvolt = <2500000>;
- regulator-max-microvolt = <3300000>;
- regulator-ramp-delay = <12500>;
- };
-
- ldo34_reg: LDO34 {
- regulator-name = "VCC_1.8V_MHL_AP";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <2100000>;
- };
-
- ldo35_reg: LDO35 {
- regulator-name = "OIS_VM_2.8V";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <2800000>;
- };
-
- ldo36_reg: LDO36 {
- regulator-name = "VSIL_1.0V";
- regulator-min-microvolt = <1000000>;
- regulator-max-microvolt = <1000000>;
- };
-
- ldo37_reg: LDO37 {
- regulator-name = "VF_1.8V";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo38_reg: LDO38 {
- regulator-name = "VCC_3.0V_MOTOR_AP";
- regulator-min-microvolt = <3000000>;
- regulator-max-microvolt = <3000000>;
- };
-
- ldo39_reg: LDO39 {
- regulator-name = "V_HRM_1.8V";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- };
-
- ldo40_reg: LDO40 {
- regulator-name = "V_HRM_3.3V";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- };
-
- buck1_reg: BUCK1 {
- regulator-name = "VDD_MIF_0.9V_AP";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1500000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- buck2_reg: BUCK2 {
- regulator-name = "VDD_EGL_1.0V_AP";
- regulator-min-microvolt = <900000>;
- regulator-max-microvolt = <1300000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- buck3_reg: BUCK3 {
- regulator-name = "VDD_KFC_1.0V_AP";
- regulator-min-microvolt = <800000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- buck4_reg: BUCK4 {
- regulator-name = "VDD_INT_0.95V_AP";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1500000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- buck5_reg: BUCK5 {
- regulator-name = "VDD_DISP_CAM0_0.9V_AP";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1500000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- buck6_reg: BUCK6 {
- regulator-name = "VDD_G3D_0.9V_AP";
- regulator-min-microvolt = <600000>;
- regulator-max-microvolt = <1500000>;
- regulator-always-on;
- regulator-state-mem {
- regulator-off-in-suspend;
- };
- };
-
- buck7_reg: BUCK7 {
- regulator-name = "VDD_MEM1_1.2V_AP";
- regulator-min-microvolt = <1200000>;
- regulator-max-microvolt = <1200000>;
- regulator-always-on;
- };
-
- buck8_reg: BUCK8 {
- regulator-name = "VDD_LLDO_1.35V_AP";
- regulator-min-microvolt = <1350000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- buck9_reg: BUCK9 {
- regulator-name = "VDD_MLDO_2.0V_AP";
- regulator-min-microvolt = <1350000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- };
-
- buck10_reg: BUCK10 {
- regulator-name = "vdd_mem2";
- regulator-min-microvolt = <550000>;
- regulator-max-microvolt = <1500000>;
- regulator-always-on;
- };
- };
- };
-};
-
-&hsi2c_8 {
- status = "okay";
-
- max77843 at 66 {
- compatible = "maxim,max77843";
- interrupt-parent = <&gpa1>;
- interrupts = <5 IRQ_TYPE_EDGE_FALLING>;
- reg = <0x66>;
-
- muic: max77843-muic {
- compatible = "maxim,max77843-muic";
- };
-
- regulators {
- compatible = "maxim,max77843-regulator";
- safeout1_reg: SAFEOUT1 {
- regulator-name = "SAFEOUT1";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <4950000>;
- };
-
- safeout2_reg: SAFEOUT2 {
- regulator-name = "SAFEOUT2";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <4950000>;
- };
-
- charger_reg: CHARGER {
- regulator-name = "CHARGER";
- regulator-min-microamp = <100000>;
- regulator-max-microamp = <3150000>;
- };
- };
-
- haptic: max77843-haptic {
- compatible = "maxim,max77843-haptic";
- haptic-supply = <&ldo38_reg>;
- pwms = <&pwm 0 33670 0>;
- pwm-names = "haptic";
- };
- };
-};
-
-&i2s0 {
- status = "okay";
-};
-
-&mshc_0 {
- status = "okay";
- num-slots = <1>;
- mmc-hs200-1_8v;
- mmc-hs400-1_8v;
- cap-mmc-highspeed;
- non-removable;
- card-detect-delay = <200>;
- samsung,dw-mshc-ciu-div = <3>;
- samsung,dw-mshc-sdr-timing = <0 4>;
- samsung,dw-mshc-ddr-timing = <0 2>;
- samsung,dw-mshc-hs400-timing = <0 3>;
- samsung,read-strobe-delay = <90>;
- fifo-depth = <0x80>;
- pinctrl-names = "default";
- pinctrl-0 = <&sd0_clk &sd0_cmd &sd0_qrdy &sd0_bus1 &sd0_bus4
- &sd0_bus8 &sd0_rdqs>;
- bus-width = <8>;
- assigned-clocks = <&cmu_top CLK_SCLK_MMC0_FSYS>;
- assigned-clock-rates = <800000000>;
-};
-
-&mshc_2 {
- status = "okay";
- num-slots = <1>;
- cap-sd-highspeed;
- disable-wp;
- cd-gpios = <&gpa2 4 GPIO_ACTIVE_HIGH>;
- cd-inverted;
- card-detect-delay = <200>;
- samsung,dw-mshc-ciu-div = <3>;
- samsung,dw-mshc-sdr-timing = <0 4>;
- samsung,dw-mshc-ddr-timing = <0 2>;
- fifo-depth = <0x80>;
- pinctrl-names = "default";
- pinctrl-0 = <&sd2_clk &sd2_cmd &sd2_bus1 &sd2_bus4>;
- bus-width = <4>;
-};
-
-&ppmu_d0_general {
- status = "okay";
- events {
- ppmu_event0_d0_general: ppmu-event0-d0-general {
- event-name = "ppmu-event0-d0-general";
- };
- };
-};
-
-&ppmu_d1_general {
- status = "okay";
- events {
- ppmu_event0_d1_general: ppmu-event0-d1-general {
- event-name = "ppmu-event0-d1-general";
- };
- };
-};
-
-&pinctrl_alive {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_alive>;
-
- initial_alive: initial-state {
- PIN(INPUT, gpa0-0, DOWN, FAST_SR1);
- PIN(INPUT, gpa0-1, NONE, FAST_SR1);
- PIN(INPUT, gpa0-2, DOWN, FAST_SR1);
- PIN(INPUT, gpa0-3, NONE, FAST_SR1);
- PIN(INPUT, gpa0-4, NONE, FAST_SR1);
- PIN(INPUT, gpa0-5, DOWN, FAST_SR1);
- PIN(INPUT, gpa0-6, NONE, FAST_SR1);
- PIN(INPUT, gpa0-7, NONE, FAST_SR1);
-
- PIN(INPUT, gpa1-0, UP, FAST_SR1);
- PIN(INPUT, gpa1-1, NONE, FAST_SR1);
- PIN(INPUT, gpa1-2, NONE, FAST_SR1);
- PIN(INPUT, gpa1-3, DOWN, FAST_SR1);
- PIN(INPUT, gpa1-4, DOWN, FAST_SR1);
- PIN(INPUT, gpa1-5, NONE, FAST_SR1);
- PIN(INPUT, gpa1-6, NONE, FAST_SR1);
- PIN(INPUT, gpa1-7, NONE, FAST_SR1);
-
- PIN(INPUT, gpa2-0, NONE, FAST_SR1);
- PIN(INPUT, gpa2-1, NONE, FAST_SR1);
- PIN(INPUT, gpa2-2, NONE, FAST_SR1);
- PIN(INPUT, gpa2-3, DOWN, FAST_SR1);
- PIN(INPUT, gpa2-4, NONE, FAST_SR1);
- PIN(INPUT, gpa2-5, DOWN, FAST_SR1);
- PIN(INPUT, gpa2-6, DOWN, FAST_SR1);
- PIN(INPUT, gpa2-7, NONE, FAST_SR1);
-
- PIN(INPUT, gpa3-0, DOWN, FAST_SR1);
- PIN(INPUT, gpa3-1, DOWN, FAST_SR1);
- PIN(INPUT, gpa3-2, NONE, FAST_SR1);
- PIN(INPUT, gpa3-3, DOWN, FAST_SR1);
- PIN(INPUT, gpa3-4, NONE, FAST_SR1);
- PIN(INPUT, gpa3-5, DOWN, FAST_SR1);
- PIN(INPUT, gpa3-6, DOWN, FAST_SR1);
- PIN(INPUT, gpa3-7, DOWN, FAST_SR1);
-
- PIN(INPUT, gpf1-0, NONE, FAST_SR1);
- PIN(INPUT, gpf1-1, NONE, FAST_SR1);
- PIN(INPUT, gpf1-2, DOWN, FAST_SR1);
- PIN(INPUT, gpf1-4, UP, FAST_SR1);
- PIN(OUTPUT, gpf1-5, NONE, FAST_SR1);
- PIN(INPUT, gpf1-6, DOWN, FAST_SR1);
- PIN(INPUT, gpf1-7, DOWN, FAST_SR1);
-
- PIN(INPUT, gpf2-0, DOWN, FAST_SR1);
- PIN(INPUT, gpf2-1, DOWN, FAST_SR1);
- PIN(INPUT, gpf2-2, DOWN, FAST_SR1);
- PIN(INPUT, gpf2-3, DOWN, FAST_SR1);
-
- PIN(INPUT, gpf3-0, DOWN, FAST_SR1);
- PIN(INPUT, gpf3-1, DOWN, FAST_SR1);
- PIN(INPUT, gpf3-2, NONE, FAST_SR1);
- PIN(INPUT, gpf3-3, DOWN, FAST_SR1);
-
- PIN(INPUT, gpf4-0, DOWN, FAST_SR1);
- PIN(INPUT, gpf4-1, DOWN, FAST_SR1);
- PIN(INPUT, gpf4-2, DOWN, FAST_SR1);
- PIN(INPUT, gpf4-3, DOWN, FAST_SR1);
- PIN(INPUT, gpf4-4, DOWN, FAST_SR1);
- PIN(INPUT, gpf4-5, DOWN, FAST_SR1);
- PIN(INPUT, gpf4-6, DOWN, FAST_SR1);
- PIN(INPUT, gpf4-7, DOWN, FAST_SR1);
-
- PIN(INPUT, gpf5-0, DOWN, FAST_SR1);
- PIN(INPUT, gpf5-1, DOWN, FAST_SR1);
- PIN(INPUT, gpf5-2, DOWN, FAST_SR1);
- PIN(INPUT, gpf5-3, DOWN, FAST_SR1);
- PIN(OUTPUT, gpf5-4, NONE, FAST_SR1);
- PIN(INPUT, gpf5-5, DOWN, FAST_SR1);
- PIN(INPUT, gpf5-6, DOWN, FAST_SR1);
- PIN(INPUT, gpf5-7, DOWN, FAST_SR1);
- };
-
- te_irq: te_irq {
- samsung,pins = "gpf1-3";
- samsung,pin-function = <0xf>;
- };
-};
-
-&pinctrl_cpif {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_cpif>;
-
- initial_cpif: initial-state {
- PIN(INPUT, gpv6-0, DOWN, FAST_SR1);
- PIN(INPUT, gpv6-1, DOWN, FAST_SR1);
- };
-};
-
-&pinctrl_ese {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_ese>;
-
- initial_ese: initial-state {
- PIN(INPUT, gpj2-0, DOWN, FAST_SR1);
- PIN(INPUT, gpj2-1, DOWN, FAST_SR1);
- PIN(INPUT, gpj2-2, DOWN, FAST_SR1);
- };
-};
-
-&pinctrl_fsys {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_fsys>;
-
- initial_fsys: initial-state {
- PIN(INPUT, gpr3-0, NONE, FAST_SR1);
- PIN(INPUT, gpr3-1, DOWN, FAST_SR1);
- PIN(INPUT, gpr3-2, DOWN, FAST_SR1);
- PIN(INPUT, gpr3-3, DOWN, FAST_SR1);
- PIN(INPUT, gpr3-7, NONE, FAST_SR1);
- };
-};
-
-&pinctrl_imem {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_imem>;
-
- initial_imem: initial-state {
- PIN(INPUT, gpf0-0, UP, FAST_SR1);
- PIN(INPUT, gpf0-1, UP, FAST_SR1);
- PIN(INPUT, gpf0-2, DOWN, FAST_SR1);
- PIN(INPUT, gpf0-3, UP, FAST_SR1);
- PIN(INPUT, gpf0-4, DOWN, FAST_SR1);
- PIN(INPUT, gpf0-5, NONE, FAST_SR1);
- PIN(INPUT, gpf0-6, DOWN, FAST_SR1);
- PIN(INPUT, gpf0-7, UP, FAST_SR1);
- };
-};
-
-&pinctrl_nfc {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_nfc>;
-
- initial_nfc: initial-state {
- PIN(INPUT, gpj0-2, DOWN, FAST_SR1);
- };
-};
-
-&pinctrl_peric {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_peric>;
-
- initial_peric: initial-state {
- PIN(INPUT, gpv7-0, DOWN, FAST_SR1);
- PIN(INPUT, gpv7-1, DOWN, FAST_SR1);
- PIN(INPUT, gpv7-2, NONE, FAST_SR1);
- PIN(INPUT, gpv7-3, DOWN, FAST_SR1);
- PIN(INPUT, gpv7-4, DOWN, FAST_SR1);
- PIN(INPUT, gpv7-5, DOWN, FAST_SR1);
-
- PIN(INPUT, gpb0-4, DOWN, FAST_SR1);
-
- PIN(INPUT, gpc0-2, DOWN, FAST_SR1);
- PIN(INPUT, gpc0-5, DOWN, FAST_SR1);
- PIN(INPUT, gpc0-7, DOWN, FAST_SR1);
-
- PIN(INPUT, gpc1-1, DOWN, FAST_SR1);
-
- PIN(INPUT, gpc3-4, NONE, FAST_SR1);
- PIN(INPUT, gpc3-5, NONE, FAST_SR1);
- PIN(INPUT, gpc3-6, NONE, FAST_SR1);
- PIN(INPUT, gpc3-7, NONE, FAST_SR1);
-
- PIN(OUTPUT, gpg0-0, NONE, FAST_SR1);
- PIN(2, gpg0-1, DOWN, FAST_SR1);
-
- PIN(INPUT, gpd2-5, DOWN, FAST_SR1);
-
- PIN(INPUT, gpd4-0, NONE, FAST_SR1);
- PIN(INPUT, gpd4-1, DOWN, FAST_SR1);
- PIN(INPUT, gpd4-2, DOWN, FAST_SR1);
- PIN(INPUT, gpd4-3, DOWN, FAST_SR1);
- PIN(INPUT, gpd4-4, DOWN, FAST_SR1);
-
- PIN(INPUT, gpd6-3, DOWN, FAST_SR1);
-
- PIN(INPUT, gpd8-1, UP, FAST_SR1);
-
- PIN(INPUT, gpg1-0, DOWN, FAST_SR1);
- PIN(INPUT, gpg1-1, DOWN, FAST_SR1);
- PIN(INPUT, gpg1-2, DOWN, FAST_SR1);
- PIN(INPUT, gpg1-3, DOWN, FAST_SR1);
- PIN(INPUT, gpg1-4, DOWN, FAST_SR1);
-
- PIN(INPUT, gpg2-0, DOWN, FAST_SR1);
- PIN(INPUT, gpg2-1, DOWN, FAST_SR1);
-
- PIN(INPUT, gpg3-0, DOWN, FAST_SR1);
- PIN(INPUT, gpg3-1, DOWN, FAST_SR1);
- PIN(INPUT, gpg3-5, DOWN, FAST_SR1);
- PIN(INPUT, gpg3-7, DOWN, FAST_SR1);
- };
-};
-
-&pinctrl_touch {
- pinctrl-names = "default";
- pinctrl-0 = <&initial_touch>;
-
- initial_touch: initial-state {
- PIN(INPUT, gpj1-2, DOWN, FAST_SR1);
- };
-};
-
-&pwm {
- pinctrl-0 = <&pwm0_out>;
- pinctrl-names = "default";
- status = "okay";
-};
-
-&mic {
- status = "okay";
-
- i80-if-timings {
- };
-};
-
-&pmu_system_controller {
- assigned-clocks = <&pmu_system_controller 0>;
- assigned-clock-parents = <&xxti>;
-};
-
-&serial_1 {
- status = "okay";
-};
-
-&spi_1 {
- cs-gpios = <&gpd6 3 GPIO_ACTIVE_HIGH>;
- status = "okay";
-
- wm5110: wm5110-codec at 0 {
- compatible = "wlf,wm5110";
- reg = <0x0>;
- spi-max-frequency = <20000000>;
- interrupt-parent = <&gpa0>;
- interrupts = <4 IRQ_TYPE_NONE>;
- clocks = <&pmu_system_controller 0>,
- <&s2mps13_osc S2MPS11_CLK_BT>;
- clock-names = "mclk1", "mclk2";
-
- gpio-controller;
- #gpio-cells = <2>;
-
- wlf,micd-detect-debounce = <300>;
- wlf,micd-bias-start-time = <0x1>;
- wlf,micd-rate = <0x7>;
- wlf,micd-dbtime = <0x1>;
- wlf,micd-force-micbias;
- wlf,micd-configs = <0x0 1 0>;
- wlf,hpdet-channel = <1>;
- wlf,gpsw = <0x1>;
- wlf,inmode = <2 0 2 0>;
-
- wlf,reset = <&gpc0 7 GPIO_ACTIVE_HIGH>;
- wlf,ldoena = <&gpf0 0 GPIO_ACTIVE_HIGH>;
-
- /* core supplies */
- AVDD-supply = <&ldo18_reg>;
- DBVDD1-supply = <&ldo18_reg>;
- CPVDD-supply = <&ldo18_reg>;
- DBVDD2-supply = <&ldo18_reg>;
- DBVDD3-supply = <&ldo18_reg>;
-
- controller-data {
- samsung,spi-feedback-delay = <0>;
- };
- };
-};
-
-&timer {
- clock-frequency = <24000000>;
-};
-
-&tmu_atlas0 {
- vtmu-supply = <&ldo3_reg>;
- status = "okay";
-};
-
-&tmu_apollo {
- vtmu-supply = <&ldo3_reg>;
- status = "okay";
-};
-
-&tmu_g3d {
- vtmu-supply = <&ldo3_reg>;
- status = "okay";
-};
-
-&usbdrd30 {
- vdd33-supply = <&ldo10_reg>;
- vdd10-supply = <&ldo6_reg>;
- status = "okay";
-};
-
-&usbdrd_dwc3_0 {
- dr_mode = "otg";
-};
-
-&usbdrd30_phy {
- vbus-supply = <&safeout1_reg>;
- status = "okay";
-};
-
-&xxti {
- clock-frequency = <24000000>;
-};
+/*
+ * SAMSUNG Exynos5433 TM2 board device tree source
+ *
+ * Copyright (c) 2016 Samsung Electronics Co., Ltd.
+ *
+ * Device tree source file for Samsung's TM2 board which is based on
+ * Samsung Exynos5433 SoC.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "exynos5433-tm2-common.dtsi"
+
+/ {
+ model = "Samsung TM2 board";
+ compatible = "samsung,tm2", "samsung,exynos5433";
+};
+
+&ldo31_reg {
+ regulator-name = "TSP_VDD_1.85V_AP";
+ regulator-min-microvolt = <1850000>;
+ regulator-max-microvolt = <1850000>;
+};
+
+&ldo38_reg {
+ regulator-name = "VCC_3.0V_MOTOR_AP";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+};
diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
index 854c583092d5..2fbf3a860316 100644
--- a/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
+++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2e.dts
@@ -11,7 +11,7 @@
* published by the Free Software Foundation.
*/
-#include "exynos5433-tm2.dts"
+#include "exynos5433-tm2-common.dtsi"
/ {
model = "Samsung TM2E board";
--
2.11.0
^ permalink raw reply related
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