* [PATCH] i2c: i2c-cadence: Don't register the adapter until it's ready
From: Vladimir Zapolskiy @ 2017-01-06 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483613240-32501-1-git-send-email-mike.looijmans@topic.nl>
Hello Mike,
On 01/05/2017 12:47 PM, Mike Looijmans wrote:
> The driver calls i2c_add_adapter before writing to config registers,
> resulting in dmesg output like this, where devices fail to initialize:
>
> cdns-i2c ff030000.i2c: timeout waiting on completion
> pca953x 1-0041: failed reading register
> pca953x: probe of 1-0041 failed with error -110
> at24 1-0050: 512 byte 24c04 EEPROM, writable, 1 bytes/write
> cdns-i2c ff030000.i2c: 100 kHz mmio ff030000 irq 197
>
> The adapter is being used before it completed the "probe". To fix
> this, make "i2c_add_adapter" the last thing it calls in probe.
> It also makes sense to show the adapter initialization before
> the devices on the bus.
commonly "it also" in a commit message means a change, which should be done
separately, and this is the case here as well.
Because the adapter registration i2c_add_adapter() can fail, information
about the adapter initialization would be expected only in case of
successful registration.
The information sent to the kernel log buffer here is quite trivial,
probably dev_info() can be just removed, but in any case it should be
a separate change.
> Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v5 3/5] input: Add support for the tm2 touchkey device driver
From: Chanwoo Choi @ 2017-01-06 21:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106134350.32428-4-andi.shyti@samsung.com>
Hi,
2017-01-06 22:43 GMT+09:00 Andi Shyti <andi.shyti@samsung.com>:
> From: Jaechul Lee <jcsing.lee@samsung.com>
>
> This patch adds the binding description of the tm2 touchkey
> device driver.
>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
> Acked-by: Rob Herring <robh@kernel.org>
> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
> .../bindings/input/samsung,tm2-touchkey.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/samsung,tm2-touchkey.txt
>
> diff --git a/Documentation/devicetree/bindings/input/samsung,tm2-touchkey.txt b/Documentation/devicetree/bindings/input/samsung,tm2-touchkey.txt
> new file mode 100644
> index 000000000000..4de1af0f0a37
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/samsung,tm2-touchkey.txt
> @@ -0,0 +1,27 @@
> +Samsung tm2-touchkey
> +
> +Required properties:
> +- compatible: must be "samsung,tm2-touchkey"
> +- reg: I2C address of the chip.
> +- interrupt-parent: a phandle for the interrupt controller (see interrupt
> + binding[0]).
> +- interrupts: interrupt to which the chip is connected (see interrupt
> + binding[0]).
> +- vcc-supply : internal regulator output. 1.8V
> +- vdd-supply : power supply for IC 3.3V
> +
> +[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
> +
> +Example:
> + &i2c0 {
> + /* ... */
> +
> + touchkey at 20 {
> + compatible = "samsung,tm2-touchkey";
> + reg = <0x20>;
> + interrupt-parent = <&gpa3>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> + vcc-supply=<&ldo32_reg>;
> + vdd-supply=<&ldo33_reg>;
> + };
> + };
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* [PATCH v3 0/3] Rockchip: generalize GRF setup
From: Heiko Stuebner @ 2017-01-06 21:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116230304.8432-1-heiko@sntech.de>
Am Donnerstag, 17. November 2016, 00:03:01 CET schrieb Heiko Stuebner:
> The General register files contain a big bunch of settings for various
> components. Things like the automatic sdmmc/jtag switch may even affect
> us in a bad way, while that property (and possibly others) are not even
> part of the dw_mmc controller itself.
>
> And while the rk3288 could still carry adaptions to these defaults
> in its mach files, this is no longer possible on the arm64 socs, while
> things like the jtag-switch from above still can affect us there.
applied these 3 to my drivers branch for 4.11
^ permalink raw reply
* [RFC PATCH] vring: Force use of DMA API for ARM-based systems
From: Andy Lutomirski @ 2017-01-06 21:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cb98e455-bdee-19ab-8896-9123c6d12a26@arm.com>
On Fri, Jan 6, 2017 at 10:32 AM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 06/01/17 17:48, Jean-Philippe Brucker wrote:
>> Hi Will,
>>
>> On 20/12/16 15:14, Will Deacon wrote:
>>> Booting Linux on an ARM fastmodel containing an SMMU emulation results
>>> in an unexpected I/O page fault from the legacy virtio-blk PCI device:
>>>
>>> [ 1.211721] arm-smmu-v3 2b400000.smmu: event 0x10 received:
>>> [ 1.211800] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
>>> [ 1.211880] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
>>> [ 1.211959] arm-smmu-v3 2b400000.smmu: 0x00000008fa081002
>>> [ 1.212075] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
>>> [ 1.212155] arm-smmu-v3 2b400000.smmu: event 0x10 received:
>>> [ 1.212234] arm-smmu-v3 2b400000.smmu: 0x00000000fffff010
>>> [ 1.212314] arm-smmu-v3 2b400000.smmu: 0x0000020800000000
>>> [ 1.212394] arm-smmu-v3 2b400000.smmu: 0x00000008fa081000
>>> [ 1.212471] arm-smmu-v3 2b400000.smmu: 0x0000000000000000
>>>
>>> <system hangs failing to read partition table>
>>>
>>> This is because the virtio-blk is behind an SMMU, so we have consequently
>>> swizzled its DMA ops and configured the SMMU to translate accesses. This
>>> then requires the vring code to use the DMA API to establish translations,
>>> otherwise all transactions will result in fatal faults and termination.
>>>
>>> Given that ARM-based systems only see an SMMU if one is really present
>>> (the topology is all described by firmware tables such as device-tree or
>>> IORT), then we can safely use the DMA API for all virtio devices.
>>
>> There is a problem with the platform block device on that same model.
>> Since it's not behind the SMMU, the DMA ops fall back to swiotlb, which
>> limits the number of mappings.
>>
>> It used to work with 4.9, but since 9491ae4 ("mm: don't cap request size
>> based on read-ahead setting") unlocked read-ahead, we quickly run into
>> the limit of swiotlb and panic:
>>
>> [ 5.382359] virtio-mmio 1c130000.virtio_block: swiotlb buffer is full
>> (sz: 491520 bytes)
>> [ 5.382452] virtio-mmio 1c130000.virtio_block: DMA: Out of SW-IOMMU
>> space for 491520 bytes
>> [ 5.382531] Kernel panic - not syncing: DMA: Random memory could be
>> DMA written
>> ...
>> [ 5.383148] [<ffff0000083ad754>] swiotlb_map_page+0x194/0x1a0
>> [ 5.383226] [<ffff000008096bb8>] __swiotlb_map_page+0x20/0x88
>> [ 5.383320] [<ffff0000084bf738>] vring_map_one_sg.isra.1+0x70/0x88
>> [ 5.383417] [<ffff0000084c04fc>] virtqueue_add_sgs+0x2ec/0x4e8
>> [ 5.383505] [<ffff00000856d99c>] __virtblk_add_req+0x9c/0x1a8
>> ...
>> [ 5.384449] [<ffff0000081829c4>] ondemand_readahead+0xfc/0x2b8
>>
>> Commit 9491ae4 caps the read-ahead request to a limit set by the backing
>> device. For virtio-blk, it is infinite (as set by the call to
>> blk_queue_max_hw_sectors in virtblk_probe).
>>
>> I'm not sure how to fix this. Setting an arbitrary sector limit in the
>> virtio-blk driver seems unfair to other users. Maybe we should check if
>> the device is behind a hardware IOMMU before using the DMA API?
>
> Hmm, this looks more like the virtio_block device simply has the wrong
> DMA mask to begin with. For virtio-pci we set the streaming DMA mask to
> 64 bits - should a platform device not be similarly capable?
If it's not, then turning off DMA API will cause random corruption.
ISTM one way or another the bug is in either the DMA ops or in the
driver initialization.
--Andy
^ permalink raw reply
* [PATCH v2 0/9] Use mmio-sram driver for Keystone MSMC RAM
From: Suman Anna @ 2017-01-06 21:57 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
The Keystone 2 family of SoCs have an on-chip RAM called the
Multicore Shared Memory (MSM) RAM. This RAM is accessible through
the Multicore Shared Memory Controller (MSMC). This series represents
these on-chip RAMs as sram nodes so that the memory allocations
can be managed by the in-kernel mmio-sram driver.
This is v2 of the previous series [1], and now includes 4 additional
patches that reserve the portions of the MSMC RAM used by the
Keystone Boot Monitor. The first 5 patches are essentially the same
as in v1, with minor commit description updates for using the proper
SoC names, but no code changes.
Patches baselined on 4.10-rc1.
regards
Suman
[1] http://marc.info/?l=linux-arm-kernel&m=147277092730387&w=2
Suman Anna (9):
ARM: dts: keystone-k2hk: Add MSM RAM node
ARM: dts: keystone-k2l: Add MSM RAM node
ARM: dts: keystone-k2e: Add MSM RAM node
ARM: dts: keystone-k2g: Add MSM RAM node
ARM: configs: keystone: Enable Generic on-chip SRAM driver
ARM: dts: keystone-k2hk: Reserve MSM RAM for boot monitor
ARM: dts: keystone-k2l: Reserve MSM RAM for boot monitor
ARM: dts: keystone-k2e: Reserve MSM RAM for boot monitor
ARM: dts: keystone-k2g: Reserve MSM RAM for boot monitor
arch/arm/boot/dts/keystone-k2e.dtsi | 12 ++++++++++++
arch/arm/boot/dts/keystone-k2g.dtsi | 12 ++++++++++++
arch/arm/boot/dts/keystone-k2hk.dtsi | 12 ++++++++++++
arch/arm/boot/dts/keystone-k2l.dtsi | 12 ++++++++++++
arch/arm/configs/keystone_defconfig | 1 +
5 files changed, 49 insertions(+)
--
2.10.2
^ permalink raw reply
* [PATCH v2 1/9] ARM: dts: keystone-k2hk: Add MSM RAM node
From: Suman Anna @ 2017-01-06 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106215733.41637-1-s-anna@ti.com>
Add the RAM managed by the Multicore Shared Memory Controller (MSMC)
as a mmio-sram node. The 66AK2H SoCs have 6 MB of such memory. Any
specific MSM memory range needed by a software module ought to be
reserved using an appropriate child node.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: No code changes, SoC name in commit message corrected to use 66AK2H
arch/arm/boot/dts/keystone-k2hk.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2hk.dtsi b/arch/arm/boot/dts/keystone-k2hk.dtsi
index 8f67fa8df936..39e88d815235 100644
--- a/arch/arm/boot/dts/keystone-k2hk.dtsi
+++ b/arch/arm/boot/dts/keystone-k2hk.dtsi
@@ -46,6 +46,14 @@
soc {
/include/ "keystone-k2hk-clocks.dtsi"
+ msm_ram: msmram at 0c000000 {
+ compatible = "mmio-sram";
+ reg = <0x0c000000 0x600000>;
+ ranges = <0x0 0x0c000000 0x600000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
dspgpio0: keystone_dsp_gpio at 02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 2/9] ARM: dts: keystone-k2l: Add MSM RAM node
From: Suman Anna @ 2017-01-06 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106215733.41637-1-s-anna@ti.com>
Add the RAM managed by the Multicore Shared Memory Controller (MSMC)
as a mmio-sram node. The 66AK2L SoCs have 2 MB of such memory. Any
specific MSM memory range needed by a software module ought to be
reserved using an appropriate child node.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: No code changes, SoC name in commit message corrected to use 66AK2L
arch/arm/boot/dts/keystone-k2l.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2l.dtsi b/arch/arm/boot/dts/keystone-k2l.dtsi
index 0c5e74e79ba2..edc08de4e196 100644
--- a/arch/arm/boot/dts/keystone-k2l.dtsi
+++ b/arch/arm/boot/dts/keystone-k2l.dtsi
@@ -204,6 +204,14 @@
};
};
+ msm_ram: msmram at 0c000000 {
+ compatible = "mmio-sram";
+ reg = <0x0c000000 0x200000>;
+ ranges = <0x0 0x0c000000 0x200000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
dspgpio0: keystone_dsp_gpio at 02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 3/9] ARM: dts: keystone-k2e: Add MSM RAM node
From: Suman Anna @ 2017-01-06 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106215733.41637-1-s-anna@ti.com>
Add the RAM managed by the Multicire Shared Memory Controller (MSMC)
as a mmio-sram node. The 66AK2E SoCs have 2 MB of such memory. Any
specific MSM memory range needed by a software module ought to be
reserved using an appropriate child node.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: No code changes, SoC name in commit message corrected to use 66AK2E
arch/arm/boot/dts/keystone-k2e.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2e.dtsi b/arch/arm/boot/dts/keystone-k2e.dtsi
index 497c417db5b6..256dcc87f36a 100644
--- a/arch/arm/boot/dts/keystone-k2e.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e.dtsi
@@ -82,6 +82,14 @@
};
};
+ msm_ram: msmram at 0c000000 {
+ compatible = "mmio-sram";
+ reg = <0x0c000000 0x200000>;
+ ranges = <0x0 0x0c000000 0x200000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
dspgpio0: keystone_dsp_gpio at 02620240 {
compatible = "ti,keystone-dsp-gpio";
gpio-controller;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 4/9] ARM: dts: keystone-k2g: Add MSM RAM node
From: Suman Anna @ 2017-01-06 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106215733.41637-1-s-anna@ti.com>
Add the RAM managed by the Multicore Shared Memory Controller (MSMC)
as a mmio-sram node. The 66AK2G SoCs have 1 MB of such memory. Any
specific MSM memory range needed by a software module ought to be
reserved using an appropriate child node.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: No code changes, SoC name in commit message corrected to use 66AK2G
arch/arm/boot/dts/keystone-k2g.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
index 63c7cf0c6b6d..e63e57e03b7c 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -77,6 +77,14 @@
ranges = <0x0 0x0 0x0 0xc0000000>;
dma-ranges = <0x80000000 0x8 0x00000000 0x80000000>;
+ msm_ram: msmram at 0c000000 {
+ compatible = "mmio-sram";
+ reg = <0x0c000000 0x100000>;
+ ranges = <0x0 0x0c000000 0x100000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+
k2g_pinctrl: pinmux at 02621000 {
compatible = "pinctrl-single";
reg = <0x02621000 0x410>;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 5/9] ARM: configs: keystone: Enable Generic on-chip SRAM driver
From: Suman Anna @ 2017-01-06 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106215733.41637-1-s-anna@ti.com>
All the Keystone 2 SoCs have an on-chip RAM called the MultiCore
Shared Memory (MSM) RAM managed by the Multicore Shared Memory
Controller (MSMC) that provides faster access compared to normal
DDR.
This patch enables the Generic on-chip SRAM driver that manages
this memory in software.
Signed-off-by: Suman Anna <s-anna@ti.com>
---
v2: No changes
arch/arm/configs/keystone_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/keystone_defconfig b/arch/arm/configs/keystone_defconfig
index 78cd2f197e01..1331f6dc456a 100644
--- a/arch/arm/configs/keystone_defconfig
+++ b/arch/arm/configs/keystone_defconfig
@@ -126,6 +126,7 @@ CONFIG_MTD_NAND_DAVINCI=y
CONFIG_MTD_SPI_NOR=y
CONFIG_MTD_UBI=y
CONFIG_BLK_DEV_LOOP=y
+CONFIG_SRAM=y
CONFIG_EEPROM_AT24=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
--
2.10.2
^ permalink raw reply related
* [PATCH v2 6/9] ARM: dts: keystone-k2hk: Reserve MSM RAM for boot monitor
From: Suman Anna @ 2017-01-06 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106215733.41637-1-s-anna@ti.com>
The Keystone 2 boot monitor uses 32 KB of the MSM RAM @ 0x0c5f0000
on 66AK2H SoCs, so add a reserved child node for the same.
This address is aligned to the values used within the latest boot
monitor firmware [1] as of commit cf8b431e8b3b ("soc: Move load
address to end of MSMC").
[1] git://git.ti.com/processor-firmware/ks2-boot-monitor.git
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/keystone-k2hk.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2hk.dtsi b/arch/arm/boot/dts/keystone-k2hk.dtsi
index 39e88d815235..e0780f111537 100644
--- a/arch/arm/boot/dts/keystone-k2hk.dtsi
+++ b/arch/arm/boot/dts/keystone-k2hk.dtsi
@@ -52,6 +52,10 @@
ranges = <0x0 0x0c000000 0x600000>;
#address-cells = <1>;
#size-cells = <1>;
+
+ sram-bm at 5f0000 {
+ reg = <0x5f0000 0x8000>;
+ };
};
dspgpio0: keystone_dsp_gpio at 02620240 {
--
2.10.2
^ permalink raw reply related
* [PATCH v2 7/9] ARM: dts: keystone-k2l: Reserve MSM RAM for boot monitor
From: Suman Anna @ 2017-01-06 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106215733.41637-1-s-anna@ti.com>
The Keystone 2 boot monitor uses 32 KB of the MSM RAM @ 0x0c1f8000
on 66AK2L SoCs, so add a reserved child node for the same.
This address is aligned to the values used within the latest boot
monitor firmware [1] as of commit cf8b431e8b3b ("soc: Move load
address to end of MSMC").
[1] git://git.ti.com/processor-firmware/ks2-boot-monitor.git
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/keystone-k2l.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2l.dtsi b/arch/arm/boot/dts/keystone-k2l.dtsi
index edc08de4e196..b58015737a35 100644
--- a/arch/arm/boot/dts/keystone-k2l.dtsi
+++ b/arch/arm/boot/dts/keystone-k2l.dtsi
@@ -210,6 +210,10 @@
ranges = <0x0 0x0c000000 0x200000>;
#address-cells = <1>;
#size-cells = <1>;
+
+ sram-bm at 1f8000 {
+ reg = <0x001f8000 0x8000>;
+ };
};
dspgpio0: keystone_dsp_gpio at 02620240 {
--
2.10.2
^ permalink raw reply related
* [PATCH v2 8/9] ARM: dts: keystone-k2e: Reserve MSM RAM for boot monitor
From: Suman Anna @ 2017-01-06 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106215733.41637-1-s-anna@ti.com>
The Keystone 2 boot monitor uses 32 KB of the MSM RAM @ 0x0c1f0000
on 66AK2E SoCs, so add a reserved child node for the same.
This address is aligned to the values used within the latest boot
monitor firmware [1] as of commit cf8b431e8b3b ("soc: Move load
address to end of MSMC").
[1] git://git.ti.com/processor-firmware/ks2-boot-monitor.git
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/keystone-k2e.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2e.dtsi b/arch/arm/boot/dts/keystone-k2e.dtsi
index 256dcc87f36a..9d1d8a64d10e 100644
--- a/arch/arm/boot/dts/keystone-k2e.dtsi
+++ b/arch/arm/boot/dts/keystone-k2e.dtsi
@@ -88,6 +88,10 @@
ranges = <0x0 0x0c000000 0x200000>;
#address-cells = <1>;
#size-cells = <1>;
+
+ sram-bm at 1f0000 {
+ reg = <0x001f0000 0x8000>;
+ };
};
dspgpio0: keystone_dsp_gpio at 02620240 {
--
2.10.2
^ permalink raw reply related
* [PATCH v2 9/9] ARM: dts: keystone-k2g: Reserve MSM RAM for boot monitor
From: Suman Anna @ 2017-01-06 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106215733.41637-1-s-anna@ti.com>
The Keystone 2 boot monitor uses 32 KB of the MSM RAM @ 0x0c0f7000
on 66AK2G SoCs, so add a reserved child node for the same.
This address is aligned to the values used within the latest boot
monitor firmware [1] as of commit cf8b431e8b3b ("soc: Move load
address to end of MSMC").
[1] git://git.ti.com/processor-firmware/ks2-boot-monitor.git
Signed-off-by: Suman Anna <s-anna@ti.com>
---
arch/arm/boot/dts/keystone-k2g.dtsi | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/keystone-k2g.dtsi b/arch/arm/boot/dts/keystone-k2g.dtsi
index e63e57e03b7c..c36d168bc874 100644
--- a/arch/arm/boot/dts/keystone-k2g.dtsi
+++ b/arch/arm/boot/dts/keystone-k2g.dtsi
@@ -83,6 +83,10 @@
ranges = <0x0 0x0c000000 0x100000>;
#address-cells = <1>;
#size-cells = <1>;
+
+ sram-bm at f7000 {
+ reg = <0x000f7000 0x8000>;
+ };
};
k2g_pinctrl: pinmux at 02621000 {
--
2.10.2
^ permalink raw reply related
* [PATCH v5 4/5] input: tm2-touchkey: Add touchkey driver support for TM2
From: Chanwoo Choi @ 2017-01-06 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106134350.32428-5-andi.shyti@samsung.com>
Hi,
I have a question. In this patch, the compatible name includes the
specific h/w board name(TM2). Usually, when developing the device
driver, we prefer to use the original h/w name of each device.
- "samsung,tm2-touchkey"
If this touchkey device is used on other h/w board, you should add new
compatible name.
Why don't you use the original device name?
And I have a minor comment.
2017-01-06 22:43 GMT+09:00 Andi Shyti <andi.shyti@samsung.com>:
> From: Jaechul Lee <jcsing.lee@samsung.com>
>
> This patch adds support for the TM2 touch key and led
> functionality.
>
> The driver interfaces with userspace through an input device and
> reports KEY_PHONE and KEY_BACK event types. LED brightness can be
> controlled by "/sys/class/leds/tm2-touchkey/brightness".
>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Reviewed-by: Andi Shyti <andi.shyti@samsung.com>
> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> ---
> drivers/input/keyboard/Kconfig | 11 ++
> drivers/input/keyboard/Makefile | 1 +
> drivers/input/keyboard/tm2-touchkey.c | 280 ++++++++++++++++++++++++++++++++++
> 3 files changed, 292 insertions(+)
> create mode 100644 drivers/input/keyboard/tm2-touchkey.c
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index cbd75cf44739..e6e98585b4b0 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -666,6 +666,17 @@ config KEYBOARD_TC3589X
> To compile this driver as a module, choose M here: the
> module will be called tc3589x-keypad.
>
> +config KEYBOARD_TM2_TOUCHKEY
> + tristate "tm2-touchkey support"
> + depends on I2C
> + depends on LEDS_CLASS
> + help
> + Say Y here to enable device driver for tm2-touchkey with
> + LED control for the Exynos5433 TM2 board.
> +
> + To compile this driver as a module, choose M here.
> + module will be called tm2-touchkey.
> +
> config KEYBOARD_TWL4030
> tristate "TI TWL4030/TWL5030/TPS659x0 keypad support"
> depends on TWL4030_CORE
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index d9f4cfcf3410..7d9acff819a7 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_KEYBOARD_SUN4I_LRADC) += sun4i-lradc-keys.o
> obj-$(CONFIG_KEYBOARD_SUNKBD) += sunkbd.o
> obj-$(CONFIG_KEYBOARD_TC3589X) += tc3589x-keypad.o
> obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
> +obj-$(CONFIG_KEYBOARD_TM2_TOUCHKEY) += tm2-touchkey.o
> obj-$(CONFIG_KEYBOARD_TWL4030) += twl4030_keypad.o
> obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
> obj-$(CONFIG_KEYBOARD_W90P910) += w90p910_keypad.o
> diff --git a/drivers/input/keyboard/tm2-touchkey.c b/drivers/input/keyboard/tm2-touchkey.c
> new file mode 100644
> index 000000000000..92eacb62f8e7
> --- /dev/null
> +++ b/drivers/input/keyboard/tm2-touchkey.c
> @@ -0,0 +1,280 @@
> +/*
> + * TM2 touchkey device driver
> + *
> + * Copyright 2005 Phil Blundell
> + * Copyright 2016 Samsung Electronics Co., Ltd.
> + *
> + * Author: Beomho Seo <beomho.seo@samsung.com>
> + * Author: Jaechul Lee <jcsing.lee@samsung.com>
> + *
> + * 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 <linux/bitops.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/i2c.h>
> +#include <linux/input.h>
> +#include <linux/interrupt.h>
> +#include <linux/irq.h>
> +#include <linux/leds.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/pm.h>
> +#include <linux/regulator/consumer.h>
> +
> +#define TM2_TOUCHKEY_DEV_NAME "tm2-touchkey"
> +#define TM2_TOUCHKEY_KEYCODE_REG 0x03
> +#define TM2_TOUCHKEY_BASE_REG 0x00
> +#define TM2_TOUCHKEY_CMD_LED_ON 0x10
> +#define TM2_TOUCHKEY_CMD_LED_OFF 0x20
> +#define TM2_TOUCHKEY_BIT_PRESS_EV BIT(3)
> +#define TM2_TOUCHKEY_BIT_KEYCODE GENMASK(2, 0)
> +#define TM2_TOUCHKEY_LED_VOLTAGE_MIN 2500000
> +#define TM2_TOUCHKEY_LED_VOLTAGE_MAX 3300000
> +
> +enum {
> + TM2_TOUCHKEY_KEY_MENU = 0x1,
> + TM2_TOUCHKEY_KEY_BACK,
> +};
> +
> +struct tm2_touchkey_data {
> + struct i2c_client *client;
> + struct input_dev *input_dev;
> + struct led_classdev led_dev;
> + struct regulator_bulk_data regulators[2];
> +
> + u8 keycode_type;
> + u8 pressed;
> +};
> +
> +static void tm2_touchkey_led_brightness_set(struct led_classdev *led_dev,
> + enum led_brightness brightness)
> +{
> + struct tm2_touchkey_data *touchkey =
> + container_of(led_dev, struct tm2_touchkey_data, led_dev);
> + u32 volt;
> + u8 data;
> +
> + if (brightness == LED_OFF) {
> + volt = TM2_TOUCHKEY_LED_VOLTAGE_MIN;
> + data = TM2_TOUCHKEY_CMD_LED_OFF;
> + } else {
> + volt = TM2_TOUCHKEY_LED_VOLTAGE_MAX;
> + data = TM2_TOUCHKEY_CMD_LED_ON;
> + }
> +
> + regulator_set_voltage(touchkey->regulators[1].consumer, volt, volt);
I don't force the modification. It is minor comment.
In the case, when handling the regulator, you better to use the
definition because the integer index is difficult to understand what
does this mean.
> + i2c_smbus_write_byte_data(touchkey->client,
> + TM2_TOUCHKEY_BASE_REG, data);
> +}
> +
> +static int tm2_touchkey_power_enable(struct tm2_touchkey_data *touchkey)
> +{
> + int ret = 0;
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(touchkey->regulators),
> + touchkey->regulators);
> + if (ret)
> + return ret;
> +
> + /* waiting for device initialization, at least 150ms */
> + msleep(150);
> +
> + return 0;
> +}
> +
> +static void tm2_touchkey_power_disable(void *data)
> +{
> + struct tm2_touchkey_data *touchkey = data;
> +
> + regulator_bulk_disable(ARRAY_SIZE(touchkey->regulators),
> + touchkey->regulators);
> +}
> +
> +static irqreturn_t tm2_touchkey_irq_handler(int irq, void *devid)
> +{
> + struct tm2_touchkey_data *touchkey = devid;
> + u32 data;
> +
> + data = i2c_smbus_read_byte_data(touchkey->client,
> + TM2_TOUCHKEY_KEYCODE_REG);
> +
> + if (data < 0) {
> + dev_err(&touchkey->client->dev, "Failed to read i2c data\n");
> + return IRQ_HANDLED;
> + }
> +
> + touchkey->keycode_type = data & TM2_TOUCHKEY_BIT_KEYCODE;
> + touchkey->pressed = !(data & TM2_TOUCHKEY_BIT_PRESS_EV);
> +
> + if (touchkey->keycode_type != TM2_TOUCHKEY_KEY_MENU &&
> + touchkey->keycode_type != TM2_TOUCHKEY_KEY_BACK) {
> + dev_warn(&touchkey->client->dev, "Skip unhandled keycode(%d)\n",
> + touchkey->keycode_type);
> + return IRQ_HANDLED;
> + }
> +
> + if (!touchkey->pressed) {
> + input_report_key(touchkey->input_dev, KEY_PHONE, 0);
> + input_report_key(touchkey->input_dev, KEY_BACK, 0);
> + } else {
> + if (touchkey->keycode_type == TM2_TOUCHKEY_KEY_MENU)
> + input_report_key(touchkey->input_dev,
> + KEY_PHONE, 1);
> + else
> + input_report_key(touchkey->input_dev,
> + KEY_BACK, 1);
> + }
> + input_sync(touchkey->input_dev);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static int tm2_touchkey_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct tm2_touchkey_data *touchkey;
> + int ret;
> +
> + ret = i2c_check_functionality(client->adapter,
> + I2C_FUNC_SMBUS_BYTE |
> + I2C_FUNC_SMBUS_BYTE_DATA);
> + if (!ret) {
> + dev_err(&client->dev, "No I2C functionality found\n");
> + return -ENODEV;
> + }
> +
> + touchkey = devm_kzalloc(&client->dev, sizeof(*touchkey), GFP_KERNEL);
> + if (!touchkey)
> + return -ENOMEM;
> +
> + touchkey->client = client;
> + i2c_set_clientdata(client, touchkey);
> +
> + /* regulators */
> + touchkey->regulators[0].supply = "vcc";
> + touchkey->regulators[1].supply = "vdd";
> + ret = devm_regulator_bulk_get(&client->dev,
> + ARRAY_SIZE(touchkey->regulators),
> + touchkey->regulators);
> + if (ret) {
> + dev_err(&client->dev, "Failed to get regulators\n");
> + return ret;
> + }
> +
> + /* power */
> + ret = tm2_touchkey_power_enable(touchkey);
> + if (ret) {
> + dev_err(&client->dev, "Failed to enable power\n");
> + return ret;
> + }
> +
> + ret = devm_add_action_or_reset(&client->dev,
> + tm2_touchkey_power_disable, touchkey);
> + if (ret)
> + return ret;
> +
> + /* input device */
> + touchkey->input_dev = devm_input_allocate_device(&client->dev);
> + if (!touchkey->input_dev) {
> + dev_err(&client->dev, "Failed to alloc input device\n");
> + return -ENOMEM;
> + }
> + touchkey->input_dev->name = TM2_TOUCHKEY_DEV_NAME;
> + touchkey->input_dev->id.bustype = BUS_I2C;
> +
> + set_bit(EV_KEY, touchkey->input_dev->evbit);
> + input_set_capability(touchkey->input_dev, EV_KEY, KEY_PHONE);
> + input_set_capability(touchkey->input_dev, EV_KEY, KEY_BACK);
> +
> + input_set_drvdata(touchkey->input_dev, touchkey);
> +
> + ret = input_register_device(touchkey->input_dev);
> + if (ret) {
> + dev_err(&client->dev, "Failed to register input device\n");
> + return ret;
> + }
> +
> + /* irq */
> + ret = devm_request_threaded_irq(&client->dev,
> + client->irq, NULL,
> + tm2_touchkey_irq_handler,
> + IRQF_ONESHOT, TM2_TOUCHKEY_DEV_NAME,
> + touchkey);
> + if (ret) {
> + dev_err(&client->dev, "Failed to request threaded irq\n");
> + return ret;
> + }
> +
> + /* led device */
> + touchkey->led_dev.name = TM2_TOUCHKEY_DEV_NAME;
> + touchkey->led_dev.brightness = LED_FULL;
> + touchkey->led_dev.max_brightness = LED_FULL;
> + touchkey->led_dev.brightness_set = tm2_touchkey_led_brightness_set;
> +
> + ret = devm_led_classdev_register(&client->dev, &touchkey->led_dev);
> + if (ret < 0) {
> + dev_err(&client->dev, "Failed to register touchkey led\n");
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int __maybe_unused tm2_touchkey_suspend(struct device *dev)
> +{
> + struct tm2_touchkey_data *touchkey = dev_get_drvdata(dev);
> +
> + disable_irq(touchkey->client->irq);
> + tm2_touchkey_power_disable(touchkey);
> +
> + return 0;
> +}
> +
> +static int __maybe_unused tm2_touchkey_resume(struct device *dev)
> +{
> + struct tm2_touchkey_data *touchkey = dev_get_drvdata(dev);
> + int ret;
> +
> + enable_irq(touchkey->client->irq);
> + ret = tm2_touchkey_power_enable(touchkey);
> + if (ret)
> + dev_err(dev, "Failed to enable power\n");
> +
> + return ret;
> +}
> +
> +static SIMPLE_DEV_PM_OPS(tm2_touchkey_pm_ops, tm2_touchkey_suspend,
> + tm2_touchkey_resume);
> +
> +static const struct i2c_device_id tm2_touchkey_id_table[] = {
> + {TM2_TOUCHKEY_DEV_NAME, 0},
> + {},
> +};
> +MODULE_DEVICE_TABLE(i2c, tm2_touchkey_id_table);
> +
> +static const struct of_device_id tm2_touchkey_of_match[] = {
> + {.compatible = "samsung,tm2-touchkey",},
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, tm2_touchkey_of_match);
> +
> +static struct i2c_driver tm2_touchkey_driver = {
> + .driver = {
> + .name = TM2_TOUCHKEY_DEV_NAME,
> + .pm = &tm2_touchkey_pm_ops,
> + .of_match_table = of_match_ptr(tm2_touchkey_of_match),
> + },
> + .probe = tm2_touchkey_probe,
> + .id_table = tm2_touchkey_id_table,
> +};
> +
> +module_i2c_driver(tm2_touchkey_driver);
> +
> +MODULE_AUTHOR("Beomho Seo <beomho.seo@samsung.com>");
> +MODULE_AUTHOR("Jaechul Lee <jcsing.lee@samsung.com>");
> +MODULE_DESCRIPTION("Samsung touchkey driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node
From: Chanwoo Choi @ 2017-01-06 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGTfZH2QYQK190kYFbOMqJMFgH32548ra-VqzYwc5LVBJwqisA@mail.gmail.com>
Hi,
2017-01-07 6:31 GMT+09:00 Chanwoo Choi <cwchoi00@gmail.com>:
> Hi,
>
> 2017-01-06 22:43 GMT+09:00 Andi Shyti <andi.shyti@samsung.com>:
>> From: Jaechul Lee <jcsing.lee@samsung.com>
>>
>> Add DT node support for TM2 touchkey device.
>>
>> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
>> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
>> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
>> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>> ---
>> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> index 2449266b268f..92fcc4ec8319 100644
>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>> @@ -18,6 +18,19 @@
>> compatible = "samsung,tm2", "samsung,exynos5433";
>> };
>>
>> +&hsi2c_9 {
>> + status = "okay";
>> +
>> + touchkey at 20 {
>> + compatible = "samsung,tm2-touchkey";
>> + reg = <0x20>;
>> + interrupt-parent = <&gpa3>;
>> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
>> + vcc-supply = <&ldo32_reg>;
>> + vdd-supply = <&ldo33_reg>;
>> + };
>> +};
>> +
>> &ldo31_reg {
>> regulator-name = "TSP_VDD_1.85V_AP";
>> regulator-min-microvolt = <1850000>;
>
> Looks good to me.
> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
>
> --
> Best Regards,
> Chanwoo Choi
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* [PATCH v5 5/5] arm64: dts: exynos: Add tm2 touchkey node
From: Chanwoo Choi @ 2017-01-06 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGTfZH347ZRve20cdGLwtuf6arRAJ4Ry+HQrTubDj-RGR=K9cA@mail.gmail.com>
Hi,
2017-01-07 7:09 GMT+09:00 Chanwoo Choi <cwchoi00@gmail.com>:
> Hi,
>
> 2017-01-07 6:31 GMT+09:00 Chanwoo Choi <cwchoi00@gmail.com>:
>> Hi,
>>
>> 2017-01-06 22:43 GMT+09:00 Andi Shyti <andi.shyti@samsung.com>:
>>> From: Jaechul Lee <jcsing.lee@samsung.com>
>>>
>>> Add DT node support for TM2 touchkey device.
>>>
>>> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
>>> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
>>> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
>>> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
>>> ---
>>> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
>>> 1 file changed, 13 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> index 2449266b268f..92fcc4ec8319 100644
>>> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
>>> @@ -18,6 +18,19 @@
>>> compatible = "samsung,tm2", "samsung,exynos5433";
>>> };
>>>
>>> +&hsi2c_9 {
>>> + status = "okay";
>>> +
>>> + touchkey at 20 {
>>> + compatible = "samsung,tm2-touchkey";
>>> + reg = <0x20>;
>>> + interrupt-parent = <&gpa3>;
>>> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
>>> + vcc-supply = <&ldo32_reg>;
>>> + vdd-supply = <&ldo33_reg>;
>>> + };
>>> +};
>>> +
>>> &ldo31_reg {
>>> regulator-name = "TSP_VDD_1.85V_AP";
>>> regulator-min-microvolt = <1850000>;
>>
>> Looks good to me.
>> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
I'm sorry to send the empty mail without any content.
I repiled the touchkey driver against compatible name.
Usually, when developing the device driver, we use the specific h/w name
but in this patch, the touckey dt node uses the h/w board name instead of
original touckhey name.
If this touckey device is used on other h/w board, I think the current
compatible name
is not proper.
So. please drop the my reviewed-by tag until completing the discussion.
I'm sorry to make the confusion.
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* imx: RS-485 problems during TX, maybe DMA related
From: Clemens Gruber @ 2017-01-06 22:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5C3enuThR1DpcwNnqFdxd8tGoBwd76O62Gnviz8x1_a9w@mail.gmail.com>
Hi Fabio,
On Fri, Jan 06, 2017 at 07:22:32PM -0200, Fabio Estevam wrote:
> Hi Clemens,
>
> On Wed, Jan 4, 2017 at 2:00 PM, Clemens Gruber
> <clemens.gruber@pqgruber.com> wrote:
> > Hi,
> >
> > I observed odd behavior of the current tty/serial/imx.c driver in RS-485
> > mode.
> >
> > RX works fine, but TX does not: When sending data, it arrives multiple
>
> I am also trying to get rs485 in half-duplex mode to work on mx6dl
> with kernel 4.9.
I am glad I am not the only one working on this. Maybe we can figure it
out together :)
>
> RX also works for me, but TX does not.
>
> On my board it is the MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B pin that
> controls the rs485 transceiver flow, but I do not
> see RTS to toggle to 1 during transmit. It stays always at 0.
>
> I see you use CTS pin instead, but I thought RTS pin should be used.
I am pretty sure that CTS is the correct signal to control the
transceiver. In the reference manual on page 5231 (section 64.7.1) it
says: "The CTS_B pin can be used to control RS-485 output driver outside
the chip."
Maybe it is only called RTS in struct serial_rs485 because of DTE mode
where RX, TX, RTS and CTS are interchanged? Very confusing.
I am muxing MX6QDL_PAD_CSI0_DAT16__UART4_RTS_B and
MX6QDL_PAD_CSI0_DAT17__UART4_CTS_B because the transceiver-enable signal
is connected to ball L3 (CSI0_DAT17).
But according to the i.MX Pins tool, they can be muxed vice-versa too.
So if you connected the transceiver-enable to ball L4 (CSI0_DAT16), you
could mux MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B and
MX6QDL_PAD_CSI0_DAT17__UART4_RTS_B instead?
As far as I understand, RTS is an input which is not used for RS-485, so
it is a no-connect on our board.
>
> On my userspace application I have:
>
> /* enable RS485 mode: */
> rs485conf.flags |= SER_RS485_ENABLED;
>
> /* set logical level for RTS pin equal to 1 when sending: */
> rs485conf.flags |= SER_RS485_RTS_ON_SEND;
>
> /* set logical level for RTS pin equal to 0 after sending: */
> rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);
This is similar to my config, however I had to also enable
SER_RS485_RX_DURING_TX, otherwise TX would not work at all.
Also, due to the active-low signal output on UART4_CTS_B, I use
~SER_RS485_RTS_ON_SEND and SER_RS485_RTS_AFTER_SEND.
--
Do you have an idea what could cause this doubling of the transmitted
characters and extra data I described?
Maybe you will see that effect too after you changed the pinmuxing.
At the moment I am trying to understand the interaction between the SDMA
engine and the imx UART driver. But this is the first time I dig into
DMA parts of the kernel and i.MX6/SDMA.. very challenging imho.
What's odd is that in RS-232 mode, everything works fine. This
buffer/DMA? problem only appears in RS-485 mode.
Regards,
Clemens
^ permalink raw reply
* APM smmu implementation
From: Feng Kan @ 2017-01-06 23:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Will/Robin:
The APM IOMMU implementation is mostly just the ARM SMMU 500 variant.
However, our internal bus is only 42 bits wide. Our IAS field is coded
as 48 bits, which cause IPA to truncated to 42 bits on the physical
bus. In order for our system to work with the arm-smmu.c, there needs
to be a way to force the ipa_size to 42. The current internal solution
is to use the cpuid, but that is quite ugly. I was thinking of using
the model
as indication to right the ipa_size, but I am not too sure of the ACPI
side. Would it be okay to add an APM MMU500 variant? I would also
appreciated it if you guys have any alternate solutions.
Thanks
Feng Kan
^ permalink raw reply
* [PATCH v2 05/19] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
From: Steve Longerbeam @ 2017-01-07 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CibSU45Cw1d8ZipiGSVfhCQ4uP4XiNuWTGLa5eHmC6Qg@mail.gmail.com>
On 01/04/2017 07:26 AM, Fabio Estevam wrote:
> On Tue, Jan 3, 2017 at 6:57 PM, Steve Longerbeam <slongerbeam@gmail.com> wrote:
>
>> + camera: ov5642 at 3c {
>> + compatible = "ovti,ov5642";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_ov5642>;
>> + clocks = <&clks IMX6QDL_CLK_CKO>;
>> + clock-names = "xclk";
>> + reg = <0x3c>;
>> + xclk = <24000000>;
>> + DOVDD-supply = <&vgen4_reg>; /* 1.8v */
>> + AVDD-supply = <&vgen5_reg>; /* 2.8v, rev C board is VGEN3
>> + rev B board is VGEN5 */
> Please use vgen3 so that by default we have the valid AVDD-supply for
> revC boards which is more recent and more the users have access to.
done.
>
>> + mipi_camera: ov5640 at 3c {
>> + compatible = "ovti,ov5640_mipi";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_ov5640>;
>> + reg = <0x3c>;
>> + clocks = <&clks IMX6QDL_CLK_CKO>;
>> + clock-names = "xclk";
>> + xclk = <24000000>;
>> + DOVDD-supply = <&vgen4_reg>; /* 1.8v */
>> + AVDD-supply = <&vgen5_reg>; /* 2.8v, rev C board is VGEN3
>> + rev B board is VGEN5 */
> Same here.
done.
>
>> + pinctrl_ov5640: ov5640grp {
>> + fsl,pins = <
>> + MX6QDL_PAD_SD1_DAT2__GPIO1_IO19 0x80000000
>> + MX6QDL_PAD_SD1_CLK__GPIO1_IO20 0x80000000
> Please avoid all the 0x80000000 IOMUX settings and replace them by
> their real values.
yeah, finally got around to this, done!
Steve
^ permalink raw reply
* imx: RS-485 problems during TX, maybe DMA related
From: Fabio Estevam @ 2017-01-07 0:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170106225026.GA3804@archie.localdomain>
Hi Clemens,
On Fri, Jan 6, 2017 at 8:50 PM, Clemens Gruber
<clemens.gruber@pqgruber.com> wrote:
> But according to the i.MX Pins tool, they can be muxed vice-versa too.
> So if you connected the transceiver-enable to ball L4 (CSI0_DAT16), you
> could mux MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B and
> MX6QDL_PAD_CSI0_DAT17__UART4_RTS_B instead?
Yes, I have tried like this:
&uart4 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart4>;
uart-has-rtscts;
status = "okay";
};
pinctrl_uart4: uart4grp {
fsl,pins = <
MX6QDL_PAD_CSI0_DAT12__UART4_TX_DATA 0x1b0b1
MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
MX6QDL_PAD_CSI0_DAT16__UART4_CTS_B 0x1b0b1
>;
};
In this case the DE pin of the rs485 transceiver is always at 0 then
RX works and TX does not.
Then I tried to use a gpio for controling the rts line:
&uart4 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart4>;
rts-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;
status = "okay";
};
pinctrl_uart4: uart4grp {
fsl,pins = <
MX6QDL_PAD_CSI0_DAT12__UART4_TX_DATA 0x1b0b1
MX6QDL_PAD_KEY_ROW0__UART4_RX_DATA 0x1b0b1
MX6QDL_PAD_CSI0_DAT16__GPIO6_IO02 0x1b0b1
>;
}
In this case the DE pin of the rs485 transceiver is always at 1, then
TX works and RX does not.
So I was never able to observe the DE pin toggling correctly.
Maybe you could share your userspace application with me offline?
Thanks
^ permalink raw reply
* [PATCH] clk: scpi: don't add cpufreq device if the scpi dvfs node is disabled
From: Michał Zegan @ 2017-01-07 0:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483706070-12357-1-git-send-email-sudeep.holla@arm.com>
seems the patch works as intended.
W dniu 06.01.2017 o 13:34, Sudeep Holla pisze:
> 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;
> }
>
>
-------------- 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/20170107/0969a2b2/attachment.sig>
^ permalink raw reply
* [PATCH 2/5] ARM: dts: qcom: apq8064: Add riva-pil node
From: John Stultz @ 2017-01-07 1:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221114939.19973-2-bjorn.andersson@linaro.org>
On Wed, Dec 21, 2016 at 3:49 AM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> Add nodes for the Riva PIL, IRIS RF module, BT and WiFI services exposed
> by the Riva firmware and the related memory reserve.
>
> Also provides pinctrl nodes for devices enabling the riva-pil.
>
> Cc: John Stultz <john.stultz@linaro.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: John Stultz <john.stultz@linaro.org>
thanks
-john
^ permalink raw reply
* [PATCH 1/5] ARM: dts: qcom: apq8064: Add missing scm clock
From: John Stultz @ 2017-01-07 1:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161221114939.19973-1-bjorn.andersson@linaro.org>
On Wed, Dec 21, 2016 at 3:49 AM, Bjorn Andersson
<bjorn.andersson@linaro.org> wrote:
> As per the device tree binding the apq8064 scm node requires the core
> clock to be specified, so add this.
>
> Cc: John Stultz <john.stultz@linaro.org>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
> ---
> arch/arm/boot/dts/qcom-apq8064.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi b/arch/arm/boot/dts/qcom-apq8064.dtsi
> index 268bd470c865..78bf155a52f3 100644
> --- a/arch/arm/boot/dts/qcom-apq8064.dtsi
> +++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
> @@ -303,6 +303,9 @@
> firmware {
> scm {
> compatible = "qcom,scm-apq8064";
> +
> + clocks = <&gcc CE3_CORE_CLK>;
> + clock-names = "core";
Tested-by: John Stultz <john.stultz@linaro.org>
I know Bjorn has a new version of this patch that uses the
RPM_DAYTONA_FABRIC_CLK value, but that one results in problems with
usb gadget functionality on my Nexus7. This one seems to work ok
though.
thanks
-john
^ permalink raw reply
* Re: [PATCH V7 1/4] Documentation/devicetree/bindings: b850v3_lvds_dp
From: Peter Senna Tschudin @ 2017-01-07 1:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_JsqJk=QZ20VmV5uE1ta2T0TEO3rvWFbiGsJpH1e3-ojnBfA@mail.gmail.com>
On 04 January, 2017 21:39 CET, Rob Herring <robh@kernel.org> wrote:
> On Tue, Jan 3, 2017 at 5:34 PM, Peter Senna Tschudin
> <peter.senna@collabora.co.uk> wrote:
> > Hi Rob,
> >
> > Thank you for the review.
> >
> > On 03 January, 2017 23:51 CET, Rob Herring <robh@kernel.org> wrote:
> >
> >> On Sun, Jan 01, 2017 at 09:24:29PM +0100, Peter Senna Tschudin wrote:
> >> > Devicetree bindings documentation for the GE B850v3 LVDS/DP++
> >> > display bridge.
> >> >
> >> > Cc: Martyn Welch <martyn.welch@collabora.co.uk>
> >> > Cc: Martin Donnelly <martin.donnelly@ge.com>
> >> > Cc: Javier Martinez Canillas <javier@dowhile0.org>
> >> > Cc: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >> > Cc: Philipp Zabel <p.zabel@pengutronix.de>
> >> > Cc: Rob Herring <robh@kernel.org>
> >> > Cc: Fabio Estevam <fabio.estevam@nxp.com>
> >> > Signed-off-by: Peter Senna Tschudin <peter.senna@collabora.com>
> >> > ---
> >> > There was an Acked-by from Rob Herring <robh@kernel.org> for V6, but I changed
> >> > the bindings to use i2c_new_secondary_device() so I removed it from the commit
> >> > message.
> >> >
> >> > .../devicetree/bindings/ge/b850v3-lvds-dp.txt | 39 ++++++++++++++++++++++
> >>
> >> Generally, bindings are not organized by vendor. Put in
> >> bindings/display/bridge/... instead.
> >
> > Will change that.
> >
> >>
> >> > 1 file changed, 39 insertions(+)
> >> > create mode 100644 Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> >> >
> >> > diff --git a/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> >> > new file mode 100644
> >> > index 0000000..1bc6ebf
> >> > --- /dev/null
> >> > +++ b/Documentation/devicetree/bindings/ge/b850v3-lvds-dp.txt
> >> > @@ -0,0 +1,39 @@
> >> > +Driver for GE B850v3 LVDS/DP++ display bridge
> >> > +
> >> > +Required properties:
> >> > + - compatible : should be "ge,b850v3-lvds-dp".
> >>
> >> Isn't '-lvds-dp' redundant? The part# should be enough.
> >
> > b850v3 is the name of the product, this is why the proposed name. What about, b850v3-dp2 dp2 indicating the second DP output?
>
> Humm, b850v3 is the board name? This node should be the name of the bridge chip.
>From the cover letter:
-- // --
There are two physical bridges on the video signal pipeline: a STDP4028(LVDS to
DP) and a STDP2690(DP to DP++). The hardware and firmware made it complicated
for this binding to comprise two device tree nodes, as the design goal is to
configure both bridges based on the LVDS signal, which leave the driver
powerless to control the video processing pipeline. The two bridges behaves as
a single bridge, and the driver is only needed for telling the host about EDID /
HPD, and for giving the host powers to ack interrupts. The video signal
pipeline is as follows:
Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
-- // --
^ 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