* [PATCH/RFT v2 07/17] ARM: davinci: da8xx: Enable the usb20 "per" clk on phy_clk_enable
From: David Lechner @ 2016-10-25 2:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024164634.4330-8-ahaslam@baylibre.com>
On 10/24/2016 11:46 AM, ahaslam at baylibre.com wrote:
> From: Axel Haslam <ahaslam@baylibre.com>
>
> While probing ochi phy with usb20 phy as a parent clock for usb11_phy,
> the usb20_phy clock enable would time out. This is because the usb20
> module clock needs to enabled while trying to lock the usb20_phy PLL.
>
> Call clk enable and get for the usb20 peripheral before trying to
> enable the phy PLL.
>
> Signed-off-by: Axel Haslam <ahaslam@baylibre.com>
> ---
This patch can be combined with "ARM: davinci: da8xx: add usb phy
clocks" since that patch has not been merged yet.
If you like, I can resubmit my patches from this series along with the
changes from this patch.
^ permalink raw reply
* [PATCH 5/5] ARM: dts: Add LEGO MINDSTORTMS EV3 dts
From: David Lechner @ 2016-10-25 2:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1593441f-d147-4c91-8aab-8622dd8ced19@lechnology.com>
On 10/24/2016 10:50 AM, David Lechner wrote:
> On 10/24/2016 06:58 AM, Sekhar Nori wrote:
>> On Saturday 22 October 2016 12:06 AM, David Lechner wrote:
>>> +};
>>> +
>>> +&spi1 {
>>> + status = "okay";
>>> + pinctrl-names = "default";
>>> + pinctrl-0 = <&spi1_pins>, <&spi1_cs0_pin>;
>>> +
>>> + /* TODO: LCD Display goes here */
>>
>> Add this node when you actually have display working.
>
> What if we set this up as a spidev node instead? This way the display
> could be used from userspace without a driver.
>
To answer my own question, it seems that specifying "spidev" in
devicetree is frowned upon since it does not "describe the hardware".
^ permalink raw reply
* [PATCH 0/2] to support memblock near alloc and memoryless on arm64
From: Zhen Lei @ 2016-10-25 2:59 UTC (permalink / raw)
To: linux-arm-kernel
If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
actually exist. The percpu variable areas and numa control blocks of that
memoryless numa nodes need to be allocated from the nearest available
node to improve performance.
In the beginning, I added a new function:
phys_addr_t __init memblock_alloc_near_nid(phys_addr_t size, phys_addr_t align, int nid);
But it can not replace memblock_virt_alloc_try_nid, because the latter can specify a min_addr,
it usually be assigned as __pa(MAX_DMA_ADDRESS), to prevent memory be allocated from DMA area.
It's bad to add another function, because the code will be duplicated in these two functions.
So I make memblock_alloc_near_nid to be called in the subfunctions of memblock_alloc_try_nid
and memblock_virt_alloc_try_nid. Add a macro node_distance_ready to distinguish different
situations:
1) By default, the value of node_distance_ready is zero, memblock_*_try_nid work as normal as before.
2) ARCH platforms set the value of node_distance_ready to be true when numa node distances are ready, (please refer patch 2)
memblock_*_try_nid allocate memory from the nearest node relative to the specified node.
Zhen Lei (2):
mm/memblock: prepare a capability to support memblock near alloc
arm64/numa: support HAVE_MEMORYLESS_NODES
arch/arm64/Kconfig | 4 +++
arch/arm64/include/asm/numa.h | 3 ++
arch/arm64/mm/numa.c | 6 +++-
mm/memblock.c | 76 ++++++++++++++++++++++++++++++++++++-------
4 files changed, 77 insertions(+), 12 deletions(-)
--
2.5.0
^ permalink raw reply
* [PATCH 1/2] mm/memblock: prepare a capability to support memblock near alloc
From: Zhen Lei @ 2016-10-25 2:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477364358-10620-1-git-send-email-thunder.leizhen@huawei.com>
If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
actually exist. The percpu variable areas and numa control blocks of that
memoryless numa nodes need to be allocated from the nearest available
node to improve performance.
Although memblock_alloc_try_nid and memblock_virt_alloc_try_nid try the
specified nid at the first time, but if that allocation failed it will
directly drop to use NUMA_NO_NODE. This mean any nodes maybe possible at
the second time.
To compatible the above old scene, I use a marco node_distance_ready to
control it. By default, the marco node_distance_ready is not defined in
any platforms, the above mentioned functions will work as normal as
before. Otherwise, they will try the nearest node first.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
mm/memblock.c | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++---------
1 file changed, 65 insertions(+), 11 deletions(-)
diff --git a/mm/memblock.c b/mm/memblock.c
index 7608bc3..556bbd2 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1213,9 +1213,71 @@ phys_addr_t __init memblock_alloc(phys_addr_t size, phys_addr_t align)
return memblock_alloc_base(size, align, MEMBLOCK_ALLOC_ACCESSIBLE);
}
+#ifndef node_distance_ready
+#define node_distance_ready() 0
+#endif
+
+static phys_addr_t __init memblock_alloc_near_nid(phys_addr_t size,
+ phys_addr_t align, phys_addr_t start,
+ phys_addr_t end, int nid, ulong flags,
+ int alloc_func_type)
+{
+ int nnid, round = 0;
+ u64 pa;
+ DECLARE_BITMAP(nodes_map, MAX_NUMNODES);
+
+ bitmap_zero(nodes_map, MAX_NUMNODES);
+
+again:
+ /*
+ * There are total 4 cases:
+ * <nid == NUMA_NO_NODE>
+ * 1)2) node_distance_ready || !node_distance_ready
+ * Round 1, nnid = nid = NUMA_NO_NODE;
+ * <nid != NUMA_NO_NODE>
+ * 3) !node_distance_ready
+ * Round 1, nnid = nid;
+ * ::Round 2, currently only applicable for alloc_func_type = <0>
+ * Round 2, nnid = NUMA_NO_NODE;
+ * 4) node_distance_ready
+ * Round 1, LOCAL_DISTANCE, nnid = nid;
+ * Round ?, nnid = nearest nid;
+ */
+ if (!node_distance_ready() || (nid == NUMA_NO_NODE)) {
+ nnid = (++round == 1) ? nid : NUMA_NO_NODE;
+ } else {
+ int i, distance = INT_MAX;
+
+ for_each_clear_bit(i, nodes_map, MAX_NUMNODES)
+ if (node_distance(nid, i) < distance) {
+ nnid = i;
+ distance = node_distance(nid, i);
+ }
+ }
+
+ switch (alloc_func_type) {
+ case 0:
+ pa = memblock_find_in_range_node(size, align, start, end, nnid, flags);
+ break;
+
+ case 1:
+ default:
+ pa = memblock_alloc_nid(size, align, nnid);
+ if (!node_distance_ready())
+ return pa;
+ }
+
+ if (!pa && (nnid != NUMA_NO_NODE)) {
+ bitmap_set(nodes_map, nnid, 1);
+ goto again;
+ }
+
+ return pa;
+}
+
phys_addr_t __init memblock_alloc_try_nid(phys_addr_t size, phys_addr_t align, int nid)
{
- phys_addr_t res = memblock_alloc_nid(size, align, nid);
+ phys_addr_t res = memblock_alloc_near_nid(size, align, 0, 0, nid, 0, 1);
if (res)
return res;
@@ -1276,19 +1338,11 @@ static void * __init memblock_virt_alloc_internal(
max_addr = memblock.current_limit;
again:
- alloc = memblock_find_in_range_node(size, align, min_addr, max_addr,
- nid, flags);
+ alloc = memblock_alloc_near_nid(size, align, min_addr, max_addr,
+ nid, flags, 0);
if (alloc)
goto done;
- if (nid != NUMA_NO_NODE) {
- alloc = memblock_find_in_range_node(size, align, min_addr,
- max_addr, NUMA_NO_NODE,
- flags);
- if (alloc)
- goto done;
- }
-
if (min_addr) {
min_addr = 0;
goto again;
--
2.5.0
^ permalink raw reply related
* [PATCH 2/2] arm64/numa: support HAVE_MEMORYLESS_NODES
From: Zhen Lei @ 2016-10-25 2:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477364358-10620-1-git-send-email-thunder.leizhen@huawei.com>
Some numa nodes may have no memory. For example:
1) a node has no memory bank plugged.
2) a node has no memory bank slots.
To ensure percpu variable areas and numa control blocks of the
memoryless numa nodes to be allocated from the nearest available node to
improve performance, defined node_distance_ready. And make its value to be
true immediately after node distances have been initialized.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
---
arch/arm64/Kconfig | 4 ++++
arch/arm64/include/asm/numa.h | 3 +++
arch/arm64/mm/numa.c | 6 +++++-
3 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 30398db..648dd13 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -609,6 +609,10 @@ config NEED_PER_CPU_EMBED_FIRST_CHUNK
def_bool y
depends on NUMA
+config HAVE_MEMORYLESS_NODES
+ def_bool y
+ depends on NUMA
+
source kernel/Kconfig.preempt
source kernel/Kconfig.hz
diff --git a/arch/arm64/include/asm/numa.h b/arch/arm64/include/asm/numa.h
index 600887e..9d068bf 100644
--- a/arch/arm64/include/asm/numa.h
+++ b/arch/arm64/include/asm/numa.h
@@ -13,6 +13,9 @@
int __node_distance(int from, int to);
#define node_distance(a, b) __node_distance(a, b)
+extern int __initdata arch_node_distance_ready;
+#define node_distance_ready() arch_node_distance_ready
+
extern nodemask_t numa_nodes_parsed __initdata;
/* Mappings between node number and cpus on that node. */
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 9a71d06..5db9765 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -36,6 +36,7 @@ static int cpu_to_node_map[NR_CPUS] = { [0 ... NR_CPUS-1] = NUMA_NO_NODE };
static int numa_distance_cnt;
static u8 *numa_distance;
static bool numa_off;
+int __initdata arch_node_distance_ready;
static __init int numa_parse_early_param(char *opt)
{
@@ -395,9 +396,12 @@ static int __init numa_init(int (*init_func)(void))
return -EINVAL;
}
+ arch_node_distance_ready = 1;
ret = numa_register_nodes();
- if (ret < 0)
+ if (ret < 0) {
+ arch_node_distance_ready = 0;
return ret;
+ }
setup_node_to_cpumask_map();
--
2.5.0
^ permalink raw reply related
* [PATCH 1/3] phy: sun4i: check PHY id when poking unknown bit of pmu
From: Icenowy Zheng @ 2016-10-25 3:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024082802.ev72szwmuqba5ll4@lukather>
> On Mon, Oct 24, 2016 at 11:59:30AM +0800, Icenowy Zheng wrote:
>
>> Allwinner SoC's PHY 0, when used as OTG controller, have no pmu part.
>> The code that poke some unknown bit of PMU for H3/A64 didn't check
>> the PHY, and will cause kernel oops when PHY 0 is used.
>>
>> Fixes: b3e0d141ca9f (phy: sun4i: add support for A64 usb phy)
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>
> Cc'ing stable would be nice.
Yes... As it's also used by H3...
>
> Apart from that, Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
If I change it to check whether phy->pmu is null, will you keep the ACK?
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
^ permalink raw reply
* [PATCH v2] hwrng: meson: Fix module autoload for OF registration
From: Herbert Xu @ 2016-10-25 3:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476733877-20275-1-git-send-email-javier@osg.samsung.com>
On Mon, Oct 17, 2016 at 04:51:17PM -0300, Javier Martinez Canillas wrote:
> If the driver is built as a module, autoload won't work because the module
> alias information is not filled. So user-space can't match the registered
> device with the corresponding module.
>
> Export the module alias information using the MODULE_DEVICE_TABLE() macro.
>
> Before this patch:
>
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias: platform:meson-rng
>
> After this patch:
>
> $ modinfo drivers/char/hw_random/meson-rng.ko | grep alias
> alias: platform:meson-rng
> alias: of:N*T*Camlogic,meson-rngC*
> alias: of:N*T*Camlogic,meson-rng
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] hwrng: meson: Remove unneeded platform MODULE_ALIAS
From: Herbert Xu @ 2016-10-25 3:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476906618-14455-1-git-send-email-javier@osg.samsung.com>
On Wed, Oct 19, 2016 at 04:50:18PM -0300, Javier Martinez Canillas wrote:
> The Amlogic Meson is a DT-only platform, which means the devices are
> registered via OF and not using the legacy platform devices support.
>
> So there's no need to have a MODULE_ALIAS("platform:meson-rng") since
> the reported uevent MODALIAS to user-space will always be the OF one.
>
> Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] ARM64: dts: bcm2835: Fix bcm2837 compatible string
From: Eric Anholt @ 2016-10-25 3:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477321791-7896-1-git-send-email-afaerber@suse.de>
e<#secure method=pgpmime mode=sign>
Andreas F?rber <afaerber@suse.de> writes:
> bcm2837-rpi-3-b.dts, its only in-tree user, was overriding it as
> "brcm,bcm2837" already.
Pulled to bcm2835-dt-64-next. Thanks!
^ permalink raw reply
* [PATCH 5/8] ARM: gr8: Add missing pwm channel 1 pin
From: Chen-Yu Tsai @ 2016-10-25 4:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020170739.lgt2ywm346vm47zd@lukather>
On Fri, Oct 21, 2016 at 1:07 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Thu, Oct 20, 2016 at 10:10:03PM +0800, Chen-Yu Tsai wrote:
>> On Thu, Oct 20, 2016 at 4:12 PM, Maxime Ripard
>> <maxime.ripard@free-electrons.com> wrote:
>> > The PWM controller has two different channels, but only the first pin was
>> > exposed in the DTSI. Add the other one.
>> >
>> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>>
>> Acked-by: Chen-Yu Tsai <wens@csie.org>
>>
>> > ---
>> > arch/arm/boot/dts/ntc-gr8.dtsi | 7 +++++++
>> > 1 file changed, 7 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/arch/arm/boot/dts/ntc-gr8.dtsi b/arch/arm/boot/dts/ntc-gr8.dtsi
>> > index 74aff795e723..fad7381630f3 100644
>> > --- a/arch/arm/boot/dts/ntc-gr8.dtsi
>> > +++ b/arch/arm/boot/dts/ntc-gr8.dtsi
>> > @@ -854,6 +854,13 @@
>> > allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> > };
>> >
>> > + pwm1_pins_a: pwm1 at 0 {
>>
>> Nit: really don't need "_a" and "@0" here.
>
> Fixed and applied.
Oops, you forgot to fix the label in the chip-pro dts:
DTC arch/arm/boot/dts/ntc-gr8-chip-pro.dtb
ERROR (phandle_references): Reference to non-existent node or label
"pwm1_pins_a"
ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:313: recipe for target
'arch/arm/boot/dts/ntc-gr8-chip-pro.dtb' failed
ChenYu
^ permalink raw reply
* [PATCH RESEND 1/2] dt: bindings: add allwinner, otg-routed property for phy-sun4i-usb
From: Icenowy Zheng @ 2016-10-25 4:11 UTC (permalink / raw)
To: linux-arm-kernel
On some newer Allwinner SoCs (H3 or A64), the PHY0 can be either routed to
the MUSB controller (which is an OTG controller) or the OHCI/EHCI pair
(which is a Host-only controller, but more stable and easy to implement).
This property marks whether on a certain board which controller should be
attached to the PHY.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index 287150d..a63c766 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -36,6 +36,12 @@ Optional properties:
- usb1_vbus-supply : regulator phandle for controller usb1 vbus
- usb2_vbus-supply : regulator phandle for controller usb2 vbus
+Optional properties for H3 or A64 SoCs:
+- allwinner,otg-routed : USB0 (OTG) PHY is routed to OHCI/EHCI pair rather than
+ MUSB. (boolean, if this property is set, the OHCI/EHCI
+ controllers at PHY0 should be enabled and the MUSB
+ controller must *NOT* be enabled)
+
Example:
usbphy: phy at 0x01c13400 {
#phy-cells = <1>;
--
2.10.1
^ permalink raw reply related
* [PATCH RESEND 2/2] phy-sun4i-usb: add support for host mode of phy0 on A64 SoC
From: Icenowy Zheng @ 2016-10-25 4:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025041139.46454-1-icenowy@aosc.xyz>
The OTG phy of A64 can be put into the host mode with an OHCI/EHCI pair,
just like the H3 SoC.
Some A64 boards (such as Pine64 series) use the USB OTG port as a generic
USB-A port, and thus can be fully support by the driver now.
The register's name is changed to PHY_OTG_CFG, as it's described in the
A64 downstream BSP kernel source, at drivers/usb/host/sunxi_hci.h .
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
drivers/phy/phy-sun4i-usb.c | 46 +++++++++++++++++++++++++++++++++------------
1 file changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index a4db658..9287247 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -47,7 +47,7 @@
#define REG_PHYBIST 0x08
#define REG_PHYTUNE 0x0c
#define REG_PHYCTL_A33 0x10
-#define REG_PHY_UNK_H3 0x20
+#define REG_PHY_OTG_CFG 0x20
#define REG_PMU_UNK1 0x10
@@ -107,6 +107,7 @@ struct sun4i_usb_phy_cfg {
u8 phyctl_offset;
bool dedicated_clocks;
bool enable_pmu_unk1;
+ bool route_otg;
};
struct sun4i_usb_phy_data {
@@ -135,6 +136,7 @@ struct sun4i_usb_phy_data {
int id_det;
int vbus_det;
struct delayed_work detect;
+ bool otg_routed;
};
#define to_sun4i_usb_phy_data(phy) \
@@ -263,10 +265,11 @@ static int sun4i_usb_phy_init(struct phy *_phy)
writel(val & ~2, phy->pmu + REG_PMU_UNK1);
}
- if (data->cfg->type == sun8i_h3_phy) {
- if (phy->index == 0) {
- val = readl(data->base + REG_PHY_UNK_H3);
- writel(val & ~1, data->base + REG_PHY_UNK_H3);
+ if (data->cfg->route_otg) {
+ if (phy->index == 0 && data->otg_routed) {
+ /* Route the OTG PHY to HCI */
+ val = readl(data->base + REG_PHY_OTG_CFG);
+ writel(val & ~1, data->base + REG_PHY_OTG_CFG);
}
} else {
/* Enable USB 45 Ohm resistor calibration */
@@ -283,7 +286,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
sun4i_usb_phy_passby(phy, 1);
- if (phy->index == 0) {
+ if (phy->index == 0 && !data->otg_routed) {
data->phy0_init = true;
/* Enable pull-ups */
@@ -310,7 +313,7 @@ static int sun4i_usb_phy_exit(struct phy *_phy)
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
- if (phy->index == 0) {
+ if (phy->index == 0 && !data->otg_routed) {
/* Disable pull-ups */
sun4i_usb_phy0_update_iscr(_phy, ISCR_DPDM_PULLUP_EN, 0);
sun4i_usb_phy0_update_iscr(_phy, ISCR_ID_PULLUP_EN, 0);
@@ -377,7 +380,7 @@ static int sun4i_usb_phy_power_on(struct phy *_phy)
/* For phy0 only turn on Vbus if we don't have an ext. Vbus */
if (phy->index == 0 && sun4i_usb_phy0_have_vbus_det(data) &&
- data->vbus_det)
+ data->vbus_det && !data->otg_routed)
return 0;
ret = regulator_enable(phy->vbus);
@@ -387,7 +390,7 @@ static int sun4i_usb_phy_power_on(struct phy *_phy)
phy->regulator_on = true;
/* We must report Vbus high within OTG_TIME_A_WAIT_VRISE msec. */
- if (phy->index == 0 && sun4i_usb_phy0_poll(data))
+ if (phy->index == 0 && sun4i_usb_phy0_poll(data) && !data->otg_routed)
mod_delayed_work(system_wq, &data->detect, DEBOUNCE_TIME);
return 0;
@@ -408,7 +411,7 @@ static int sun4i_usb_phy_power_off(struct phy *_phy)
* phy0 vbus typically slowly discharges, sometimes this causes the
* Vbus gpio to not trigger an edge irq on Vbus off, so force a rescan.
*/
- if (phy->index == 0 && !sun4i_usb_phy0_poll(data))
+ if (phy->index == 0 && !sun4i_usb_phy0_poll(data) && !data->otg_routed)
mod_delayed_work(system_wq, &data->detect, POLL_TIME);
return 0;
@@ -567,7 +570,17 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
return -ENOMEM;
mutex_init(&data->mutex);
- INIT_DELAYED_WORK(&data->detect, sun4i_usb_phy0_id_vbus_det_scan);
+ if (device_property_read_bool(dev, "allwinner,otg-routed")) {
+ /*
+ * PHY0 is routed to HCI rather than OTG Controller.
+ * In this situation, the port can only be used as a host port.
+ */
+ data->otg_routed = true;
+ } else {
+ /* ID/Vbus detection is only meaningful when it's really OTG */
+ INIT_DELAYED_WORK(&data->detect,
+ sun4i_usb_phy0_id_vbus_det_scan);
+ }
dev_set_drvdata(dev, data);
data->cfg = of_device_get_match_data(dev);
if (!data->cfg)
@@ -647,7 +660,8 @@ static int sun4i_usb_phy_probe(struct platform_device *pdev)
return PTR_ERR(phy->reset);
}
- if (i) { /* No pmu for usbc0 */
+ /* PMU is only valid on PHYs in HCI mode */
+ if (i || data->otg_routed) {
snprintf(name, sizeof(name), "pmu%d", i);
res = platform_get_resource_byname(pdev,
IORESOURCE_MEM, name);
@@ -719,6 +733,7 @@ static const struct sun4i_usb_phy_cfg sun4i_a10_cfg = {
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
@@ -728,6 +743,7 @@ static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
@@ -737,6 +753,7 @@ static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
@@ -746,6 +763,7 @@ static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = false,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
@@ -755,6 +773,7 @@ static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
.phyctl_offset = REG_PHYCTL_A10,
.dedicated_clocks = true,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
@@ -764,6 +783,7 @@ static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
.phyctl_offset = REG_PHYCTL_A33,
.dedicated_clocks = true,
.enable_pmu_unk1 = false,
+ .route_otg = false,
};
static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
@@ -772,6 +792,7 @@ static const struct sun4i_usb_phy_cfg sun8i_h3_cfg = {
.disc_thresh = 3,
.dedicated_clocks = true,
.enable_pmu_unk1 = true,
+ .route_otg = true,
};
static const struct sun4i_usb_phy_cfg sun50i_a64_cfg = {
@@ -781,6 +802,7 @@ static const struct sun4i_usb_phy_cfg sun50i_a64_cfg = {
.phyctl_offset = REG_PHYCTL_A33,
.dedicated_clocks = true,
.enable_pmu_unk1 = true,
+ .route_otg = true,
};
static const struct of_device_id sun4i_usb_phy_of_match[] = {
--
2.10.1
^ permalink raw reply related
* [PATCH] nvmem: sunxi-sid: SID content is not a valid source of randomness
From: LABBE Corentin @ 2016-10-25 5:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161024201020.h6akyqad2o42xkhq@lukather>
On Mon, Oct 24, 2016 at 10:10:20PM +0200, Maxime Ripard wrote:
> On Sat, Oct 22, 2016 at 03:53:28PM +0200, Corentin Labbe wrote:
> > Since SID's content is constant over reboot,
>
> That's not true, at least not across all the Allwinner SoCs, and
> especially not on the A10 and A20 that this driver supports.
>
On my cubieboard2 (A20)
hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
cubiedev ~ # reboot
cubiedev ~ # hexdump -C /sys/devices/platform/soc\@01c00000/1c23800.eeprom/sunxi-sid0/nvmem
00000000 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000100 16 51 66 83 80 48 50 72 56 54 48 48 03 c2 75 72 |.Qf..HPrVTHH..ur|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000200
So clearly for me its constant.
> > it must not be used as source of randomness.
>
> And I don't think that's true either. A constant entropy provider will
> not add any entropy, but will not remove any, would it?
I cced linux-crypto at the begining for confirmation on that.
But the problem is increased as a part of the content is predicatable over same type of device (at least the thirst bytes and all the zeros).
^ permalink raw reply
* [PATCH v2] drm/mediatek: fixed the calc method of data rate per lane
From: Jitao Shi @ 2016-10-25 5:40 UTC (permalink / raw)
To: linux-arm-kernel
Tune dsi frame rate by pixel clock, dsi add some extra signal (i.e. Tlpx,
Ths-prepare, Ths-zero, Ths-trail,Ths-exit) when enter and exit LP mode, this
signal will cause h-time larger than normal and reduce FPS.
Need to multiply a coefficient to offset the extra signal's effect.
coefficient = ((htotal*bpp/lane_number)+Tlpx+Ths_prep+Ths_zero+Ths_trail+
Ths_exit)/(htotal*bpp/lane_number))
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
Change since v1:
- phy_timing2 and phy_timing3 refer clock cycle time.
- define values of LPX HS_PRPR HS_ZERO HS_TRAIL TA_GO TA_SURE TA_GET DA_HS_EXIT
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 103 +++++++++++++++++++++++-------------
1 file changed, 67 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 28b2044..ade6f46 100644
--- a/drivers/gpu/drm/mediatek/mtk_dsi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dsi.c
@@ -85,16 +85,16 @@
#define LD0_WAKEUP_EN BIT(2)
#define DSI_PHY_TIMECON0 0x110
-#define LPX (0xff << 0)
-#define HS_PRPR (0xff << 8)
-#define HS_ZERO (0xff << 16)
-#define HS_TRAIL (0xff << 24)
+#define LPX (5 << 0)
+#define HS_PRPR (6 << 8)
+#define HS_ZERO (10 << 16)
+#define HS_TRAIL (8 << 24)
#define DSI_PHY_TIMECON1 0x114
-#define TA_GO (0xff << 0)
-#define TA_SURE (0xff << 8)
-#define TA_GET (0xff << 16)
-#define DA_HS_EXIT (0xff << 24)
+#define TA_GO (20 << 0)
+#define TA_SURE (7 << 8)
+#define TA_GET (25 << 16)
+#define DA_HS_EXIT (7 << 24)
#define DSI_PHY_TIMECON2 0x118
#define CONT_DET (0xff << 0)
@@ -158,28 +158,14 @@ static void mtk_dsi_mask(struct mtk_dsi *dsi, u32 offset, u32 mask, u32 data)
writel((temp & ~mask) | (data & mask), dsi->regs + offset);
}
-static void dsi_phy_timconfig(struct mtk_dsi *dsi)
+static void dsi_phy_timconfig(struct mtk_dsi *dsi, u32 phy_timing0,
+ u32 phy_timing1, u32 phy_timing2,
+ u32 phy_timing3)
{
- u32 timcon0, timcon1, timcon2, timcon3;
- unsigned int ui, cycle_time;
- unsigned int lpx;
-
- ui = 1000 / dsi->data_rate + 0x01;
- cycle_time = 8000 / dsi->data_rate + 0x01;
- lpx = 5;
-
- timcon0 = (8 << 24) | (0xa << 16) | (0x6 << 8) | lpx;
- timcon1 = (7 << 24) | (5 * lpx << 16) | ((3 * lpx) / 2) << 8 |
- (4 * lpx);
- timcon2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
- (NS_TO_CYCLE(0x150, cycle_time) << 16);
- timcon3 = (2 * lpx) << 16 | NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
- NS_TO_CYCLE(0x40, cycle_time);
-
- writel(timcon0, dsi->regs + DSI_PHY_TIMECON0);
- writel(timcon1, dsi->regs + DSI_PHY_TIMECON1);
- writel(timcon2, dsi->regs + DSI_PHY_TIMECON2);
- writel(timcon3, dsi->regs + DSI_PHY_TIMECON3);
+ writel(phy_timing0, dsi->regs + DSI_PHY_TIMECON0);
+ writel(phy_timing1, dsi->regs + DSI_PHY_TIMECON1);
+ writel(phy_timing2, dsi->regs + DSI_PHY_TIMECON2);
+ writel(phy_timing3, dsi->regs + DSI_PHY_TIMECON3);
}
static void mtk_dsi_enable(struct mtk_dsi *dsi)
@@ -202,19 +188,51 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
{
struct device *dev = dsi->dev;
int ret;
+ u64 bit_clock, total_bits;
+ u32 htotal, htotal_bits, bit_per_pixel, overhead_cycles, overhead_bits;
+ u32 phy_timing0, phy_timing1, phy_timing2, phy_timing3;
+ u32 ui, cycle_time;
if (++dsi->refcount != 1)
return 0;
+ switch (dsi->format) {
+ case MIPI_DSI_FMT_RGB565:
+ bit_per_pixel = 16;
+ break;
+ case MIPI_DSI_FMT_RGB666_PACKED:
+ bit_per_pixel = 18;
+ break;
+ case MIPI_DSI_FMT_RGB666:
+ case MIPI_DSI_FMT_RGB888:
+ default:
+ bit_per_pixel = 24;
+ break;
+ }
+ /**
+ * data_rate = (pixel_clock) * bit_per_pixel * mipi_ratio / lane_num;
+ * vm.pixelclock is Khz, data_rata unit is Hz, so need to multiply 1000
+ * mipi_ratio is (htotal * byte_per_pixel / lane_num + Tlpx + Ths_prep
+ * + Thstrail + Ths_exit + Ths_zero) /
+ * (htotal * byte_per_pixel /lane_number)
+ */
+ bit_clock = dsi->vm.pixelclock * 1000 * bit_per_pixel;
+ htotal = dsi->vm.hactive + dsi->vm.hback_porch + dsi->vm.hfront_porch +
+ dsi->vm.hsync_len;
+ htotal_bits = htotal * bit_per_pixel;
+
/**
- * data_rate = (pixel_clock / 1000) * pixel_dipth * mipi_ratio;
- * pixel_clock unit is Khz, data_rata unit is MHz, so need divide 1000.
- * mipi_ratio is mipi clk coefficient for balance the pixel clk in mipi.
- * we set mipi_ratio is 1.05.
+ * overhead = lpx + hs_prepare + hs_zero + hs_trail + hs_exit
*/
- dsi->data_rate = dsi->vm.pixelclock * 3 * 21 / (1 * 1000 * 10);
+ overhead_cycles = LPX + (HS_PRPR >> 8) + (HS_ZERO >> 16) +
+ (HS_TRAIL >> 24) + (DA_HS_EXIT >> 24);
+ overhead_bits = overhead_cycles * dsi->lanes * 8;
+ total_bits = htotal_bits + overhead_bits;
- ret = clk_set_rate(dsi->hs_clk, dsi->data_rate * 1000000);
+ dsi->data_rate = DIV_ROUND_UP_ULL(bit_clock * total_bits,
+ htotal_bits * dsi->lanes);
+
+ ret = clk_set_rate(dsi->hs_clk, dsi->data_rate);
if (ret < 0) {
dev_err(dev, "Failed to set data rate: %d\n", ret);
goto err_refcount;
@@ -236,7 +254,20 @@ static int mtk_dsi_poweron(struct mtk_dsi *dsi)
mtk_dsi_enable(dsi);
mtk_dsi_reset(dsi);
- dsi_phy_timconfig(dsi);
+
+ ui = 1000 / dsi->data_rate + 0x01;
+ cycle_time = 8000 / dsi->data_rate + 0x01;
+
+ phy_timing0 = LPX | HS_PRPR | HS_ZERO | HS_TRAIL;
+ phy_timing1 = TA_GO | TA_SURE | TA_GET | DA_HS_EXIT;
+ phy_timing2 = ((NS_TO_CYCLE(0x64, cycle_time) + 0xa) << 24) |
+ (NS_TO_CYCLE(0x150, cycle_time) << 16);
+ phy_timing3 = (2 * LPX) << 16 |
+ NS_TO_CYCLE(80 + 52 * ui, cycle_time) << 8 |
+ NS_TO_CYCLE(0x40, cycle_time);
+
+ dsi_phy_timconfig(dsi, phy_timing0, phy_timing1, phy_timing2,
+ phy_timing3);
return 0;
--
1.7.9.5
^ permalink raw reply related
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: Mugunthan V N @ 2016-10-25 5:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <038C6B01-8443-4321-9C65-BAC4095237D3@gmail.com>
On Tuesday 25 October 2016 02:28 AM, John Syne wrote:
>> > On Oct 23, 2016, at 11:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>> >
>> > Increase ADC reference clock from 3MHz to 24MHz so that the
>> > sampling rates goes up from 100K samples per second to 800K
>> > samples per second on AM335x and AM437x SoC.
>> >
>> > Also increase opendelay for touchscreen configuration to
>> > equalize the increase in ADC reference clock frequency,
>> > which results in the same amount touch events reported via
>> > evtest on AM335x GP EVM.
>> >
>> > Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>> > ---
>> >
>> > This patch depends on ADC DMA patch series [1]
>> >
>> > Without DMA support, when ADC ref clock is set at 24MHz, I am
>> > seeing fifo overflow as CPU is not able to pull the ADC samples.
>> > This answers that DMA support is must for ADC to consume the
>> > samples generated at 24MHz with no open, step delay or
>> > averaging with patch [2].
>> >
>> > Measured the performance with the iio_generic_buffer with the
>> > patch [3] applied
>> >
>> > [1] - http://www.spinics.net/lists/devicetree/msg145045.html
>> > [2] - http://pastebin.ubuntu.com/23357935/
>> > [3] - http://pastebin.ubuntu.com/23357939/
>> >
>> > ---
>> > include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
>> > 1 file changed, 2 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>> > index b9a53e0..96c4207 100644
>> > --- a/include/linux/mfd/ti_am335x_tscadc.h
>> > +++ b/include/linux/mfd/ti_am335x_tscadc.h
>> > @@ -90,7 +90,7 @@
>> > /* Delay register */
>> > #define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
>> > #define STEPDELAY_OPEN(val) ((val) << 0)
>> > -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
> Wouldn?t this be better to add this to the devicetree?
>
> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
For a touch screen, there is not need to change in these parameter
settings, so my opinion is to keep it as is. Or am I missing something?
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: John Syne @ 2016-10-25 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <086ab2fa-63ee-c5ab-2715-b2efd78270d7@ti.com>
> On Oct 24, 2016, at 10:52 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>
> On Tuesday 25 October 2016 02:28 AM, John Syne wrote:
>>>> On Oct 23, 2016, at 11:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>>
>>>> Increase ADC reference clock from 3MHz to 24MHz so that the
>>>> sampling rates goes up from 100K samples per second to 800K
>>>> samples per second on AM335x and AM437x SoC.
>>>>
>>>> Also increase opendelay for touchscreen configuration to
>>>> equalize the increase in ADC reference clock frequency,
>>>> which results in the same amount touch events reported via
>>>> evtest on AM335x GP EVM.
>>>>
>>>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>>>> ---
>>>>
>>>> This patch depends on ADC DMA patch series [1]
>>>>
>>>> Without DMA support, when ADC ref clock is set at 24MHz, I am
>>>> seeing fifo overflow as CPU is not able to pull the ADC samples.
>>>> This answers that DMA support is must for ADC to consume the
>>>> samples generated at 24MHz with no open, step delay or
>>>> averaging with patch [2].
>>>>
>>>> Measured the performance with the iio_generic_buffer with the
>>>> patch [3] applied
>>>>
>>>> [1] - http://www.spinics.net/lists/devicetree/msg145045.html
>>>> [2] - http://pastebin.ubuntu.com/23357935/
>>>> [3] - http://pastebin.ubuntu.com/23357939/
>>>>
>>>> ---
>>>> include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>>>> index b9a53e0..96c4207 100644
>>>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>>>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>>>> @@ -90,7 +90,7 @@
>>>> /* Delay register */
>>>> #define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
>>>> #define STEPDELAY_OPEN(val) ((val) << 0)
>>>> -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
>> Wouldn?t this be better to add this to the devicetree?
>>
>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
>> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
>
> For a touch screen, there is not need to change in these parameter
> settings, so my opinion is to keep it as is. Or am I missing something?
I was thinking that if you are using this driver as an ADC, you may want the flexibility to make these changes in the DT. I?m doing this by connecting sensors to the ADC inputs. I?m not using this driver for a touchscreen.
Regards,
John
>
> Regards
> Mugunthan V N
^ permalink raw reply
* [PATCH v1] ARM: at91/dt: add dts file for sama5d36ek CMP board
From: Wenyou Yang @ 2016-10-25 6:08 UTC (permalink / raw)
To: linux-arm-kernel
The difference between sama5d36ek_cmp.dts and sama5d36ek.dts
is listed as below.
1. The USB host nodes are removed, that is, the USB host is disabled.
2. The gpio_keys node is added to wake up from the sleep.
3. The sama5d3xdm.dtsi isn't included, because the pins for LCD are
conflicted with one for gpio_keys.
As said in errata, "When the USB host ports are used in high speed
mode (EHCI), it is not possible to suspend the ports if no device is
attached on each port. This leads to increased power consumption even
if the system is in a low power mode." That is why the the USB host
isn't enabled.
Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
---
arch/arm/boot/dts/sama5d36ek_cmp.dts | 51 ++++++++
arch/arm/boot/dts/sama5d3xcm_cmp.dtsi | 166 ++++++++++++++++++++++++
arch/arm/boot/dts/sama5d3xmb_cmp.dtsi | 230 ++++++++++++++++++++++++++++++++++
3 files changed, 447 insertions(+)
create mode 100644 arch/arm/boot/dts/sama5d36ek_cmp.dts
create mode 100644 arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
create mode 100644 arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
diff --git a/arch/arm/boot/dts/sama5d36ek_cmp.dts b/arch/arm/boot/dts/sama5d36ek_cmp.dts
new file mode 100644
index 0000000..fd6bcd6
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d36ek_cmp.dts
@@ -0,0 +1,51 @@
+/*
+ * sama5d36ek_cmp.dts - Device Tree file for SAMA5D36-EK CMP board
+ *
+ * Copyright (C) 2016 Atmel,
+ *
+ * Licensed under GPLv2 or later.
+ */
+/dts-v1/;
+#include "sama5d36.dtsi"
+#include "sama5d3xmb_cmp.dtsi"
+
+/ {
+ model = "Atmel SAMA5D36-EK";
+ compatible = "atmel,sama5d36ek", "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d36", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ spi0: spi at f0004000 {
+ status = "okay";
+ };
+
+ ssc0: ssc at f0008000 {
+ status = "okay";
+ };
+
+ can0: can at f000c000 {
+ status = "okay";
+ };
+
+ i2c0: i2c at f0014000 {
+ status = "okay";
+ };
+
+ i2c1: i2c at f0018000 {
+ status = "okay";
+ };
+
+ macb0: ethernet at f0028000 {
+ status = "okay";
+ };
+
+ macb1: ethernet at f802c000 {
+ status = "okay";
+ };
+ };
+ };
+
+ sound {
+ status = "okay";
+ };
+};
diff --git a/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
new file mode 100644
index 0000000..77638c3
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3xcm_cmp.dtsi
@@ -0,0 +1,166 @@
+/*
+ * sama5d3xcm_cmp.dtsi - Device Tree Include file for SAMA5D36 CMP CPU Module
+ *
+ * Copyright (C) 2016 Atmel,
+ *
+ * Licensed under GPLv2 or later.
+ */
+
+/ {
+ compatible = "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
+
+ chosen {
+ bootargs = "rootfstype=ubifs ubi.mtd=5 root=ubi0:rootfs";
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory {
+ reg = <0x20000000 0x20000000>;
+ };
+
+ clocks {
+ slow_xtal {
+ clock-frequency = <32768>;
+ };
+
+ main_xtal {
+ clock-frequency = <12000000>;
+ };
+ };
+
+ ahb {
+ apb {
+ spi0: spi at f0004000 {
+ cs-gpios = <&pioD 13 0>, <0>, <0>, <0>;
+ };
+
+ macb0: ethernet at f0028000 {
+ phy-mode = "rgmii";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethernet-phy at 1 {
+ reg = <0x1>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
+
+ ethernet-phy at 7 {
+ reg = <0x7>;
+ interrupt-parent = <&pioB>;
+ interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
+ txen-skew-ps = <800>;
+ txc-skew-ps = <3000>;
+ rxdv-skew-ps = <400>;
+ rxc-skew-ps = <3000>;
+ rxd0-skew-ps = <400>;
+ rxd1-skew-ps = <400>;
+ rxd2-skew-ps = <400>;
+ rxd3-skew-ps = <400>;
+ };
+ };
+
+ i2c1: i2c at f0018000 {
+ pmic: act8865 at 5b {
+ compatible = "active-semi,act8865";
+ reg = <0x5b>;
+ status = "disabled";
+
+ regulators {
+ vcc_1v8_reg: DCDC_REG1 {
+ regulator-name = "VCC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ vcc_1v2_reg: DCDC_REG2 {
+ regulator-name = "VCC_1V2";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-always-on;
+ };
+
+ vcc_3v3_reg: DCDC_REG3 {
+ regulator-name = "VCC_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vddana_reg: LDO_REG1 {
+ regulator-name = "VDDANA";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ vddfuse_reg: LDO_REG2 {
+ regulator-name = "FUSE_2V5";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ };
+ };
+ };
+ };
+ };
+
+ nand0: nand at 60000000 {
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ atmel,has-pmecc;
+ atmel,pmecc-cap = <4>;
+ atmel,pmecc-sector-size = <512>;
+ nand-on-flash-bbt;
+ status = "okay";
+
+ at91bootstrap at 0 {
+ label = "at91bootstrap";
+ reg = <0x0 0x40000>;
+ };
+
+ bootloader at 40000 {
+ label = "bootloader";
+ reg = <0x40000 0x80000>;
+ };
+
+ bootloaderenv at c0000 {
+ label = "bootloader env";
+ reg = <0xc0000 0xc0000>;
+ };
+
+ dtb at 180000 {
+ label = "device tree";
+ reg = <0x180000 0x80000>;
+ };
+
+ kernel at 200000 {
+ label = "kernel";
+ reg = <0x200000 0x600000>;
+ };
+
+ rootfs at 800000 {
+ label = "rootfs";
+ reg = <0x800000 0x0f800000>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ d2 {
+ label = "d2";
+ gpios = <&pioE 25 GPIO_ACTIVE_LOW>; /* PE25, conflicts with A25, RXD2 */
+ linux,default-trigger = "heartbeat";
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
new file mode 100644
index 0000000..3ec78867
--- /dev/null
+++ b/arch/arm/boot/dts/sama5d3xmb_cmp.dtsi
@@ -0,0 +1,230 @@
+/*
+ * sama5d3xmb_cmp.dts - Device Tree file for SAMA5D3x CMP mother board
+ *
+ * Copyright (C) 2016 Atmel,
+ *
+ * Licensed under GPLv2 or later.
+ */
+#include "sama5d3xcm_cmp.dtsi"
+
+/ {
+ compatible = "atmel,sama5d3xmb", "atmel,sama5d3xcm", "atmel,sama5d3", "atmel,sama5";
+
+ ahb {
+ apb {
+ mmc0: mmc at f0000000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc0_clk_cmd_dat0 &pinctrl_mmc0_dat1_3 &pinctrl_mmc0_cd>;
+ status = "okay";
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ cd-gpios = <&pioD 17 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ spi0: spi at f0004000 {
+ dmas = <0>, <0>; /* Do not use DMA for spi0 */
+
+ m25p80 at 0 {
+ compatible = "atmel,at25df321a";
+ spi-max-frequency = <50000000>;
+ reg = <0>;
+ };
+ };
+
+ ssc0: ssc at f0008000 {
+ atmel,clk-from-rk-pin;
+ };
+
+ /*
+ * i2c0 conflicts with ISI:
+ * disable it to allow the use of ISI
+ * can not enable audio when i2c0 disabled
+ */
+ i2c0: i2c at f0014000 {
+ wm8904: wm8904 at 1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ clocks = <&pck0>;
+ clock-names = "mclk";
+ };
+ };
+
+ i2c1: i2c at f0018000 {
+ ov2640: camera at 0x30 {
+ compatible = "ovti,ov2640";
+ reg = <0x30>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck1_as_isi_mck &pinctrl_sensor_power &pinctrl_sensor_reset>;
+ resetb-gpios = <&pioE 24 GPIO_ACTIVE_LOW>;
+ pwdn-gpios = <&pioE 29 GPIO_ACTIVE_HIGH>;
+ /* use pck1 for the master clock of ov2640 */
+ clocks = <&pck1>;
+ clock-names = "xvclk";
+ assigned-clocks = <&pck1>;
+ assigned-clock-rates = <25000000>;
+
+ port {
+ ov2640_0: endpoint {
+ remote-endpoint = <&isi_0>;
+ bus-width = <8>;
+ };
+ };
+ };
+ };
+
+ usart1: serial at f0020000 {
+ dmas = <0>, <0>; /* Do not use DMA for usart1 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usart1 &pinctrl_usart1_rts_cts>;
+ status = "okay";
+ };
+
+ isi: isi at f0034000 {
+ port {
+ isi_0: endpoint {
+ remote-endpoint = <&ov2640_0>;
+ bus-width = <8>;
+ vsync-active = <1>;
+ hsync-active = <1>;
+ };
+ };
+ };
+
+ mmc1: mmc at f8000000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_mmc1_clk_cmd_dat0 &pinctrl_mmc1_dat1_3 &pinctrl_mmc1_cd>;
+ status = "okay";
+ slot at 0 {
+ reg = <0>;
+ bus-width = <4>;
+ cd-gpios = <&pioD 18 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ adc0: adc at f8018000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &pinctrl_adc0_adtrg
+ &pinctrl_adc0_ad0
+ &pinctrl_adc0_ad1
+ &pinctrl_adc0_ad2
+ &pinctrl_adc0_ad3
+ &pinctrl_adc0_ad4
+ >;
+ status = "okay";
+ };
+
+ macb1: ethernet at f802c000 {
+ phy-mode = "rmii";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ phy0: ethernet-phy at 1 {
+ /*interrupt-parent = <&pioE>;*/
+ /*interrupts = <30 IRQ_TYPE_EDGE_FALLING>;*/
+ reg = <1>;
+ };
+ };
+
+ pinctrl at fffff200 {
+ board {
+ pinctrl_gpio_keys: gpio_keys {
+ atmel,pins =
+ <AT91_PIOE 27 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP>;
+ };
+
+ pinctrl_mmc0_cd: mmc0_cd {
+ atmel,pins =
+ <AT91_PIOD 17 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD17 GPIO with pullup deglitch */
+ };
+
+ pinctrl_mmc1_cd: mmc1_cd {
+ atmel,pins =
+ <AT91_PIOD 18 AT91_PERIPH_GPIO AT91_PINCTRL_PULL_UP_DEGLITCH>; /* PD18 GPIO with pullup deglitch */
+ };
+
+ pinctrl_pck0_as_audio_mck: pck0_as_audio_mck {
+ atmel,pins =
+ <AT91_PIOD 30 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD30 periph B */
+ };
+
+ pinctrl_pck1_as_isi_mck: pck1_as_isi_mck-0 {
+ atmel,pins =
+ <AT91_PIOD 31 AT91_PERIPH_B AT91_PINCTRL_NONE>; /* PD31 periph B ISI_MCK */
+ };
+
+ pinctrl_sensor_reset: sensor_reset-0 {
+ atmel,pins =
+ <AT91_PIOE 24 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE24 gpio */
+ };
+
+ pinctrl_sensor_power: sensor_power-0 {
+ atmel,pins =
+ <AT91_PIOE 29 AT91_PERIPH_GPIO AT91_PINCTRL_NONE>; /* PE29 gpio */
+ };
+
+ pinctrl_usba_vbus: usba_vbus {
+ atmel,pins =
+ <AT91_PIOD 29 AT91_PERIPH_GPIO AT91_PINCTRL_DEGLITCH>; /* PD29 GPIO with deglitch */
+ };
+ };
+ };
+
+ dbgu: serial at ffffee00 {
+ dmas = <0>, <0>; /* Do not use DMA for dbgu */
+ status = "okay";
+ };
+
+ watchdog at fffffe40 {
+ status = "okay";
+ };
+ };
+
+ usb0: gadget at 00500000 {
+ atmel,vbus-gpio = <&pioD 29 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usba_vbus>;
+ status = "okay";
+ };
+ };
+
+ sound {
+ compatible = "atmel,asoc-wm8904";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pck0_as_audio_mck>;
+
+ atmel,model = "wm8904 @ SAMA5D3EK";
+ atmel,audio-routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "Mic", "MICBIAS",
+ "IN1L", "Mic";
+
+ atmel,ssc-controller = <&ssc0>;
+ atmel,audio-codec = <&wm8904>;
+
+ status = "disabled";
+ };
+
+ /* Conflict with LCD pins */
+ gpio_keys {
+ compatible = "gpio-keys";
+ status = "okay";
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ pb_user1 {
+ label = "pb_user1";
+ gpios = <&pioE 27 GPIO_ACTIVE_HIGH>;
+ linux,code = <0x100>;
+ gpio-key,wakeup;
+ };
+ };
+};
--
2.7.4
^ permalink raw reply related
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: John Syne @ 2016-10-25 6:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <12725C92-9BB8-4F77-A7B4-F3C3DA9F8B0B@gmail.com>
> On Oct 24, 2016, at 11:01 PM, John Syne <john3909@gmail.com> wrote:
>
>>
>> On Oct 24, 2016, at 10:52 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>
>> On Tuesday 25 October 2016 02:28 AM, John Syne wrote:
>>>>> On Oct 23, 2016, at 11:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>>>
>>>>> Increase ADC reference clock from 3MHz to 24MHz so that the
>>>>> sampling rates goes up from 100K samples per second to 800K
>>>>> samples per second on AM335x and AM437x SoC.
>>>>>
>>>>> Also increase opendelay for touchscreen configuration to
>>>>> equalize the increase in ADC reference clock frequency,
>>>>> which results in the same amount touch events reported via
>>>>> evtest on AM335x GP EVM.
>>>>>
>>>>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
>>>>> ---
>>>>>
>>>>> This patch depends on ADC DMA patch series [1]
>>>>>
>>>>> Without DMA support, when ADC ref clock is set at 24MHz, I am
>>>>> seeing fifo overflow as CPU is not able to pull the ADC samples.
>>>>> This answers that DMA support is must for ADC to consume the
>>>>> samples generated at 24MHz with no open, step delay or
>>>>> averaging with patch [2].
>>>>>
>>>>> Measured the performance with the iio_generic_buffer with the
>>>>> patch [3] applied
>>>>>
>>>>> [1] - http://www.spinics.net/lists/devicetree/msg145045.html
>>>>> [2] - http://pastebin.ubuntu.com/23357935/
>>>>> [3] - http://pastebin.ubuntu.com/23357939/
>>>>>
>>>>> ---
>>>>> include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>>>>> index b9a53e0..96c4207 100644
>>>>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>>>>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>>>>> @@ -90,7 +90,7 @@
>>>>> /* Delay register */
>>>>> #define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
>>>>> #define STEPDELAY_OPEN(val) ((val) << 0)
>>>>> -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
>>> Wouldn?t this be better to add this to the devicetree?
>>>
>>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
>>> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
>>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
>>
>> For a touch screen, there is not need to change in these parameter
>> settings, so my opinion is to keep it as is. Or am I missing something?
> I was thinking that if you are using this driver as an ADC, you may want the flexibility to make these changes in the DT. I?m doing this by connecting sensors to the ADC inputs. I?m not using this driver for a touchscreen.
Here is a DT overlay were this gets using on the BeagleBoneBlack.
https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts
Besides, these DT features are already implemented in the driver so it is just a matter of adding these entries to the am33xx.dtsi & am4372.dtsi, which you modified in this patch series.
Regards,
John
>
> Regards,
> John
>>
>> Regards
>> Mugunthan V N
^ permalink raw reply
* [PATCH V3 0/8] IOMMU probe deferral support
From: Archit Taneja @ 2016-10-25 6:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475600632-21289-1-git-send-email-sricharan@codeaurora.org>
On 10/04/2016 10:33 PM, Sricharan R wrote:
> Initial post from Laurent Pinchart[1]. This is
> series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/driver is called. Similarly dma_deconfigure is called during
> device/driver_detach path.
>
>
> pci_bus_add_devices (platform/amba)(_device_create/driver_register)
> | |
> pci_bus_add_device (device_add/driver_register)
> | |
> device_attach device_initial_probe
> | |
> __device_attach_driver __device_attach_driver
> |
> driver_probe_device
> |
> really_probe
> |
> dma_configure
>
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
>
> If the ACPI bus code follows the same, we can add acpi_dma_configure
> at the same place as of_dma_configure.
>
> This series is based on the recently merged Generic DT bindings for
> PCI IOMMUs and ARM SMMU from Robin Murphy robin.murphy at arm.com [2]
>
> This time tested this with platform and pci device for probe deferral
> and reprobe on arm64 based platform. There is an issue on the cleanup
> path for arm64 though, where there is WARN_ON if the dma_ops is reset while
> device is attached to an domain in arch_teardown_dma_ops.
> But with iommu_groups created from the iommu driver, the device is always
> attached to a domain/default_domain. So so the WARN has to be removed/handled
> probably.
>
Tested-by: Archit Taneja <architt@codeaurora.org>
> Previous post of this series [3].
>
> [V3]
> * Removed the patch to split dma_masks/dma_ops configuration separately
> based on review comments that both masks and ops are required only
> during the device probe time.
>
> * Reworked the series based on Generic DT bindings series [2].
>
> * Added call to iommu's remove_device in the cleanup path for arm and arm64.
>
> * Removed the notifier trick in arm64 to handle early device registration.
>
> * Added reset of dma_ops in cleanup path for arm based on comments.
>
> * Fixed the pci_iommu_configure path and tested with PCI device as well.
>
> * Fixed a bug to return the correct iommu_ops from patch 7 [4] in last post.
>
> * Fixed few other cosmetic comments.
>
> [V2]
> * Updated the Initial post to call dma_configure/deconfigure from generic code
>
> * Added iommu add_device callback from of_iommu_configure path
>
> [V1]
> * Initial post
>
> [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
> [2] http://www.spinics.net/lists/devicetree/msg142943.html
> [3] https://www.mail-archive.com/iommu at lists.linux-foundation.org/msg13941.html
> [4] https://www.mail-archive.com/iommu at lists.linux-foundation.org/msg13940.html
>
>
>
> Laurent Pinchart (4):
> arm: dma-mapping: Don't override dma_ops in arch_setup_dma_ops()
> of: dma: Move range size workaround to of_dma_get_range()
> of: dma: Make of_dma_deconfigure() public
> iommu: of: Handle IOMMU lookup failure with deferred probing or error
>
> Sricharan R (4):
> drivers: platform: Configure dma operations at probe time
> arm: dma-mapping: Reset the device's dma_ops
> arm/arm64: dma-mapping: Call iommu's remove_device callback during
> device detach
> arm64: dma-mapping: Remove the notifier trick to handle early setting
> of dma_ops
>
> arch/arm/mm/dma-mapping.c | 18 ++++++++
> arch/arm64/mm/dma-mapping.c | 107 +++++---------------------------------------
> drivers/base/dd.c | 10 +++++
> drivers/base/dma-mapping.c | 11 +++++
> drivers/iommu/of_iommu.c | 47 +++++++++++++++++--
> drivers/of/address.c | 20 ++++++++-
> drivers/of/device.c | 34 +++++++-------
> drivers/of/platform.c | 9 ----
> drivers/pci/probe.c | 5 +--
> include/linux/dma-mapping.h | 3 ++
> include/linux/of_device.h | 7 ++-
> 11 files changed, 138 insertions(+), 133 deletions(-)
>
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 2/4] iommu/arm-smmu: Add pm_runtime/sleep ops
From: Sricharan @ 2016-10-25 6:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkw8Y-5MkeM2U9fLWX951Mo7ErsMCUBjSx3-0689jWD4rQ@mail.gmail.com>
Hi,
>On 21 October 2016 at 11:14, Sricharan R <sricharan@codeaurora.org> wrote:
>> The smmu needs to be functional when the respective
>> master/s using it are active. As there is a device_link
>> between the master and smmu, the pm runtime ops for the smmu
>> gets invoked in sync with the master's runtime, thus the
>> smmu remains powered only when needed.
>>
>> There are couple of places in the driver during probe,
>> master attach, where the smmu needs to be clocked without
>> the context of the master. So doing a pm_runtime_get/put sync
>> in those places separately.
>>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>> drivers/iommu/arm-smmu.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 108 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 083489e4..45f2762 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -45,6 +45,7 @@
>> #include <linux/of_iommu.h>
>> #include <linux/pci.h>
>> #include <linux/platform_device.h>
>> +#include <linux/pm_runtime.h>
>> #include <linux/slab.h>
>> #include <linux/spinlock.h>
>>
>> @@ -373,6 +374,8 @@ struct arm_smmu_device {
>> u32 num_global_irqs;
>> u32 num_context_irqs;
>> unsigned int *irqs;
>> + int num_clocks;
>> + struct clk **clocks;
>>
>> u32 cavium_id_base; /* Specific to Cavium */
>> };
>> @@ -430,6 +433,31 @@ static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
>> return container_of(dom, struct arm_smmu_domain, domain);
>> }
>>
>> +static int arm_smmu_enable_clocks(struct arm_smmu_device *smmu)
>> +{
>> + int i, ret = 0;
>> +
>> + for (i = 0; i < smmu->num_clocks; ++i) {
>> + ret = clk_prepare_enable(smmu->clocks[i]);
>> + if (ret) {
>> + dev_err(smmu->dev, "Couldn't enable clock #%d\n", i);
>> + while (i--)
>> + clk_disable_unprepare(smmu->clocks[i]);
>> + break;
>> + }
>> + }
>> +
>> + return ret;
>> +}
>> +
>> +static void arm_smmu_disable_clocks(struct arm_smmu_device *smmu)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < smmu->num_clocks; ++i)
>> + clk_disable_unprepare(smmu->clocks[i]);
>> +}
>> +
>> static void parse_driver_options(struct arm_smmu_device *smmu)
>> {
>> int i = 0;
>> @@ -1187,11 +1215,13 @@ static void arm_smmu_master_free_smes(struct iommu_fwspec *fwspec)
>> int i, idx;
>>
>> mutex_lock(&smmu->stream_map_mutex);
>> + pm_runtime_get_sync(smmu->dev);
>
>Since this is generic code it is probably a good idea to check the
>return value, same for _put_sync() below.
Ok, i will do it for V2.
>
>> for_each_cfg_sme(fwspec, i, idx) {
>> if (arm_smmu_free_sme(smmu, idx))
>> arm_smmu_write_sme(smmu, idx);
>> cfg->smendx[i] = INVALID_SMENDX;
>> }
>> + pm_runtime_put_sync(smmu->dev);
>> mutex_unlock(&smmu->stream_map_mutex);
>> }
>>
>> @@ -1424,9 +1454,11 @@ static int arm_smmu_add_device(struct device *dev)
>> while (i--)
>> cfg->smendx[i] = INVALID_SMENDX;
>>
>> + pm_runtime_get_sync(smmu->dev);
>> ret = arm_smmu_master_alloc_smes(dev);
>> if (ret)
>> goto out_free;
>> + pm_runtime_put_sync(smmu->dev);
>>
>> return 0;
>>
>> @@ -1650,6 +1682,44 @@ static int arm_smmu_id_size_to_bits(int size)
>> }
>> }
>>
>> +static int arm_smmu_init_clocks(struct arm_smmu_device *smmu)
>> +{
>> + const char *cname;
>> + struct property *prop;
>> + int i;
>> + struct device *dev = smmu->dev;
>> +
>> + smmu->num_clocks =
>> + of_property_count_strings(dev->of_node, "clock-names");
>> +
>> + if (smmu->num_clocks < 1)
>> + return 0;
>> +
>> + smmu->clocks = devm_kzalloc(dev,
>> + sizeof(*smmu->clocks) * smmu->num_clocks,
>> + GFP_KERNEL);
>> +
>> + if (!smmu->clocks) {
>> + dev_err(dev, "Failed to allocate memory for clocks\n");
>> + return -ENODEV;
>> + }
>> +
>> + i = 0;
>
>Please do the initialisation above when you declare the variable.
ok, will change it.
Regards,
Sricharan
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: Vignesh R @ 2016-10-25 6:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB09B26E-C5AB-427A-82D5-6FE857E7C218@gmail.com>
On Tuesday 25 October 2016 11:46 AM, John Syne wrote:
>
>> On Oct 24, 2016, at 11:01 PM, John Syne <john3909@gmail.com> wrote:
>>
>>>
>>> On Oct 24, 2016, at 10:52 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
>>>
[...]
>>>>>>
>>>>>> ---
>>>>>> include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
>>>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
>>>>>> index b9a53e0..96c4207 100644
>>>>>> --- a/include/linux/mfd/ti_am335x_tscadc.h
>>>>>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
>>>>>> @@ -90,7 +90,7 @@
>>>>>> /* Delay register */
>>>>>> #define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
>>>>>> #define STEPDELAY_OPEN(val) ((val) << 0)
>>>>>> -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
>>>> Wouldn?t this be better to add this to the devicetree?
>>>>
>>>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
>>>> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
>>>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
>>>
>>> For a touch screen, there is not need to change in these parameter
>>> settings, so my opinion is to keep it as is. Or am I missing something?
>> I was thinking that if you are using this driver as an ADC, you may want the flexibility to make these changes in the DT. I?m doing this by connecting sensors to the ADC inputs. I?m not using this driver for a touchscreen.
>
ti_am335x_adc driver already supports above DT parameters and its upto
the user to adjust these parameters as required.
> Here is a DT overlay were this gets using on the BeagleBoneBlack.
>
> https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts
>
> Besides, these DT features are already implemented in the driver so it is just a matter of adding these entries to the am33xx.dtsi & am4372.dtsi, which you modified in this patch series.
>
Touchscreen driver (ti_am335x_tsc.c) does not support above DT parameters.
--
Regards
Vignesh
^ permalink raw reply
* [PATCH] drivers: mfd: ti_am335x_tscadc: increase ADC ref clock to 24MHz
From: Lee Jones @ 2016-10-25 6:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <DB09B26E-C5AB-427A-82D5-6FE857E7C218@gmail.com>
On Mon, 24 Oct 2016, John Syne wrote:
> > On Oct 24, 2016, at 11:01 PM, John Syne <john3909@gmail.com> wrote:
> >> On Oct 24, 2016, at 10:52 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> >>
> >> On Tuesday 25 October 2016 02:28 AM, John Syne wrote:
> >>>>> On Oct 23, 2016, at 11:02 PM, Mugunthan V N <mugunthanvnm@ti.com> wrote:
> >>>>>
> >>>>> Increase ADC reference clock from 3MHz to 24MHz so that the
> >>>>> sampling rates goes up from 100K samples per second to 800K
> >>>>> samples per second on AM335x and AM437x SoC.
> >>>>>
> >>>>> Also increase opendelay for touchscreen configuration to
> >>>>> equalize the increase in ADC reference clock frequency,
> >>>>> which results in the same amount touch events reported via
> >>>>> evtest on AM335x GP EVM.
> >>>>>
> >>>>> Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> >>>>> ---
> >>>>>
> >>>>> This patch depends on ADC DMA patch series [1]
> >>>>>
> >>>>> Without DMA support, when ADC ref clock is set at 24MHz, I am
> >>>>> seeing fifo overflow as CPU is not able to pull the ADC samples.
> >>>>> This answers that DMA support is must for ADC to consume the
> >>>>> samples generated at 24MHz with no open, step delay or
> >>>>> averaging with patch [2].
> >>>>>
> >>>>> Measured the performance with the iio_generic_buffer with the
> >>>>> patch [3] applied
> >>>>>
> >>>>> [1] - http://www.spinics.net/lists/devicetree/msg145045.html
> >>>>> [2] - http://pastebin.ubuntu.com/23357935/
> >>>>> [3] - http://pastebin.ubuntu.com/23357939/
> >>>>>
> >>>>> ---
> >>>>> include/linux/mfd/ti_am335x_tscadc.h | 4 ++--
> >>>>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/include/linux/mfd/ti_am335x_tscadc.h b/include/linux/mfd/ti_am335x_tscadc.h
> >>>>> index b9a53e0..96c4207 100644
> >>>>> --- a/include/linux/mfd/ti_am335x_tscadc.h
> >>>>> +++ b/include/linux/mfd/ti_am335x_tscadc.h
> >>>>> @@ -90,7 +90,7 @@
> >>>>> /* Delay register */
> >>>>> #define STEPDELAY_OPEN_MASK (0x3FFFF << 0)
> >>>>> #define STEPDELAY_OPEN(val) ((val) << 0)
> >>>>> -#define STEPCONFIG_OPENDLY STEPDELAY_OPEN(0x098)
> >>> Wouldn?t this be better to add this to the devicetree?
> >>>
> >>> ti,chan-step-avg = <0x16 0x16 0x16 0x16 0x16 0x16 0x16>;
> >>> ti,chan-step-opendelay = <0x500 0x500 0x500 0x500 0x500 0x500 0x500>;
> >>> ti,chan-step-sampledelay = <0x0 0x0 0x0 0x0 0x0 0x0 0x0>;
> >>
> >> For a touch screen, there is not need to change in these parameter
> >> settings, so my opinion is to keep it as is. Or am I missing something?
> > I was thinking that if you are using this driver as an ADC, you may want the flexibility to make these changes in the DT. I?m doing this by connecting sensors to the ADC inputs. I?m not using this driver for a touchscreen.
>
> Here is a DT overlay were this gets using on the BeagleBoneBlack.
>
> https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts
>
> Besides, these DT features are already implemented in the driver so it is just a matter of adding these entries to the am33xx.dtsi & am4372.dtsi, which you modified in this patch series.
This looks like configuration, no?
DT should be used to describe the hardware.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH 3/4] iommu/arm-smmu: Add context save restore support
From: Sricharan @ 2016-10-25 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkxumkKodObeH9N4KGecsWYpwEo1DfR1WrBctzRY-ESFrg@mail.gmail.com>
Hi,
>> The smes registers and the context bank registers are
>> back. The data required to configure the context banks
>> are the master's domain data and pgtable cfgs.
>> So store them as a part of the context banks info
>> the ones that are needs to be saved and restored.
>> Fortunately the smes are already stored as a part
>> of the smmu device structure. So just write that
>> and just reconfigure the context banks on the restore
>> path.
>>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>> drivers/iommu/arm-smmu.c | 52 +++++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 51 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 45f2762..578cdc2 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -328,6 +328,11 @@ struct arm_smmu_master_cfg {
>> #define for_each_cfg_sme(fw, i, idx) \
>> for (i = 0; idx = __fwspec_cfg(fw)->smendx[i], i < fw->num_ids; ++i)
>>
>> +struct cbinfo {
>> + struct arm_smmu_domain *domain;
>> + struct io_pgtable_cfg pgtbl_cfg;
>> +};
>> +
>> struct arm_smmu_device {
>> struct device *dev;
>>
>> @@ -378,6 +383,9 @@ struct arm_smmu_device {
>> struct clk **clocks;
>>
>> u32 cavium_id_base; /* Specific to Cavium */
>> +
>> + /* For save/restore of context bank registers */
>> + struct cbinfo *cb_saved_ctx;
>
>It's not that clear to me this will become an array - better
>documentation would help reviewing the code.
ok, will add the doc for this.
>
>> };
>>
>> enum arm_smmu_context_fmt {
>> @@ -972,6 +980,8 @@ static int arm_smmu_init_domain_context(struct iommu_domain *domain,
>>
>> /* Initialise the context bank with our page table cfg */
>> arm_smmu_init_context_bank(smmu_domain, &pgtbl_cfg);
>> + smmu->cb_saved_ctx[cfg->cbndx].domain = smmu_domain;
>> + smmu->cb_saved_ctx[cfg->cbndx].pgtbl_cfg = pgtbl_cfg;
>>
>> /*
>> * Request context fault interrupt. Do this last to avoid the
>> @@ -1861,6 +1871,10 @@ static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
>> }
>> dev_notice(smmu->dev, "\t%u context banks (%u stage-2 only)\n",
>> smmu->num_context_banks, smmu->num_s2_context_banks);
>> +
>> + smmu->cb_saved_ctx = devm_kzalloc(smmu->dev,
>> + sizeof(struct cbinfo) * smmu->num_context_banks,
>> + GFP_KERNEL);
>> /*
>> * Cavium CN88xx erratum #27704.
>> * Ensure ASID and VMID allocation is unique across all SMMUs in
>> @@ -2115,8 +2129,44 @@ static int arm_smmu_resume(struct device *dev)
>> {
>> struct platform_device *pdev = to_platform_device(dev);
>> struct arm_smmu_device *smmu = platform_get_drvdata(pdev);
>> + struct arm_smmu_domain *domain = NULL;
>> + struct io_pgtable_cfg *pgtbl_cfg = NULL;
>> + struct arm_smmu_smr *smrs = smmu->smrs;
>> + int i = 0, idx, cb, ret, pcb = 0;
>> +
>> + ret = arm_smmu_enable_clocks(smmu);
>> + if (ret)
>> + return ret;
>> +
>> + arm_smmu_device_reset(smmu);
>>
>> - return arm_smmu_enable_clocks(smmu);
>> + /* Restore the smes and the context banks */
>> + for (idx = 0; idx < smmu->num_mapping_groups; ++idx) {
>> + mutex_lock(&smmu->stream_map_mutex);
>> + if (!smrs[idx].valid) {
>> + mutex_unlock(&smmu->stream_map_mutex);
>> + continue;
>> + }
>> +
>> + arm_smmu_write_sme(smmu, idx);
>> + cb = smmu->s2crs[idx].cbndx;
>> + mutex_unlock(&smmu->stream_map_mutex);
>> +
>> + if (!i || (cb != pcb)) {
>> + domain = smmu->cb_saved_ctx[cb].domain;
>> + pgtbl_cfg = &smmu->cb_saved_ctx[cb].pgtbl_cfg;
>> +
>> + if (domain) {
>> + mutex_lock(&domain->init_mutex);
>> + arm_smmu_init_context_bank(domain, pgtbl_cfg);
>> + mutex_unlock(&domain->init_mutex);
>> + }
>> + }
>> + pcb = cb;
>> + i++;
>
>What are you doing with variable 'i'? Again, some comments would
>greatly help with reviewing.
hmm, i was using variable 'i' to pass through the 'if' first time
even if cb != pcb, because pcb is uninitialized at that point.
But i could just initialize 'pcb' with some -EINVAL and then
avoid the extra 'i' itself. Also check for cb != pcb was required
because same context bank could be populated multiple times
for different sids in sequence. I will document these and send V2.
Thanks for your time to review this.
Regards,
Sricharan
^ permalink raw reply
* [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2
From: Daniel Vetter @ 2016-10-25 6:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8afc5e020c5767face34fe3a9ab300ce9e67ba00.1477142934.git.moinejf@free.fr>
On Fri, Oct 21, 2016 at 09:26:18AM +0200, Jean-Francois Moine wrote:
> +static int de2_drm_bind(struct device *dev)
> +{
> + struct drm_device *drm;
> + struct priv *priv;
> + int ret;
> +
> + drm = drm_dev_alloc(&de2_drm_driver, dev);
> + if (!drm)
> + return -ENOMEM;
> +
> + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> + if (!priv) {
> + dev_err(dev, "failed to allocate private area\n");
> + ret = -ENOMEM;
> + goto out1;
> + }
> +
> + dev_set_drvdata(dev, drm);
> + drm->dev_private = priv;
> +
> + drm_mode_config_init(drm);
> + drm->mode_config.min_width = 32; /* needed for cursor */
> + drm->mode_config.min_height = 32;
> + drm->mode_config.max_width = 1920;
> + drm->mode_config.max_height = 1080;
> + drm->mode_config.funcs = &de2_mode_config_funcs;
> +
> + drm->irq_enabled = true;
> +
> + /* initialize the display engine */
> + priv->soc_type = (int) of_match_device(de2_drm_of_match, dev)->data;
> + ret = de2_de_init(priv, dev);
> + if (ret)
> + goto out2;
> +
> + /* start the subdevices */
> + ret = component_bind_all(dev, drm);
> + if (ret < 0)
> + goto out2;
> +
> + ret = drm_dev_register(drm, 0);
This needs to be the very last step in your driver load sequence.
Kerneldoc explains why. Similar, but inverted for unloading:
drm_dev_unregister is the very first thing you must call.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2
From: Daniel Vetter @ 2016-10-25 6:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161025064422.4jua6qmpr7zu3ijt@phenom.ffwll.local>
On Tue, Oct 25, 2016 at 08:44:22AM +0200, Daniel Vetter wrote:
> On Fri, Oct 21, 2016 at 09:26:18AM +0200, Jean-Francois Moine wrote:
> > +static int de2_drm_bind(struct device *dev)
> > +{
> > + struct drm_device *drm;
> > + struct priv *priv;
> > + int ret;
> > +
> > + drm = drm_dev_alloc(&de2_drm_driver, dev);
Oh and you might want to look into drm_dev_init, allows you to use
subclassing instead of pointer chasing for your driver-private data.
-Daniel
> > + if (!drm)
> > + return -ENOMEM;
> > +
> > + priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> > + if (!priv) {
> > + dev_err(dev, "failed to allocate private area\n");
> > + ret = -ENOMEM;
> > + goto out1;
> > + }
> > +
> > + dev_set_drvdata(dev, drm);
> > + drm->dev_private = priv;
> > +
> > + drm_mode_config_init(drm);
> > + drm->mode_config.min_width = 32; /* needed for cursor */
> > + drm->mode_config.min_height = 32;
> > + drm->mode_config.max_width = 1920;
> > + drm->mode_config.max_height = 1080;
> > + drm->mode_config.funcs = &de2_mode_config_funcs;
> > +
> > + drm->irq_enabled = true;
> > +
> > + /* initialize the display engine */
> > + priv->soc_type = (int) of_match_device(de2_drm_of_match, dev)->data;
> > + ret = de2_de_init(priv, dev);
> > + if (ret)
> > + goto out2;
> > +
> > + /* start the subdevices */
> > + ret = component_bind_all(dev, drm);
> > + if (ret < 0)
> > + goto out2;
> > +
> > + ret = drm_dev_register(drm, 0);
>
> This needs to be the very last step in your driver load sequence.
> Kerneldoc explains why. Similar, but inverted for unloading:
> drm_dev_unregister is the very first thing you must call.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ 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