* [PATCH V2 03/10] of: irq: make of_msi_configure accessible from modules
From: Sinan Kaya @ 2016-09-12 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473685384-19913-1-git-send-email-okaya@codeaurora.org>
The of_msi_configure routine is only accessible by the built-in
kernel drivers. Export this function so that modules can use it
too.
This function is useful for configuring MSI on child device tree
nodes on hierarchical objects.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
drivers/of/irq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index a2e68f7..20c09e0 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -767,3 +767,4 @@ void of_msi_configure(struct device *dev, struct device_node *np)
dev_set_msi_domain(dev,
of_msi_get_domain(dev, np, DOMAIN_BUS_PLATFORM_MSI));
}
+EXPORT_SYMBOL_GPL(of_msi_configure);
--
1.9.1
^ permalink raw reply related
* [PATCH V2 02/10] Documentation: DT: qcom_hidma: correct spelling mistakes
From: Sinan Kaya @ 2016-09-12 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473685384-19913-1-git-send-email-okaya@codeaurora.org>
Fix the spelling mistakes and extra and statements in the sentences.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
index 47bfb5a..f99f642 100644
--- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -5,13 +5,13 @@ memcpy and memset capabilities. It has been designed for virtualized
environments.
Each HIDMA HW instance consists of multiple DMA channels. These channels
-share the same bandwidth. The bandwidth utilization can be parititioned
+share the same bandwidth. The bandwidth utilization can be partitioned
among channels based on the priority and weight assignments.
There are only two priority levels and 15 weigh assignments possible.
Other parameters here determine how much of the system bus this HIDMA
-instance can use like maximum read/write request and and number of bytes to
+instance can use like maximum read/write request and number of bytes to
read/write in a single burst.
Main node required properties:
--
1.9.1
^ permalink raw reply related
* [PATCH V2 01/10] Documentation: DT: qcom_hidma: update binding for MSI
From: Sinan Kaya @ 2016-09-12 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473685384-19913-1-git-send-email-okaya@codeaurora.org>
Adding a new binding for qcom,hidma-1.1 to distinguish HW supporting
MSI interrupts from the older revision.
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
---
Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
index fd5618b..47bfb5a 100644
--- a/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
+++ b/Documentation/devicetree/bindings/dma/qcom_hidma_mgmt.txt
@@ -47,12 +47,23 @@ When the OS is not in control of the management interface (i.e. it's a guest),
the channel nodes appear on their own, not under a management node.
Required properties:
-- compatible: must contain "qcom,hidma-1.0"
+- compatible: must contain "qcom,hidma-1.0" for initial HW or "qcom,hidma-1.1"
+for MSI capable HW.
- reg: Addresses for the transfer and event channel
- interrupts: Should contain the event interrupt
- desc-count: Number of asynchronous requests this channel can handle
- iommus: required a iommu node
+Optional properties for MSI:
+- msi-parent: pointer to the MSI controller object with the DeviceID in use.
+
+Example:
+ msi_parent: <&msi0 0x80024>
+
+msi0 is the MSI controller in the system. Bits 0-5 is the channel ID. 4
+is the channel ID. Bits 5-8 is the instance number. This is for the HIDMA
+instance 1.
+
Example:
Hypervisor OS configuration:
--
1.9.1
^ permalink raw reply related
* [PATCH V2 00/10] dmaengine: qcom_hidma: add MSI interrupt support
From: Sinan Kaya @ 2016-09-12 13:02 UTC (permalink / raw)
To: linux-arm-kernel
The new version of the HW supports MSI interrupts instead of wired
interrupts. The MSI interrupts are especially useful for the guest machine
execution. The wired interrupts usually trap to the hypervisor and then are
relayed to the actual interrupt.
The MSI interrupts can be directly fed into the interrupt controller.
Adding a new OF compat string (qcom,hidma-1.1) and ACPI string (QCOM8062)
to distinguish newer HW from the older ones.
Changes from v1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/444167.html
* Documentation update for DT bindings
* Rebased to slave-next
* Dropped dmaengine: qcom_hidma: eliminate processed variables. Replaced it
with dmaengine: qcom_hidma: protect common data structures
Sinan Kaya (10):
Documentation: DT: qcom_hidma: update binding for MSI
Documentation: DT: qcom_hidma: correct spelling mistakes
of: irq: make of_msi_configure accessible from modules
dmaengine: qcom_hidma: configure DMA and MSI for OF
dmaengine: qcom_hidma: make pending_tre_count atomic
dmaengine: qcom_hidma: make error and success path common
dmaengine: qcom_hidma: bring out interrupt cause
dmaengine: qcom_hidma: add a common API to setup the interrupt
dmaengine: qcom_hidma: protect common data structures
dmaengine: qcom_hidma: add MSI support for interrupts
.../devicetree/bindings/dma/qcom_hidma_mgmt.txt | 17 +-
drivers/dma/qcom/hidma.c | 128 +++++++++-
drivers/dma/qcom/hidma.h | 6 +-
drivers/dma/qcom/hidma_dbg.c | 3 +-
drivers/dma/qcom/hidma_ll.c | 278 ++++++++++-----------
drivers/dma/qcom/hidma_mgmt.c | 5 +-
drivers/of/irq.c | 1 +
7 files changed, 279 insertions(+), 159 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH V2 00/10] PM / Domains: Add support for removing PM domains
From: Ulf Hansson @ 2016-09-12 13:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473678074-15126-1-git-send-email-jonathanh@nvidia.com>
On 12 September 2016 at 13:01, Jon Hunter <jonathanh@nvidia.com> wrote:
> In order to safely remove PM domains there are a few changes that need to be
> made to ensure that no one is holding an external reference to a PM domain
> after it has been removed. One solution, implemented here, solves this by
> eliminating external references to PM domain.
>
> Changes from V1:
> - Added test when removing a PM domain to ensure the PM domain provider
> has been removed.
> - Re-organised patches 8-10 so that patch #8 adds the code to verify if
> the provider is present, patch #9 adds basic support for removing PM
> domains and patch #10 adds support for removing PM domains by provider.
>
> Changes from initial RFC:
> - Renamed functions made static per Ulf's feedback.
> - Added patch to clean-up provider/xlate APIs per Ulf's feedback
> - Re-worked and simplified the association between PM domains and PM
> domain providers. Dropped the 'provider_data' variable from the
> generic_pm_domain structure in favour of using the fwnode_handle.
> - Split patch for removing PM domains into multiple patches per Ulf's
> feedback.
>
> Jon Hunter (10):
> PM / Domains: Add new helper functions for device-tree
> ARM: EXYNOS: Remove calls to of_genpd_get_from_provider()
> staging: board: Remove calls to of_genpd_get_from_provider()
> PM / Domains: Don't expose generic_pm_domain structure to clients
> PM / Domains: Don't expose xlate and provider helper functions
> PM / Domains: Verify the PM domain is present when adding a provider
> PM / Domains: Prepare for adding support to remove PM domains
> PM / Domains: Store the provider in the PM domain structure
> PM / Domains: Add support for removing PM domains
> PM / Domains: Add support for removing nested PM domains by provider
>
> drivers/base/power/domain.c | 353 +++++++++++++++++++++++++++++++++++----
> drivers/soc/samsung/pm_domains.c | 23 +--
> drivers/staging/board/board.c | 9 +-
> include/linux/pm_domain.h | 74 ++++----
> 4 files changed, 364 insertions(+), 95 deletions(-)
>
> --
> 2.1.4
>
Jon, thanks for being patient and keep working on this series! I have
now completed the review and I am happy with this version.
Also, I remember Krzysztof requested an immutable branch for this
series, I guess Rafael can arrange that if still needed!?
Kind regards
Uffe
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Mark Rutland @ 2016-09-12 12:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912123027.GA13741@leverpostej>
On Mon, Sep 12, 2016 at 01:30:28PM +0100, Mark Rutland wrote:
> On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > some cleanup [1,2] that just landed in the arm64 for-next/core branch.
> > >
> > > Could you please rebase atop of that?
> >
> > Well, we should figure out what tree this is going through first. There
> > are a mixture of arm, arm64, driver and dts changes here and not all
> > of it is carrying the appropriate acks for me to queue it.
>
> Given that mix, I had assumed that this would all go through the arm64
> tree -- I see that Rob has already acked the binding, and I'm happy to
> give my ack for the driver once that's in shape.
Now I see that I'd missed the arch/arm changes in patch 4, which lack a
relevant ack.
Given that, I don't know what to suggest.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v4 3/8] drm/tilcdc: Add blue-and-red-crossed devicetree property
From: Rob Herring @ 2016-09-12 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <097cda0d23741ab21aa13bd3f152ca2f32bf9ab3.1472719892.git.jsarha@ti.com>
On Thu, Sep 01, 2016 at 12:09:07PM +0300, Jyri Sarha wrote:
> Add "blue-and-red-wiring"-device tree property and update devicetree
> binding document.
>
> The red and blue components are reversed between 24 and 16 bit modes
> on am335x LCDC output pins. To get 24 RGB format the red and blue
> wires has to be crossed and this in turn causes 16 colors output to be
> in BGR format. With straight wiring the 16 color is RGB and 24 bit is
> BGR.
>
> The new property describes whether the red and blue wires are crossed
> or not. If the property is not present or its value is not recognized
> the legacy mode is assumed. The legacy configuration supports RGB565,
> RGB888 and XRGB8888 formats. However, depending on wiring, the red and
> blue colors are swapped in either 16 or 24-bit color modes.
>
> For more details see section 3.1.1 in AM335x Silicon Errata:
> http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360
>
> Signed-off-by: Jyri Sarha <jsarha@ti.com>
> ---
> .../devicetree/bindings/display/tilcdc/tilcdc.txt | 22 ++++++++++++
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 41 ++++++++++++++++++++++
> drivers/gpu/drm/tilcdc/tilcdc_drv.h | 4 +++
> drivers/gpu/drm/tilcdc/tilcdc_plane.c | 9 ++---
> 4 files changed, 70 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
> index 6efa4c5..a5007aa 100644
> --- a/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
> +++ b/Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt
> @@ -17,6 +17,18 @@ Optional properties:
> the lcd controller.
> - max-pixelclock: The maximum pixel clock that can be supported
> by the lcd controller in KHz.
> + - blue-and-red-wiring: Recognized values "default", "straight" or
Need to drop default from here. With that,
Acked-by: Rob Herring <robh@kernel.org>
> + "crossed". This property deals with the LCDC revision 2 (found on
> + AM335x) color errata [1].
> + - "straight" indicates normal wiring that supports RGB565,
> + BGR888, and XBGR8888 color formats.
> + - "crossed" indicates wiring that has blue and red wires
> + crossed. This setup supports BGR565, RGB888 and XRGB8888
> + formats.
> + - If the property is not present or its value is not recognized
> + the legacy mode is assumed. This configuration supports RGB565,
> + RGB888 and XRGB8888 formats. However, depending on wiring, the red
> + and blue colors are swapped in either 16 or 24-bit color modes.
>
> Optional nodes:
>
> @@ -28,6 +40,14 @@ Optional nodes:
> Documentation/devicetree/bindings/display/tilcdc/tfp410.txt for connecting
> tfp410 DVI encoder or lcd panel to lcdc
>
> +[1] There is an errata about AM335x color wiring. For 16-bit color mode
> + the wires work as they should (LCD_DATA[0:4] is for Blue[3:7]),
> + but for 24 bit color modes the wiring of blue and red components is
> + crossed and LCD_DATA[0:4] is for Red[3:7] and LCD_DATA[11:15] is
> + for Blue[3-7]. For more details see section 3.1.1 in AM335x
> + Silicon Errata:
> + http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=sprz360
> +
> Example:
>
> fb: fb at 4830e000 {
> @@ -37,6 +57,8 @@ Example:
> interrupts = <36>;
> ti,hwmods = "lcdc";
>
> + blue-and-red-wiring = "crossed";
> +
> port {
> lcdc_0: endpoint at 0 {
> remote-endpoint = <&hdmi_0>;
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> index e45c268..ed4dc5c 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
> @@ -33,6 +33,20 @@
>
> static LIST_HEAD(module_list);
>
> +static const u32 tilcdc_rev1_formats[] = { DRM_FORMAT_RGB565 };
> +
> +static const u32 tilcdc_straight_formats[] = { DRM_FORMAT_RGB565,
> + DRM_FORMAT_BGR888,
> + DRM_FORMAT_XBGR8888 };
> +
> +static const u32 tilcdc_crossed_formats[] = { DRM_FORMAT_BGR565,
> + DRM_FORMAT_RGB888,
> + DRM_FORMAT_XRGB8888 };
> +
> +static const u32 tilcdc_legacy_formats[] = { DRM_FORMAT_RGB565,
> + DRM_FORMAT_RGB888,
> + DRM_FORMAT_XRGB8888 };
> +
> void tilcdc_module_init(struct tilcdc_module *mod, const char *name,
> const struct tilcdc_module_ops *funcs)
> {
> @@ -318,6 +332,33 @@ static int tilcdc_load(struct drm_device *dev, unsigned long flags)
>
> pm_runtime_put_sync(dev->dev);
>
> + if (priv->rev == 1) {
> + DBG("Revision 1 LCDC supports only RGB565 format");
> + priv->pixelformats = tilcdc_rev1_formats;
> + priv->num_pixelformats = ARRAY_SIZE(tilcdc_rev1_formats);
> + } else {
> + const char *str = "\0";
> +
> + of_property_read_string(node, "blue-and-red-wiring", &str);
> + if (0 == strcmp(str, "crossed")) {
> + DBG("Configured for crossed blue and red wires");
> + priv->pixelformats = tilcdc_crossed_formats;
> + priv->num_pixelformats =
> + ARRAY_SIZE(tilcdc_crossed_formats);
> + } else if (0 == strcmp(str, "straight")) {
> + DBG("Configured for straight blue and red wires");
> + priv->pixelformats = tilcdc_straight_formats;
> + priv->num_pixelformats =
> + ARRAY_SIZE(tilcdc_straight_formats);
> + } else {
> + DBG("Blue and red wiring '%s' unknown, use legacy mode",
> + str);
> + priv->pixelformats = tilcdc_legacy_formats;
> + priv->num_pixelformats =
> + ARRAY_SIZE(tilcdc_legacy_formats);
> + }
> + }
> +
> ret = modeset_init(dev);
> if (ret < 0) {
> dev_err(dev->dev, "failed to initialize mode setting\n");
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.h b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> index 13001df..0e19c14 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.h
> @@ -65,6 +65,10 @@ struct tilcdc_drm_private {
> */
> uint32_t max_width;
>
> + /* Supported pixel formats */
> + const uint32_t *pixelformats;
> + uint32_t num_pixelformats;
> +
> /* The context for pm susped/resume cycle is stored here */
> struct drm_atomic_state *saved_state;
>
> diff --git a/drivers/gpu/drm/tilcdc/tilcdc_plane.c b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> index 41911e3..74c65fa 100644
> --- a/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> +++ b/drivers/gpu/drm/tilcdc/tilcdc_plane.c
> @@ -24,10 +24,6 @@
>
> #include "tilcdc_drv.h"
>
> -static const u32 tilcdc_formats[] = { DRM_FORMAT_RGB565,
> - DRM_FORMAT_RGB888,
> - DRM_FORMAT_XRGB8888 };
> -
> static struct drm_plane_funcs tilcdc_plane_funcs = {
> .update_plane = drm_atomic_helper_update_plane,
> .disable_plane = drm_atomic_helper_disable_plane,
> @@ -114,12 +110,13 @@ static const struct drm_plane_helper_funcs plane_helper_funcs = {
> int tilcdc_plane_init(struct drm_device *dev,
> struct drm_plane *plane)
> {
> + struct tilcdc_drm_private *priv = dev->dev_private;
> int ret;
>
> ret = drm_plane_init(dev, plane, 1,
> &tilcdc_plane_funcs,
> - tilcdc_formats,
> - ARRAY_SIZE(tilcdc_formats),
> + priv->pixelformats,
> + priv->num_pixelformats,
> true);
> if (ret) {
> dev_err(dev->dev, "Failed to initialize plane: %d\n", ret);
> --
> 1.9.1
>
^ permalink raw reply
* [PATCH v4 6/9] pinctrl: Add IRQ support to STM32 gpios
From: Linus Walleij @ 2016-09-12 12:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0063a1ef-1b09-7cfc-f18b-76f2bb07eb84@st.com>
On Thu, Sep 8, 2016 at 5:47 PM, Alexandre Torgue
<alexandre.torgue@st.com> wrote:
> Just one question, when you say "super-complex irqchip in use", do you mean
> I could use another (simplest) solution to handle this EXTI controller?
I don't know, GPIOLIB_IRQCHIP is to be used for some specific
cases documented in Documentation/gpio/driver.txt.
For anything complex, we either need to have this hairy code
or invent new abstractions.
For now, I assume this is needed...
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] arm64: mm: move zero page from .bss to right before swapper_pg_dir
From: Mark Rutland @ 2016-09-12 12:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473604714-5512-1-git-send-email-ard.biesheuvel@linaro.org>
Hi,
On Sun, Sep 11, 2016 at 03:38:34PM +0100, Ard Biesheuvel wrote:
> Move the statically allocated zero page from the .bss section to right
> before swapper_pg_dir. This allows us to refer to its physical address
> by simply reading TTBR1_EL1 (which always points to swapper_pg_dir and
> always has its ASID field cleared), and subtracting PAGE_SIZE.
On a conflicting note, I was hoping to move the zero page into .rodata
so as to catch any erroneous modification.
Given that we can't rely on TTBR1 poiting at the swapper_pg_dir, that
leaves us with Image size reduction vs RO-ification.
Any thoughts/preference?
Thanks,
Mark,
> Inspired-by: http://marc.info/?l=linux-arm-kernel&m=147282867511801
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/include/asm/mmu_context.h | 10 ++++++----
> arch/arm64/kernel/head.S | 1 -
> arch/arm64/kernel/vmlinux.lds.S | 2 ++
> arch/arm64/mm/mmu.c | 1 -
> 4 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/include/asm/mmu_context.h b/arch/arm64/include/asm/mmu_context.h
> index b1892a0dbcb0..94461ba5febd 100644
> --- a/arch/arm64/include/asm/mmu_context.h
> +++ b/arch/arm64/include/asm/mmu_context.h
> @@ -49,13 +49,15 @@ static inline void contextidr_thread_switch(struct task_struct *next)
> */
> static inline void cpu_set_reserved_ttbr0(void)
> {
> - unsigned long ttbr = virt_to_phys(empty_zero_page);
> + unsigned long dummy;
>
> - asm(
> + asm volatile(
> + " mrs %0, ttbr1_el1 // get TTBR1\n"
> + " sub %0, %0, %1 // subtract PAGE_SIZE\n"
> " msr ttbr0_el1, %0 // set TTBR0\n"
> " isb"
> - :
> - : "r" (ttbr));
> + : "=&r" (dummy)
> + : "I" (PAGE_SIZE));
> }
>
> /*
> diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
> index 8bc9458f9add..6020b884b076 100644
> --- a/arch/arm64/kernel/head.S
> +++ b/arch/arm64/kernel/head.S
> @@ -449,7 +449,6 @@ __primary_switched:
> adr_l x2, __bss_stop
> sub x2, x2, x0
> bl __pi_memset
> - dsb ishst // Make zero page visible to PTW
>
> #ifdef CONFIG_KASAN
> bl kasan_early_init
> diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
> index 659963d40bb4..a14eb8ff5144 100644
> --- a/arch/arm64/kernel/vmlinux.lds.S
> +++ b/arch/arm64/kernel/vmlinux.lds.S
> @@ -193,6 +193,8 @@ SECTIONS
> . = ALIGN(PAGE_SIZE);
> idmap_pg_dir = .;
> . += IDMAP_DIR_SIZE;
> + empty_zero_page = .;
> + . += PAGE_SIZE;
> swapper_pg_dir = .;
> . += SWAPPER_DIR_SIZE;
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 4989948d1feb..539ce9d11325 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -53,7 +53,6 @@ EXPORT_SYMBOL(kimage_voffset);
> * Empty_zero_page is a special page that is used for zero-initialized data
> * and COW.
> */
> -unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)] __page_aligned_bss;
> EXPORT_SYMBOL(empty_zero_page);
>
> static pte_t bm_pte[PTRS_PER_PTE] __page_aligned_bss;
> --
> 2.7.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply
* [PATCH V2 10/10] PM / Domains: Add support for removing nested PM domains by provider
From: Ulf Hansson @ 2016-09-12 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473678074-15126-11-git-send-email-jonathanh@nvidia.com>
On 12 September 2016 at 13:01, Jon Hunter <jonathanh@nvidia.com> wrote:
> If a device supports PM domains that are subdomains of another PM
> domain, then the PM domains should be removed in reverse order to
> ensure that the subdomains are removed first. Furthermore, if there is
> more than one provider, then there needs to be a way to remove the
> domains in reverse order for a specific provider.
>
> Add the function of_genpd_remove_last() to remove the last PM domain
> added by a given PM domain provider and return the generic_pm_domain
> structure for the PM domain that was removed.
>
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
> ---
> drivers/base/power/domain.c | 35 +++++++++++++++++++++++++++++++++++
> include/linux/pm_domain.h | 7 +++++++
> 2 files changed, 42 insertions(+)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 7481e3e316a2..b0cf46dcae73 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -1745,6 +1745,41 @@ int of_genpd_add_subdomain(struct of_phandle_args *parent_spec,
> EXPORT_SYMBOL_GPL(of_genpd_add_subdomain);
>
> /**
> + * of_genpd_remove_last - Remove the last PM domain registered for a provider
> + * @provider: Pointer to device structure associated with provider
> + *
> + * Find the last PM domain that was added by a particular provider and
> + * remove this PM domain from the list of PM domains. The provider is
> + * identified by the 'provider' device structure that is passed. The PM
> + * domain will only be removed, if the provider associated with domain
> + * has been removed.
> + *
> + * Returns a valid pointer to struct generic_pm_domain on success or
> + * ERR_PTR() on failure.
> + */
> +struct generic_pm_domain *of_genpd_remove_last(struct device_node *np)
> +{
> + struct generic_pm_domain *gpd, *genpd = ERR_PTR(-ENOENT);
> + int ret;
> +
> + if (IS_ERR_OR_NULL(np))
> + return ERR_PTR(-EINVAL);
> +
> + mutex_lock(&gpd_list_lock);
> + list_for_each_entry(gpd, &gpd_list, gpd_list_node) {
> + if (gpd->provider == &np->fwnode) {
> + ret = genpd_remove(gpd);
> + genpd = ret ? ERR_PTR(ret) : gpd;
> + break;
> + }
> + }
> + mutex_unlock(&gpd_list_lock);
> +
> + return genpd;
> +}
> +EXPORT_SYMBOL_GPL(of_genpd_remove_last);
> +
> +/**
> * genpd_dev_pm_detach - Detach a device from its PM domain.
> * @dev: Device to detach.
> * @power_off: Currently not used
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index 85f7d53a9827..a09fe5c009c8 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -204,6 +204,7 @@ extern int of_genpd_add_device(struct of_phandle_args *args,
> struct device *dev);
> extern int of_genpd_add_subdomain(struct of_phandle_args *parent,
> struct of_phandle_args *new_subdomain);
> +extern struct generic_pm_domain *of_genpd_remove_last(struct device_node *np);
>
> int genpd_dev_pm_attach(struct device *dev);
> #else /* !CONFIG_PM_GENERIC_DOMAINS_OF */
> @@ -237,6 +238,12 @@ static inline int genpd_dev_pm_attach(struct device *dev)
> {
> return -ENODEV;
> }
> +
> +static inline
> +struct generic_pm_domain *of_genpd_remove_last(struct device_node *np)
> +{
> + return ERR_PTR(-ENOTSUPP);
> +}
> #endif /* CONFIG_PM_GENERIC_DOMAINS_OF */
>
> #ifdef CONFIG_PM
> --
> 2.1.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V2 09/10] PM / Domains: Add support for removing PM domains
From: Ulf Hansson @ 2016-09-12 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473678074-15126-10-git-send-email-jonathanh@nvidia.com>
On 12 September 2016 at 13:01, Jon Hunter <jonathanh@nvidia.com> wrote:
> The genpd framework allows users to add PM domains via the pm_genpd_init()
> function, however, there is no corresponding function to remove a PM
> domain. For most devices this may be fine as the PM domains are never
> removed, however, for devices that wish to populate the PM domains from
> within a driver, having the ability to remove a PM domain if the probing
> of the device fails or the driver is unloaded is necessary.
>
> Add the function pm_genpd_remove() to remove a PM domain by referencing
> it's generic_pm_domain structure. Note that the bulk of the code that
> removes the PM domain is placed in a separate local function
> genpd_remove() (which is called by pm_genpd_remove()). The code is
> structured in this way to prepare for adding another function to remove
> a PM domain by provider that will also call genpd_remove(). Note that
> users of genpd_remove() must call this function with the mutex,
> gpd_list_lock, held.
>
> PM domains can only be removed if the associated provider has been
> removed, they are not a parent domain to another PM domain and have no
> devices associated with them.
>
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
> ---
> drivers/base/power/domain.c | 60 +++++++++++++++++++++++++++++++++++++++++++++
> include/linux/pm_domain.h | 5 ++++
> 2 files changed, 65 insertions(+)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index d5135caa84db..7481e3e316a2 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -1358,6 +1358,66 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
> }
> EXPORT_SYMBOL_GPL(pm_genpd_init);
>
> +static int genpd_remove(struct generic_pm_domain *genpd)
> +{
> + struct gpd_link *l, *link;
> +
> + if (IS_ERR_OR_NULL(genpd))
> + return -EINVAL;
> +
> + mutex_lock(&genpd->lock);
> +
> + if (genpd->has_provider) {
> + mutex_unlock(&genpd->lock);
> + pr_err("Provider present, unable to remove %s\n", genpd->name);
> + return -EBUSY;
> + }
> +
> + if (!list_empty(&genpd->master_links) || genpd->device_count) {
> + mutex_unlock(&genpd->lock);
> + pr_err("%s: unable to remove %s\n", __func__, genpd->name);
> + return -EBUSY;
> + }
> +
> + list_for_each_entry_safe(link, l, &genpd->slave_links, slave_node) {
> + list_del(&link->master_node);
> + list_del(&link->slave_node);
> + kfree(link);
> + }
> +
> + list_del(&genpd->gpd_list_node);
> + mutex_unlock(&genpd->lock);
> + cancel_work_sync(&genpd->power_off_work);
> + pr_debug("%s: removed %s\n", __func__, genpd->name);
> +
> + return 0;
> +}
> +
> +/**
> + * pm_genpd_remove - Remove a generic I/O PM domain
> + * @genpd: Pointer to PM domain that is to be removed.
> + *
> + * To remove the PM domain, this function:
> + * - Removes the PM domain as a subdomain to any parent domains,
> + * if it was added.
> + * - Removes the PM domain from the list of registered PM domains.
> + *
> + * The PM domain will only be removed, if the associated provider has
> + * been removed, it is not a parent to any other PM domain and has no
> + * devices associated with it.
> + */
> +int pm_genpd_remove(struct generic_pm_domain *genpd)
> +{
> + int ret;
> +
> + mutex_lock(&gpd_list_lock);
> + ret = genpd_remove(genpd);
> + mutex_unlock(&gpd_list_lock);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(pm_genpd_remove);
> +
> #ifdef CONFIG_PM_GENERIC_DOMAINS_OF
>
> typedef struct generic_pm_domain *(*genpd_xlate_t)(struct of_phandle_args *args,
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index 554f8915c691..85f7d53a9827 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -130,6 +130,7 @@ extern int pm_genpd_remove_subdomain(struct generic_pm_domain *genpd,
> struct generic_pm_domain *target);
> extern int pm_genpd_init(struct generic_pm_domain *genpd,
> struct dev_power_governor *gov, bool is_off);
> +extern int pm_genpd_remove(struct generic_pm_domain *genpd);
>
> extern struct dev_power_governor simple_qos_governor;
> extern struct dev_power_governor pm_domain_always_on_gov;
> @@ -165,6 +166,10 @@ static inline int pm_genpd_init(struct generic_pm_domain *genpd,
> {
> return -ENOSYS;
> }
> +static inline int pm_genpd_remove(struct generic_pm_domain *genpd)
> +{
> + return -ENOTSUPP;
> +}
> #endif
>
> static inline int pm_genpd_add_device(struct generic_pm_domain *genpd,
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH V2 08/10] PM / Domains: Store the provider in the PM domain structure
From: Ulf Hansson @ 2016-09-12 12:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473678074-15126-9-git-send-email-jonathanh@nvidia.com>
On 12 September 2016 at 13:01, Jon Hunter <jonathanh@nvidia.com> wrote:
> It is possible that a device has more than one provider of PM domains
> and to support the removal of a PM domain by provider, it is necessary
> to store a reference to the provider in the PM domain structure.
> Therefore, store a reference to the firmware node handle in the PM
> domain structure and populate it when providers (only device-tree based
> providers are currently supported by PM domains) are registered.
>
> Please note that when removing PM domains, it is necessary to verify
> that the PM domain provider has been removed from the list of providers
> before the PM domain can be removed. To do this add another member to
> the PM domain structure that indicates if the provider is present and
> set this member accordingly when providers are added and removed.
>
> Initialise the 'provider' and 'has_provider' members of the
> generic_pm_domain structure when a PM domains is added by calling
> pm_genpd_init().
>
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Kind regards
Uffe
> ---
> drivers/base/power/domain.c | 42 +++++++++++++++++++++++++++++++++++++-----
> include/linux/pm_domain.h | 2 ++
> 2 files changed, 39 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
> index 1bd8d412db06..d5135caa84db 100644
> --- a/drivers/base/power/domain.c
> +++ b/drivers/base/power/domain.c
> @@ -1306,6 +1306,8 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
> genpd->device_count = 0;
> genpd->max_off_time_ns = -1;
> genpd->max_off_time_changed = true;
> + genpd->provider = NULL;
> + genpd->has_provider = false;
> genpd->domain.ops.runtime_suspend = genpd_runtime_suspend;
> genpd->domain.ops.runtime_resume = genpd_runtime_resume;
> genpd->domain.ops.prepare = pm_genpd_prepare;
> @@ -1491,6 +1493,11 @@ int of_genpd_add_provider_simple(struct device_node *np,
> if (pm_genpd_present(genpd))
> ret = genpd_add_provider(np, genpd_xlate_simple, genpd);
>
> + if (!ret) {
> + genpd->provider = &np->fwnode;
> + genpd->has_provider = true;
> + }
> +
> mutex_unlock(&gpd_list_lock);
>
> return ret;
> @@ -1506,7 +1513,7 @@ int of_genpd_add_provider_onecell(struct device_node *np,
> struct genpd_onecell_data *data)
> {
> unsigned int i;
> - int ret;
> + int ret = -EINVAL;
>
> if (!np || !data)
> return -EINVAL;
> @@ -1514,13 +1521,26 @@ int of_genpd_add_provider_onecell(struct device_node *np,
> mutex_lock(&gpd_list_lock);
>
> for (i = 0; i < data->num_domains; i++) {
> - if (!pm_genpd_present(data->domains[i])) {
> - mutex_unlock(&gpd_list_lock);
> - return -EINVAL;
> - }
> + if (!pm_genpd_present(data->domains[i]))
> + goto error;
> +
> + data->domains[i]->provider = &np->fwnode;
> + data->domains[i]->has_provider = true;
> }
>
> ret = genpd_add_provider(np, genpd_xlate_onecell, data);
> + if (ret < 0)
> + goto error;
> +
> + mutex_unlock(&gpd_list_lock);
> +
> + return 0;
> +
> +error:
> + while (i--) {
> + data->domains[i]->provider = NULL;
> + data->domains[i]->has_provider = false;
> + }
>
> mutex_unlock(&gpd_list_lock);
>
> @@ -1535,10 +1555,21 @@ EXPORT_SYMBOL_GPL(of_genpd_add_provider_onecell);
> void of_genpd_del_provider(struct device_node *np)
> {
> struct of_genpd_provider *cp;
> + struct generic_pm_domain *gpd;
>
> + mutex_lock(&gpd_list_lock);
> mutex_lock(&of_genpd_mutex);
> list_for_each_entry(cp, &of_genpd_providers, link) {
> if (cp->node == np) {
> + /*
> + * For each PM domain associated with the
> + * provider, set the 'has_provider' to false
> + * so that the PM domain can be safely removed.
> + */
> + list_for_each_entry(gpd, &gpd_list, gpd_list_node)
> + if (gpd->provider == &np->fwnode)
> + gpd->has_provider = false;
> +
> list_del(&cp->link);
> of_node_put(cp->node);
> kfree(cp);
> @@ -1546,6 +1577,7 @@ void of_genpd_del_provider(struct device_node *np)
> }
> }
> mutex_unlock(&of_genpd_mutex);
> + mutex_unlock(&gpd_list_lock);
> }
> EXPORT_SYMBOL_GPL(of_genpd_del_provider);
>
> diff --git a/include/linux/pm_domain.h b/include/linux/pm_domain.h
> index f103869db443..554f8915c691 100644
> --- a/include/linux/pm_domain.h
> +++ b/include/linux/pm_domain.h
> @@ -51,6 +51,8 @@ struct generic_pm_domain {
> struct mutex lock;
> struct dev_power_governor *gov;
> struct work_struct power_off_work;
> + struct fwnode_handle *provider; /* Identity of the domain provider */
> + bool has_provider;
> const char *name;
> atomic_t sd_count; /* Number of subdomains with power "on" */
> enum gpd_status status; /* Current state of the domain */
> --
> 2.1.4
>
^ permalink raw reply
* [PATCH] ARM: dma-mapping: add in missing white space in error message text
From: Colin King @ 2016-09-12 12:52 UTC (permalink / raw)
To: linux-arm-kernel
From: Colin Ian King <colin.king@canonical.com>
A dev_warn message spans two lines and the literal string is missing
a white space between words. Add the white space.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
arch/arm/common/dmabounce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/common/dmabounce.c b/arch/arm/common/dmabounce.c
index 3012816..f47767b 100644
--- a/arch/arm/common/dmabounce.c
+++ b/arch/arm/common/dmabounce.c
@@ -547,7 +547,7 @@ void dmabounce_unregister_dev(struct device *dev)
if (!device_info) {
dev_warn(dev,
- "Never registered with dmabounce but attempting"
+ "Never registered with dmabounce but attempting "
"to unregister!\n");
return;
}
--
2.9.3
^ permalink raw reply related
* [PATCH] arm: imx-dma: Don't change desc pointer before calling callback
From: Ian Arkver @ 2016-09-12 12:50 UTC (permalink / raw)
To: linux-arm-kernel
This commit...
fcaaba6 dmaengine: imx-dma: fix callback path in tasklet
moved the test and call of the DMA completion callback function
into the tasklet exit path which is after the manipulation of ld_queue
and ld_active. This manipulation changes the desc pointer and can result
in the wrong descriptor being checked for the callback function.
One fix is to use a temporary variable to do the queue update.
Signed-off-by: Ian Jamison <ian.dev@arkver.com>
---
I found the bug and tested this patch on kernel 3.10.103 which has the
original patch backported. It was found using m2m_deinterlacer which issues
several DMAs with a callback on the last one. When the callback is called
early there is a race between the v4l2 framework returning the buffers
which invalidates the buffer pointers and the next DMA completion. This
resulted in intermittent NULL pointer dereferences. I believe the fix is
relevant to current mainline kernel as this code fragment has not changed.
drivers/dma/imx-dma.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/imx-dma.c b/drivers/dma/imx-dma.c
index a960608..335c2d0 100644
--- a/drivers/dma/imx-dma.c
+++ b/drivers/dma/imx-dma.c
@@ -653,10 +653,10 @@ static void imxdma_tasklet(unsigned long data)
list_move_tail(imxdmac->ld_active.next, &imxdmac->ld_free);
if (!list_empty(&imxdmac->ld_queue)) {
- desc = list_first_entry(&imxdmac->ld_queue, struct
imxdma_desc,
- node);
+ struct imxdma_desc *tmpdesc = list_first_entry(
+ &imxdmac->ld_queue, struct imxdma_desc, node);
list_move_tail(imxdmac->ld_queue.next,
&imxdmac->ld_active);
- if (imxdma_xfer_desc(desc) < 0)
+ if (imxdma_xfer_desc(tmpdesc) < 0)
dev_warn(imxdma->dev, "%s: channel: %d couldn't
xfer desc\n",
__func__, imxdmac->channel);
}
--
2.9.3
^ permalink raw reply related
* [RFC PATCH 0/5] arm64: Signal context expansion
From: Florian Weimer @ 2016-09-12 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912111749.GB3958@e103592.cambridge.arm.com>
On 09/12/2016 01:17 PM, Dave Martin wrote:
>>> If the stack isn't large enough, we'll still have to SEGV the task
>>> though.
>>
>> You could skip copying the data and not install a pointer to it in the
>> existing signal context.
>
> We could, but then we'd corrupt the task state in sigreturn, since
> we wouldn't have been able to save/restore part of the state.
Ah, I wasn't aware that the kernel doesn't have a copy of the state.
Could the kernel reserve space for it when sigaltstack is called?
> The least-wrong thing I can think of to do is:
>
> * deprecate but continue to support the existing sigaltstack API/ABI
> with today's {,MIN}SIGSTKSZ definitions
There is also PTHREAD_STACK_MIN. The glibc default for that (which is
overriden by some architectures) is 16 KiB. It is also quite small; see
the sequence of events mentioned here:
<https://sourceware.org/bugzilla/show_bug.cgi?id=20249>
> * guarantee (as much as possible) that software using this ABI continues
> to work (by saving/restoring only data that _must_ be saved/restored at
> each signal, which may be small enough to fit)
>
> * providing a clean failure mode (fatal signal) when this proves
> impossible at signal delivery/return time;
>
> * define a new interface for runtime-querying the required signal stack
> size;
>
> * define a new syscall or new stack_t.ss_flags flags (say, SS_STRICT)
> that permits the kernel to enforce a runtime-determined minimum greater
> than MINSIGSTKSZ when calling sigaltstack().
>
>
> Another option would be:
>
> * define a new interface for runtime-querying the required signal stack
> size, and
>
> * support the current API/ABI, but make a call to sigaltstack() SEGV or
> SIGILL the caller if it specifies ss_stack >= MINSIGSTKSZ but smaller
> than the actual runtime minimum.
>
> (this would cause old software to break immediately in an obvious way on
> new systems, forcing people to fix their software -- which they might or
> might not actually bother to do).
The second option looks a bit problematic from a support perspective.
Do you think it would be possible to block access to hardware features
that cause signal stack bloat on a per-process basis? Then we could
bump the kernel requirement enforced by sigaltstack directly for the
default, and define a compatibility personality that minimizes the
signal stack size for old applications. (A way to query the required
alternative signal stack size would still come in handy, though.)
Florian
^ permalink raw reply
* [PATCH v2 3/4] ARM: dts: Add NextThing GR8 dtsi
From: Laurent Pinchart @ 2016-09-12 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbrvDZGM3OJsAMk4T5awSSbrJ4MDyKXV2C45ZSE7zUVNQ@mail.gmail.com>
Hi Linus,
On Monday 12 Sep 2016 14:40:15 Linus Walleij wrote:
> On Thu, Sep 8, 2016 at 9:37 AM, Maxime Ripard wrote:
> > On Thu, Sep 08, 2016 at 12:46:14PM +0800, Chen-Yu Tsai wrote:
> >> Also, I think we are needlessly using pin groups, 1 pin per group.
> >> Can pinconf/pinctrl work without them? Would there be any harm
> >> converting the sunxi driver to work directly with pins? This would
> >> make it match generic pinconf parsing, and make it easier to get
> >> both working together.
> >
> > I think it comes from a requirement that you had to have groups at
> > some point (I don't know if it's still the case), which is why we
> > ended up with single-pin groups, because we can mux each pins entirely
> > separately.
> >
> > If it's not required anymore, then yes, it makes total sense to remove
> > it.
>
> The groups vs individual pins is an eternal debate that has
> been going on since the inception of pinctrl.
>
> If you see it from the point of the programmer, you may just see
> a register for each pin and they seem all independent. This is
> why pinctrl-single exist, and that driver is for this purpose: one
> register per pin, software-wise independent.
>
> HOWEVER it often turns out that while you can programmatically
> and individually set pins to any function (and biasing etc), the
> person designing the hardware was not thinking that you should
> be able to do whatever you like, e.g. even if it is possible to
> take two pins and use one of them for half an SPI bus and the
> other for half an I2C bus, that doesn't mean that this is useful
> or makes any kind of electronic sense, it just makes "software
> sense".
>
> So for a deeper understanding, several SoCs (amongst them
> my own and Qualcomm etc) define groups that are not really
> about software restrictions for what you can do with the pins, but
> about usecase and electronic restrictions for what can be done
> with the pins.
>
> E.g. it makes *sense* to have a group for muxing I2C on two
> pins, and not allow one of them to be muxed to I2C and the other
> not, because it does not make electronic sense.
>
> One-group-per-pin groups is usually coming from a failure or
> inability to identify these electronically sound and usecase
> oriented pingroups.
I'd argue that you would find out about lots of clever/insane use cases that
don't fit this model if you looked at all the hardware available out there,
especially non-phone devices. Your SPI example is a good one, I've seen SPI
being used in unidirectional mode only, with only MISO or MOSI mattering. In
that case the other pin could be used as a GPIO for a totally unrelated
purpose when the design is short on GPIOs or when GPIOs have been allocated
without any knowledge of the Linux pinctrl subsystem.
Looking at the sh-pfc driver, I wish the hardware had followed the pinctrl-
single model. sh-pfc is a good example of how bloated a pinctrl driver can
become when there is no choice but model all the relationships betweens pins
and functions in C code.
> Some (like pinctrl-single) say they don't care, and wish to
> see things as the world is just software and one register per
> pin, removing those electric usecase restrictions, and only
> keeping the muxing restrictions to e.g. the four different functions
> that can be muxed on that pin, disregarding the bigger picture.
>
> I don't know about this driver or the pins it manages,
> I seldom have time or brains to dive in and review things
> deeply enough :(
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCHv6 0/3] pwm: imx: support output polarity inversion
From: Alexandre Belloni @ 2016-09-12 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909091857.7a263220@ipc1.ka-ro>
On 09/09/2016 at 09:18:57 +0200, Lothar Wa?mann wrote :
> Hi,
>
> On Thu, 08 Sep 2016 15:15:57 -0700 Stefan Agner wrote:
> > On 2014-10-10 07:22, Lothar Wa?mann wrote:
> > > This patch series adds support for polarity inversion to the pwm-imx
> > > driver. The patches have been tested on i.MX6, i.MX53 and with the
> > > ti-ehrpwm.c driver.
> >
> > Do you know what prevented this patchset from getting merged?
> >
> No idea.
>
> > We are looking for Polarity support in PWM for too, this is especially
> > useful for backlight control.
> >
> Actually the PWM driver may be the wrong place to achieve this. When
> the backlight driver sets the brightness to 0 to switch the backlight
> off, it will disable the PWM. This will make the PWM pin go LOW and
> thus turn the backlight to full brightness rather than off (unless there
> is an additional GPIO that controls a backlight enable pin on the LCD).
>
Isn't a properly designed PWM putting a high level on its pin when
disabled and configured with inversed polarity ?
If the HW is capable of it, the driver should be fixed.
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 3/4] ARM: dts: Add NextThing GR8 dtsi
From: Linus Walleij @ 2016-09-12 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908073748.GF8913@lukather>
On Thu, Sep 8, 2016 at 9:37 AM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Thu, Sep 08, 2016 at 12:46:14PM +0800, Chen-Yu Tsai wrote:
>> Also, I think we are needlessly using pin groups, 1 pin per group.
>> Can pinconf/pinctrl work without them? Would there be any harm
>> converting the sunxi driver to work directly with pins? This would
>> make it match generic pinconf parsing, and make it easier to get
>> both working together.
>
> I think it comes from a requirement that you had to have groups at
> some point (I don't know if it's still the case), which is why we
> ended up with single-pin groups, because we can mux each pins entirely
> separately.
>
> If it's not required anymore, then yes, it makes total sense to remove
> it.
The groups vs individual pins is an eternal debate that has
been going on since the inception of pinctrl.
If you see it from the point of the programmer, you may just see
a register for each pin and they seem all independent. This is
why pinctrl-single exist, and that driver is for this purpose: one
register per pin, software-wise independent.
HOWEVER it often turns out that while you can programmatically
and individually set pins to any function (and biasing etc), the
person designing the hardware was not thinking that you should
be able to do whatever you like, e.g. even if it is possible to
take two pins and use one of them for half an SPI bus and the
other for half an I2C bus, that doesn't mean that this is useful
or makes any kind of electronic sense, it just makes "software
sense".
So for a deeper understanding, several SoCs (amongst them
my own and Qualcomm etc) define groups that are not really
about software restrictions for what you can do with the pins, but
about usecase and electronic restrictions for what can be done
with the pins.
E.g. it makes *sense* to have a group for muxing I2C on two
pins, and not allow one of them to be muxed to I2C and the other
not, because it does not make electronic sense.
One-group-per-pin groups is usually coming from a failure or
inability to identify these electronically sound and usecase
oriented pingroups.
Some (like pinctrl-single) say they don't care, and wish to
see things as the world is just software and one register per
pin, removing those electric usecase restrictions, and only
keeping the muxing restrictions to e.g. the four different functions
that can be muxed on that pin, disregarding the bigger picture.
I don't know about this driver or the pins it manages,
I seldom have time or brains to dive in and review things
deeply enough :(
Yours,
Linus Walleij
^ permalink raw reply
* ARM, SoC: About the use DT-defined properties by 3rd-party drivers
From: Mark Rutland @ 2016-09-12 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57D69FB1.2020801@laposte.net>
On Mon, Sep 12, 2016 at 02:29:37PM +0200, Sebastian Frias wrote:
> My question is about submitting DT properties/nodes (describing some HW) for
> which there is no Linux driver. Like register addresses for HW blocks,
> including HW capabilities of said HW blocks, which may or may not be setup
> by Linux directly.
>
> The idea being that since DT describes the HW and is usually shared with the
> bootloader (yet stored in the Linux kernel tree), all layers of the stack
> could use the same DT and each layer would use relevant properties. So the
> DT would describe the whole SoC even if not all HW blocks have a Linux
> driver.
>
> 3rd party users of said SoC could then write kernel modules for such HW
> blocks using the DT description. The DT would thus become the authoritative
> source of information regarding register programming for the SoC.
I don't follow this part entirely. Why are you expecting thrid parties
to write a driver for those blocks rather than upstreaming a driver for
them?
> Currently, HW blocks for which there is no public driver (that it is
> accessed through user-mode libraries or firmware) require a separate
> HW description (be it Documentation, headers, etc.)
>
> Since the DT describes the HW, it would make sense to expose the HW through
> DT, that would centralise the HW description.
I would generally agree that the hardware should be described in DT.
The difficulty is that without a 'real' user it's not always possible to
tell if we're describing the thing correctly.
Putting smoething together that's only sufficient to support some
out-of-tree driver with implicit assumptions that we are not aware of is
far from fantastic.
> However, after discussing over IRC, it looks like there was no guidance on
> this. Some people think submitting DT properties/nodes without a corresponding
> Linux driver is frowned upon, while others thought it was an odd limitation
> and suggested asking here.
Unfortunately, I think that the area is sufficiently vague that there
simply is no clear and general answer.
For the sake of discussion, an example of a particular block, along with
what you expect/need to describe would be helpful.
Thanks,
Mark.
^ permalink raw reply
* [UPDATE PATCH V10 1/8] ACPI: I/O Remapping Table (IORT) initial support
From: Tomasz Nowicki @ 2016-09-12 12:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160909092012.GC19669@red-moon>
Hi Rafael,
On 09.09.2016 11:20, Lorenzo Pieralisi wrote:
> Hi Rafael,
>
> On Wed, Sep 07, 2016 at 01:56:52PM +0200, Tomasz Nowicki wrote:
>> IORT shows representation of IO topology for ARM based systems.
>> It describes how various components are connected together on
>> parent-child basis e.g. PCI RC -> SMMU -> ITS. Also see IORT spec.
>> http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
>>
>> Initial support allows to detect IORT table presence and save its
>> root pointer obtained through acpi_get_table(). The pointer validity
>> depends on acpi_gbl_permanent_mmap because if acpi_gbl_permanent_mmap
>> is not set while using IORT nodes we would dereference unmapped pointers.
>>
>> For the aforementioned reason call iort_table_detect() from acpi_init()
>> which guarantees acpi_gbl_permanent_mmap to be set at that point.
>>
>> Add generic helpers which are helpful for scanning and retrieving
>> information from IORT table content. List of the most important helpers:
>> - iort_find_dev_node() finds IORT node for a given device
>> - iort_node_map_rid() maps device RID and returns IORT node which provides
>> final translation
>>
>> IORT support is placed under drivers/acpi/arm64/ new directory due to its
>> ARM64 specific nature. The code there is considered only for ARM64.
>> The long term plan is to keep all ARM64 specific tables support
>> in this place e.g. GTDT table.
>>
>> Signed-off-by: Tomasz Nowicki <tn@semihalf.com>
>> Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
>> Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
>> ---
>
> Apart from the minor commit logs oversights we consider these two
> patches ready to go, please let us know if there is something you want
> changed since we are at risk of missing yet another merge window.
>
> It is ARM64 specific code, we created and moved the code to its
> ARM64 specific directory and we are happy to maintain it as such,
> we need your ACK to get this done so if there is something you
> want changed please let us know otherwise I would ask your ACK
> on these two patches to give Marc a go-ahead for -next and
> hopefully 4.9.
Kindly reminder. Is there anything we need to do more about these
patches? Please let us know. Note this is the major thing for incoming
IORT more advance feature.
Thanks,
Tomasz
^ permalink raw reply
* [PATCH 4/4] mmc: sdhci-st: Handle interconnect clock
From: Ulf Hansson @ 2016-09-12 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908115849.GS4921@dell>
On 8 September 2016 at 13:58, Lee Jones <lee.jones@linaro.org> wrote:
> Sorry Adrian, left you of the list. Rectifying.
>
> FYI, this patch is due for the v4.8 -rcs:
>
> http://www.spinics.net/lists/kernel/msg2338219.html
>
>> Some ST platforms contain interconnect (ICN) clocks which must be handed
>> correctly in order to obtain full functionality of a given IP. In this
>> case, if the ICN clocks are not handled properly by the ST SDHCI driver
>> MMC will break and the following output can be observed:
>>
>> [ 13.916949] mmc0: Timeout waiting for hardware interrupt.
>> [ 13.922349] sdhci: =========== REGISTER DUMP (mmc0)===========
>> [ 13.928175] sdhci: Sys addr: 0x00000000 | Version: 0x00001002
>> [ 13.933999] sdhci: Blk size: 0x00007040 | Blk cnt: 0x00000001
>> [ 13.939825] sdhci: Argument: 0x00fffff0 | Trn mode: 0x00000013
>> [ 13.945650] sdhci: Present: 0x1fff0206 | Host ctl: 0x00000011
>> [ 13.951475] sdhci: Power: 0x0000000f | Blk gap: 0x00000080
>> [ 13.957300] sdhci: Wake-up: 0x00000000 | Clock: 0x00003f07
>> [ 13.963126] sdhci: Timeout: 0x00000004 | Int stat: 0x00000000
>> [ 13.968952] sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b
>> [ 13.974777] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
>> [ 13.980602] sdhci: Caps: 0x21ed3281 | Caps_1: 0x00000000
>> [ 13.986428] sdhci: Cmd: 0x0000063a | Max curr: 0x00000000
>> [ 13.992252] sdhci: Host ctl2: 0x00000000
>> [ 13.996166] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x7c048200
>> [ 14.001990] sdhci: ===========================================
>> [ 14.009802] mmc0: Got data interrupt 0x02000000 even though no data operation was in progress.
>>
>> A decent point was raised about minimising the use of a local variable that
>> we 'could' do without. I've chosen consistency over the possibility of
>> reducing the local variable count by 1. Thinking that it's more important
>> for the code to be grouped and authoured in a similar manner/style for
>> greater maintainability/readability.
>>
>> Cc: stable at vger.kernel.org
>> Tested-by: Peter Griffin <peter.griffin@linaro.org>
>> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Thanks, applied for fixes!
Adrian, please tell if you have any objections else I intend to send
this for the rcs later this week.
Kind regards
Uffe
>> ---
>> drivers/mmc/host/sdhci-st.c | 15 ++++++++++++++-
>> 1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/sdhci-st.c b/drivers/mmc/host/sdhci-st.c
>> index c95ba83..ed92ce7 100644
>> --- a/drivers/mmc/host/sdhci-st.c
>> +++ b/drivers/mmc/host/sdhci-st.c
>> @@ -28,6 +28,7 @@
>>
>> struct st_mmc_platform_data {
>> struct reset_control *rstc;
>> + struct clk *icnclk;
>> void __iomem *top_ioaddr;
>> };
>>
>> @@ -353,7 +354,7 @@ static int sdhci_st_probe(struct platform_device *pdev)
>> struct sdhci_host *host;
>> struct st_mmc_platform_data *pdata;
>> struct sdhci_pltfm_host *pltfm_host;
>> - struct clk *clk;
>> + struct clk *clk, *icnclk;
>> int ret = 0;
>> u16 host_version;
>> struct resource *res;
>> @@ -365,6 +366,11 @@ static int sdhci_st_probe(struct platform_device *pdev)
>> return PTR_ERR(clk);
>> }
>>
>> + /* ICN clock isn't compulsory, but use it if it's provided. */
>> + icnclk = devm_clk_get(&pdev->dev, "icn");
>> + if (IS_ERR(icnclk))
>> + icnclk = NULL;
>> +
>> rstc = devm_reset_control_get(&pdev->dev, NULL);
>> if (IS_ERR(rstc))
>> rstc = NULL;
>> @@ -389,6 +395,7 @@ static int sdhci_st_probe(struct platform_device *pdev)
>> }
>>
>> clk_prepare_enable(clk);
>> + clk_prepare_enable(icnclk);
>>
>> /* Configure the FlashSS Top registers for setting eMMC TX/RX delay */
>> res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
>> @@ -400,6 +407,7 @@ static int sdhci_st_probe(struct platform_device *pdev)
>> }
>>
>> pltfm_host->clk = clk;
>> + pdata->icnclk = icnclk;
>>
>> /* Configure the Arasan HC inside the flashSS */
>> st_mmcss_cconfig(np, host);
>> @@ -422,6 +430,7 @@ static int sdhci_st_probe(struct platform_device *pdev)
>> return 0;
>>
>> err_out:
>> + clk_disable_unprepare(icnclk);
>> clk_disable_unprepare(clk);
>> err_of:
>> sdhci_pltfm_free(pdev);
>> @@ -442,6 +451,8 @@ static int sdhci_st_remove(struct platform_device *pdev)
>>
>> ret = sdhci_pltfm_unregister(pdev);
>>
>> + clk_disable_unprepare(pdata->icnclk);
>> +
>> if (rstc)
>> reset_control_assert(rstc);
>>
>> @@ -462,6 +473,7 @@ static int sdhci_st_suspend(struct device *dev)
>> if (pdata->rstc)
>> reset_control_assert(pdata->rstc);
>>
>> + clk_disable_unprepare(pdata->icnclk);
>> clk_disable_unprepare(pltfm_host->clk);
>> out:
>> return ret;
>> @@ -475,6 +487,7 @@ static int sdhci_st_resume(struct device *dev)
>> struct device_node *np = dev->of_node;
>>
>> clk_prepare_enable(pltfm_host->clk);
>> + clk_prepare_enable(pdata->icnclk);
>>
>> if (pdata->rstc)
>> reset_control_deassert(pdata->rstc);
>
> --
> 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] dt-bindings: mmc: sdhci-st: Mention the discretionary "icn" clock
From: Ulf Hansson @ 2016-09-12 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160908091136.17301-4-lee.jones@linaro.org>
On 8 September 2016 at 11:11, Lee Jones <lee.jones@linaro.org> wrote:
> The interconnect (ICN) clock is required for functional working of
> MMC on some ST platforms. When not supplied it can result in
> broken MMC and the following output:
>
> [ 13.916949] mmc0: Timeout waiting for hardware interrupt.
> [ 13.922349] sdhci: =========== REGISTER DUMP (mmc0)===========
> [ 13.928175] sdhci: Sys addr: 0x00000000 | Version: 0x00001002
> [ 13.933999] sdhci: Blk size: 0x00007040 | Blk cnt: 0x00000001
> [ 13.939825] sdhci: Argument: 0x00fffff0 | Trn mode: 0x00000013
> [ 13.945650] sdhci: Present: 0x1fff0206 | Host ctl: 0x00000011
> [ 13.951475] sdhci: Power: 0x0000000f | Blk gap: 0x00000080
> [ 13.957300] sdhci: Wake-up: 0x00000000 | Clock: 0x00003f07
> [ 13.963126] sdhci: Timeout: 0x00000004 | Int stat: 0x00000000
> [ 13.968952] sdhci: Int enab: 0x02ff008b | Sig enab: 0x02ff008b
> [ 13.974777] sdhci: AC12 err: 0x00000000 | Slot int: 0x00000000
> [ 13.980602] sdhci: Caps: 0x21ed3281 | Caps_1: 0x00000000
> [ 13.986428] sdhci: Cmd: 0x0000063a | Max curr: 0x00000000
> [ 13.992252] sdhci: Host ctl2: 0x00000000
> [ 13.996166] sdhci: ADMA Err: 0x00000000 | ADMA Ptr: 0x7c048200
> [ 14.001990] sdhci: ===========================================
> [ 14.009802] mmc0: Got data interrupt 0x02000000 even though no data operation was in progress.
>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
Thanks, applied for fixes!
Kind regards
Uffe
> ---
> Documentation/devicetree/bindings/mmc/sdhci-st.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-st.txt b/Documentation/devicetree/bindings/mmc/sdhci-st.txt
> index 88faa91..3cd4c43 100644
> --- a/Documentation/devicetree/bindings/mmc/sdhci-st.txt
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-st.txt
> @@ -10,7 +10,7 @@ Required properties:
> subsystem (mmcss) inside the FlashSS (available in STiH407 SoC
> family).
>
> -- clock-names: Should be "mmc".
> +- clock-names: Should be "mmc" and "icn". (NB: The latter is not compulsory)
> See: Documentation/devicetree/bindings/resource-names.txt
> - clocks: Phandle to the clock.
> See: Documentation/devicetree/bindings/clock/clock-bindings.txt
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Mark Rutland @ 2016-09-12 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160912114406.GG23211@arm.com>
On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > some cleanup [1,2] that just landed in the arm64 for-next/core branch.
> >
> > Could you please rebase atop of that?
>
> Well, we should figure out what tree this is going through first. There
> are a mixture of arm, arm64, driver and dts changes here and not all
> of it is carrying the appropriate acks for me to queue it.
Given that mix, I had assumed that this would all go through the arm64
tree -- I see that Rob has already acked the binding, and I'm happy to
give my ack for the driver once that's in shape.
The dts change could go through arm-soc in parallel, I guess. It doesn't
look like arm-soc have been Cc'd for that, though.
Thanks,
Mark.
^ permalink raw reply
* ARM, SoC: About the use DT-defined properties by 3rd-party drivers
From: Sebastian Frias @ 2016-09-12 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOZdJXVjsR3NTWiJX33yT3jYk=FU65raWoMooTLD7OMN3sqP-A@mail.gmail.com>
Hi Timur,
On 08/28/2016 10:36 PM, Timur Tabi wrote:
> On Wed, Aug 24, 2016 at 9:29 AM, Sebastian Frias <sf84@laposte.net> wrote:
>>
>> If this is really not possible, it forces the SoC manufacturer to expose
>> those properties in a different way, thus wasting a (seemingly) perfectly
>> fine way of doing so: the DT and its documentation.
>
> When you submit a new driver upstream, that patch also includes the
> new device tree nodes and documentation for those nodes. Everything
> is peer-reviewed together. I don't understand what you think the
> problem is.
>
Thanks for your comment and sorry for the late reply.
My question is about submitting DT properties/nodes (describing some HW) for
which there is no Linux driver. Like register addresses for HW blocks,
including HW capabilities of said HW blocks, which may or may not be setup
by Linux directly.
The idea being that since DT describes the HW and is usually shared with the
bootloader (yet stored in the Linux kernel tree), all layers of the stack
could use the same DT and each layer would use relevant properties. So the
DT would describe the whole SoC even if not all HW blocks have a Linux
driver.
3rd party users of said SoC could then write kernel modules for such HW
blocks using the DT description. The DT would thus become the authoritative
source of information regarding register programming for the SoC.
Currently, HW blocks for which there is no public driver (that it is
accessed through user-mode libraries or firmware) require a separate
HW description (be it Documentation, headers, etc.)
Since the DT describes the HW, it would make sense to expose the HW through
DT, that would centralise the HW description.
However, after discussing over IRC, it looks like there was no guidance on
this. Some people think submitting DT properties/nodes without a corresponding
Linux driver is frowned upon, while others thought it was an odd limitation
and suggested asking here.
Does that clarifies the scope of the question?
Best regards,
Sebastian
^ permalink raw reply
* [PATCH v2 3/3] gpio: mxc: add generic gpio request/free callbacks to pinctrl
From: Linus Walleij @ 2016-09-12 12:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473299296-22458-4-git-send-email-vladimir_zapolskiy@mentor.com>
On Thu, Sep 8, 2016 at 3:48 AM, Vladimir Zapolskiy
<vladimir_zapolskiy@mentor.com> wrote:
> If a GPIO controller description in board DTB contains information
> about mappings between GPIOs and pads under IOMUX control use it to
> request and free GPIOs with respect to pinctrl/pinmux subsystems.
>
> One of immediate positive functional changes is inability to
> request non-existing GPIOs, i.e. if there is no pad such. Also
> pinctrl/pinmux may now properly account pads occupied by requested
> GPIOs.
>
> The change has no effect, if "gpio-ranges" property is not found
> including the case if a board has no DTB firmware.
>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> Changes from v1 to v2:
> * none
Patch applied with Shawn's ACK.
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox