* [PATCH v3 2/4] ARM: Define KERNEL_START and KERNEL_END
From: Florian Fainelli @ 2016-12-09 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209233628.6642-1-f.fainelli@gmail.com>
In preparation for adding CONFIG_DEBUG_VIRTUAL support, define a set of
common constants: KERNEL_START and KERNEL_END which abstract
CONFIG_XIP_KERNEL vs. !CONFIG_XIP_KERNEL. Update the code where
relevant.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/include/asm/memory.h | 7 +++++++
arch/arm/mm/init.c | 7 ++-----
arch/arm/mm/mmu.c | 6 +-----
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
index 76cbd9c674df..bee7511c5098 100644
--- a/arch/arm/include/asm/memory.h
+++ b/arch/arm/include/asm/memory.h
@@ -111,6 +111,13 @@
#endif /* !CONFIG_MMU */
+#ifdef CONFIG_XIP_KERNEL
+#define KERNEL_START _sdata
+#else
+#define KERNEL_START _stext
+#endif
+#define KERNEL_END _end
+
/*
* We fix the TCM memories max 32 KiB ITCM resp DTCM at these
* locations
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 370581aeb871..c87d0d5b65f2 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -230,11 +230,8 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t size, phys_addr_t align)
void __init arm_memblock_init(const struct machine_desc *mdesc)
{
/* Register the kernel text, kernel data and initrd with memblock. */
-#ifdef CONFIG_XIP_KERNEL
- memblock_reserve(__pa(_sdata), _end - _sdata);
-#else
- memblock_reserve(__pa(_stext), _end - _stext);
-#endif
+ memblock_reserve(__pa(KERNEL_START), _end - KERNEL_START);
+
#ifdef CONFIG_BLK_DEV_INITRD
/* FDT scan will populate initrd_start */
if (initrd_start && !phys_initrd_size) {
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 4001dd15818d..f0fd1a2db036 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -1437,11 +1437,7 @@ static void __init kmap_init(void)
static void __init map_lowmem(void)
{
struct memblock_region *reg;
-#ifdef CONFIG_XIP_KERNEL
- phys_addr_t kernel_x_start = round_down(__pa(_sdata), SECTION_SIZE);
-#else
- phys_addr_t kernel_x_start = round_down(__pa(_stext), SECTION_SIZE);
-#endif
+ phys_addr_t kernel_x_start = round_down(__pa(KERNEL_START), SECTION_SIZE);
phys_addr_t kernel_x_end = round_up(__pa(__init_end), SECTION_SIZE);
/* Map all the lowmem memory banks. */
--
2.9.3
^ permalink raw reply related
* [PATCH v3 1/4] mtd: lart: Rename partition defines to be prefixed with PART_
From: Florian Fainelli @ 2016-12-09 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209233628.6642-1-f.fainelli@gmail.com>
In preparation for defining KERNEL_START on ARM, rename KERNEL_START to
PART_KERNEL_START, and to be consistent, do this for all
partition-related constants.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
---
drivers/mtd/devices/lart.c | 24 ++++++++++++------------
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/devices/lart.c b/drivers/mtd/devices/lart.c
index 82bd00af5cc3..268aae45b514 100644
--- a/drivers/mtd/devices/lart.c
+++ b/drivers/mtd/devices/lart.c
@@ -75,18 +75,18 @@ static char module_name[] = "lart";
/* blob */
#define NUM_BLOB_BLOCKS FLASH_NUMBLOCKS_16m_PARAM
-#define BLOB_START 0x00000000
-#define BLOB_LEN (NUM_BLOB_BLOCKS * FLASH_BLOCKSIZE_PARAM)
+#define PART_BLOB_START 0x00000000
+#define PART_BLOB_LEN (NUM_BLOB_BLOCKS * FLASH_BLOCKSIZE_PARAM)
/* kernel */
#define NUM_KERNEL_BLOCKS 7
-#define KERNEL_START (BLOB_START + BLOB_LEN)
-#define KERNEL_LEN (NUM_KERNEL_BLOCKS * FLASH_BLOCKSIZE_MAIN)
+#define PART_KERNEL_START (PART_BLOB_START + PART_BLOB_LEN)
+#define PART_KERNEL_LEN (NUM_KERNEL_BLOCKS * FLASH_BLOCKSIZE_MAIN)
/* initial ramdisk */
#define NUM_INITRD_BLOCKS 24
-#define INITRD_START (KERNEL_START + KERNEL_LEN)
-#define INITRD_LEN (NUM_INITRD_BLOCKS * FLASH_BLOCKSIZE_MAIN)
+#define PART_INITRD_START (PART_KERNEL_START + PART_KERNEL_LEN)
+#define PART_INITRD_LEN (NUM_INITRD_BLOCKS * FLASH_BLOCKSIZE_MAIN)
/*
* See section 4.0 in "3 Volt Fast Boot Block Flash Memory" Intel Datasheet
@@ -587,20 +587,20 @@ static struct mtd_partition lart_partitions[] = {
/* blob */
{
.name = "blob",
- .offset = BLOB_START,
- .size = BLOB_LEN,
+ .offset = PART_BLOB_START,
+ .size = PART_BLOB_LEN,
},
/* kernel */
{
.name = "kernel",
- .offset = KERNEL_START, /* MTDPART_OFS_APPEND */
- .size = KERNEL_LEN,
+ .offset = PART_KERNEL_START, /* MTDPART_OFS_APPEND */
+ .size = PART_KERNEL_LEN,
},
/* initial ramdisk / file system */
{
.name = "file system",
- .offset = INITRD_START, /* MTDPART_OFS_APPEND */
- .size = INITRD_LEN, /* MTDPART_SIZ_FULL */
+ .offset = PART_INITRD_START, /* MTDPART_OFS_APPEND */
+ .size = PART_INITRD_LEN, /* MTDPART_SIZ_FULL */
}
};
#define NUM_PARTITIONS ARRAY_SIZE(lart_partitions)
--
2.9.3
^ permalink raw reply related
* [PATCH v3 0/4] ARM: Add support for CONFIG_DEBUG_VIRTUAL
From: Florian Fainelli @ 2016-12-09 23:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161208185933.13749-1-f.fainelli@gmail.com>
This patch series builds on top of Laura's [PATCHv5 00/10] CONFIG_DEBUG_VIRTUAL
for arm64 to add support for CONFIG_DEBUG_VIRTUAL for ARM.
This was tested on a Brahma B15 platform (ARMv7 + HIGHMEM + LPAE).
Note that the treewide changes would involve a huge CC list, which
is why it has been purposely trimmed to just focusing on the DEBUG_VIRTUAL
aspect.
Changes in v3:
- fix build failures reported by Kbuild test robot
Changes in v2:
- Modified MTD LART driver not to create symbol conflicts with
KERNEL_START
- Fixed patch that defines and uses KERNEL_START/END
- Fixed __pa_symbol()'s definition
- Inline __pa_symbol() check wihtin the VIRTUAL_BUG_ON statement
- Simplified check for virtual addresses
- Added a tree-wide patch changing SMP/PM implementations to use
__pa_symbol(), build tested against multi_v{5,7}_defconfig
Thanks!
Florian Fainelli (4):
mtd: lart: Rename partition defines to be prefixed with PART_
ARM: Define KERNEL_START and KERNEL_END
ARM: Add support for CONFIG_DEBUG_VIRTUAL
ARM: treewide: Replace uses of virt_to_phys with __pa_symbol
arch/arm/Kconfig | 1 +
arch/arm/boot/compressed/piggy.xzkern | Bin 0 -> 2998584 bytes
arch/arm/common/mcpm_entry.c | 12 +++----
arch/arm/include/asm/memory.h | 23 ++++++++++++--
arch/arm/mach-alpine/platsmp.c | 2 +-
arch/arm/mach-axxia/platsmp.c | 2 +-
arch/arm/mach-bcm/bcm63xx_smp.c | 2 +-
arch/arm/mach-bcm/platsmp-brcmstb.c | 2 +-
arch/arm/mach-bcm/platsmp.c | 4 +--
arch/arm/mach-berlin/platsmp.c | 2 +-
arch/arm/mach-exynos/firmware.c | 4 +--
arch/arm/mach-exynos/mcpm-exynos.c | 2 +-
arch/arm/mach-exynos/platsmp.c | 4 +--
arch/arm/mach-exynos/pm.c | 6 ++--
arch/arm/mach-exynos/suspend.c | 6 ++--
arch/arm/mach-hisi/platmcpm.c | 2 +-
arch/arm/mach-hisi/platsmp.c | 6 ++--
arch/arm/mach-imx/platsmp.c | 2 +-
arch/arm/mach-imx/pm-imx6.c | 2 +-
arch/arm/mach-imx/src.c | 2 +-
arch/arm/mach-mediatek/platsmp.c | 2 +-
arch/arm/mach-mvebu/pm.c | 2 +-
arch/arm/mach-mvebu/pmsu.c | 2 +-
arch/arm/mach-mvebu/system-controller.c | 2 +-
arch/arm/mach-omap2/control.c | 8 ++---
arch/arm/mach-omap2/omap-mpuss-lowpower.c | 8 ++---
arch/arm/mach-omap2/omap-smp.c | 4 +--
arch/arm/mach-prima2/platsmp.c | 2 +-
arch/arm/mach-prima2/pm.c | 2 +-
arch/arm/mach-pxa/palmz72.c | 2 +-
arch/arm/mach-pxa/pxa25x.c | 2 +-
arch/arm/mach-pxa/pxa27x.c | 2 +-
arch/arm/mach-pxa/pxa3xx.c | 2 +-
arch/arm/mach-realview/platsmp-dt.c | 2 +-
arch/arm/mach-rockchip/platsmp.c | 4 +--
arch/arm/mach-rockchip/pm.c | 2 +-
arch/arm/mach-s3c24xx/mach-jive.c | 2 +-
arch/arm/mach-s3c24xx/pm-s3c2410.c | 2 +-
arch/arm/mach-s3c24xx/pm-s3c2416.c | 2 +-
arch/arm/mach-s3c64xx/pm.c | 2 +-
arch/arm/mach-s5pv210/pm.c | 2 +-
arch/arm/mach-sa1100/pm.c | 2 +-
arch/arm/mach-shmobile/platsmp-apmu.c | 6 ++--
arch/arm/mach-shmobile/platsmp-scu.c | 4 +--
arch/arm/mach-socfpga/platsmp.c | 4 +--
arch/arm/mach-spear/platsmp.c | 2 +-
arch/arm/mach-sti/platsmp.c | 2 +-
arch/arm/mach-sunxi/platsmp.c | 4 +--
arch/arm/mach-tango/platsmp.c | 2 +-
arch/arm/mach-tango/pm.c | 2 +-
arch/arm/mach-tegra/reset.c | 4 +--
arch/arm/mach-ux500/platsmp.c | 2 +-
arch/arm/mach-vexpress/dcscb.c | 2 +-
arch/arm/mach-vexpress/platsmp.c | 2 +-
arch/arm/mach-vexpress/tc2_pm.c | 4 +--
arch/arm/mach-zx/platsmp.c | 4 +--
arch/arm/mach-zynq/platsmp.c | 2 +-
arch/arm/mm/Makefile | 1 +
arch/arm/mm/init.c | 7 ++--
arch/arm/mm/mmu.c | 6 +---
arch/arm/mm/physaddr.c | 51 ++++++++++++++++++++++++++++++
drivers/mtd/devices/lart.c | 24 +++++++-------
62 files changed, 173 insertions(+), 108 deletions(-)
create mode 100644 arch/arm/boot/compressed/piggy.xzkern
create mode 100644 arch/arm/mm/physaddr.c
--
2.9.3
^ permalink raw reply
* [PATCH] usb: dwc3: omap: remove devm_request_threaded_irq
From: Grygorii Strashko @ 2016-12-09 23:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209230457.GO4920@atomide.com>
On 12/09/2016 05:04 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko@ti.com> [161209 14:46]:
>>
>>
>> On 12/09/2016 03:59 PM, Tony Lindgren wrote:
>>> * Grygorii Strashko <grygorii.strashko@ti.com> [161209 12:55]:
>>>> Switch back from devm_request_threaded_irq() to request_threaded_irq() to
>>>> avoid races between interrupt handler execution and PM runtime in error
>>>> handling code path in probe and in dwc3_omap_remove():
>>>
>>> Can't you just call disable_irq() on the exit path instead of removing
>>> devm?
>>>
>>
>> I can. But what will be the benefit from using devm then?
>
> Hmm good point. Probably the least number of code would be to just
> do NOAUTOEN before devm_request_irq(), then only do enable_irq()
> just before returning from the probe. After all, we don't really
> want the irq running until the probe is done.
>
> I think that would leave out the extra handling from the error
> path?
>
Good question here is - do we need this irq to be enabled for sub-device
probing from of_platform_populate()? ;)
--
regards,
-grygorii
^ permalink raw reply
* [PATCH] usb: dwc3: omap: remove devm_request_threaded_irq
From: Tony Lindgren @ 2016-12-09 23:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <db75608b-f92c-6bfa-80a9-a3ab3adf7c23@ti.com>
* Grygorii Strashko <grygorii.strashko@ti.com> [161209 14:46]:
>
>
> On 12/09/2016 03:59 PM, Tony Lindgren wrote:
> > * Grygorii Strashko <grygorii.strashko@ti.com> [161209 12:55]:
> > > Switch back from devm_request_threaded_irq() to request_threaded_irq() to
> > > avoid races between interrupt handler execution and PM runtime in error
> > > handling code path in probe and in dwc3_omap_remove():
> >
> > Can't you just call disable_irq() on the exit path instead of removing
> > devm?
> >
>
> I can. But what will be the benefit from using devm then?
Hmm good point. Probably the least number of code would be to just
do NOAUTOEN before devm_request_irq(), then only do enable_irq()
just before returning from the probe. After all, we don't really
want the irq running until the probe is done.
I think that would leave out the extra handling from the error
path?
Regards,
Tony
^ permalink raw reply
* [PATCH v3 2/6] mfd: dt: ranges, #address-cells and #size-cells as optional properties
From: Andrew Jeffery @ 2016-12-09 22:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209224927.3indhfdjgyndtjid@rob-hp-laptop>
On Fri, 2016-12-09 at 16:49 -0600, Rob Herring wrote:
> On Tue, Dec 06, 2016 at 01:53:17PM +1100, Andrew Jeffery wrote:
> > Whilst describing a device and not a bus, simple-mfd is modelled on
> > simple-bus where child nodes are iterated and registered as platform
> > devices. Some complex devices, e.g. the Aspeed LPC controller, can
> > benefit from address space mapping such that child nodes can use the
> > regs property to describe their resources within the multi-function
> > device.
> >
> > > > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> > ---
> > ?Documentation/devicetree/bindings/mfd/mfd.txt | 10 ++++++++++
> > ?1 file changed, 10 insertions(+)
>
> No objections to this, but this is all implied by having a reg property.
Thanks for clarifying. I wasn't sure so I wrote the patch with the
thought that we could drop it if it wasn't necessary. Regardless, I
think being explicit about the properties is nice.
>
> Acked-by: Rob Herring <robh@kernel.org>
Thanks,
Andrew
>
> Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161210/2a6b2791/attachment.sig>
^ permalink raw reply
* [PATCH v3 2/6] mfd: dt: ranges, #address-cells and #size-cells as optional properties
From: Rob Herring @ 2016-12-09 22:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206025321.1792-3-andrew@aj.id.au>
On Tue, Dec 06, 2016 at 01:53:17PM +1100, Andrew Jeffery wrote:
> Whilst describing a device and not a bus, simple-mfd is modelled on
> simple-bus where child nodes are iterated and registered as platform
> devices. Some complex devices, e.g. the Aspeed LPC controller, can
> benefit from address space mapping such that child nodes can use the
> regs property to describe their resources within the multi-function
> device.
>
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Documentation/devicetree/bindings/mfd/mfd.txt | 10 ++++++++++
> 1 file changed, 10 insertions(+)
No objections to this, but this is all implied by having a reg property.
Acked-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* [PATCH] usb: dwc3: omap: remove devm_request_threaded_irq
From: Grygorii Strashko @ 2016-12-09 22:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209215958.GN4920@atomide.com>
On 12/09/2016 03:59 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko@ti.com> [161209 12:55]:
>> Switch back from devm_request_threaded_irq() to request_threaded_irq() to
>> avoid races between interrupt handler execution and PM runtime in error
>> handling code path in probe and in dwc3_omap_remove():
>
> Can't you just call disable_irq() on the exit path instead of removing
> devm?
>
I can. But what will be the benefit from using devm then?
--
regards,
-grygorii
^ permalink raw reply
* [PATCH v3 1/6] mfd: dt: Fix "indicates" typo in mfd bindings document
From: Rob Herring @ 2016-12-09 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161206025321.1792-2-andrew@aj.id.au>
On Tue, Dec 06, 2016 at 01:53:16PM +1100, Andrew Jeffery wrote:
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> Documentation/devicetree/bindings/mfd/mfd.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] usb: dwc3: omap: remove devm_request_threaded_irq
From: Tony Lindgren @ 2016-12-09 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209205508.6456-1-grygorii.strashko@ti.com>
* Grygorii Strashko <grygorii.strashko@ti.com> [161209 12:55]:
> Switch back from devm_request_threaded_irq() to request_threaded_irq() to
> avoid races between interrupt handler execution and PM runtime in error
> handling code path in probe and in dwc3_omap_remove():
Can't you just call disable_irq() on the exit path instead of removing
devm?
Regards,
Tony
^ permalink raw reply
* [PATCHv4 11/15] clk: ti: clockdomain: add clock provider support to clockdomains
From: Tony Lindgren @ 2016-12-09 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148131892585.16621.5033331614135070003@resonance>
* Michael Turquette <mturquette@baylibre.com> [161209 13:28]:
> Quoting Tony Lindgren (2016-12-09 12:40:16)
> > Yeah that's what we already have with hwmod and PM runtime for the
> > clockctrl register. But hwmod currently directly manages the clkctrl
> > register, we just want to move that part to be a clock driver.
> >
> > The children of the interconnect target modules just need to use
> > PM runtime, but the interconnect target module driver needs to know
> > it's clkctrl clock.
>
> OK, that sounds good to me but I'm not quite sure about the difference
> between "children of interconnect target modules" versus just the
> "interconnect target module".
The interconnect target module specific registers are "sysc", "syss"
and "revision". Those are usually stuffed to random addresses, and
currently managed by hwmod. Each interconnect target module has a
module gate clock "clkctrl" in some clockdomain. Each clockdomain
has multiple similar "clckctrl" clocks.
> Can you give an example on each? I just want to understand for my own
> curiosity.
For example, musb on am335x has these as children of a single
interconnect target module:
- Two instances of musb wrapper IP
- Two instances of musb IP
- One instance of CPP41 DMA
The on omap4, the whole system control module is just a single
interconnect target module with tens of devices in it like padconf,
clocks, pbias regulator and whatever random devices.
> > I don't think the clockdomain should be a genpd provider because
> > that creates a genpd network of dependencies instead of a tree
> > structure. If we end up setting the clockdomains with genpd, then
> > only the other clockdomains should use them, but I don't know how
> > we ever keep drivers from directly tinkering with them..
>
> Genpd is set up as an arbitrary graph, not strictly a tree, so these
> types of dependencies should be OK.
Well maybe that works then, worth checking for sure.
Regards,
Tony
^ permalink raw reply
* [PATCH] net: mlx5: Fix Kconfig help text
From: Christopher Covington @ 2016-12-09 21:53 UTC (permalink / raw)
To: linux-arm-kernel
Since the following commit, Infiniband and Ethernet have not been
mutually exclusive.
Fixes: 4aa17b28 mlx5: Enable mutual support for IB and Ethernet
Signed-off-by: Christopher Covington <cov@codeaurora.org>
---
drivers/net/ethernet/mellanox/mlx5/core/Kconfig | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
index aae4688..521cfdb 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
+++ b/drivers/net/ethernet/mellanox/mlx5/core/Kconfig
@@ -18,8 +18,6 @@ config MLX5_CORE_EN
default n
---help---
Ethernet support in Mellanox Technologies ConnectX-4 NIC.
- Ethernet and Infiniband support in ConnectX-4 are currently mutually
- exclusive.
config MLX5_CORE_EN_DCB
bool "Data Center Bridging (DCB) Support"
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora
Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 1/3] dt: pwm: lpc32xx: add description of clocks and #pwm-cells properties
From: Rob Herring @ 2016-12-09 21:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205014237.1689-2-vz@mleia.com>
On Mon, Dec 05, 2016 at 03:42:37AM +0200, Vladimir Zapolskiy wrote:
> NXP LPC32xx SoCs have two simple independent PWM controllers with a single
> output each, in this case there is no need to specify PWM channel argument
> on client side, one cell for setting PWM output frequency is sufficient.
>
> Another added to the description property 'clocks' has a standard meaning
> of a controller supply clock, in the LPC32xx User's Manual the clock is
> denoted as PWM1_CLK or PWM2_CLK clock.
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> ---
> Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt b/Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt
> index 74b5bc5..523d796 100644
> --- a/Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt
> +++ b/Documentation/devicetree/bindings/pwm/lpc32xx-pwm.txt
> @@ -3,15 +3,22 @@ LPC32XX PWM controller
> Required properties:
> - compatible: should be "nxp,lpc3220-pwm"
> - reg: physical base address and length of the controller's registers
> +- clocks: clock phandle and clock specifier pair
> +- #pwm-cells: should be 1, the cell is used to specify the period in
> + nanoseconds.
This use of the cell is a bit odd as the period is s/w config and this
would typically be a channel selection or such.
What if I want user specified/changed periods?
Rob
^ permalink raw reply
* [PATCH] dt: pwm: bcm2835: fix typo in clocks property name
From: Rob Herring @ 2016-12-09 21:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205001025.13909-1-vz@mleia.com>
On Mon, Dec 05, 2016 at 02:10:25AM +0200, Vladimir Zapolskiy wrote:
> According to the examples of BCM2835 PWM device nodes there is a typo in
> 'clocks' property name, which is a common property name on clock consumer
> side to store a phandle to an input clock.
>
> Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
> ---
> Documentation/devicetree/bindings/pwm/pwm-bcm2835.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
Rob
^ permalink raw reply
* [PATCH net-next v3 1/2] net: dt-bindings: add RGMII TX delay configuration to meson8b-dwmac
From: Rob Herring @ 2016-12-09 21:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161202233238.17561-2-martin.blumenstingl@googlemail.com>
On Sat, Dec 03, 2016 at 12:32:37AM +0100, Martin Blumenstingl wrote:
> This allows configuring the RGMII TX clock delay. The RGMII clock is
> generated by underlying hardware of the the Meson 8b / GXBB DWMAC glue.
> The configuration depends on the actual hardware (no delay may be
> needed due to the design of the actual circuit, the PHY might add this
> delay, etc.).
>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Tested-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/net/meson-dwmac.txt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCHv4 11/15] clk: ti: clockdomain: add clock provider support to clockdomains
From: Michael Turquette @ 2016-12-09 21:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209204015.GL4920@atomide.com>
Quoting Tony Lindgren (2016-12-09 12:40:16)
> * Michael Turquette <mturquette@baylibre.com> [161209 12:02]:
> > Quoting Tony Lindgren (2016-12-05 07:25:34)
> > > * Tero Kristo <t-kristo@ti.com> [161205 02:09]:
> ...
> <snip>
>
> > I had a recent conversation with Kevin Hilman about a related issue
> > (we were not discussing this thread or this series) and we both agreed
> > that most drivers don't even need to managed their clocks directly, so
> > much as they need to manage their on/off resources. Clocks are just one
> > part of that, and if we can hide that stuff inside of an attached genpd
> > then it would be better than having the driver manage clocks explicitly.
> >
> > Obviously some devices such as audio codec or uart will need to manage
> > clocks directly, but this is mostly the exception, not the rule.
>
> Yes. And we do that already for clkctrl clocks via PM runtime where
> hwmod manages them. Tero's series still has hwmod manage the clocks,
> but the clock register handling is moved to live under drivers/clock.
>
> > > > > > There is certainly no API for that in the clock framework, but for genpd
> > > > > > your runtime_pm_get() callback for clkdm_A could call runtime_pm_get
> > > > > > against clkdm_B, which would satisfy the requirement. See section
> > > > > > 3.1.1.1.7 Clock Domain Dependency in the OMAP4 TRM, version AB.
> > > >
> > > > For static dependencies the apis genpd_add/remove_subdomain could probably
> > > > be used.
> > > >
> > > > > To me it seems the API is just clk_get() :) Do you have some
> > > > > specific example we can use to check? My guess is that the
> > > > > TRM "Clock Domain Dependency" is just the usual parent child
> > > > > relationship between clocks that are the clockdomains..
> >
> > clk_get() only fetches a pointer to the clk. I guess you mean
> > clk_prepare_enable() to actually increment the use count?
>
> Right, with clocks that's all we should need to do :)
>
> > If we used the clk framework here is that it would look something like
> > this:
> >
> > clk_enable(clk_a)
> > -> .enable(clk_a_hw)
> > -> clk_enable(clk_b)
> >
> > However, clk_a and clk_b do not have a parent-child relationship in the
> > clock tree. This is purely a functional relationship between IP blocks.
> > Modeling this sort of thing in the clk framework would be wrong, and
> > genpd is a much better place to establish these arbitrary relationships.
>
> Hmm yes, and I don't mean the clock framework should do anything more
> complex beyond what it already does.
>
> We just want to represent the clocks as clocks, then have the
> interconnect code manage those clocks. That's currently hwmod, eventually
> it will be genpd.
>
> > > > > If there is something more magical there certainly that should
> > > > > be considered though.
> > > >
> > > > The hwmods could be transformed to individual genpds also I guess. On DT
> > > > level though, we would still need a clock pointer to the main clock and a
> > > > genpd pointer in addition to that.
> > >
> > > Hmm a genpd pointer to where exactly? AFAIK each interconnect
> > > instance should be a genpd provider, and the individual interconnect
> > > target modules should be consumers for that genpd.
> >
> > I was thinking that the clock domains would be modeled as genpd objects
> > with the interconnect target modules attached as struct devices.
>
> I think clock domains should be just clocks, then we let the interconnect
> code and eventually genpd manage them.
>
> > > > Tony, any thoughts on that? Would this break up the plans for the
> > > > interconnect completely?
> > >
> > > Does using genpd for clockdomains cause issues for using genpd for
> > > interconnect instances and the target modules?
> >
> > Can they be the same object in Linux? If there is a one-to-one mapping
> > between clock domains and the interconnect port then maybe you can just
> > model them together.
>
> I'm thinking that it should be the interconnect code implementing
> genpd, and use clk_request_enable().
>
> > > The thing I'd be worried about there is that the clockdomains and
> > > their child clocks are just devices sitting on the interconnect,
> > > so we could easily end up with genpd modeling something that does
> > > not represent the hardware.
> > >
> > > For example, on 4430 we have:
> > >
> > > l4_cfg interconnect
> > > ...
> > > segment at 0
> > > ...
> > > target_module at 4000
> > > cm1: cm1 at 0
> >
> > How about:
> >
> > l4_cfg interconnect
> > ...
> > segment at 0
> > ...
> > cm1 at 4000
> > module: foo_module at 0
>
> That's the wrong way around from hardware point of view. There's
> a generic interconnect wrapper module with it's own registers,
> then cm1 (and possibly other devices) are children of that target
> module.
>
> > I don't know much about the segments. Do they map one-to-one with the
> > clock domains?
>
> I need to check, it's been a while, but I recall some interconnects
> are partioned to segments based on voltages or clocks.
>
> > If my quick-and-dirty DT above makes sense, then the target modules
> > (e.g. io controller) would not get clocks anymore, but just
> > pm_runtime_get(). The genpd backing object would call clk_enable/disable
> > as needed.
>
> Yeah that's what we already have with hwmod and PM runtime for the
> clockctrl register. But hwmod currently directly manages the clkctrl
> register, we just want to move that part to be a clock driver.
>
> The children of the interconnect target modules just need to use
> PM runtime, but the interconnect target module driver needs to know
> it's clkctrl clock.
OK, that sounds good to me but I'm not quite sure about the difference
between "children of interconnect target modules" versus just the
"interconnect target module".
Can you give an example on each? I just want to understand for my own
curiosity.
>
> > If fine grained control of a clock is needed (e.g. for clk_set_rate)
> > then the driver can still clk_get it. Whether or not the clockdomain
> > provides that clock or if it comes from the clock generator (e.g. cm1,
> > cm2, prm, etc) isn't as important to me, but I prefer for the
> > clockdomain to not be a clock provider if possible.
>
> Yeah I totally agree with that, and that's already what we mostly
> have.
>
> > > I don't at least yet
> > > follow what we need to do with the clockdomains with genpd :)
> >
> > Use the clockdomain genpd to call clk_enable/disable under the hood.
> > Don't use them as clock providers to the target modules. Clockdomain
> > genpds would be the clock consumers.
>
> I don't think the clockdomain should be a genpd provider because
> that creates a genpd network of dependencies instead of a tree
> structure. If we end up setting the clockdomains with genpd, then
> only the other clockdomains should use them, but I don't know how
> we ever keep drivers from directly tinkering with them..
Genpd is set up as an arbitrary graph, not strictly a tree, so these
types of dependencies should be OK.
>
> IMO, the clockdomain clock driver should just provides clocks, then
> we can have the interconnect target module driver deal with the
> clockdomain dependencies.
>
> > > Wouldn't just doing clk_get() from one clockdomain clock to
> > > another clockdomain clock (or it's output) be enough to
> > > represent the clockdomain dependencies?
> >
> > s/clk_get/clk_prepare_enable/
> >
> > Yes, but you're stuffing functional dependencies into the clock tree,
> > which sucks. genpd was created to model these arbitrary dependencies.
>
> Well let's not stuff anything beyond clock framework to the
> clockdomain clock drivers. We already have the clockdomain
> dependencies handled by the interconnect code (hwmod), and there
> should be no problem moving those to be handled by genpd and the
> interconnect target driver instances.
>
> Care to take another look at Tero's patches with the assumption
> that the clockdomain clocks stay just as a clocks?
Sure.
Regards,
Mike
>
> Regards,
>
> Tony
^ permalink raw reply
* [PATCH v2 1/3] crypto: brcm: DT documentation for Broadcom SPU driver
From: Rob Herring @ 2016-12-09 21:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480714499-1476-2-git-send-email-rob.rice@broadcom.com>
On Fri, Dec 02, 2016 at 04:34:57PM -0500, Rob Rice wrote:
> Device tree documentation for Broadcom Secure Processing Unit
> (SPU) crypto driver.
>
> Signed-off-by: Steve Lin <steven.lin1@broadcom.com>
> Signed-off-by: Rob Rice <rob.rice@broadcom.com>
> ---
> .../devicetree/bindings/crypto/brcm,spu-crypto.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
>
> diff --git a/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
> new file mode 100644
> index 0000000..e5fe942
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/brcm,spu-crypto.txt
> @@ -0,0 +1,25 @@
> +The Broadcom Secure Processing Unit (SPU) driver supports symmetric
Bindings describe h/w, not drivers.
> +cryptographic offload for Broadcom SoCs with SPU hardware. A SoC may have
> +multiple SPU hardware blocks.
> +
> +Required properties:
> +- compatible : Should be "brcm,spum-crypto" for devices with SPU-M hardware
Additionally, you should have SoC specific compatible here.
> + (e.g., Northstar2) or "brcm,spum-nsp-crypto" for the Northstar Plus variant
> + of the SPU-M hardware.
> +
> +- reg: Should contain SPU registers location and length.
> +- mboxes: A list of mailbox channels to be used by the kernel driver. Mailbox
> +channels correspond to DMA rings on the device.
What determines the mbox assignment?
Needs to specify how many.
> +
> +Example:
> + spu-crypto at 612d0000 {
Just crypto at ...
Rob
^ permalink raw reply
* [PATCH 1/3] nvmem: imx-ocotp: Add support for i.MX6UL
From: Rob Herring @ 2016-12-09 21:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480689949-17957-1-git-send-email-d.schultz@phytec.de>
On Fri, Dec 02, 2016 at 03:45:47PM +0100, Daniel Schultz wrote:
> This patch adds OCOTP support for the i.MX6UL SoC.
>
> Signed-off-by: Daniel Schultz <d.schultz@phytec.de>
> ---
> Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 5 +++--
> drivers/nvmem/imx-ocotp.c | 1 +
> 2 files changed, 4 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [RESEND PATCH v2 5/7] drm/vc4: Document VEC DT binding
From: Rob Herring @ 2016-12-09 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480686493-4813-6-git-send-email-boris.brezillon@free-electrons.com>
On Fri, Dec 02, 2016 at 02:48:11PM +0100, Boris Brezillon wrote:
> Document the DT binding for the VEC (Video EnCoder) IP.
>
> Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
> ---
> Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v4] arm64: fpsimd: improve stacking logic in non-interruptible context
From: Ard Biesheuvel @ 2016-12-09 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161209192932.GD1574@e103592.cambridge.arm.com>
On 9 December 2016 at 19:29, Dave Martin <Dave.Martin@arm.com> wrote:
> On Fri, Dec 09, 2016 at 06:21:55PM +0000, Catalin Marinas wrote:
>> On Fri, Dec 09, 2016 at 04:46:32PM +0000, Ard Biesheuvel wrote:
>> > void kernel_neon_begin_partial(u32 num_regs)
>> > {
>> > - if (in_interrupt()) {
>> > - struct fpsimd_partial_state *s = this_cpu_ptr(
>> > - in_irq() ? &hardirq_fpsimdstate : &softirq_fpsimdstate);
>> > + struct fpsimd_partial_state *s;
>> > + int level;
>> > +
>> > + preempt_disable();
>> > +
>> > + level = this_cpu_inc_return(kernel_neon_nesting_level);
>> > + BUG_ON(level > 3);
>> > +
>> > + if (level > 1) {
>> > + s = this_cpu_ptr(nested_fpsimdstate);
>> >
>> > - BUG_ON(num_regs > 32);
>> > - fpsimd_save_partial_state(s, roundup(num_regs, 2));
>> > + WARN_ON_ONCE(num_regs > 32);
>> > + num_regs = min(roundup(num_regs, 2), 32U);
>> > +
>> > + fpsimd_save_partial_state(&s[level - 2], num_regs);
>> > } else {
>> > /*
>> > * Save the userland FPSIMD state if we have one and if we
>> > @@ -241,7 +256,6 @@ void kernel_neon_begin_partial(u32 num_regs)
>> > * that there is no longer userland FPSIMD state in the
>> > * registers.
>> > */
>> > - preempt_disable();
>> > if (current->mm &&
>> > !test_and_set_thread_flag(TIF_FOREIGN_FPSTATE))
>> > fpsimd_save_state(¤t->thread.fpsimd_state);
>>
>> I wonder whether we could actually do this saving and flag/level setting
>> in reverse to simplify the races. Something like your previous patch but
>> only set TIF_FOREIGN_FPSTATE after saving:
>>
>> level = this_cpu_read(kernel_neon_nesting_level);
>> if (level > 0) {
>> ...
>> fpsimd_save_partial_state();
>> } else {
>> if (!test_thread_flag(TIF_FOREIGN_FPSTATE))
>> fpsimd_save_state();
>> set_thread_flag(TIF_FOREIGN_FPSTATE);
>> }
>> this_cpu_inc(kernel_neon_nesting_level);
>>
>> There is a risk of extra saving if we get an interrupt after
>> test_thread_flag() and before set_thread_flag() but I don't think this
>> would corrupt any state, just writing things twice.
>
> I would worry that we can save two states over the same buffer and then
> restore an uninitialised buffer in this case unless we are careful.
> Because the level-dependent code is now misbracketed by the inc/dec,
> a preempting call races with the outer call and use the same value.
>
> I guess we could do
>
> if (!test_thread_flag(TIF_FOREIGN_FPSTATE))
> fpsimd_save_state();
> clear_thread_flag(TIF_FOREIGN_FPSTATE);
>
> at the start unconditionally, before the _inc_return().
>
> The task state may then get saved in the middle of being saved, but
> as you say it shouldn't have changed in the meantime.
It /will/ have changed in the meantime: when the interrupted context
is resumed, it will happily proceed with saving the state where it
left off, but now the register file contains whatever was left after
the interrupt handler is done with the NEON.
> The nested
> save code may then do a partial save of the same state on top of that
> which could get restored at the inner kernel_neon_end() call.
>
I'm afraid the only way to deal with this correctly is to treat the
whole sequence as a critical section, which means execute it with
interrupts disabled.
^ permalink raw reply
* [PATCH] usb: dwc3: omap: remove devm_request_threaded_irq
From: Grygorii Strashko @ 2016-12-09 20:55 UTC (permalink / raw)
To: linux-arm-kernel
Switch back from devm_request_threaded_irq() to request_threaded_irq() to
avoid races between interrupt handler execution and PM runtime in error
handling code path in probe and in dwc3_omap_remove():
in probe:
...
err1:
pm_runtime_put_sync(dev);
^^ PM runtime can race with IRQ handler when deferred probing happening
due to extcon
pm_runtime_disable(dev);
return ret;
in dwc3_omap_remove:
...
dwc3_omap_disable_irqs(omap);
^^ IRQs are disabled in HW, but handler may still run
of_platform_depopulate(omap->dev);
pm_runtime_put_sync(&pdev->dev);
^^ PM runtime can race with IRQ handler
pm_runtime_disable(&pdev->dev);
return 0;
So, OMAP DWC3 IRQ need to be disabled end freed before calling
pm_runtime_put() in probe and in dwc3_omap_remove().
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
Hi Tony,
This is reworked patch, so might be it need to be re-tested.
drivers/usb/dwc3/dwc3-omap.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 29e80cc..79d74f6 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -511,18 +511,18 @@ static int dwc3_omap_probe(struct platform_device *pdev)
/* check the DMA Status */
reg = dwc3_omap_readl(omap->base, USBOTGSS_SYSCONFIG);
- ret = devm_request_threaded_irq(dev, omap->irq, dwc3_omap_interrupt,
- dwc3_omap_interrupt_thread, IRQF_SHARED,
- "dwc3-omap", omap);
+ ret = request_threaded_irq(omap->irq, dwc3_omap_interrupt,
+ dwc3_omap_interrupt_thread, IRQF_SHARED,
+ "dwc3-omap", omap);
if (ret) {
dev_err(dev, "failed to request IRQ #%d --> %d\n",
omap->irq, ret);
- goto err1;
+ goto err11;
}
ret = dwc3_omap_extcon_register(omap);
if (ret < 0)
- goto err1;
+ goto err11;
ret = of_platform_populate(node, NULL, NULL, dev);
if (ret) {
@@ -538,6 +538,8 @@ static int dwc3_omap_probe(struct platform_device *pdev)
extcon_unregister_notifier(omap->edev, EXTCON_USB, &omap->vbus_nb);
extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, &omap->id_nb);
+err11:
+ free_irq(omap->irq, omap);
err1:
pm_runtime_put_sync(dev);
pm_runtime_disable(dev);
@@ -552,6 +554,7 @@ static int dwc3_omap_remove(struct platform_device *pdev)
extcon_unregister_notifier(omap->edev, EXTCON_USB, &omap->vbus_nb);
extcon_unregister_notifier(omap->edev, EXTCON_USB_HOST, &omap->id_nb);
dwc3_omap_disable_irqs(omap);
+ free_irq(omap->irq, omap);
of_platform_depopulate(omap->dev);
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
--
2.10.1
^ permalink raw reply related
* [PATCHv4 11/15] clk: ti: clockdomain: add clock provider support to clockdomains
From: Tony Lindgren @ 2016-12-09 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <148131376868.16621.16082839810419290638@resonance>
* Michael Turquette <mturquette@baylibre.com> [161209 12:02]:
> Quoting Tony Lindgren (2016-12-05 07:25:34)
> > * Tero Kristo <t-kristo@ti.com> [161205 02:09]:
...
<snip>
> I had a recent conversation with Kevin Hilman about a related issue
> (we were not discussing this thread or this series) and we both agreed
> that most drivers don't even need to managed their clocks directly, so
> much as they need to manage their on/off resources. Clocks are just one
> part of that, and if we can hide that stuff inside of an attached genpd
> then it would be better than having the driver manage clocks explicitly.
>
> Obviously some devices such as audio codec or uart will need to manage
> clocks directly, but this is mostly the exception, not the rule.
Yes. And we do that already for clkctrl clocks via PM runtime where
hwmod manages them. Tero's series still has hwmod manage the clocks,
but the clock register handling is moved to live under drivers/clock.
> > > > > There is certainly no API for that in the clock framework, but for genpd
> > > > > your runtime_pm_get() callback for clkdm_A could call runtime_pm_get
> > > > > against clkdm_B, which would satisfy the requirement. See section
> > > > > 3.1.1.1.7 Clock Domain Dependency in the OMAP4 TRM, version AB.
> > >
> > > For static dependencies the apis genpd_add/remove_subdomain could probably
> > > be used.
> > >
> > > > To me it seems the API is just clk_get() :) Do you have some
> > > > specific example we can use to check? My guess is that the
> > > > TRM "Clock Domain Dependency" is just the usual parent child
> > > > relationship between clocks that are the clockdomains..
>
> clk_get() only fetches a pointer to the clk. I guess you mean
> clk_prepare_enable() to actually increment the use count?
Right, with clocks that's all we should need to do :)
> If we used the clk framework here is that it would look something like
> this:
>
> clk_enable(clk_a)
> -> .enable(clk_a_hw)
> -> clk_enable(clk_b)
>
> However, clk_a and clk_b do not have a parent-child relationship in the
> clock tree. This is purely a functional relationship between IP blocks.
> Modeling this sort of thing in the clk framework would be wrong, and
> genpd is a much better place to establish these arbitrary relationships.
Hmm yes, and I don't mean the clock framework should do anything more
complex beyond what it already does.
We just want to represent the clocks as clocks, then have the
interconnect code manage those clocks. That's currently hwmod, eventually
it will be genpd.
> > > > If there is something more magical there certainly that should
> > > > be considered though.
> > >
> > > The hwmods could be transformed to individual genpds also I guess. On DT
> > > level though, we would still need a clock pointer to the main clock and a
> > > genpd pointer in addition to that.
> >
> > Hmm a genpd pointer to where exactly? AFAIK each interconnect
> > instance should be a genpd provider, and the individual interconnect
> > target modules should be consumers for that genpd.
>
> I was thinking that the clock domains would be modeled as genpd objects
> with the interconnect target modules attached as struct devices.
I think clock domains should be just clocks, then we let the interconnect
code and eventually genpd manage them.
> > > Tony, any thoughts on that? Would this break up the plans for the
> > > interconnect completely?
> >
> > Does using genpd for clockdomains cause issues for using genpd for
> > interconnect instances and the target modules?
>
> Can they be the same object in Linux? If there is a one-to-one mapping
> between clock domains and the interconnect port then maybe you can just
> model them together.
I'm thinking that it should be the interconnect code implementing
genpd, and use clk_request_enable().
> > The thing I'd be worried about there is that the clockdomains and
> > their child clocks are just devices sitting on the interconnect,
> > so we could easily end up with genpd modeling something that does
> > not represent the hardware.
> >
> > For example, on 4430 we have:
> >
> > l4_cfg interconnect
> > ...
> > segment at 0
> > ...
> > target_module at 4000
> > cm1: cm1 at 0
>
> How about:
>
> l4_cfg interconnect
> ...
> segment at 0
> ...
> cm1 at 4000
> module: foo_module at 0
That's the wrong way around from hardware point of view. There's
a generic interconnect wrapper module with it's own registers,
then cm1 (and possibly other devices) are children of that target
module.
> I don't know much about the segments. Do they map one-to-one with the
> clock domains?
I need to check, it's been a while, but I recall some interconnects
are partioned to segments based on voltages or clocks.
> If my quick-and-dirty DT above makes sense, then the target modules
> (e.g. io controller) would not get clocks anymore, but just
> pm_runtime_get(). The genpd backing object would call clk_enable/disable
> as needed.
Yeah that's what we already have with hwmod and PM runtime for the
clockctrl register. But hwmod currently directly manages the clkctrl
register, we just want to move that part to be a clock driver.
The children of the interconnect target modules just need to use
PM runtime, but the interconnect target module driver needs to know
it's clkctrl clock.
> If fine grained control of a clock is needed (e.g. for clk_set_rate)
> then the driver can still clk_get it. Whether or not the clockdomain
> provides that clock or if it comes from the clock generator (e.g. cm1,
> cm2, prm, etc) isn't as important to me, but I prefer for the
> clockdomain to not be a clock provider if possible.
Yeah I totally agree with that, and that's already what we mostly
have.
> > I don't at least yet
> > follow what we need to do with the clockdomains with genpd :)
>
> Use the clockdomain genpd to call clk_enable/disable under the hood.
> Don't use them as clock providers to the target modules. Clockdomain
> genpds would be the clock consumers.
I don't think the clockdomain should be a genpd provider because
that creates a genpd network of dependencies instead of a tree
structure. If we end up setting the clockdomains with genpd, then
only the other clockdomains should use them, but I don't know how
we ever keep drivers from directly tinkering with them..
IMO, the clockdomain clock driver should just provides clocks, then
we can have the interconnect target module driver deal with the
clockdomain dependencies.
> > Wouldn't just doing clk_get() from one clockdomain clock to
> > another clockdomain clock (or it's output) be enough to
> > represent the clockdomain dependencies?
>
> s/clk_get/clk_prepare_enable/
>
> Yes, but you're stuffing functional dependencies into the clock tree,
> which sucks. genpd was created to model these arbitrary dependencies.
Well let's not stuff anything beyond clock framework to the
clockdomain clock drivers. We already have the clockdomain
dependencies handled by the interconnect code (hwmod), and there
should be no problem moving those to be handled by genpd and the
interconnect target driver instances.
Care to take another look at Tero's patches with the assumption
that the clockdomain clocks stay just as a clocks?
Regards,
Tony
^ permalink raw reply
* [PATCH 1/3] clkdev: add devm_get_clk_from_child()
From: Russell King - ARM Linux @ 2016-12-09 20:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8737i3vtl7.wl%kuninori.morimoto.gx@renesas.com>
On Mon, Dec 05, 2016 at 05:23:20AM +0000, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> Some driver is using this type of DT bindings for clock (more detail,
> see ${LINUX}/Documentation/devicetree/bindings/sound/simple-card.txt).
>
> sound_soc {
> ...
> cpu {
> clocks = <&xxx>;
> ...
> };
> codec {
> clocks = <&xxx>;
> ...
> };
> };
>
> Current driver in this case uses of_clk_get() for each node, but there
> is no devm_of_clk_get() today.
> OTOH, the problem of having devm_of_clk_get() is that it encourages the
> use of of_clk_get() when clk_get() is more desirable.
>
> Thus, this patch adds new devm_get_clk_from_chile() which explicitly
> reads as get a clock from a child node of this device.
> By this function, we can also use this type of DT bindings
>
> sound_soc {
> clocks = <&xxx>, <&xxx>;
> clock-names = "cpu", "codec";
> ...
> cpu {
> ...
> };
> codec {
> ...
> };
> };
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
This looks lots better, thanks.
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH 4/4] ARM: versatile: support configuring versatile machine for no-MMU
From: Russell King - ARM Linux @ 2016-12-09 20:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58481DD1.6090606@arm.com>
On Wed, Dec 07, 2016 at 02:33:53PM +0000, Vladimir Murzin wrote:
> Hi Linus,
>
> On 07/12/16 14:11, Linus Walleij wrote:
> > Another target I had in mind was the Integrator which
> > incidentally supports a bunch of the old noMMU core
> > tiles where we can swap in an ARM946, which I guess
> > could work with this?
>
> Do you mind trying my "Allow NOMMU for MULTIPLATFORM" series [1]? Greg just
> reported it did a trick for Versatile, there is a good chance it would work
> for Integrator too ;)
My views on gluing multiplatform and nommu together have already been
stated several times, and remain unchanged.
Greg's patch looks almost sane, but what I'd like to see is instead of
directly doing this:
config ARCH_VERSATILE
bool "ARM Ltd. Versatile family"
- depends on ARCH_MULTI_V5
+ depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
we could do:
config ARCH_VERSATILE
bool "ARM Ltd. Versatile family" if ARCH_MULTI_V5
- depends on ARCH_MULTI_V5
+ depends on ARCH_MULTI_V5 || ARM_SINGLE_ARMV5
default y if ARM_SINGLE_ARCH_VERSATILE
adding the versatile entry in the upper level choice (where it always used
to be) but with "ARM_SINGLE_ARCH_VERSATILE" instead.
This would have the effect of allowing the multiplatform-converted stuff
to start being used on nommu (again) but without running into the problems
I've highlighted.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH v2 1/2] firmware: arm_scpi: zero RX buffer before requesting data from the mbox
From: Martin Blumenstingl @ 2016-12-09 20:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f544a379-a6a0-7839-85c3-a22449fecc46@arm.com>
On Wed, Dec 7, 2016 at 7:17 PM, Sudeep Holla <sudeep.holla@arm.com> wrote:
>
>
> On 25/11/16 00:54, Martin Blumenstingl wrote:
>> The original code was relying on the fact that the SCPI firmware
>> responds with the same number of bytes (or more, all extra data would be
>> ignored in that case) as requested.
>> However, we have some pre-v1.0 SCPI firmwares which are responding with
>> less data for some commands (sensor_value.hi_val did not exist in the
>> old implementation). This means that some data from the previous
>> command's RX buffer was leaked into the current command (as the RX
>> buffer is re-used for all commands on the same channel). Clearing the
>> RX buffer before (re-) using it ensures we get a consistent result, even
>> if the SCPI firmware returns less bytes than requested.
>>
>> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>> ---
>> drivers/firmware/arm_scpi.c | 19 ++++++++++++++++++-
>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/firmware/arm_scpi.c b/drivers/firmware/arm_scpi.c
>> index 70e1323..8c183d8 100644
>> --- a/drivers/firmware/arm_scpi.c
>> +++ b/drivers/firmware/arm_scpi.c
>> @@ -259,6 +259,7 @@ struct scpi_chan {
>> struct mbox_chan *chan;
>> void __iomem *tx_payload;
>> void __iomem *rx_payload;
>> + resource_size_t max_payload_len;
>> struct list_head rx_pending;
>> struct list_head xfers_list;
>> struct scpi_xfer *xfers;
>> @@ -470,6 +471,20 @@ static void scpi_tx_prepare(struct mbox_client *c, void *msg)
>> if (t->rx_buf) {
>> if (!(++ch->token))
>> ++ch->token;
>> +
>> + /* clear the RX buffer as it is shared across all commands on
>> + * the same channel (to make sure we're not leaking data from
>> + * the previous response into the current command if the SCPI
>> + * firmware writes less data than requested).
>> + * This is especially important for pre-v1.0 SCPI firmwares
>> + * where some fields in the responses do not exist (while they
>> + * exist but are optional in newer versions). One example for
>> + * this problem is sensor_value.hi_val, which would contain
>> + * ("leak") the second 4 bytes of the RX buffer from the
>> + * previous command.
>> + */
>> + memset_io(ch->rx_payload, 0, ch->max_payload_len);
>> +
>
> This looks like a overkill to me. I prefer your first approach over
> this, if it's only this command that's affected. I am still not sure
> why Neil Armstrong mentioned that it worked for him with 64-bit read.
OK, I'm fine with that. I also had a look at the patch you posted in
the cover-letter (I did not have time to test it yet though, I'll give
feedback tomorrow) - this looks better than my v1.
I think the explanation why it worked for Neil is pretty simple:
it depends on the SCPI command which was executed before the "read
sensor" command:
if that command returned [4 bytes with any value]0x00000000[any number
of bytes] then he got a valid result
^ 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