* [PATCH] coresight: tmc: fix for trace collection bug in sysFS mode
From: Suzuki K Poulose @ 2016-09-14 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkzNqMuwcmYJtoORXrON54Wt1oj5uyp2NQpKYM2AN4F26g@mail.gmail.com>
On 13/09/16 16:41, Mathieu Poirier wrote:
> On 13 September 2016 at 06:20, Venkatesh Vivekanandan
> <venkatesh.vivekanandan@broadcom.com> wrote:
>> tmc_etb_dump_hw is never called in sysFS mode to collect trace from
>> hardware, because drvdata->mode is set to CS_MODE_DISABLED at
>> tmc_disable_etf/etr_sink
>>
>> static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
>> {
>> .
>> .
>> if (local_read(&drvdata->mode) == CS_MODE_SYSFS)
>> tmc_etb_dump_hw(drvdata);
>> .
>> .
>> }
>>
>> static void tmc_disable_etf_sink(struct coresight_device *csdev)
>> {
>> .
>> .
>> val = local_xchg(&drvdata->mode, CS_MODE_DISABLED);
>> /* Disable the TMC only if it needs to */
>> if (val != CS_MODE_DISABLED)
>> tmc_etb_disable_hw(drvdata);
>
> You are correct.
>
>> .
>> .
>> }
>>
>> Signed-off-by: Venkatesh Vivekanandan <venkatesh.vivekanandan@broadcom.com>
>> ---
>> drivers/hwtracing/coresight/coresight-tmc-etf.c | 9 +++++----
>> drivers/hwtracing/coresight/coresight-tmc-etr.c | 9 +++++----
>> 2 files changed, 10 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/hwtracing/coresight/coresight-tmc-etf.c b/drivers/hwtracing/coresight/coresight-tmc-etf.c
>> index 466af86..c7fb7f7 100644
>> --- a/drivers/hwtracing/coresight/coresight-tmc-etf.c
>> +++ b/drivers/hwtracing/coresight/coresight-tmc-etf.c
>> @@ -61,6 +61,8 @@ static void tmc_etb_dump_hw(struct tmc_drvdata *drvdata)
>>
>> static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
>> {
>> + long val;
>> +
>> CS_UNLOCK(drvdata->base);
>>
>> tmc_flush_and_stop(drvdata);
>> @@ -68,7 +70,8 @@ static void tmc_etb_disable_hw(struct tmc_drvdata *drvdata)
>> * When operating in sysFS mode the content of the buffer needs to be
>> * read before the TMC is disabled.
>> */
>> - if (local_read(&drvdata->mode) == CS_MODE_SYSFS)
>> + val = local_xchg(&drvdata->mode, CS_MODE_DISABLED);
>> + if (val == CS_MODE_SYSFS)
>> tmc_etb_dump_hw(drvdata);
>> tmc_disable_hw(drvdata);
>>
>> @@ -225,7 +228,6 @@ static int tmc_enable_etf_sink(struct coresight_device *csdev, u32 mode)
>>
>> static void tmc_disable_etf_sink(struct coresight_device *csdev)
>> {
>> - long val;
>> unsigned long flags;
>> struct tmc_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>>
>> @@ -235,9 +237,8 @@ static void tmc_disable_etf_sink(struct coresight_device *csdev)
>> return;
>> }
>>
>> - val = local_xchg(&drvdata->mode, CS_MODE_DISABLED);
>> /* Disable the TMC only if it needs to */
>> - if (val != CS_MODE_DISABLED)
>> + if (local_read(&drvdata->mode) != CS_MODE_DISABLED)
>> tmc_etb_disable_hw(drvdata);
>
> This would work but tmc_enable_etf_sink() and tmc_disable_etf_sink()
> are no longer balanced. Another approach would be to add a "mode"
> parameter to tmc_etb_disable_hw() and so something like:
>
> if (val != CS_MODE_DISABLED)
> tmc_etb_disable_hw(drvdata, val);
>
> In tmc_etb_disable_hw(), if mode == CS_MODE_SYSFS then we can move
> ahead with the dump operation. The same apply for ETR
I think we should :
1) First switch the drvdata->mode to a normal type from local_t. Using an
atomic type for mode is completely unnecessary and comes with the overhead
of barriers/synchronisation instructions, while all accesses, including read/write
are performed under the drvdata->spinlock. I have a patch already for this, which
I plan to send it soon.
and
2) Do something like :
void tmc_disable_etX_sink()
{
if (drvdata->mode != CS_MODE_DISABLED) {
tmc_etX_disable_hw(drvdata);
drvdata->mode = CS_MODE_DISABLED;
}
}
Leaving the tmc_etX_disable_hw() untouched.
Suzuki
^ permalink raw reply
* [PATCH 0/4] ARM: amlogic: add i2c support to Amlogic's gxbb family
From: Jerome Brunet @ 2016-09-14 10:06 UTC (permalink / raw)
To: linux-arm-kernel
Add support for the meson i2c controller found on the gxbb SoC family
This patchset adds 1 i2c in the AO domain and 3 in the EE domain (A,B,C).
There is 1 last i2c in the EE domain (D) but it is actually not connected
to the pad of the SoC, so there is no point in adding it here.
Patches for the i2c [0] driver and pinctrl [1] have been sent in
dedicated series
[0]: http://lkml.kernel.org/r/1473846557-18123-1-git-send-email-jbrunet at baylibre.com
[1]: http://lkml.kernel.org/r/1473846328-17339-1-git-send-email-jbrunet at baylibre.com
Jerome Brunet (3):
clk: gxbb: expose i2c clocks
ARM64: dts: meson-gxbb: add pins for I2C
ARM64: dts: gxbb: add i2c bus
Neil Armstrong (1):
ARM64: dts: meson-gxbb: add I2C nodes
.../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 6 ++
arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 6 ++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 72 ++++++++++++++++++++++
drivers/clk/meson/gxbb.h | 4 +-
include/dt-bindings/clock/gxbb-clkc.h | 2 +
5 files changed, 88 insertions(+), 2 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH 1/4] clk: gxbb: expose i2c clocks
From: Jerome Brunet @ 2016-09-14 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473847568-20163-1-git-send-email-jbrunet@baylibre.com>
I2C and AO_I2C clocks are needed for the i2c driver, expose to DT
(and comment out in clk driver)
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/meson/gxbb.h | 4 ++--
include/dt-bindings/clock/gxbb-clkc.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/meson/gxbb.h b/drivers/clk/meson/gxbb.h
index 044fc44e9144..0252939ba58f 100644
--- a/drivers/clk/meson/gxbb.h
+++ b/drivers/clk/meson/gxbb.h
@@ -190,7 +190,7 @@
#define CLKID_PL301 19
#define CLKID_PERIPHS 20
#define CLKID_SPICC 21
-#define CLKID_I2C 22
+/* CLKID_I2C */
#define CLKID_SAR_ADC 23
#define CLKID_SMART_CARD 24
#define CLKID_RNG0 25
@@ -261,7 +261,7 @@
#define CLKID_AO_AHB_SRAM 90
#define CLKID_AO_AHB_BUS 91
#define CLKID_AO_IFACE 92
-#define CLKID_AO_I2C 93
+/* CLKID_AO_I2C */
/* CLKID_SD_EMMC_A */
/* CLKID_SD_EMMC_B */
/* CLKID_SD_EMMC_C */
diff --git a/include/dt-bindings/clock/gxbb-clkc.h b/include/dt-bindings/clock/gxbb-clkc.h
index 743c45b40361..baade6f429d0 100644
--- a/include/dt-bindings/clock/gxbb-clkc.h
+++ b/include/dt-bindings/clock/gxbb-clkc.h
@@ -13,12 +13,14 @@
#define CLKID_CLK81 12
#define CLKID_MPLL2 15
#define CLKID_SPI 34
+#define CLKID_I2C 22
#define CLKID_ETH 36
#define CLKID_USB0 50
#define CLKID_USB1 51
#define CLKID_USB 55
#define CLKID_USB1_DDR_BRIDGE 64
#define CLKID_USB0_DDR_BRIDGE 65
+#define CLKID_AO_I2C 93
#define CLKID_SD_EMMC_A 94
#define CLKID_SD_EMMC_B 95
#define CLKID_SD_EMMC_C 96
--
2.7.4
^ permalink raw reply related
* [PATCH 2/4] ARM64: dts: meson-gxbb: add pins for I2C
From: Jerome Brunet @ 2016-09-14 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473847568-20163-1-git-send-email-jbrunet@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 32 +++++++++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 9506597fcc1c..75aca5013e61 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -293,6 +293,14 @@
};
};
+ i2c_ao_pins: i2c_ao {
+ mux {
+ groups = "i2c_sck_ao",
+ "i2c_sda_ao";
+ function = "i2c_ao";
+ };
+ };
+
pwm_ao_a_3_pins: pwm_ao_a_3 {
mux {
groups = "pwm_ao_a_3";
@@ -455,6 +463,30 @@
};
};
+ i2c_a_pins: i2c_a {
+ mux {
+ groups = "i2c_sck_a",
+ "i2c_sda_a";
+ function = "i2c_a";
+ };
+ };
+
+ i2c_b_pins: i2c_b {
+ mux {
+ groups = "i2c_sck_b",
+ "i2c_sda_b";
+ function = "i2c_b";
+ };
+ };
+
+ i2c_c_pins: i2c_c {
+ mux {
+ groups = "i2c_sck_c",
+ "i2c_sda_c";
+ function = "i2c_c";
+ };
+ };
+
eth_pins: eth_c {
mux {
groups = "eth_mdio",
--
2.7.4
^ permalink raw reply related
* [PATCH 3/4] ARM64: dts: meson-gxbb: add I2C nodes
From: Jerome Brunet @ 2016-09-14 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473847568-20163-1-git-send-email-jbrunet@baylibre.com>
From: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 40 +++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 75aca5013e61..4aa59dc2beb9 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -242,6 +242,36 @@
clocks = <&clkc CLKID_SPI>;
status = "disabled";
};
+
+ i2c_A: i2c at 8500 {
+ compatible = "amlogic,meson-gxbb-i2c";
+ reg = <0x0 0x08500 0x0 0x20>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc CLKID_I2C>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c_B: i2c at 87c0 {
+ compatible = "amlogic,meson-gxbb-i2c";
+ reg = <0x0 0x087c0 0x0 0x20>;
+ interrupts = <GIC_SPI 214 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc CLKID_I2C>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
+ i2c_C: i2c at 87e0 {
+ compatible = "amlogic,meson-gxbb-i2c";
+ reg = <0x0 0x087e0 0x0 0x20>;
+ interrupts = <GIC_SPI 215 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc CLKID_I2C>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
gic: interrupt-controller at c4301000 {
@@ -358,6 +388,16 @@
#pwm-cells = <3>;
status = "disabled";
};
+
+ i2c_AO: i2c at 500 {
+ compatible = "amlogic,meson-gxbb-i2c";
+ reg = <0x0 0x500 0x0 0x20>;
+ interrupts = <GIC_SPI 195 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&clkc CLKID_AO_I2C>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
};
periphs: periphs at c8834000 {
--
2.7.4
^ permalink raw reply related
* [PATCH 4/4] ARM64: dts: gxbb: add i2c bus
From: Jerome Brunet @ 2016-09-14 10:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473847568-20163-1-git-send-email-jbrunet@baylibre.com>
Add nodes for i2c bus on gxbb based platforms.
On the OdroidC2 (I2C A) and P200 (I2C B), the pull-up resistor are
present directly on the board. This indicates that these pins are
dedicated to i2c.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 6 ++++++
arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts | 6 ++++++
2 files changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
index 4f1554a27422..c6d78d3a018f 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
@@ -180,3 +180,9 @@
vmmc-supply = <&vcc3v3>;
vqmmc-supply = <&vcc1v8>;
};
+
+&i2c_A {
+ status = "okay";
+ pinctrl-0 = <&i2c_a_pins>;
+ pinctrl-names = "default";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
index 62979076e250..03e3d76626dd 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p200.dts
@@ -50,3 +50,9 @@
compatible = "amlogic,p200", "amlogic,meson-gxbb";
model = "Amlogic Meson GXBB P200 Development Board";
};
+
+&i2c_B {
+ status = "okay";
+ pinctrl-0 = <&i2c_b_pins>;
+ pinctrl-names = "default";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH 1/5] clk: add support for runtime pm
From: Marek Szyprowski @ 2016-09-14 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFqufBW0TmPVBx-noSnCvk26WBk9jP4PjgS5wKVuq6cJmA@mail.gmail.com>
Hi Ulf,
On 2016-09-13 17:03, Ulf Hansson wrote:
> [...]
>
>>> This needs to be clarified. I agree we need to cover system PM as
>>> well, but let's try be a bit more precise about it.
>>
>> Right, I wasn't precise here. I've developed this code on older (v4.1 and
>> v4.6)
>> kernels, which had a code which disables runtime pm during system sleep
>> transition
>> time. Maybe I need to revisit it and consider your change merged to
>> v4.8-rc1, which
>> keeps runtime pm enabled during system sleep transitions.
> Right, I see.
>
>>>> static bool clk_core_is_prepared(struct clk_core *core)
>>>> {
>>>> + if (clk_pm_runtime_suspended(core))
>>>> + return false;
>>>> +
>>> This isn't safe, as even if the clock controller is runtime resumed at
>>> this point, that's *not* a guarantee that is stays runtime resumed
>>> while invoking the ->ops->is_prepared().
>>>
>>> Instead you must call a pm_runtime_get_noresume() before you check the
>>> runtime PM status, as that should avoid the device from being runtime
>>> suspended. Then when the ->ops->is_prepared() has been invoked, we
>>> should call pm_runtime_put().
>>>
>>> Although, I am not sure the above change becomes entirely correct as I
>>> think we are mixing the runtime PM status with the clock prepare
>>> status here. In other words, the next time the clock controller
>>> becomes runtime resumed, it may very well restore some register
>>> context which may prepare the clock, unless someone explicitly has
>>> unprepared it.
>>>
>>> Of course, it all depends on how clk_core_is_prepared() is used by the
>>> clock framework.
>>
>> clk_core_is_prepared() is mainly used by disable_unused_tree_*. You are
>> right that it mixes a bit clock prepared state with runtime pm active
>> state of clock controller's, but I assumed here that clock cannot be
>> prepared if runtime pm state of controller is suspended. Other approach
>> here would be to call pm_runtime_get(), check status and then
>> pm_runtime_put(). If you prefer such approach, I will change it.
> Using pm_runtime_get|put() would work for the clk_core_is_prepared()
> case, although perhaps not for the clk_core_is_enabled() case.
>
> The reason is that I guess the clk_core_is_enabled() API may be called
> from atomic context? Thus we would need to enable
> pm_runtime_irq_safe() for the clock provider device, which I *really*
> would like to avoid.
I've checked clk_core_is_enabled() is only used for implementing disabling
of unused clock trees or implementing ->is_enabled() callback, which is used
for the same purpose, so it should be safe to use standard
pm_runtime_get/put
there.
There should be no other usecases for ->is_enabled() method, as it itself is
not really race prone, as other caller might enable/disable given clock in
meantime.
I will remove clk_pm_runtime_suspended() usage then.
> [...]
>
>>> I believe we are also accessing the clock controller HW from the
>>> late_initcall_sync(clk_disable_unused) function.
>>
>> This was indirectly handled by the runtime pm state check in is_prepared
>> and is_enabled().
> I see.
>
> Although, I was thinking that you explicitly would like to
> disable/unprepare unused clocks in this phase, so then it isn't
> sufficient to rely on the runtime PM status to know whether the clock
> is prepared/enabled.
>
> Perhaps, this is the only case when you actually need a
> pm_runtime_get|put() around the ->is_enabled|prepared()!?
Right.
[...]
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH] pinctrl: stm32: add IRQ_DOMAIN_HIERARCHY dependency
From: Arnd Bergmann @ 2016-09-14 10:13 UTC (permalink / raw)
To: linux-arm-kernel
The newly added irqchip support for the stm32 pinctrl driver uses
hierarchical IRQ domains as provided by the NVIC primary irqchip.
This works great for any configuration that may be relevant on
stm32, but when doing compile-testing (randconfig), we can
enable it without NVIC or any other primary irqchip that
enables IRQ_DOMAIN_HIERARCHY:
drivers/pinctrl/stm32/pinctrl-stm32.c:212:13: error: 'irq_chip_eoi_parent' undeclared here (not in a function)
drivers/pinctrl/stm32/pinctrl-stm32.c:213:20: error: 'irq_chip_mask_parent' undeclared here (not in a function)
drivers/pinctrl/stm32/pinctrl-stm32.c:214:20: error: 'irq_chip_unmask_parent' undeclared here (not in a function)
drivers/pinctrl/stm32/pinctrl-stm32.c:215:20: error: 'irq_chip_set_type_parent' undeclared here (not in a function)
This adds a Kconfig dependency to limit compile-testing to
configurations that have IRQ_DOMAIN_HIERARCHY already enabled.
It's not obvious whether we should use 'depends on' or 'select'
here, I think either one works, with 'depends on' being more
intuitive, while 'select' would be less likely to cause dependency
loops.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Fixes: 0eb9f683336d ("pinctrl: Add IRQ support to STM32 gpios")
---
drivers/pinctrl/stm32/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/stm32/Kconfig b/drivers/pinctrl/stm32/Kconfig
index 24bc68308af2..c03dce7a22df 100644
--- a/drivers/pinctrl/stm32/Kconfig
+++ b/drivers/pinctrl/stm32/Kconfig
@@ -10,13 +10,13 @@ config PINCTRL_STM32
config PINCTRL_STM32F429
bool "STMicroelectronics STM32F429 pin control" if COMPILE_TEST && !MACH_STM32F429
- depends on OF
+ depends on OF && IRQ_DOMAIN_HIERARCHY
default MACH_STM32F429
select PINCTRL_STM32
config PINCTRL_STM32F746
bool "STMicroelectronics STM32F746 pin control" if COMPILE_TEST && !MACH_STM32F746
- depends on OF
+ depends on OF && IRQ_DOMAIN_HIERARCHY
default MACH_STM32F746
select PINCTRL_STM32
--
2.9.0
^ permalink raw reply related
* [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
From: Ard Biesheuvel @ 2016-09-14 10:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473788797-10879-1-git-send-email-catalin.marinas@arm.com>
On 13 September 2016 at 18:46, Catalin Marinas <catalin.marinas@arm.com> wrote:
> This is the third version of the arm64 PAN emulation using TTBR0_EL1
> switching. The series has not yet included the alternative nop patches
> from Mark Rutland, nor the empty_zero_page from Ard B. This will be done
> in a subsequent version once 4.9-rc1 is out (which will include Mark's
> alternative nop patches).
>
> Changes since v2:
>
> - efi_set_pgd() reworked to update the saved ttbr0 during run-time
> services as this value is used during exception return
>
> - uaccess_(enable|disable) C macros no longer take an 'alt' parameter
> Instead, uaccess_(enable|disable)_not_uao are introduced for the case
> where hardware PAN switching is not required when UAO is present
>
> - post_ttbr0_update_workaround macro no longer takes a 'ret' parameter
>
> - system_supports_ttbr0_pan renamed to system_uses_ttbr0_pan
>
> - init_thread_info.ttbr0 moved towards the end of the setup_arch()
> function and comment updated
>
> - vmlinux.lds.S fixed to use RESERVED_TTBR0_SIZE
>
> - Config option changed to ARM64_SW_TTBR0_PAN
>
> - Some comment clean-ups and commit log updates
>
Given that every __get_user() call now incurs the PAN switch overhead,
I wonder if it would be worth it to stash the real TTBR0_EL1 value in,
e.g., TPIDRRO_EL0 rather than load it from memory each time. We'd have
to reload the real value of TPIDRRO_EL0 at kernel exit every time, but
only for compat tasks, and not nearly as often, obviously.
^ permalink raw reply
* [PATCH v5 02/16] dt/bindings: Update binding for PM domain idle states
From: Brendan Jackman @ 2016-09-14 10:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913193844.GB28944@linaro.org>
On Tue, Sep 13 2016 at 20:38, Lina Iyer wrote:
> On Tue, Sep 13 2016 at 11:50 -0600, Brendan Jackman wrote:
>>
>>On Mon, Sep 12 2016 at 18:09, Sudeep Holla wrote:
>>> On 12/09/16 17:16, Lina Iyer wrote:
>>>> On Mon, Sep 12 2016 at 09:19 -0600, Brendan Jackman wrote:
>>>>>
>>>>> Hi Lina,
>>>>>
>>>>> Sorry for the delay here, Sudeep and I were both been on holiday last
>>>>> week.
>>>>>
>>>>> On Fri, Sep 02 2016 at 21:16, Lina Iyer wrote:
>>>>>> On Fri, Sep 02 2016 at 07:21 -0700, Sudeep Holla wrote:
>>>>> [...]
>>>>>>> This version is *not very descriptive*. Also the discussion we had
>>>>>>> on v3
>>>>>>> version has not yet concluded IMO. So can I take that we agreed on what
>>>>>>> was proposed there or not ?
>>>>>>>
>>>>>> Sorry, this example is not very descriptive. Pls. check the 8916 dtsi
>>>>>> for the new changes in the following patches. Let me know if that makes
>>>>>> sense.
>>>
>>> Please add all possible use-cases in the bindings. Though one can refer
>>> the usage examples, it might not cover all usage descriptions. It helps
>>> preventing people from defining their own when they don't see examples.
>>> Again DT bindings are like specifications, it should be descriptive
>>> especially this kind of generic ones.
>>>
>>>>>
>>>>> The not-yet-concluded discussion Sudeep is referring to is at [1].
>>>>>
>>>>> In that thread we initially proposed the idea of, instead of splitting
>>>>> state phandles between cpu-idle-states and domain-idle-states, putting
>>>>> CPUs in their own domains and using domain-idle-states for _all_
>>>>> phandles, deprecating cpu-idle-states. I've brought this up in other
>>>>> threads [2] but discussion keeps petering out, and neither this example
>>>>> nor the 8916 dtsi in this patch series reflect the idea.
>>>>>
>>>> Brendan, while your idea is good and will work for CPUs, I do not expect
>>>> other domains and possibly CPU domains on some architectures to follow
>>>> this model. There is nothing that prevents you from doing this today,
>>
>>As I understand it your opposition to this approach is this:
>>
>>There may be devices/CPUs which have idle states which do not constitute
>>"power off". If we put those devices in their own power domain for the
>>purpose of putting their (non-power-off) idle state phandles in
>>domain-idle-states, we are "lying" because no true power domain exists
>>there.
>>
>>Am I correct that that's your opposition?
>>
>>If so, it seems we essentially disagree on the definition of a power
>>domain, i.e. you define it as a set of devices that are powered on/off
>>together while I define it as a set of devices whose power states
>>(including idle states, not just on/off) are tied together. I said
>>something similar on another thread [1] which died out.
>>
>>Do you agree that this is basically where we disagree, or am I missing
>>something else?
>>
>>[2] http://www.spinics.net/lists/devicetree/msg141050.html
>>
> Yes, you are right, I disagree with the definition of a domain around a
> device.
OK, great.
> However, as long as you don't force SoC's to define devices in
> the CPU PM domain to have their own virtual domains, I have no problem.
> You are welcome to define it the way you want for Juno or any other
> platform.
I don't think that's true; the bindings have to work the same way for
all platforms. If for Juno we put CPU idle state phandles in a
domain-idle-states property for per-CPU domains then, with the current
implementation, the CPU-level idle states would be duplicated between
cpuidle and the CPU PM domains.
> I don't want that to be the forced and expected out of all
> SoCs. All I am saying here is that the current implementation would
> handle your case as well.
The current implementation certainly does cover the work I want to
do. The suggestion of per-device power domains for devices/CPUs with
their own idle states is simply intended to minimise the binding design,
since we'd no longer need cpu-idle-states or device-idle-states
(the latter was proposed elsewhere).
I am fine with the bindings as they are implemented currently so long
as:
- The binding doc makes clear how idle state phandles should be split
between cpu-idle-states and domain-idle-states. It should make it
obvious that no phandle should ever appear in both properties. It
would even be worth briefly going over the backward-compatibility
implications (e.g. what happens with old-kernel/new-DT and
new-kernel/old-DT combos if a platform has OSI and PC support and we
move cluster-level idle state phandles out of cpu-idle-states and into
domai-idle-states).
- We have a reason against the definition of power domains as "a set of
devices bound by a common power (including idle) state", since that
definition would simplify the bindings. In my view, "nobody thinks
that's what a power domain is" _is_ a compelling reason, so if others
on the list get involved I'm convinced. I think I speak for Sudeep
here too.
Cheers,
Brendan
^ permalink raw reply
* [PATCH v4 0/2] ARM: cleanup PCI specific configs
From: Kishon Vijay Abraham I @ 2016-09-14 10:19 UTC (permalink / raw)
To: linux-arm-kernel
This series was initially sent to add support for two PCIe
ports in dra7. This included selecting PCI_DOMAINS config
in SOC_DRA7XX.
However from the review, PCI_DOMAINS can instead be selected
from ARCH_MULTIPLATFORM. This is fixed in this series along
with removing PCI_DOMAINS from other configs.
Changes from v3:
*) Added *Acked-by:*
*) Fixed $subject to not have *Fix*
Kishon Vijay Abraham I (2):
ARM: stop *MIGHT_HAVE_PCI* config from being selected redundantly
ARM: select PCI_DOMAINS config from ARCH_MULTIPLATFORM
arch/arm/Kconfig | 1 +
arch/arm/mach-at91/Kconfig | 1 -
arch/arm/mach-axxia/Kconfig | 2 --
arch/arm/mach-cns3xxx/Kconfig | 1 -
arch/arm/mach-exynos/Kconfig | 2 --
arch/arm/mach-imx/Kconfig | 2 --
arch/arm/mach-integrator/Kconfig | 1 -
arch/arm/mach-keystone/Kconfig | 2 --
arch/arm/mach-shmobile/Kconfig | 1 -
arch/arm/mach-spear/Kconfig | 1 -
arch/arm/mach-versatile/Kconfig | 1 -
11 files changed, 1 insertion(+), 14 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v4 1/2] ARM: stop *MIGHT_HAVE_PCI* config from being selected redundantly
From: Kishon Vijay Abraham I @ 2016-09-14 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473848346-17905-1-git-send-email-kishon@ti.com>
*MIGHT_HAVE_PCI* config is already selected in ARCH_MULTIPLATFORM.
Don't select it redundantly in all ARCH_MULTIPLATFORM based machines.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
---
arch/arm/mach-at91/Kconfig | 1 -
arch/arm/mach-axxia/Kconfig | 1 -
arch/arm/mach-exynos/Kconfig | 1 -
arch/arm/mach-integrator/Kconfig | 1 -
arch/arm/mach-keystone/Kconfig | 1 -
arch/arm/mach-spear/Kconfig | 1 -
arch/arm/mach-versatile/Kconfig | 1 -
7 files changed, 7 deletions(-)
diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
index 5204395..841e924 100644
--- a/arch/arm/mach-at91/Kconfig
+++ b/arch/arm/mach-at91/Kconfig
@@ -55,7 +55,6 @@ config SOC_AT91RM9200
select ATMEL_ST
select CPU_ARM920T
select HAVE_AT91_USB_CLK
- select MIGHT_HAVE_PCI
select PINCTRL_AT91
select SOC_SAM_V4_V5
select SRAM if PM
diff --git a/arch/arm/mach-axxia/Kconfig b/arch/arm/mach-axxia/Kconfig
index 6c6d5e7..ee2e131 100644
--- a/arch/arm/mach-axxia/Kconfig
+++ b/arch/arm/mach-axxia/Kconfig
@@ -7,7 +7,6 @@ config ARCH_AXXIA
select ARM_TIMER_SP804
select HAVE_ARM_ARCH_TIMER
select MFD_SYSCON
- select MIGHT_HAVE_PCI
select PCI_DOMAINS if PCI
select ZONE_DMA
help
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 8f820de..ee8a99c 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -126,7 +126,6 @@ config SOC_EXYNOS5440
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
select HAVE_ARM_ARCH_TIMER
select AUTO_ZRELADDR
- select MIGHT_HAVE_PCI
select PCI_DOMAINS if PCI
select PINCTRL_EXYNOS5440
select PM_OPP
diff --git a/arch/arm/mach-integrator/Kconfig b/arch/arm/mach-integrator/Kconfig
index 599f973..cefe44f 100644
--- a/arch/arm/mach-integrator/Kconfig
+++ b/arch/arm/mach-integrator/Kconfig
@@ -21,7 +21,6 @@ if ARCH_INTEGRATOR
config ARCH_INTEGRATOR_AP
bool "Support Integrator/AP and Integrator/PP2 platforms"
select INTEGRATOR_AP_TIMER
- select MIGHT_HAVE_PCI
select SERIAL_AMBA_PL010 if TTY
select SERIAL_AMBA_PL010_CONSOLE if TTY
select SOC_BUS
diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index 8ff61be..1507287 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -8,7 +8,6 @@ config ARCH_KEYSTONE
select COMMON_CLK_KEYSTONE
select ARCH_SUPPORTS_BIG_ENDIAN
select ZONE_DMA if ARM_LPAE
- select MIGHT_HAVE_PCI
select PCI_DOMAINS if PCI
select PINCTRL
help
diff --git a/arch/arm/mach-spear/Kconfig b/arch/arm/mach-spear/Kconfig
index b7260c2..1b6cae5 100644
--- a/arch/arm/mach-spear/Kconfig
+++ b/arch/arm/mach-spear/Kconfig
@@ -20,7 +20,6 @@ config ARCH_SPEAR13XX
select HAVE_ARM_TWD if SMP
select PINCTRL
select MFD_SYSCON
- select MIGHT_HAVE_PCI
help
Supports for ARM's SPEAR13XX family
diff --git a/arch/arm/mach-versatile/Kconfig b/arch/arm/mach-versatile/Kconfig
index b0cc262..c257d40 100644
--- a/arch/arm/mach-versatile/Kconfig
+++ b/arch/arm/mach-versatile/Kconfig
@@ -9,7 +9,6 @@ config ARCH_VERSATILE
select CPU_ARM926T
select ICST
select MFD_SYSCON
- select MIGHT_HAVE_PCI
select PLAT_VERSATILE
select POWER_RESET
select POWER_RESET_VERSATILE
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 2/2] ARM: select PCI_DOMAINS config from ARCH_MULTIPLATFORM
From: Kishon Vijay Abraham I @ 2016-09-14 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473848346-17905-1-git-send-email-kishon@ti.com>
PCI_DOMAINS config should be selected for any SoCs
having more than a single PCIe controller. Without PCI_DOMAINS
config, only one PCIe controller gets registered.
Select PCI_DOMAINS in ARCH_MULTIPLATFORM if PCI is selected, since
it doesn't harm even if a platform has a single PCIe port.
Also remove PCI_DOMAINS being selected from other platform
specific configs.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
---
arch/arm/Kconfig | 1 +
arch/arm/mach-axxia/Kconfig | 1 -
arch/arm/mach-cns3xxx/Kconfig | 1 -
arch/arm/mach-exynos/Kconfig | 1 -
arch/arm/mach-imx/Kconfig | 2 --
arch/arm/mach-keystone/Kconfig | 1 -
arch/arm/mach-shmobile/Kconfig | 1 -
7 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index a9c4e48..fb1b867 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -337,6 +337,7 @@ config ARCH_MULTIPLATFORM
select GENERIC_CLOCKEVENTS
select MIGHT_HAVE_PCI
select MULTI_IRQ_HANDLER
+ select PCI_DOMAINS if PCI
select SPARSE_IRQ
select USE_OF
diff --git a/arch/arm/mach-axxia/Kconfig b/arch/arm/mach-axxia/Kconfig
index ee2e131..fe627cb 100644
--- a/arch/arm/mach-axxia/Kconfig
+++ b/arch/arm/mach-axxia/Kconfig
@@ -7,7 +7,6 @@ config ARCH_AXXIA
select ARM_TIMER_SP804
select HAVE_ARM_ARCH_TIMER
select MFD_SYSCON
- select PCI_DOMAINS if PCI
select ZONE_DMA
help
This enables support for the LSI Axxia devices.
diff --git a/arch/arm/mach-cns3xxx/Kconfig b/arch/arm/mach-cns3xxx/Kconfig
index eb14a0f..5fd836b 100644
--- a/arch/arm/mach-cns3xxx/Kconfig
+++ b/arch/arm/mach-cns3xxx/Kconfig
@@ -2,7 +2,6 @@ menuconfig ARCH_CNS3XXX
bool "Cavium Networks CNS3XXX family"
depends on ARCH_MULTI_V6
select ARM_GIC
- select PCI_DOMAINS if PCI
help
Support for Cavium Networks CNS3XXX platform.
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index ee8a99c..18f0c85 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -126,7 +126,6 @@ config SOC_EXYNOS5440
select ARCH_DMA_ADDR_T_64BIT if ARM_LPAE
select HAVE_ARM_ARCH_TIMER
select AUTO_ZRELADDR
- select PCI_DOMAINS if PCI
select PINCTRL_EXYNOS5440
select PM_OPP
help
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index ee9a318..757cd11 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -523,7 +523,6 @@ config SOC_IMX6Q
select ARM_ERRATA_764369 if SMP
select HAVE_ARM_SCU if SMP
select HAVE_ARM_TWD
- select PCI_DOMAINS if PCI
select PINCTRL_IMX6Q
select SOC_IMX6
@@ -569,7 +568,6 @@ config SOC_LS1021A
bool "Freescale LS1021A support"
select ARM_GIC
select HAVE_ARM_ARCH_TIMER
- select PCI_DOMAINS if PCI
select ZONE_DMA if ARM_LPAE
help
This enables support for Freescale LS1021A processor.
diff --git a/arch/arm/mach-keystone/Kconfig b/arch/arm/mach-keystone/Kconfig
index 1507287..24bd64d 100644
--- a/arch/arm/mach-keystone/Kconfig
+++ b/arch/arm/mach-keystone/Kconfig
@@ -8,7 +8,6 @@ config ARCH_KEYSTONE
select COMMON_CLK_KEYSTONE
select ARCH_SUPPORTS_BIG_ENDIAN
select ZONE_DMA if ARM_LPAE
- select PCI_DOMAINS if PCI
select PINCTRL
help
Support for boards based on the Texas Instruments Keystone family of
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 4a48c9f..09817ba 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -22,7 +22,6 @@ config ARCH_RCAR_GEN2
select PM_GENERIC_DOMAINS
select RENESAS_IRQC
select SYS_SUPPORTS_SH_CMT
- select PCI_DOMAINS if PCI
config ARCH_RMOBILE
bool
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3] arm64: mm: move zero page from .bss to right before swapper_pg_dir
From: Mark Rutland @ 2016-09-14 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8MJL=PP8Kc_BdMUnn-r9+QLhERHehpqF+si6+ZpZCBYg@mail.gmail.com>
On Tue, Sep 13, 2016 at 09:29:50PM +0100, Ard Biesheuvel wrote:
> On 13 September 2016 at 21:24, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Tue, Sep 13, 2016 at 08:18:52PM +0100, Ard Biesheuvel wrote:
> >> On 13 September 2016 at 18:35, Mark Rutland <mark.rutland@arm.com> wrote:
> >> Thanks. But actually, I think it makes sense to make the first
> >> swapper_pg_dir page read-only as well, given that it is only modified
> >> via the fixmap, and we can trivially extend the r/o bss region to end
> >> at 'swapper_pg_dir + PAGE_SIZE'
> >>
> >> Thoughts?
> >
> > I thought that we lazy-allocated the vmalloc region at runtime, and initialised
> > pgd level entries.
> >
> > From a quick dig it looks like a vmalloc() could eventually call
> > pgd_populate(), which seems to set a pgd entry without using a fixmap slot.
> >
> > Is there some reason that won't happen at runtime?
>
> Ah, right. I thought all swapper_pg_dir manipulations went via the
> arch64/mm/mmu.c routines that use the fixmap slots, but apparently
> this is not the case.
For better or worse, we only use a fixmap'd pgd under paging_init, and
only for the temporary pgd, not the "real" swapper pgd.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
From: Mark Rutland @ 2016-09-14 10:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu-zHmExwk-YqXVg2ZuVi1M8L4BbJb6-iARxQ7b_2eH-rA@mail.gmail.com>
On Wed, Sep 14, 2016 at 11:13:33AM +0100, Ard Biesheuvel wrote:
> On 13 September 2016 at 18:46, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > This is the third version of the arm64 PAN emulation using TTBR0_EL1
> > switching.
> Given that every __get_user() call now incurs the PAN switch overhead,
> I wonder if it would be worth it to stash the real TTBR0_EL1 value in,
> e.g., TPIDRRO_EL0 rather than load it from memory each time. We'd have
> to reload the real value of TPIDRRO_EL0 at kernel exit every time, but
> only for compat tasks, and not nearly as often, obviously.
FWIW, my plan for vmap'd stacks involves clobbering TPIDRRO_EL0 early
upon kernel entry to reliably detect/handle stack overflow (as we need
to free up GPR to detect overflow, and we need to detect that before we
try to store to the stack).
For non-compat tasks we must restore zero, so either way we'll end up
with a load (to determine compat-ness or to load the precise value).
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
From: Ard Biesheuvel @ 2016-09-14 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914102659.GC14330@leverpostej>
On 14 September 2016 at 11:27, Mark Rutland <mark.rutland@arm.com> wrote:
> On Wed, Sep 14, 2016 at 11:13:33AM +0100, Ard Biesheuvel wrote:
>> On 13 September 2016 at 18:46, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> > This is the third version of the arm64 PAN emulation using TTBR0_EL1
>> > switching.
>
>> Given that every __get_user() call now incurs the PAN switch overhead,
>> I wonder if it would be worth it to stash the real TTBR0_EL1 value in,
>> e.g., TPIDRRO_EL0 rather than load it from memory each time. We'd have
>> to reload the real value of TPIDRRO_EL0 at kernel exit every time, but
>> only for compat tasks, and not nearly as often, obviously.
>
> FWIW, my plan for vmap'd stacks involves clobbering TPIDRRO_EL0 early
> upon kernel entry to reliably detect/handle stack overflow (as we need
> to free up GPR to detect overflow, and we need to detect that before we
> try to store to the stack).
>
> For non-compat tasks we must restore zero, so either way we'll end up
> with a load (to determine compat-ness or to load the precise value).
>
Are you saying that with vmapped stacks, we'll end up clobbering it
(and thus restoring it) anyway when entering the kernel, and so we
could use it for free afterwards while running in the kernel,
potentially for the real value of TTBR0_EL1?
^ permalink raw reply
* [PATCHv2 3/3] tty/serial: at91: fix hardware handshake on SAM9x5 (without GPIOs)
From: Richard Genoud @ 2016-09-14 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913134556.wpodujgk6yn7rfxz@piout.net>
2016-09-13 15:45 GMT+02:00 Alexandre Belloni
<alexandre.belloni@free-electrons.com>:
> On 12/09/2016 at 12:50:38 +0200, Richard Genoud wrote :
>> >> diff --git a/drivers/tty/serial/atmel_serial.c b/drivers/tty/serial/atmel_serial.c
>> >> index e9b4fbf88c2d..32154e7231ce 100644
>> >> --- a/drivers/tty/serial/atmel_serial.c
>> >> +++ b/drivers/tty/serial/atmel_serial.c
>> >> @@ -2130,15 +2130,19 @@ static void atmel_set_termios(struct uart_port *port, struct ktermios *termios,
>> >> } else if ((termios->c_cflag & CRTSCTS) &&
>> >> !mctrl_gpio_use_rtscts(atmel_port->gpios)) {
>> >> /*
>> >> - * RS232 with hardware handshake (RTS/CTS)
>> >> - * handled by the controller.
>> >> + * Automatic hardware handshake (RTS/CTS) only work with
>> >> + * FIFOs or PDC.
>> >> + * Meaning that on SAM9x5 the controller can't handle
>> >> + * the hardware handshake (no FIFOs nor PDC on these platforms).
>> >> */
>> >> - if (atmel_use_dma_rx(port) && !atmel_use_fifo(port)) {
>> >> - dev_info(port->dev, "not enabling hardware flow control because DMA is used");
>> >> - termios->c_cflag &= ~CRTSCTS;
>> >> - } else {
>> >> + if (atmel_use_pdc_rx(port) || atmel_use_fifo(port))
>> >> mode |= ATMEL_US_USMODE_HWHS;
>> >> - }
>> >> + else
>> >> + /*
>> >> + * The hardware handshake won't be handle by the
>> >> + * controller but by the driver.
>> >> + */
>> >> + mode |= ATMEL_US_USMODE_NORMAL;
>> >
>> > You still need the case where HWHS is impossible and there are no gpio
>> > configured. You need to inform userspace that the configuration was not
>> > applied instead of silently ignoring the error.
>>
>> Could you explain which case it is ?
>> The only one I can see is when there's no GPIO declared for RTS/CTS
>> AND, there's no pin muxed for RTS/CTS either.
>>
>> Have you got another example in mind ?
>>
>
> Hum, actually, it is that case. The other one (CRTSCTS and gpios) is
> handled in the else below. I think you need to keep the termios->c_cflag
> &= ~CRTSCTS; here so that userspace knows configuring it failed.
So, could you explain how you intend to detect that there's no pin
muxed for RTS/CTS ?
Because IHMO, that's not possible with what is described in the DTS.
To be sure that we really understand each other, I want you to tell me
how you intend to make the difference between:
pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
AND
pinctrl-0 = <&pinctrl_usart1>;
in the atmel_serial driver ?
and then your test would be:
if (rts_cts_not_muxed()) {
dev_info(port->dev, "hey ! there's no pin muxed for RTS/CTS, I won't
enable HWHS");
}
Meanwhile, I did quite some testing with a sama5d3 xplained I have.
Same results as the SAM9x5. (Unfortunately, I don't have a sama5d2,
the only ones with fifos).
Here are those results:
With RTS/CTS NOT handled by GPIOs (pinctrl-0 = <&pinctrl_usart1
&pinctrl_usart1_rts_cts>;) :
- if USMODE==HW : Fails in every case. (DMA/PDC/PIO)
- if USMODE==NORMAL + PDC : crask kernel (quite normal since there's no PDC)
- if USMODE==NORMAL + DMA : works great, CTS and RTS respond OK
- if USMODE==NORMAL + PIO : works fine, but some chars gets eaten.
With RTS/CTS handled by GPIOs
(pinctrl-0 = <&pinctrl_usart1;rts-gpios = <&pioB 27
GPIO_ACTIVE_LOW>;cts-gpios = <&pioB 26 GPIO_ACTIVE_LOW>;) :
- if USMODE==HW : Nonsense
- if USMODE==NORMAL + PDC : crask kernel (quite normal since there's no PDC)
- if USMODE==NORMAL + DMA : works great, CTS and RTS respond OK
- if USMODE==NORMAL + PIO : works fine, but some chars gets eaten.
So, again, commit 5be605ac9af9 is wrong because we don't want to
remove the CRTSCTS flag if rts_cts are muxed !!!
If someone does some testing on a sama5d2, it would help, but from the
informations I have, I stick to this logic:
/*
* Automatic hardware handshake (RTS/CTS) only work with
* FIFOs or PDC.
* Meaning that on SAM9x5 the controller can't handle
* the hardware handshake (no FIFOs nor PDC on these platforms).
*/
if (atmel_use_pdc_rx(port) || atmel_use_fifo(port))
mode |= ATMEL_US_USMODE_HWHS;
else
/*
* The hardware handshake won't be handle by the
* controller but by the driver.
*/
mode |= ATMEL_US_USMODE_NORMAL;
Test configuration on 3xplained :
DTS:
usart1: serial at f0020000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xf0020000 0x100>;
interrupts = <13 IRQ_TYPE_LEVEL_HIGH 5>;
atmel,use-dma-rx; // comment to switch to PIO
dmas = <&dma0 2 AT91_DMA_CFG_PER_ID(5)>, <&dma0 2
(AT91_DMA_CFG_PER_ID(6) | AT91_DMA_CFG_FIFOCFG_ASAP)>;
dma-names = "tx", "rx";
pinctrl-names = "default";
clocks = <&usart1_clk>;
clock-names = "usart";
pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
/*
//or
rts-gpios = <&pioB 27 GPIO_ACTIVE_LOW>;
cts-gpios = <&pioB 26 GPIO_ACTIVE_LOW>;
pinctrl-0 = <&pinctrl_usart1>;
*/
status = "okay";
};
usart2: serial at f8020000 {
compatible = "atmel,at91sam9260-usart";
reg = <0xf8020000 0x100>;
interrupts = <14 IRQ_TYPE_LEVEL_HIGH 5>;
atmel,use-dma-rx;
dmas = <&dma1 2 AT91_DMA_CFG_PER_ID(7)>, <&dma1 2
(AT91_DMA_CFG_PER_ID(8) | AT91_DMA_CFG_FIFOCFG_ASAP)>;
rts-gpios = <&pioA 20 GPIO_ACTIVE_LOW>;
cts-gpios = <&pioA 21 GPIO_ACTIVE_LOW>;
dma-names = "tx", "rx";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_usart2>;
clocks = <&usart2_clk>;
clock-names = "usart";
status = "okay";
};
On board:
stty -F /dev/ttyS2 115200 raw -echo crtscts -opost clocal cread
stty -F /dev/ttyS3 115200 raw -echo crtscts -opost clocal cread
On one terminal :
cat MAINTAINERS > /dev/ttyS3
On another:
exec 4</dev/ttyS2
cat <&4 >> /tmp/rcv # ctrl-c and again several times
exec 4<&-
diff -u MAINTAINERS /tmp/rcv
^ permalink raw reply
* [PATCH v7 00/22] Generic DT bindings for PCI IOMMUs and ARM SMMU
From: Robin Murphy @ 2016-09-14 10:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <11ebd81e-2ea5-5ff3-35b3-be95f03e05bd@redhat.com>
On 14/09/16 09:41, Auger Eric wrote:
> Hi,
>
> On 12/09/2016 18:13, Robin Murphy wrote:
>> Hi all,
>>
>> To any more confusing fixups and crazily numbered extra patches, here's
>> a quick v7 with everything rebased into the right order. The significant
>> change this time is to implement iommu_fwspec properly from the start,
>> which ends up being far simpler and more robust than faffing about
>> introducing it somewhere 'less intrusive' to move toward core code later.
>>
>> New branch in the logical place:
>>
>> git://linux-arm.org/linux-rm iommu/generic-v7
>
> For information, as discussed privately with Robin I experience some
> regressions with the former and now deprecated dt description.
>
> on my AMD Overdrive board and my old dt description I now only see a
> single group:
>
> /sys/kernel/iommu_groups/
> /sys/kernel/iommu_groups/0
> /sys/kernel/iommu_groups/0/devices
> /sys/kernel/iommu_groups/0/devices/e0700000.xgmac
>
> whereas I formerly see
>
> /sys/kernel/iommu_groups/
> /sys/kernel/iommu_groups/3
> /sys/kernel/iommu_groups/3/devices
> /sys/kernel/iommu_groups/3/devices/0000:00:00.0
> /sys/kernel/iommu_groups/1
> /sys/kernel/iommu_groups/1/devices
> /sys/kernel/iommu_groups/1/devices/e0700000.xgmac
> /sys/kernel/iommu_groups/4
> /sys/kernel/iommu_groups/4/devices
> /sys/kernel/iommu_groups/4/devices/0000:00:02.2
> /sys/kernel/iommu_groups/4/devices/0000:01:00.1
> /sys/kernel/iommu_groups/4/devices/0000:00:02.0
> /sys/kernel/iommu_groups/4/devices/0000:01:00.0
> /sys/kernel/iommu_groups/2
> /sys/kernel/iommu_groups/2/devices
> /sys/kernel/iommu_groups/2/devices/e0900000.xgmac
> /sys/kernel/iommu_groups/0
> /sys/kernel/iommu_groups/0/devices
> /sys/kernel/iommu_groups/0/devices/f0000000.pcie
>
> This is the group topology without ACS override. Applying the non
> upstreamed "pci: Enable overrides for missing ACS capabilities" I used
> to see separate groups for each PCIe components. Now I don't see any
> difference with and without ACS override.
OK, having reproduced on my Juno, the problem looks to be that
of_for_each_phandle() leaves err set to -ENOENT after successfully
walking a phandle list, which makes __find_legacy_master_phandle()
always bail out after the first SMMU.
Can you confirm that the following diff fixes things for you?
Robin
--->8---
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index fa892d25004d..ac4aab97c93a 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -477,7 +477,7 @@ static int __find_legacy_master_phandle(struct
device *dev, void *data)
return 1;
}
it->node = np;
- return err;
+ return err == -ENOENT ? 0 : err;
}
static struct platform_driver arm_smmu_driver;
^ permalink raw reply related
* [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
From: Mark Rutland @ 2016-09-14 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_ww5+_vcKfnFsUgG6h1v87-CWhLp_o7qHS6=3nd6-cow@mail.gmail.com>
On Wed, Sep 14, 2016 at 11:30:05AM +0100, Ard Biesheuvel wrote:
> On 14 September 2016 at 11:27, Mark Rutland <mark.rutland@arm.com> wrote:
> > On Wed, Sep 14, 2016 at 11:13:33AM +0100, Ard Biesheuvel wrote:
> >> On 13 September 2016 at 18:46, Catalin Marinas <catalin.marinas@arm.com> wrote:
> >> > This is the third version of the arm64 PAN emulation using TTBR0_EL1
> >> > switching.
> >
> >> Given that every __get_user() call now incurs the PAN switch overhead,
> >> I wonder if it would be worth it to stash the real TTBR0_EL1 value in,
> >> e.g., TPIDRRO_EL0 rather than load it from memory each time. We'd have
> >> to reload the real value of TPIDRRO_EL0 at kernel exit every time, but
> >> only for compat tasks, and not nearly as often, obviously.
> >
> > FWIW, my plan for vmap'd stacks involves clobbering TPIDRRO_EL0 early
> > upon kernel entry to reliably detect/handle stack overflow (as we need
> > to free up GPR to detect overflow, and we need to detect that before we
> > try to store to the stack).
> >
> > For non-compat tasks we must restore zero, so either way we'll end up
> > with a load (to determine compat-ness or to load the precise value).
>
> Are you saying that with vmapped stacks, we'll end up clobbering it
> (and thus restoring it) anyway when entering the kernel, and so we
> could use it for free afterwards while running in the kernel,
> potentially for the real value of TTBR0_EL1?
Yes, assuming that we end up following my current plan for how to
implement that.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v3 0/7] arm64: Privileged Access Never using TTBR0_EL1 switching
From: Mark Rutland @ 2016-09-14 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914103632.GD14330@leverpostej>
On Wed, Sep 14, 2016 at 11:36:46AM +0100, Mark Rutland wrote:
> On Wed, Sep 14, 2016 at 11:30:05AM +0100, Ard Biesheuvel wrote:
> > On 14 September 2016 at 11:27, Mark Rutland <mark.rutland@arm.com> wrote:
> > > On Wed, Sep 14, 2016 at 11:13:33AM +0100, Ard Biesheuvel wrote:
> > >> On 13 September 2016 at 18:46, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > >> > This is the third version of the arm64 PAN emulation using TTBR0_EL1
> > >> > switching.
> > >
> > >> Given that every __get_user() call now incurs the PAN switch overhead,
> > >> I wonder if it would be worth it to stash the real TTBR0_EL1 value in,
> > >> e.g., TPIDRRO_EL0 rather than load it from memory each time. We'd have
> > >> to reload the real value of TPIDRRO_EL0 at kernel exit every time, but
> > >> only for compat tasks, and not nearly as often, obviously.
> > >
> > > FWIW, my plan for vmap'd stacks involves clobbering TPIDRRO_EL0 early
> > > upon kernel entry to reliably detect/handle stack overflow (as we need
> > > to free up GPR to detect overflow, and we need to detect that before we
> > > try to store to the stack).
> > >
> > > For non-compat tasks we must restore zero, so either way we'll end up
> > > with a load (to determine compat-ness or to load the precise value).
> >
> > Are you saying that with vmapped stacks, we'll end up clobbering it
> > (and thus restoring it) anyway when entering the kernel, and so we
> > could use it for free afterwards while running in the kernel,
> > potentially for the real value of TTBR0_EL1?
>
> Yes, assuming that we end up following my current plan for how to
> implement that.
Actually, after thinknig for more than a picosecond, no we can't.
We need to be able to clbober it on EL1 -> EL1 exceptions, to catch
kernel stack overflow.
So if anything, the two approaches are mutually exclusive, unless we
restore the stashed TTBR0 value back into TPIDRRO_EL0 before returning
from EL1 -> EL1.
/me fetches some more coffee.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v7 22/22] iommu/dma: Avoid PCI host bridge windows
From: Marek Szyprowski @ 2016-09-14 10:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5f7bfee298f98d29a35933d3e0252d32b83d62b8.1473695704.git.robin.murphy@arm.com>
Hi Robin,
On 2016-09-12 18:14, Robin Murphy wrote:
> With our DMA ops enabled for PCI devices, we should avoid allocating
> IOVAs which a host bridge might misinterpret as peer-to-peer DMA and
> lead to faults, corruption or other badness. To be safe, punch out holes
> for all of the relevant host bridge's windows when initialising a DMA
> domain for a PCI device.
>
> CC: Marek Szyprowski <m.szyprowski@samsung.com>
> CC: Inki Dae <inki.dae@samsung.com>
> Reported-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
I don't know much about PCI and their IOMMU integration, but can't we use
the direct mapping region feature of iommu core for it? There are already
iommu_get_dm_regions(), iommu_put_dm_regions() and
iommu_request_dm_for_dev()
functions for handling them...
> ---
>
> - Squash in the previous drm/exynos fixup
> - If need be, this one can probably wait
> ---
> arch/arm64/mm/dma-mapping.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_iommu.h | 2 +-
> drivers/iommu/dma-iommu.c | 25 ++++++++++++++++++++++++-
> include/linux/dma-iommu.h | 3 ++-
> 4 files changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
> index c4284c432ae8..610d8e53011e 100644
> --- a/arch/arm64/mm/dma-mapping.c
> +++ b/arch/arm64/mm/dma-mapping.c
> @@ -827,7 +827,7 @@ static bool do_iommu_attach(struct device *dev, const struct iommu_ops *ops,
> * then the IOMMU core will have already configured a group for this
> * device, and allocated the default domain for that group.
> */
> - if (!domain || iommu_dma_init_domain(domain, dma_base, size)) {
> + if (!domain || iommu_dma_init_domain(domain, dma_base, size, dev)) {
> pr_warn("Failed to set up IOMMU for device %s; retaining platform DMA ops\n",
> dev_name(dev));
> return false;
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.h b/drivers/gpu/drm/exynos/exynos_drm_iommu.h
> index c8de4913fdbe..87f6b5672e11 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.h
> @@ -66,7 +66,7 @@ static inline int __exynos_iommu_create_mapping(struct exynos_drm_private *priv,
> if (ret)
> goto free_domain;
>
> - ret = iommu_dma_init_domain(domain, start, size);
> + ret = iommu_dma_init_domain(domain, start, size, NULL);
> if (ret)
> goto put_cookie;
>
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 4329d18080cf..c5ab8667e6f2 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -27,6 +27,7 @@
> #include <linux/iova.h>
> #include <linux/irq.h>
> #include <linux/mm.h>
> +#include <linux/pci.h>
> #include <linux/scatterlist.h>
> #include <linux/vmalloc.h>
>
> @@ -103,18 +104,38 @@ void iommu_put_dma_cookie(struct iommu_domain *domain)
> }
> EXPORT_SYMBOL(iommu_put_dma_cookie);
>
> +static void iova_reserve_pci_windows(struct pci_dev *dev,
> + struct iova_domain *iovad)
> +{
> + struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
> + struct resource_entry *window;
> + unsigned long lo, hi;
> +
> + resource_list_for_each_entry(window, &bridge->windows) {
> + if (resource_type(window->res) != IORESOURCE_MEM &&
> + resource_type(window->res) != IORESOURCE_IO)
> + continue;
> +
> + lo = iova_pfn(iovad, window->res->start - window->offset);
> + hi = iova_pfn(iovad, window->res->end - window->offset);
> + reserve_iova(iovad, lo, hi);
> + }
> +}
> +
> /**
> * iommu_dma_init_domain - Initialise a DMA mapping domain
> * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
> * @base: IOVA at which the mappable address space starts
> * @size: Size of IOVA space
> + * @dev: Device the domain is being initialised for
> *
> * @base and @size should be exact multiples of IOMMU page granularity to
> * avoid rounding surprises. If necessary, we reserve the page at address 0
> * to ensure it is an invalid IOVA. It is safe to reinitialise a domain, but
> * any change which could make prior IOVAs invalid will fail.
> */
> -int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base, u64 size)
> +int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
> + u64 size, struct device *dev)
> {
> struct iova_domain *iovad = cookie_iovad(domain);
> unsigned long order, base_pfn, end_pfn;
> @@ -152,6 +173,8 @@ int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base, u64 size
> iovad->dma_32bit_pfn = end_pfn;
> } else {
> init_iova_domain(iovad, 1UL << order, base_pfn, end_pfn);
> + if (dev && dev_is_pci(dev))
> + iova_reserve_pci_windows(to_pci_dev(dev), iovad);
> }
> return 0;
> }
> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> index 5ee806e41b5c..32c589062bd9 100644
> --- a/include/linux/dma-iommu.h
> +++ b/include/linux/dma-iommu.h
> @@ -30,7 +30,8 @@ int iommu_get_dma_cookie(struct iommu_domain *domain);
> void iommu_put_dma_cookie(struct iommu_domain *domain);
>
> /* Setup call for arch DMA mapping code */
> -int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base, u64 size);
> +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);
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH v7 22/22] iommu/dma: Avoid PCI host bridge windows
From: Robin Murphy @ 2016-09-14 11:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ab8693f6-20d6-2a95-9f1f-0607e72bc012@samsung.com>
Hi Marek,
On 14/09/16 11:55, Marek Szyprowski wrote:
> Hi Robin,
>
>
> On 2016-09-12 18:14, Robin Murphy wrote:
>> With our DMA ops enabled for PCI devices, we should avoid allocating
>> IOVAs which a host bridge might misinterpret as peer-to-peer DMA and
>> lead to faults, corruption or other badness. To be safe, punch out holes
>> for all of the relevant host bridge's windows when initialising a DMA
>> domain for a PCI device.
>>
>> CC: Marek Szyprowski <m.szyprowski@samsung.com>
>> CC: Inki Dae <inki.dae@samsung.com>
>> Reported-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>
> I don't know much about PCI and their IOMMU integration, but can't we use
> the direct mapping region feature of iommu core for it? There are already
> iommu_get_dm_regions(), iommu_put_dm_regions() and
> iommu_request_dm_for_dev()
> functions for handling them...
It's rather the opposite problem - in the direct-mapping case, we're
making sure the iommu_domain has translations installed for the given
IOVAs (which are also the corresponding physical address) before it goes
live, whereas what we need to do here is make sure the these addresses
never get used as IOVAs at all, because any attempt to do so them will
likely go wrong. Thus we carve them out of the iova_domain such that
they will never get near an actual IOMMU API call.
This is a slightly generalised equivalent of e.g. amd_iommu.c's
init_reserved_iova_ranges().
Robin.
>
>> ---
>>
>> - Squash in the previous drm/exynos fixup
>> - If need be, this one can probably wait
>> ---
>> arch/arm64/mm/dma-mapping.c | 2 +-
>> drivers/gpu/drm/exynos/exynos_drm_iommu.h | 2 +-
>> drivers/iommu/dma-iommu.c | 25
>> ++++++++++++++++++++++++-
>> include/linux/dma-iommu.h | 3 ++-
>> 4 files changed, 28 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
>> index c4284c432ae8..610d8e53011e 100644
>> --- a/arch/arm64/mm/dma-mapping.c
>> +++ b/arch/arm64/mm/dma-mapping.c
>> @@ -827,7 +827,7 @@ static bool do_iommu_attach(struct device *dev,
>> const struct iommu_ops *ops,
>> * then the IOMMU core will have already configured a group for
>> this
>> * device, and allocated the default domain for that group.
>> */
>> - if (!domain || iommu_dma_init_domain(domain, dma_base, size)) {
>> + if (!domain || iommu_dma_init_domain(domain, dma_base, size, dev)) {
>> pr_warn("Failed to set up IOMMU for device %s; retaining
>> platform DMA ops\n",
>> dev_name(dev));
>> return false;
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.h
>> b/drivers/gpu/drm/exynos/exynos_drm_iommu.h
>> index c8de4913fdbe..87f6b5672e11 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_iommu.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.h
>> @@ -66,7 +66,7 @@ static inline int
>> __exynos_iommu_create_mapping(struct exynos_drm_private *priv,
>> if (ret)
>> goto free_domain;
>> - ret = iommu_dma_init_domain(domain, start, size);
>> + ret = iommu_dma_init_domain(domain, start, size, NULL);
>> if (ret)
>> goto put_cookie;
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index 4329d18080cf..c5ab8667e6f2 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -27,6 +27,7 @@
>> #include <linux/iova.h>
>> #include <linux/irq.h>
>> #include <linux/mm.h>
>> +#include <linux/pci.h>
>> #include <linux/scatterlist.h>
>> #include <linux/vmalloc.h>
>> @@ -103,18 +104,38 @@ void iommu_put_dma_cookie(struct iommu_domain
>> *domain)
>> }
>> EXPORT_SYMBOL(iommu_put_dma_cookie);
>> +static void iova_reserve_pci_windows(struct pci_dev *dev,
>> + struct iova_domain *iovad)
>> +{
>> + struct pci_host_bridge *bridge = pci_find_host_bridge(dev->bus);
>> + struct resource_entry *window;
>> + unsigned long lo, hi;
>> +
>> + resource_list_for_each_entry(window, &bridge->windows) {
>> + if (resource_type(window->res) != IORESOURCE_MEM &&
>> + resource_type(window->res) != IORESOURCE_IO)
>> + continue;
>> +
>> + lo = iova_pfn(iovad, window->res->start - window->offset);
>> + hi = iova_pfn(iovad, window->res->end - window->offset);
>> + reserve_iova(iovad, lo, hi);
>> + }
>> +}
>> +
>> /**
>> * iommu_dma_init_domain - Initialise a DMA mapping domain
>> * @domain: IOMMU domain previously prepared by iommu_get_dma_cookie()
>> * @base: IOVA at which the mappable address space starts
>> * @size: Size of IOVA space
>> + * @dev: Device the domain is being initialised for
>> *
>> * @base and @size should be exact multiples of IOMMU page
>> granularity to
>> * avoid rounding surprises. If necessary, we reserve the page at
>> address 0
>> * to ensure it is an invalid IOVA. It is safe to reinitialise a
>> domain, but
>> * any change which could make prior IOVAs invalid will fail.
>> */
>> -int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t
>> base, u64 size)
>> +int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t base,
>> + u64 size, struct device *dev)
>> {
>> struct iova_domain *iovad = cookie_iovad(domain);
>> unsigned long order, base_pfn, end_pfn;
>> @@ -152,6 +173,8 @@ int iommu_dma_init_domain(struct iommu_domain
>> *domain, dma_addr_t base, u64 size
>> iovad->dma_32bit_pfn = end_pfn;
>> } else {
>> init_iova_domain(iovad, 1UL << order, base_pfn, end_pfn);
>> + if (dev && dev_is_pci(dev))
>> + iova_reserve_pci_windows(to_pci_dev(dev), iovad);
>> }
>> return 0;
>> }
>> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
>> index 5ee806e41b5c..32c589062bd9 100644
>> --- a/include/linux/dma-iommu.h
>> +++ b/include/linux/dma-iommu.h
>> @@ -30,7 +30,8 @@ int iommu_get_dma_cookie(struct iommu_domain *domain);
>> void iommu_put_dma_cookie(struct iommu_domain *domain);
>> /* Setup call for arch DMA mapping code */
>> -int iommu_dma_init_domain(struct iommu_domain *domain, dma_addr_t
>> base, u64 size);
>> +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);
>
> Best regards
^ permalink raw reply
* [PATCH v3 1/2] ARM: dts: imx6ul: Add DTS for liteSOM module
From: Marcin Niestroj @ 2016-09-14 11:13 UTC (permalink / raw)
To: linux-arm-kernel
This is a SOM (System on Module), so it will be part of another boards.
Hence, this is a "dtsi" file that will be included from another device
tree files.
Hardware specification:
* Freescale i.MX6UL SoC
* up to 512 MB RAM
* eMMC on uSDHC2
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes v2 -> v3:
* Remove cpu0 supplies (arm-supply, soc-supply), as they were already
set in imx6ul.dtsi file (reported by S?bastien Szymanski)
Changes v1 -> v2:
* Use dual license
arch/arm/boot/dts/imx6ul-litesom.dtsi | 82 +++++++++++++++++++++++++++++++++++
1 file changed, 82 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-litesom.dtsi
diff --git a/arch/arm/boot/dts/imx6ul-litesom.dtsi b/arch/arm/boot/dts/imx6ul-litesom.dtsi
new file mode 100644
index 0000000..461292d
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-litesom.dtsi
@@ -0,0 +1,82 @@
+/*
+ * Copyright 2016 Grinn
+ *
+ * Author: Marcin Niestroj <m.niestroj@grinn-global.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file 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.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "imx6ul.dtsi"
+
+/ {
+ model = "Grinn i.MX6UL liteSOM";
+ compatible = "grinn,imx6ul-litesom", "fsl,imx6ul";
+
+ memory {
+ reg = <0x80000000 0x20000000>;
+ };
+};
+
+&iomuxc {
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x10069
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x17059
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x17059
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x17059
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x17059
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x17059
+ MX6UL_PAD_NAND_DATA04__USDHC2_DATA4 0x17059
+ MX6UL_PAD_NAND_DATA05__USDHC2_DATA5 0x17059
+ MX6UL_PAD_NAND_DATA06__USDHC2_DATA6 0x17059
+ MX6UL_PAD_NAND_DATA07__USDHC2_DATA7 0x17059
+ MX6UL_PAD_NAND_ALE__USDHC2_RESET_B 0x17059
+ >;
+ };
+};
+
+&usdhc2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ no-1-8-v;
+ non-removable;
+ keep-power-in-suspend;
+ wakeup-source;
+ bus-width = <8>;
+ status = "okay";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH v3 2/2] ARM: dts: imx6ul: Add DTS for liteBoard
From: Marcin Niestroj @ 2016-09-14 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914111304.2583-1-m.niestroj@grinn-global.com>
liteBoard is a development board which uses liteSOM as its base.
Hardware specification:
* liteSOM (i.MX6UL, DRAM, eMMC)
* Ethernet PHY (id 0)
* USB host (usb_otg1)
* MicroSD slot (uSDHC1)
Signed-off-by: Marcin Niestroj <m.niestroj@grinn-global.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
---
Changes v2 -> v3: none
Changes v1 -> v2:
* Use dual license
* Fix typo "defaullt" -> "default"
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/imx6ul-liteboard.dts | 153 +++++++++++++++++++++++++++++++++
2 files changed, 154 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-liteboard.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index faacd52..b149313 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -407,6 +407,7 @@ dtb-$(CONFIG_SOC_IMX6SX) += \
imx6sx-sdb.dtb
dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-14x14-evk.dtb \
+ imx6ul-liteboard.dtb \
imx6ul-pico-hobbit.dtb \
imx6ul-tx6ul-0010.dtb \
imx6ul-tx6ul-0011.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-liteboard.dts b/arch/arm/boot/dts/imx6ul-liteboard.dts
new file mode 100644
index 0000000..f2e04f2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-liteboard.dts
@@ -0,0 +1,153 @@
+/*
+ * Copyright 2016 Grinn
+ *
+ * Author: Marcin Niestroj <m.niestroj@grinn-global.com>
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file 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.
+ *
+ * This file 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.
+ *
+ * Or, alternatively
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "imx6ul-litesom.dtsi"
+
+/ {
+ model = "Grinn i.MX6UL liteBoard";
+ compatible = "grinn,imx6ul-liteboard", "grinn,imx6ul-litesom",
+ "fsl,imx6ul";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ reg_usb_otg1_vbus: usb_otg1_regulator {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb_otg1_vbus>;
+ regulator-name = "usb_otg1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio2 8 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
+ MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0
+ MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b031
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x17059
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10071
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+ >;
+ };
+
+ pinctrl_usb_otg1_vbus: usb_otg1_vbus {
+ fsl,pins = <
+ MX6UL_PAD_ENET2_RX_DATA0__GPIO2_IO08 0x79
+ >;
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1>;
+ phy-mode = "rmii";
+ phy-handle = <ðphy0>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy at 0 {
+ reg = <0>;
+ };
+ };
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&usbotg1 {
+ vbus-supply = <®_usb_otg1_vbus>;
+ dr_mode = "host";
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
+ no-1-8-v;
+ keep-power-in-suspend;
+ wakeup-source;
+ status = "okay";
+};
--
2.9.3
^ permalink raw reply related
* [PATCH 18/33] pcmcia: sa1100: provide generic CF support
From: Linus Walleij @ 2016-09-14 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914090602.GB1041@n2100.armlinux.org.uk>
On Wed, Sep 14, 2016 at 11:06 AM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> Thanks, I've included a change there, should be part of the branch by
> the time you get this email - sa1100 head should be 9ad0f8181616. If
> not, it's probably still being pushed out over my slow 'net link.
Thanks, fetched it and tested, this fix is there things work so far.
>> (It revealed another bug in fetching GPIOs but it is an orthogobal
>> problem altogether, looking into it.)
>
> If you're referring to the generic sa1100 pcmcia code, there's a fix
> for that already in my branch.
Unfortunately not, the bug is still there, I'll point it out in the relevant
patch, just need to do a boot test.
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox