* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Santosh Shilimkar @ 2014-01-31 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131164534.GL20736@saruman.home>
On Friday 31 January 2014 11:45 AM, Felipe Balbi wrote:
> On Fri, Jan 31, 2014 at 10:50:40AM -0500, Santosh Shilimkar wrote:
>> On Friday 31 January 2014 10:47 AM, Felipe Balbi wrote:
>>> On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote:
>>>> On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote:
>>>>> Hi,
>>>>>
>>>>> On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote:
>>>>>> The Keystone PM management layer has been implemented using PM bus for
>>>>>> power management clocks. As result, most of Keystone drivers don't need
>>>>>> to manage clocks directly. They just need to enable runtime PM and use it
>>>>>> to handle their PM state and clocks.
>>>>>>
>>>>>> Hence, remove clock management code and switch to use runtime PM.
>>>>>>
>>>>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>>>>>
>>>>> quite a few weeks back I sent a series enabling runtime pm for all glue
>>>>> layers. I'll use that version instead, sorry.
>>>>>
>>>> That should be fine but you need to drop clk_*() related code
>>>> from that patch. I assume you will send refresh version of it then.
>>>
>>> why ? it makes no difference if you enable twice and disable twice.
>>>
>> Sure but why do you want to have the clock node handling code in drivers
>> if it is not needed. Isn't that better ?
>
> It might, but then way that I wanted to see it is so that I can make
> assumptions about the device state. From a driver perspective, what I
> would love to see is the ability to assume that when my probe gets
> called the device is already enabled. So if you can make sure that
> clk_enable() happens before my probe and that you call
> pm_runtime_set_active() before my probe too, then I can more than
> hapilly remove clk_* calls from the driver ;-)
>
> either that or maintain the driver like so:
>
> probe()
> {
> ...
>
> clk_get(dev, "fck");
> clk_prepare(clk);
> clk_enable(clk);
> pm_runtime_set_active(dev);
> pm_runtime_enable(dev);
> pm_runtime_get_sync(dev);
> ...
> }
>
> runtime_suspend()
> {
> clk_disable(dev);
> }
>
> runtime_resume()
> {
> clk_enable(dev);
> }
>
> note that because of pm_runtime_set_active() that first
> pm_runtime_get_sync() in probe() will simply increase the reference
> counter without calling my ->runtime_resume() callback, which is exactly
> what we want, as that would completely avoid situations of bad context
> being restored because of that initial pm_runtime_get_sync().
>
Thanks for making your point bit clear.
> Then, we can even make pm_runtime completely async easily, because
> clk_prepare() was called only on probe() (or before it, for that
> matter).
>
> Bottomline is, if you can guarantee me that clk_get(), clk_prepare(),
> clk_enable() and pm_runtime_set_active() will be called properly before
> my probe, i'll be more than happy to comply with your request above as
> that will greatly simplify my driver.
>
Which is the case at least I see on Keystone. And hence the patch from
Grygorii works. I also noticed your proposal for wider platform to
enforce above behavior which seems to be a good idea.
> Just make, also, that if this clock is shared between dwc3-keystone
> wrapper and dwc3 core, you clk_get() on both driver's probe.
>
I understand. In summary, whichever patch you pick(yours) or Grygorii's,
its completely safe to remove the clock handling from Keystone USB driver.
Regards,
Santosh
^ permalink raw reply
* [PATCH 2/4] arm: qcom: Split Qualcomm support into legacy and multiplatform
From: Arnd Bergmann @ 2014-01-31 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391107002-21470-3-git-send-email-galak@codeaurora.org>
On Thursday 30 January 2014, Kumar Gala wrote:
> Introduce a new mach-qcom that will support SoCs that intend to be
> multiplatform compatiable while keeping mach-msm to legacy SoC/board
> support that will not transition over to multiplatform.
>
> As part of this, we move support for MSM8X60, MSM8960 and MSM8974 over
> to mach-qcom.
>
> Signed-off-by: Kumar Gala <galak@codeaurora.org>
> ---
> MAINTAINERS | 7 +++
> arch/arm/Kconfig | 7 +--
> arch/arm/Makefile | 1 +
> arch/arm/boot/dts/Makefile | 6 +--
> arch/arm/mach-msm/Kconfig | 45 +------------------
> arch/arm/mach-msm/Makefile | 7 ---
> arch/arm/mach-msm/hotplug.c | 51 ----------------------
> arch/arm/mach-qcom/Kconfig | 34 +++++++++++++++
> arch/arm/mach-qcom/Makefile | 5 +++
> .../arm/{mach-msm/board-dt.c => mach-qcom/board.c} | 9 ++--
> arch/arm/{mach-msm => mach-qcom}/scm-boot.c | 0
> arch/arm/{mach-msm => mach-qcom}/scm-boot.h | 0
> arch/arm/{mach-msm => mach-qcom}/scm.c | 0
> arch/arm/{mach-msm => mach-qcom}/scm.h | 0
> arch/arm/{mach-msm/platsmp.c => mach-qcom/smp.c} | 11 ++++-
The hotplug.c change sticks out as something that isn't just a move
of code to another place, but deletion of unused code. It would
be nice to split that out into a separate change, possibly together
with the trivial board.c and smp.c changes.
Arnd
^ permalink raw reply
* [PATCH 0/4] Split mach-msm into legacy and mach-qcom (multiplatform)
From: Olof Johansson @ 2014-01-31 19:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391107002-21470-1-git-send-email-galak@codeaurora.org>
On Thu, Jan 30, 2014 at 12:36:38PM -0600, Kumar Gala wrote:
> This is the starts of splitting the Qualcomm MSM platform into legacy support
> that we will not try and convert to multiplatform and multiplatform support.
> These patches are based on the 'CPU enable method based SMP' patches.
>
> I wanted to get these out for review, will add a few more patches for defconfig
> updates/additions, as well as some additional driver being enabled for ARCH_QCOM.
Series:
Acked-by: Olof Johansson <olof@lixom.net>
See comment on the MAINTAINERS addition; let me know how you prefer to send us
patches. We can apply from mailing lists we just need to know your preference.
-Olof
^ permalink raw reply
* [PATCH 2/4] arm: qcom: Split Qualcomm support into legacy and multiplatform
From: Olof Johansson @ 2014-01-31 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391107002-21470-3-git-send-email-galak@codeaurora.org>
On Thu, Jan 30, 2014 at 12:36:40PM -0600, Kumar Gala wrote:
> Introduce a new mach-qcom that will support SoCs that intend to be
> multiplatform compatiable while keeping mach-msm to legacy SoC/board
> support that will not transition over to multiplatform.
>
> As part of this, we move support for MSM8X60, MSM8960 and MSM8974 over
> to mach-qcom.
>
> Signed-off-by: Kumar Gala <galak@codeaurora.org>
> ---
> MAINTAINERS | 7 +++
> arch/arm/Kconfig | 7 +--
> arch/arm/Makefile | 1 +
> arch/arm/boot/dts/Makefile | 6 +--
> arch/arm/mach-msm/Kconfig | 45 +------------------
> arch/arm/mach-msm/Makefile | 7 ---
> arch/arm/mach-msm/hotplug.c | 51 ----------------------
> arch/arm/mach-qcom/Kconfig | 34 +++++++++++++++
> arch/arm/mach-qcom/Makefile | 5 +++
> .../arm/{mach-msm/board-dt.c => mach-qcom/board.c} | 9 ++--
> arch/arm/{mach-msm => mach-qcom}/scm-boot.c | 0
> arch/arm/{mach-msm => mach-qcom}/scm-boot.h | 0
> arch/arm/{mach-msm => mach-qcom}/scm.c | 0
> arch/arm/{mach-msm => mach-qcom}/scm.h | 0
> arch/arm/{mach-msm/platsmp.c => mach-qcom/smp.c} | 11 ++++-
> 15 files changed, 70 insertions(+), 113 deletions(-)
> delete mode 100644 arch/arm/mach-msm/hotplug.c
> create mode 100644 arch/arm/mach-qcom/Kconfig
> create mode 100644 arch/arm/mach-qcom/Makefile
> rename arch/arm/{mach-msm/board-dt.c => mach-qcom/board.c} (71%)
> rename arch/arm/{mach-msm => mach-qcom}/scm-boot.c (100%)
> rename arch/arm/{mach-msm => mach-qcom}/scm-boot.h (100%)
> rename arch/arm/{mach-msm => mach-qcom}/scm.c (100%)
> rename arch/arm/{mach-msm => mach-qcom}/scm.h (100%)
> rename arch/arm/{mach-msm/platsmp.c => mach-qcom/smp.c} (97%)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a31a6e3..1817078 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1174,6 +1174,13 @@ L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
> W: http://www.arm.linux.org.uk/
> S: Maintained
>
> +ARM/QUALCOMM SUPPORT
> +M: David Brown <davidb@codeaurora.org>
> +M: Kumar Gala <galak@codeaurora.org>
> +L: linux-arm-msm at vger.kernel.org
> +S: Maintained
> +F: arch/arm/mach-qcom/
Git repo? If you want us to apply patches for us we can do that, but if
you prefer to run a tree and do pull requests then you should have an
URL to it here.
-Olof
^ permalink raw reply
* [PATCH] Detect section mismatches in thumb relocations
From: David Long @ 2014-01-31 18:33 UTC (permalink / raw)
To: linux-arm-kernel
From: "David A. Long" <dave.long@linaro.org>
Add processing for normally encountered thumb relocation types so that
section mismatches will be detected.
Signed-off-by: David A. Long <dave.long@linaro.org>
---
scripts/mod/modpost.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 1785576..9e6c996 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1498,6 +1498,16 @@ static int addend_386_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r)
#define R_ARM_JUMP24 29
#endif
+#ifndef R_ARM_THM_CALL
+#define R_ARM_THM_CALL 10
+#endif
+#ifndef R_ARM_THM_JUMP24
+#define R_ARM_THM_JUMP24 30
+#endif
+#ifndef R_ARM_THM_JUMP19
+#define R_ARM_THM_JUMP19 51
+#endif
+
static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r)
{
unsigned int r_typ = ELF_R_TYPE(r->r_info);
@@ -1511,6 +1521,9 @@ static int addend_arm_rel(struct elf_info *elf, Elf_Shdr *sechdr, Elf_Rela *r)
case R_ARM_PC24:
case R_ARM_CALL:
case R_ARM_JUMP24:
+ case R_ARM_THM_CALL:
+ case R_ARM_THM_JUMP24:
+ case R_ARM_THM_JUMP19:
/* From ARM ABI: ((S + A) | T) - P */
r->r_addend = (int)(long)(elf->hdr +
sechdr->sh_offset +
--
1.8.1.2
^ permalink raw reply related
* [PATCH] of: add vendor prefix for Allwinner Technology
From: Rob Herring @ 2014-01-31 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391045798-7053-1-git-send-email-emilio@elopez.com.ar>
On Wed, Jan 29, 2014 at 7:36 PM, Emilio L?pez <emilio@elopez.com.ar> wrote:
> We have been using the "allwinner" prefix for everything so far; let's
> document it here.
>
> Signed-off-by: Emilio L?pez <emilio@elopez.com.ar>
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Applied.
Rob
>
> diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
> index edbb8d8..5a2904b 100644
> --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> @@ -7,6 +7,7 @@ ad Avionic Design GmbH
> adi Analog Devices, Inc.
> aeroflexgaisler Aeroflex Gaisler AB
> ak Asahi Kasei Corp.
> +allwinner Allwinner Technology Co., Ltd.
> altr Altera Corp.
> amcc Applied Micro Circuits Corporation (APM, formally AMCC)
> apm Applied Micro Circuits Corporation (APM)
> --
> 1.8.5.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* [RFC/PATCH] base: platform: add generic clock handling for platform-bus
From: Felipe Balbi @ 2014-01-31 18:12 UTC (permalink / raw)
To: linux-arm-kernel
Still TODO a commit log. Not for merging!!!!!
NYET-Signed-off-by: Felipe Balbi <balbi@ti.com>
---
This patch is an idea I've had recently in order to combine several different
PM implementations into the platform-bus.
This patch is bare minimum for platforms which need to handle functional and
interface clocks but the whole thing is made optional.
Note that this patch makes sure that by the time a platform_driver's probe is
called, we already have clocks enabled and pm_runtime_set_active() has been
called, thus making sure that a device driver's pm_runtime_get_sync() will
solely increase the pm usage counter.
I have *NOT* tested this anywhere *YET*, but I suppose it shouldn't cause any
issues since the clock API has ref counting too.
Would really like to get some review from several folks involved with ARM SoC
PM so that's the reason for the wide audience. If I have missed anybody, please
add them to Cc.
As mentioned above, this is *NOT* meant for merging, but serves as a starting
point for discussing some convergence of several PM domain implementations on
different arch/arm/mach-* directories.
For OMAP, this has the added benefit of removing clock handling from
omap_device/omap_hwmod and, thus, dropping the need for so many DT_CLK() tables
under drivers/clk/ti/
drivers/base/platform.c | 169 ++++++++++++++++++++++++++++++++++++++--
include/linux/platform_device.h | 9 +++
2 files changed, 173 insertions(+), 5 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 3a94b79..86aeb5b 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -484,6 +484,21 @@ static int platform_drv_probe(struct device *_dev)
if (ACPI_HANDLE(_dev))
acpi_dev_pm_attach(_dev, true);
+ dev->fck = devm_clk_get(_dev, "fck");
+ dev->ick = devm_clk_get(_dev, "ick");
+
+ if (!IS_ERR(dev->fck))
+ clk_prepare_enable(dev->fck);
+ else
+ dev->fck = NULL;
+
+ if (!IS_ERR(dev->ick))
+ clk_prepare_enable(dev->ick);
+ else
+ dev->ick = NULL;
+
+ pm_runtime_set_active(_dev);
+
ret = drv->probe(dev);
if (ret && ACPI_HANDLE(_dev))
acpi_dev_pm_detach(_dev, true);
@@ -507,6 +522,14 @@ static int platform_drv_remove(struct device *_dev)
struct platform_device *dev = to_platform_device(_dev);
int ret;
+ if (!IS_ERR(dev->ick))
+ clk_disable_unprepare(dev->ick);
+
+ if (!IS_ERR(dev->fck))
+ clk_disable_unprepare(dev->fck);
+
+ pm_runtime_set_suspended(_dev);
+
ret = drv->remove(dev);
if (ACPI_HANDLE(_dev))
acpi_dev_pm_detach(_dev, true);
@@ -780,6 +803,59 @@ static int platform_legacy_resume(struct device *dev)
#endif /* CONFIG_PM_SLEEP */
+#ifdef CONFIG_PM_RUNTIME
+int platform_pm_runtime_suspend(struct device *dev)
+{
+ struct device_driver *drv = dev->driver;
+ struct platform_driver *pdrv = to_platform_driver(drv);
+ struct platform_device *pdev = to_platform_device(dev);
+ int ret;
+
+ ret = pm_generic_runtime_suspend(dev);
+ if (ret)
+ return ret;
+
+ if (!test_bit(PLATFORM_PM_RUNTIME_KEEP_ICK, &pdrv->flags))
+ clk_disable(pdev->ick);
+
+ if (!test_bit(PLATFORM_PM_RUNTIME_KEEP_FCK, &pdrv->flags))
+ clk_disable(pdev->fck);
+
+ return ret;
+}
+
+int platform_pm_runtime_resume(struct device *dev)
+{
+ struct device_driver *drv = dev->driver;
+ struct platform_driver *pdrv = to_platform_driver(drv);
+ struct platform_device *pdev = to_platform_device(dev);
+ int ret;
+
+ if (!test_bit(PLATFORM_PM_RUNTIME_KEEP_ICK, &pdrv->flags)) {
+ ret = clk_enable(pdev->ick);
+ if (ret)
+ return ret;
+ }
+
+ if (!test_bit(PLATFORM_PM_RUNTIME_KEEP_FCK, &pdrv->flags)) {
+ ret = clk_enable(pdev->fck);
+ if (ret) {
+ clk_disable(pdev->ick);
+ return ret;
+ }
+ }
+
+ ret = pm_generic_runtime_suspend(dev);
+ if (ret) {
+ clk_disable(pdev->ick);
+ clk_disable(pdev->fck);
+ return ret;
+ }
+
+ return ret;
+}
+#endif
+
#ifdef CONFIG_SUSPEND
int platform_pm_suspend(struct device *dev)
@@ -790,6 +866,9 @@ int platform_pm_suspend(struct device *dev)
if (!drv)
return 0;
+ if (pm_runtime_suspended(dev))
+ return 0;
+
if (drv->pm) {
if (drv->pm->suspend)
ret = drv->pm->suspend(dev);
@@ -802,12 +881,27 @@ int platform_pm_suspend(struct device *dev)
int platform_pm_resume(struct device *dev)
{
+ struct platform_device *pdev = to_platform_device(dev);
struct device_driver *drv = dev->driver;
int ret = 0;
if (!drv)
return 0;
+ ret = clk_enable(pdev->ick);
+ if (ret)
+ return ret;
+
+ ret = clk_enable(pdev->fck);
+ if (ret) {
+ clk_disable(pdev->ick);
+ return ret;
+ }
+
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
if (drv->pm) {
if (drv->pm->resume)
ret = drv->pm->resume(dev);
@@ -815,7 +909,17 @@ int platform_pm_resume(struct device *dev)
ret = platform_legacy_resume(dev);
}
- return ret;
+ if (ret) {
+ clk_disable(pdev->ick);
+ clk_disable(pdev->fck);
+ pm_runtime_disable(dev);
+ pm_runtime_set_suspended(dev);
+ pm_runtime_enable(dev);
+
+ return ret;
+ }
+
+ return 0;
}
#endif /* CONFIG_SUSPEND */
@@ -830,6 +934,9 @@ int platform_pm_freeze(struct device *dev)
if (!drv)
return 0;
+ if (pm_runtime_suspended(dev))
+ return 0;
+
if (drv->pm) {
if (drv->pm->freeze)
ret = drv->pm->freeze(dev);
@@ -848,6 +955,20 @@ int platform_pm_thaw(struct device *dev)
if (!drv)
return 0;
+ ret = clk_enable(pdev->ick);
+ if (ret)
+ return ret;
+
+ ret = clk_enable(pdev->fck);
+ if (ret) {
+ clk_disable(pdev->ick);
+ return ret;
+ }
+
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
if (drv->pm) {
if (drv->pm->thaw)
ret = drv->pm->thaw(dev);
@@ -855,7 +976,17 @@ int platform_pm_thaw(struct device *dev)
ret = platform_legacy_resume(dev);
}
- return ret;
+ if (ret) {
+ clk_disable(pdev->ick);
+ clk_disable(pdev->fck);
+ pm_runtime_disable(dev);
+ pm_runtime_set_suspended(dev);
+ pm_runtime_enable(dev);
+
+ return ret;
+ }
+
+ return 0;
}
int platform_pm_poweroff(struct device *dev)
@@ -866,6 +997,9 @@ int platform_pm_poweroff(struct device *dev)
if (!drv)
return 0;
+ if (pm_runtime_suspended(dev))
+ return 0;
+
if (drv->pm) {
if (drv->pm->poweroff)
ret = drv->pm->poweroff(dev);
@@ -884,6 +1018,20 @@ int platform_pm_restore(struct device *dev)
if (!drv)
return 0;
+ ret = clk_enable(pdev->ick);
+ if (ret)
+ return ret;
+
+ ret = clk_enable(pdev->fck);
+ if (ret) {
+ clk_disable(pdev->ick);
+ return ret;
+ }
+
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
if (drv->pm) {
if (drv->pm->restore)
ret = drv->pm->restore(dev);
@@ -891,14 +1039,25 @@ int platform_pm_restore(struct device *dev)
ret = platform_legacy_resume(dev);
}
- return ret;
+ if (ret) {
+ clk_disable(pdev->ick);
+ clk_disable(pdev->fck);
+ pm_runtime_disable(dev);
+ pm_runtime_set_suspended(dev);
+ pm_runtime_enable(dev);
+
+ return ret;
+ }
+
+ return 0;
}
#endif /* CONFIG_HIBERNATE_CALLBACKS */
static const struct dev_pm_ops platform_dev_pm_ops = {
- .runtime_suspend = pm_generic_runtime_suspend,
- .runtime_resume = pm_generic_runtime_resume,
+ SET_RUNTIME_PM_OPS(platform_pm_runtime_suspend,
+ platform_pm_runtime_resume,
+ NULL)
USE_PLATFORM_PM_SLEEP_OPS
};
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index 16f6654..91133f5 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -12,6 +12,7 @@
#define _PLATFORM_DEVICE_H_
#include <linux/device.h>
+#include <linux/clk.h>
#include <linux/mod_devicetable.h>
#define PLATFORM_DEVID_NONE (-1)
@@ -21,6 +22,10 @@ struct mfd_cell;
struct platform_device {
const char *name;
+
+ struct clk *fck;
+ struct clk *ick;
+
int id;
bool id_auto;
struct device dev;
@@ -179,8 +184,12 @@ struct platform_driver {
struct device_driver driver;
const struct platform_device_id *id_table;
bool prevent_deferred_probe;
+ unsigned long flags;
};
+#define PLATFORM_PM_RUNTIME_KEEP_ICK BIT(0)
+#define PLATFORM_PM_RUNTIME_KEEP_FCK BIT(1)
+
#define to_platform_driver(drv) (container_of((drv), struct platform_driver, \
driver))
--
1.8.5.2
^ permalink raw reply related
* Extending OPP bindings
From: Lorenzo Pieralisi @ 2014-01-31 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAL_Jsq+Kq9C39xr9tY8gSX+6QFkNDqwmTyC+dBhLNcxKMweCpw@mail.gmail.com>
Hi Rob,
thanks for having a look.
On Fri, Jan 31, 2014 at 05:17:51PM +0000, Rob Herring wrote:
> On Fri, Jan 31, 2014 at 6:46 AM, Lorenzo Pieralisi
> <lorenzo.pieralisi@arm.com> wrote:
> > Hi Nishanth,
> >
> > On Fri, Jan 31, 2014 at 12:43:54AM +0000, Nishanth Menon wrote:
> >> Hi Sudeep,
> >>
> >> On 01/30/2014 07:43 AM, Sudeep Holla wrote:
> >>
> >> >
> >> > I am looking into a couple shortcomings in the current OPP bindings and
> >> > how to address them. Feel free to add to the list if you think of any more
> >> > issues that needs to be addressed or if and how any problem mentioned below
> >> > can be handled with the existing bindings.
> >> >
> >> > 1. indexing: currently there are no indices in the operating-points.
> >> indexing is based on frequency which is why the accessors use
> >> frequency to pull out the OPP data.
> >>
> >> indexing is a horrible idea - on platforms where OPP may be disabled
> >> or enabled for various reasons(see arch/arm/mach-imx/mach-imx6q.c,
> >> arch/arm/mach-omap2/board-omap3beagle.c etc) - the indexing you see in
> >> dts is just a myth that may not exist once the nodes are loaded and
> >> operated upon depending on SoC variations (example efuse describing
> >> which OPPs can be used and which not).
> >
> > I do not understand why. As long as a mapping from DT to data structures
> > in the kernel is done at boot, I can see how by indexing device nodes
> > can refer to specific OPPs. If they are disabled, amen, as long as we
> > can point at specific operating points that should be ok.
> >
> > Indexing does not mean that the index in the DT is the same as the one
> > allocated by the OS. Indexing is there to point at specific OPPs from
> > different DT nodes, a good example are clock bindings and that's exactly
> > how they work.
>
> That is not a good comparison. With clocks, you are describing which
> physical signal coming out of a hardware block much like interrupts.
> Granted the h/w is not typically documented that way for clocks
> although the numbering could correspond to register bit locations as
> interrupt numbers do. With OPP indexes, they are a totally made up
> software construct.
Well ok, it might be, what I know is that current OPPs do not allow
other nodes to reference their properties properly, I am not sure that adding
an index make things worse, actually they are already broken as they are.
> Perhaps OPPs should be nodes so new fields can be added easily and
> then you have a phandle for each OPP.
Yeah, but the end result is the same, it has more to do with how to
express dependencies with DT than the question on whether to use a phandle
or an index. If we have to add phandles so be it, it is still just a way
to reference properties for me.
> > Can you provide me with an example where the indexing would go wrong
> > please ?
>
> Putting s/w indexes into DT. Using cell-index for uarts to define
> their tty number was one example.
The idea was not related to using that index in the kernel at all, but
since you are all against using this mechanism, I think that's for a good
reason so we will not do that. How to do it, it has to be seen though.
> > Certainly relying on implicit ordering is not great either, actually I
> > would say that it is broken.
> >
> >> That said, the original OPP[1][2] series discussion started by trying
> >> to kill indexing precisely for the same reason.. once you have it - it
> >> becomes just crazy to deal with.
> >
> > I could not find any "index killing" :) discussion in there, but I will
> > keep reading.
> >
> >> > It's assumed that the list is either in ascending or descending
> >> > order of frequency but not explicit in the binding document.
> >> > There are arch/arm/boot/dts/* files with opps in both styles.
> >> it should not matter -> opp library should do an insertion sort and
> >> organize it in ascending order once all the data is inserted. (line
> >> 449ish in opp.c)
> >
> > That's OS details and they must not be mandated by the bindings.
> > We cannot rely on word of mouth for things to work, I do not like
> > implicit rules, so the bindings should speficy the ordering or better
> > a way to reference OPPs.
> >
> >> if you see issues with the insertion sort not functioning, it is a bug
> >> and should be easy to track down and fix.
> >
> > Problem is not the insertion sort, problem is that DT bindings do not
> > define a way to refer to a specific OPP, unless we do that implicitly
> > and again, I rest my case, that is broken.
> >
> >> > Few other bindings like thermal defines bindings like
> >> > cooling-{min,max}-state assuming some order which is broken IMO.
> >> Now that you bring it up, I missed it :(.. yeah, I might have
> >> preferred it to be min frequency and max_frequency - I agree it is
> >> probably broken. I'd let Eduardo comment more about it.
> >>
> >> >
> >> > One such use-case that came up recently[0] is the c-state latencies
> >> > which could be different for each OPP. It would be good if the
> >> > latencies are specified with the indices to OPP table to avoid
> >> > inconsistency between the bindings.
> >>
> >> You can define C states based on frequencies as well - which really
> >> makes sense - since that sounds really like our constraint (say
> >> valid-at-frequency "xyz"
> >
> > I do not think that's generic enough, I do not like the idea of looking
> > up frequencies (eg a C-state target_residency does not depend on the
> > frequency only - ie voltage and other factors play a role, it really
> > depends on an operating point- looking it up by frequency is misleading IMO).
>
> It seems we are trying to fit a square peg into a round hole here.
Do you mean that this is something not worth describing ? That it has to
be described differently ? Or that current DT semantics is not suitable for
describing it ?
We have to find a solution and we are keen on reworking it, otherwise we just
pretend there are no dependencies on the OPPs from other DT nodes, but I
am afraid that's already the case now.
Thank you,
Lorenzo
^ permalink raw reply
* [GIT PULL] arm64 patches for 3.14
From: Catalin Marinas @ 2014-01-31 18:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull the arm64 patches below. Thanks.
The following changes since commit 883c057367014d20a14b5054e4eb0d81ce3bea5c:
arm64: fix typo in entry.S (2014-01-13 13:55:13 +0000)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux tags/arm64-upstream
for you to fetch changes up to c2c93e5b7f3f42277ec25ff3746096abc0c0d0f7:
arm64: mm: Introduce PTE_WRITE (2014-01-31 11:30:49 +0000)
----------------------------------------------------------------
- Build fix with DMA_CMA enabled
- Introduction of PTE_WRITE to distinguish between writable but clean
and truly read-only pages
- FIQs enabling/disabling clean-up (they aren't used on arm64)
- CPU resume fix for the per-cpu offset restoring
- Code comment typos
----------------------------------------------------------------
Jingoo Han (3):
arm64: mm: use ubfm for dcache_line_size
arm64: mm: fix the function name in comment of __flush_dcache_area
arm64: mm: fix the function name in comment of cpu_do_switch_mm
Lorenzo Pieralisi (1):
arm64: kernel: fix per-cpu offset restore on resume
Nicolas Pitre (1):
arm64: FIQs are unused
Pankaj Dubey (1):
arm64: fix build error if DMA_CMA is enabled
Steve Capper (2):
arm64: mm: Remove PTE_BIT_FUNC macro
arm64: mm: Introduce PTE_WRITE
arch/arm64/include/asm/dma-contiguous.h | 1 -
arch/arm64/include/asm/pgtable.h | 93 ++++++++++++++++++++++-----------
arch/arm64/kernel/process.c | 6 ---
arch/arm64/kernel/smp.c | 2 -
arch/arm64/kernel/suspend.c | 8 +++
arch/arm64/mm/cache.S | 2 +-
arch/arm64/mm/proc-macros.S | 3 +-
arch/arm64/mm/proc.S | 2 +-
8 files changed, 74 insertions(+), 43 deletions(-)
--
Catalin
^ permalink raw reply
* [PATCH] arm: document "mach-virt" platform.
From: Rob Herring @ 2014-01-31 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA8CFE.7020404@arm.com>
On Thu, Jan 30, 2014 at 11:33 AM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On 30/01/14 17:28, Arnd Bergmann wrote:
>> On Thursday 30 January 2014, Ian Campbell wrote:
>>> mach-virt has existed for a while but it is not written down what it actually
>>> consists of. Although it seems a bit unusual to document a binding for an
>>> entire platform since mach-virt is entirely virtual it is helpful to have
>>> something to refer to in the absence of a single concrete implementation.
>>>
>>> I've done my best to capture the requirements based on the git log and my
>>> memory/understanding.
>>>
>>> While here remove the xenvm dts example, the Xen tools will now build a
>>> suitable mach-virt compatible dts when launching the guest.
>>
>> It might be worth noting in the changeset comment that the 'compatible'
>> string is actually no longer needed on newer kernels: All the members
>> of the machine descriptor are now the defaults (we should remove the
>> virt_init() function as well), and the fallback machine descriptor should
>> work just fine if any other string gets passed.
>
> I will ack the patch that removes the mach-virt directory altogether!
Did I never send that one out? I know I started something. Finding new
employment has had me distracted...
Rob
^ permalink raw reply
* [PATCH v2] dma: Add Xilinx AXI Video Direct Memory Access Engine driver support
From: Andy Gross @ 2014-01-31 17:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E2698B.6070001@metafoo.de>
On Fri, Jan 24, 2014 at 02:24:27PM +0100, Lars-Peter Clausen wrote:
> On 01/24/2014 12:16 PM, Srikanth Thokala wrote:
> > Hi Lars,
> >
> > On Thu, Jan 23, 2014 at 4:55 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> >> On 01/22/2014 05:52 PM, Srikanth Thokala wrote:
> >> [...]
> >>> +/**
> >>> + * xilinx_vdma_device_control - Configure DMA channel of the device
> >>> + * @dchan: DMA Channel pointer
> >>> + * @cmd: DMA control command
> >>> + * @arg: Channel configuration
> >>> + *
> >>> + * Return: '0' on success and failure value on error
> >>> + */
> >>> +static int xilinx_vdma_device_control(struct dma_chan *dchan,
> >>> + enum dma_ctrl_cmd cmd, unsigned long arg)
> >>> +{
> >>> + struct xilinx_vdma_chan *chan = to_xilinx_chan(dchan);
> >>> +
> >>> + switch (cmd) {
> >>> + case DMA_TERMINATE_ALL:
> >>> + xilinx_vdma_terminate_all(chan);
> >>> + return 0;
> >>> + case DMA_SLAVE_CONFIG:
> >>> + return xilinx_vdma_slave_config(chan,
> >>> + (struct xilinx_vdma_config *)arg);
> >>
> >> You really shouldn't be overloading the generic API with your own semantics.
> >> DMA_SLAVE_CONFIG should take a dma_slave_config and nothing else.
> >
> > Ok. The driver needs few additional configuration from the slave
> > device like Vertical
> > Size, Horizontal Size, Stride etc., for the DMA transfers, in that case do you
> > suggest me to define a separate dma_ctrl_cmd like the one FSLDMA_EXTERNAL_START
> > defined for Freescale drivers?
>
> In my opinion it is not a good idea to have driver implement a generic API,
> but at the same time let the driver have custom semantics for those API
> calls. It's a bit like having a gpio driver that expects 23 and 42 as the
> values passed to gpio_set_value instead of 0 and 1. It completely defeats
> the purpose of a generic API, namely that you are able to write generic code
> that makes use of the API without having to know about which implementation
> API it is talking to. The dmaengine framework provides the
> dmaengine_prep_interleaved_dma() function to setup two dimensional
> transfers, e.g. take a look at sirf-dma.c or imx-dma.c.
>
The comments in the include/linux/dmaengine.h state that if you have
non-generic, non-fixed configuration then you can just create your own
structure and embed the dma_slave_config. Using the container_of you can get
back your structure.
I agree that we should always use the generic structure if possible, but
sometimes there are some non-standard things that you have to do for your
hardware. I am currently in a bind for adding some quirky features that are
required by peripherals who want to use the QCOM DMA devices.
If the context field in prep_slave_sg and prep_dma_cyclic was exposed to
everyone, that would allow an easy way to pass in hardware specific
configuration without bastardizing the slave_config. I noticed that rapidio is
the only consumer of that field and that they have their own prep function.
If we are not going to allow people to do their own slave_config when they need
to, then we need to remove the comments from the include file and expose the
context to the dmaengine_prep_slave_sg and dmaengine_prep_dma_cyclic.
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH] ARM: zynq: Reserve not DMAable space in front of the kernel
From: Rob Herring @ 2014-01-31 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <780bb8c8fd752eeace2fd2fbe1d8ed8572dc0d76.1391170073.git.michal.simek@xilinx.com>
On Fri, Jan 31, 2014 at 6:08 AM, Michal Simek <michal.simek@xilinx.com> wrote:
> Reserve space from 0x0 - __pa(swapper_pg_dir),
> if kernel is loaded from 0, which is not DMAable.
> It is causing problem with MMC driver and others
> which want to add dma buffers to this space.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
>
> Jason: I don't think it is worth to bring 0x8000 magic
> value and count minimum from it and phys_addr of swapper_pg_dir.
> Full 512k of memory shouldn't be used by DMA.
>
> ---
> arch/arm/mach-zynq/common.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
The existing DT reserved range can't be used for this purpose?
Rob
>
> diff --git a/arch/arm/mach-zynq/common.c b/arch/arm/mach-zynq/common.c
> index 1db2a5ca..8c09a83 100644
> --- a/arch/arm/mach-zynq/common.c
> +++ b/arch/arm/mach-zynq/common.c
> @@ -25,6 +25,7 @@
> #include <linux/of_irq.h>
> #include <linux/of_platform.h>
> #include <linux/of.h>
> +#include <linux/memblock.h>
> #include <linux/irqchip.h>
> #include <linux/irqchip/arm-gic.h>
>
> @@ -41,6 +42,18 @@
>
> void __iomem *zynq_scu_base;
>
> +/**
> + * zynq_memory_init - Initialize special memory
> + *
> + * We need to stop things allocating the low memory as DMA can't work in
> + * the 1st 512K of memory.
> + */
> +static void __init zynq_memory_init(void)
> +{
> + if (!__pa(PAGE_OFFSET))
> + memblock_reserve(__pa(PAGE_OFFSET), __pa(swapper_pg_dir));
> +}
> +
> static struct platform_device zynq_cpuidle_device = {
> .name = "cpuidle-zynq",
> };
> @@ -117,5 +130,6 @@ DT_MACHINE_START(XILINX_EP107, "Xilinx Zynq Platform")
> .init_machine = zynq_init_machine,
> .init_time = zynq_timer_init,
> .dt_compat = zynq_dt_match,
> + .reserve = zynq_memory_init,
> .restart = zynq_system_reset,
> MACHINE_END
> --
> 1.8.2.3
>
^ permalink raw reply
* [PATCH 07/10] watchdog: xilinx: Fix OF binding
From: Rob Herring @ 2014-01-31 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <26d172891694e4041e73b7dae85a1848adf38034.1391177880.git.michal.simek@xilinx.com>
On Fri, Jan 31, 2014 at 8:18 AM, Michal Simek <michal.simek@xilinx.com> wrote:
> Use of_property_read_u32 functions to clean OF probing.
The subject is a bit misleading as this doesn't really fix anything.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> ---
>
> drivers/watchdog/of_xilinx_wdt.c | 25 ++++++++++---------------
> 1 file changed, 10 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/watchdog/of_xilinx_wdt.c b/drivers/watchdog/of_xilinx_wdt.c
> index c229cc4..475440a6 100644
> --- a/drivers/watchdog/of_xilinx_wdt.c
> +++ b/drivers/watchdog/of_xilinx_wdt.c
> @@ -147,8 +147,7 @@ static u32 xwdt_selftest(struct xwdt_device *xdev)
> static int xwdt_probe(struct platform_device *pdev)
> {
> int rc;
> - u32 *tmptr;
> - u32 *pfreq;
> + u32 pfreq, enable_once;
> struct resource *res;
> struct xwdt_device *xdev;
> bool no_timeout = false;
> @@ -168,28 +167,24 @@ static int xwdt_probe(struct platform_device *pdev)
> if (IS_ERR(xdev->base))
> return PTR_ERR(xdev->base);
>
> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
> - "clock-frequency", NULL);
> -
> - if (pfreq == NULL) {
> + rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency", &pfreq);
> + if (rc) {
> dev_warn(&pdev->dev,
> "The watchdog clock frequency cannot be obtained\n");
> no_timeout = true;
You can kill this...
> }
>
> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
> - "xlnx,wdt-interval", NULL);
> - if (tmptr == NULL) {
> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
> + &xdev->wdt_interval);
> + if (rc) {
> dev_warn(&pdev->dev,
> "Parameter \"xlnx,wdt-interval\" not found\n");
> no_timeout = true;
and this...
> - } else {
> - xdev->wdt_interval = *tmptr;
> }
>
> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
> - "xlnx,wdt-enable-once", NULL);
> - if (tmptr == NULL) {
> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
> + &enable_once);
> + if (!rc && enable_once) {
> dev_warn(&pdev->dev,
> "Parameter \"xlnx,wdt-enable-once\" not found\n");
> watchdog_set_nowayout(xilinx_wdt_wdd, true);
> @@ -201,7 +196,7 @@ static int xwdt_probe(struct platform_device *pdev)
> */
> if (!no_timeout)
and use "if (pfreq && xdev->wdt_interval)" if you initialize pfreq to 0.
> xilinx_wdt_wdd->timeout = 2 * ((1 << xdev->wdt_interval) /
> - *pfreq);
> + pfreq);
Is the wdog really usable if the timeout properties are missing? Seems
like you should fail to probe rather than warn.
Rob
^ permalink raw reply
* [PATCH v5 00/20] Armada 370/XP watchdog support
From: Willy Tarreau @ 2014-01-31 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129181949.GB27143@localhost>
On Wed, Jan 29, 2014 at 03:19:50PM -0300, Ezequiel Garcia wrote:
> On Mon, Jan 27, 2014 at 12:27:00PM -0300, Ezequiel Garcia wrote:
> > A new round, mostly fixing some minor nitpicks.
> >
>
> If anyone wants to give this a test, here's a public branch:
>
> https://github.com/MISL-EBU-System-SW/mainline-public/tree/wdt_for_v3.14_v5
Tested-By: Willy Tarreau <w@1wt.eu>
Works like a charm on the mirabox, I've long been missing a hardware
watchdog to save me from unplugging the power cord after some hangs
during development.
Thanks,
Willy
^ permalink raw reply
* [PATCH] arm: dma-mapping: Add support to extend DMA IOMMU mappings
From: Andreas Herrmann @ 2014-01-31 17:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130084413.GC13543@alberich>
Instead of using just one bitmap to keep track of IO virtual addresses
(handed out for IOMMU use) introduce an array of bitmaps. This allows
us to extend existing mappings when running out of iova space in the
initial mapping etc.
If there is not enough space in the mapping to service an IO virtual
address allocation request, __alloc_iova() tries to extend the mapping
-- by allocating another bitmap -- and makes another allocation
attempt using the freshly allocated bitmap.
This allows arm iommu drivers to start with a decent initial size when
an dma_iommu_mapping is created and still to avoid running out of IO
virtual addresses for the mapping.
A new parameter is introduced for arm_iommu_create_mapping:
int extensions
Specifies how often the initial mapping of size bytes can be
extended by another address range of size bytes. Thus if
extensions = 0 is passed the mapping won't be extended at
all.
Adapt existing calls to arm_iommu_create_mapping in exynos_drm_iommu.c
and shmobile-iommu.c such that they do not make use of the extension
feature.
Adapt existing call to arm_iommu_create_mapping in arm-smmu.c such
that the extension feature will be used. (The resulting maximum
mapping size is 4GB.)
Tests were done on Calxeda ECX-2000 with smmu for sata and xgmac.
I've used SZ_512K for the size of the mapping and 31 for the
extensions parameter.
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Hiroshi Doyu <hdoyu@nvidia.com>
Cc: Joerg Roedel <joro@8bytes.org>
Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com>
---
arch/arm/include/asm/dma-iommu.h | 12 ++-
arch/arm/mm/dma-mapping.c | 135 ++++++++++++++++++++++++-----
drivers/gpu/drm/exynos/exynos_drm_iommu.c | 4 +-
drivers/iommu/arm-smmu.c | 2 +-
drivers/iommu/shmobile-iommu.c | 2 +-
5 files changed, 126 insertions(+), 29 deletions(-)
Hi Marek, Will,
Here is a 2nd attempt to implement this feature. This time using
an array of bitmaps. The initial size for the mapping will be used
to extend the mapping if running out of unused IO addresses.
Comments welcome.
Regards,
Andreas
diff --git a/arch/arm/include/asm/dma-iommu.h b/arch/arm/include/asm/dma-iommu.h
index a8c56ac..e12c6c2 100644
--- a/arch/arm/include/asm/dma-iommu.h
+++ b/arch/arm/include/asm/dma-iommu.h
@@ -13,8 +13,12 @@ struct dma_iommu_mapping {
/* iommu specific data */
struct iommu_domain *domain;
- void *bitmap;
- size_t bits;
+ unsigned long **bitmaps; /* array of bitmaps */
+ unsigned int nr_bitmaps; /* nr of elements in array */
+ unsigned int extensions;
+ size_t bitmap_size; /* size of a sinble bitmap */
+ size_t bits; /* per bitmap */
+ unsigned int size; /* per bitmap */
unsigned int order;
dma_addr_t base;
@@ -23,8 +27,8 @@ struct dma_iommu_mapping {
};
struct dma_iommu_mapping *
-arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
- int order);
+arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
+ int order, int extensions);
void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping);
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index f61a570..bd9cd22 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1069,6 +1069,8 @@ fs_initcall(dma_debug_do_init);
/* IOMMU */
+static int extend_iommu_mapping(struct dma_iommu_mapping *mapping);
+
static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping,
size_t size)
{
@@ -1076,6 +1078,8 @@ static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping,
unsigned int align = 0;
unsigned int count, start;
unsigned long flags;
+ dma_addr_t iova;
+ int i;
if (order > CONFIG_ARM_DMA_IOMMU_ALIGNMENT)
order = CONFIG_ARM_DMA_IOMMU_ALIGNMENT;
@@ -1087,30 +1091,78 @@ static inline dma_addr_t __alloc_iova(struct dma_iommu_mapping *mapping,
align = (1 << (order - mapping->order)) - 1;
spin_lock_irqsave(&mapping->lock, flags);
- start = bitmap_find_next_zero_area(mapping->bitmap, mapping->bits, 0,
- count, align);
- if (start > mapping->bits) {
- spin_unlock_irqrestore(&mapping->lock, flags);
- return DMA_ERROR_CODE;
+ for (i = 0; i < mapping->nr_bitmaps; i++) {
+ start = bitmap_find_next_zero_area(mapping->bitmaps[i],
+ mapping->bits, 0, count, align);
+
+ if (start > mapping->bits)
+ continue;
+
+ bitmap_set(mapping->bitmaps[i], start, count);
+ break;
}
- bitmap_set(mapping->bitmap, start, count);
+ /*
+ * No unused range found. Try to extend the existing mapping
+ * and perform a second attempt to reserve an IO virtual
+ * address range of size bytes.
+ */
+ if (i == mapping->nr_bitmaps) {
+ if (extend_iommu_mapping(mapping)) {
+ spin_unlock_irqrestore(&mapping->lock, flags);
+ return DMA_ERROR_CODE;
+ }
+ pr_err("extended iommu mapping\n");
+ start = bitmap_find_next_zero_area(mapping->bitmaps[i],
+ mapping->bits, 0, count, align);
+
+ if (start > mapping->bits) {
+ spin_unlock_irqrestore(&mapping->lock, flags);
+ return DMA_ERROR_CODE;
+ }
+
+ bitmap_set(mapping->bitmaps[i], start, count);
+ }
spin_unlock_irqrestore(&mapping->lock, flags);
- return mapping->base + (start << (mapping->order + PAGE_SHIFT));
+ iova = mapping->base + (mapping->size * i);
+ iova += start << (mapping->order + PAGE_SHIFT);
+
+ return iova;
}
static inline void __free_iova(struct dma_iommu_mapping *mapping,
dma_addr_t addr, size_t size)
{
- unsigned int start = (addr - mapping->base) >>
- (mapping->order + PAGE_SHIFT);
- unsigned int count = ((size >> PAGE_SHIFT) +
- (1 << mapping->order) - 1) >> mapping->order;
+ unsigned int start, count;
unsigned long flags;
+ dma_addr_t bitmap_base;
+ u32 bitmap_index;
+
+ if (!size)
+ return;
+
+ bitmap_index = (u32) (addr - mapping->base) / (u32) mapping->size;
+ BUG_ON(addr < mapping->base || bitmap_index > mapping->extensions);
+
+ bitmap_base = mapping->base + mapping->size * bitmap_index;
+
+ start = (addr - bitmap_base) >> (mapping->order + PAGE_SHIFT);
+
+ if (addr + size > bitmap_base + mapping->size) {
+ /*
+ * The address range to be freed reaches into the iova
+ * range of the next bitmap. This should not happen as
+ * we don't allow this in __alloc_iova (at the
+ * moment).
+ */
+ BUG();
+ } else
+ count = ((size >> PAGE_SHIFT) +
+ (1 << mapping->order) - 1) >> mapping->order;
spin_lock_irqsave(&mapping->lock, flags);
- bitmap_clear(mapping->bitmap, start, count);
+ bitmap_clear(mapping->bitmaps[bitmap_index], start, count);
spin_unlock_irqrestore(&mapping->lock, flags);
}
@@ -1875,22 +1927,30 @@ struct dma_map_ops iommu_coherent_ops = {
* arm_iommu_create_mapping
* @bus: pointer to the bus holding the client device (for IOMMU calls)
* @base: start address of the valid IO address space
- * @size: size of the valid IO address space
+ * @size: (initial) size of the valid IO address space
* @order: accuracy of the IO addresses allocations
+ * @extensions: specifies how many times it's allowed to extend the initial
+ * mapping (0 - no extension at all, 1 - mapping can be extended
+ * once, 2 - mapping can be extended twice, etc.)
*
* Creates a mapping structure which holds information about used/unused
* IO address ranges, which is required to perform memory allocation and
* mapping with IOMMU aware functions.
*
+ * If a positive extensions parameter is passed the mapping will be
+ * extended (by size bytes) when the mapping runs out of unused IO
+ * addresses. Thus the maximum size of the mapping is
+ *
+ * size * (1 + extensions)
+ *
* The client device need to be attached to the mapping with
* arm_iommu_attach_device function.
*/
struct dma_iommu_mapping *
arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
- int order)
+ int order, int extensions)
{
unsigned int count = size >> (PAGE_SHIFT + order);
- unsigned int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
struct dma_iommu_mapping *mapping;
int err = -ENOMEM;
@@ -1901,23 +1961,35 @@ arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t size,
if (!mapping)
goto err;
- mapping->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
- if (!mapping->bitmap)
+ mapping->bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
+ mapping->bitmaps = kzalloc((extensions + 1) * sizeof(unsigned long *),
+ GFP_KERNEL);
+ if (!mapping->bitmaps)
goto err2;
+ mapping->bitmaps[0] = kzalloc(mapping->bitmap_size, GFP_KERNEL);
+ if (!mapping->bitmaps[0])
+ goto err3;
+
+ mapping->nr_bitmaps = 1;
+ mapping->extensions = extensions;
mapping->base = base;
- mapping->bits = BITS_PER_BYTE * bitmap_size;
+ mapping->size = size;
mapping->order = order;
+ mapping->bits = BITS_PER_BYTE * mapping->bitmap_size;
+
spin_lock_init(&mapping->lock);
mapping->domain = iommu_domain_alloc(bus);
if (!mapping->domain)
- goto err3;
+ goto err4;
kref_init(&mapping->kref);
return mapping;
+err4:
+ kfree(mapping->bitmaps[0]);
err3:
- kfree(mapping->bitmap);
+ kfree(mapping->bitmaps);
err2:
kfree(mapping);
err:
@@ -1927,14 +1999,35 @@ EXPORT_SYMBOL_GPL(arm_iommu_create_mapping);
static void release_iommu_mapping(struct kref *kref)
{
+ int i;
struct dma_iommu_mapping *mapping =
container_of(kref, struct dma_iommu_mapping, kref);
iommu_domain_free(mapping->domain);
- kfree(mapping->bitmap);
+ for (i = 0; i < mapping->nr_bitmaps; i++)
+ kfree(mapping->bitmaps[i]);
+ kfree(mapping->bitmaps);
kfree(mapping);
}
+static int extend_iommu_mapping(struct dma_iommu_mapping *mapping)
+{
+ int next_bitmap;
+
+ if (mapping->nr_bitmaps > mapping->extensions)
+ return -EINVAL;
+
+ next_bitmap = mapping->nr_bitmaps;
+ mapping->bitmaps[next_bitmap] = kzalloc(mapping->bitmap_size,
+ GFP_ATOMIC);
+ if (!mapping->bitmaps[next_bitmap])
+ return -ENOMEM;
+
+ mapping->nr_bitmaps++;
+
+ return 0;
+}
+
void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping)
{
if (mapping)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_iommu.c b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
index fb8db03..cc8389e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_iommu.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_iommu.c
@@ -40,8 +40,8 @@ int drm_create_iommu_mapping(struct drm_device *drm_dev)
priv->da_space_order = EXYNOS_DEV_ADDR_ORDER;
mapping = arm_iommu_create_mapping(&platform_bus_type, priv->da_start,
- priv->da_space_size,
- priv->da_space_order);
+ priv->da_space_size,
+ priv->da_space_order, 0);
if (IS_ERR(mapping))
return PTR_ERR(mapping);
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index bee88c8..67b3364 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1694,7 +1694,7 @@ static int arm_smmu_group_notifier(struct notifier_block *nb,
break;
mapping = arm_iommu_create_mapping(&platform_bus_type,
- 0, SZ_128M, 0);
+ 0, SZ_128M, 0, 31);
if (IS_ERR(mapping)) {
ret = PTR_ERR(mapping);
dev_info(dev, "arm_iommu_create_mapping failed\n");
diff --git a/drivers/iommu/shmobile-iommu.c b/drivers/iommu/shmobile-iommu.c
index d572863..2540b7e 100644
--- a/drivers/iommu/shmobile-iommu.c
+++ b/drivers/iommu/shmobile-iommu.c
@@ -343,7 +343,7 @@ static int shmobile_iommu_add_device(struct device *dev)
mapping = archdata->iommu_mapping;
if (!mapping) {
mapping = arm_iommu_create_mapping(&platform_bus_type, 0,
- L1_LEN << 20, 0);
+ L1_LEN << 20, 0, 0);
if (IS_ERR(mapping))
return PTR_ERR(mapping);
archdata->iommu_mapping = mapping;
--
1.7.9.5
^ permalink raw reply related
* Extending OPP bindings
From: Rob Herring @ 2014-01-31 17:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131124620.GC2616@e102568-lin.cambridge.arm.com>
On Fri, Jan 31, 2014 at 6:46 AM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> Hi Nishanth,
>
> On Fri, Jan 31, 2014 at 12:43:54AM +0000, Nishanth Menon wrote:
>> Hi Sudeep,
>>
>> On 01/30/2014 07:43 AM, Sudeep Holla wrote:
>>
>> >
>> > I am looking into a couple shortcomings in the current OPP bindings and
>> > how to address them. Feel free to add to the list if you think of any more
>> > issues that needs to be addressed or if and how any problem mentioned below
>> > can be handled with the existing bindings.
>> >
>> > 1. indexing: currently there are no indices in the operating-points.
>> indexing is based on frequency which is why the accessors use
>> frequency to pull out the OPP data.
>>
>> indexing is a horrible idea - on platforms where OPP may be disabled
>> or enabled for various reasons(see arch/arm/mach-imx/mach-imx6q.c,
>> arch/arm/mach-omap2/board-omap3beagle.c etc) - the indexing you see in
>> dts is just a myth that may not exist once the nodes are loaded and
>> operated upon depending on SoC variations (example efuse describing
>> which OPPs can be used and which not).
>
> I do not understand why. As long as a mapping from DT to data structures
> in the kernel is done at boot, I can see how by indexing device nodes
> can refer to specific OPPs. If they are disabled, amen, as long as we
> can point at specific operating points that should be ok.
>
> Indexing does not mean that the index in the DT is the same as the one
> allocated by the OS. Indexing is there to point at specific OPPs from
> different DT nodes, a good example are clock bindings and that's exactly
> how they work.
That is not a good comparison. With clocks, you are describing which
physical signal coming out of a hardware block much like interrupts.
Granted the h/w is not typically documented that way for clocks
although the numbering could correspond to register bit locations as
interrupt numbers do. With OPP indexes, they are a totally made up
software construct.
Perhaps OPPs should be nodes so new fields can be added easily and
then you have a phandle for each OPP.
>
> Can you provide me with an example where the indexing would go wrong
> please ?
Putting s/w indexes into DT. Using cell-index for uarts to define
their tty number was one example.
> Certainly relying on implicit ordering is not great either, actually I
> would say that it is broken.
>
>> That said, the original OPP[1][2] series discussion started by trying
>> to kill indexing precisely for the same reason.. once you have it - it
>> becomes just crazy to deal with.
>
> I could not find any "index killing" :) discussion in there, but I will
> keep reading.
>
>> > It's assumed that the list is either in ascending or descending
>> > order of frequency but not explicit in the binding document.
>> > There are arch/arm/boot/dts/* files with opps in both styles.
>> it should not matter -> opp library should do an insertion sort and
>> organize it in ascending order once all the data is inserted. (line
>> 449ish in opp.c)
>
> That's OS details and they must not be mandated by the bindings.
> We cannot rely on word of mouth for things to work, I do not like
> implicit rules, so the bindings should speficy the ordering or better
> a way to reference OPPs.
>
>> if you see issues with the insertion sort not functioning, it is a bug
>> and should be easy to track down and fix.
>
> Problem is not the insertion sort, problem is that DT bindings do not
> define a way to refer to a specific OPP, unless we do that implicitly
> and again, I rest my case, that is broken.
>
>> > Few other bindings like thermal defines bindings like
>> > cooling-{min,max}-state assuming some order which is broken IMO.
>> Now that you bring it up, I missed it :(.. yeah, I might have
>> preferred it to be min frequency and max_frequency - I agree it is
>> probably broken. I'd let Eduardo comment more about it.
>>
>> >
>> > One such use-case that came up recently[0] is the c-state latencies
>> > which could be different for each OPP. It would be good if the
>> > latencies are specified with the indices to OPP table to avoid
>> > inconsistency between the bindings.
>>
>> You can define C states based on frequencies as well - which really
>> makes sense - since that sounds really like our constraint (say
>> valid-at-frequency "xyz"
>
> I do not think that's generic enough, I do not like the idea of looking
> up frequencies (eg a C-state target_residency does not depend on the
> frequency only - ie voltage and other factors play a role, it really
> depends on an operating point- looking it up by frequency is misleading IMO).
It seems we are trying to fit a square peg into a round hole here.
Rob
^ permalink raw reply
* Why are imprecise external aborts masked on recent kernel while booting ?
From: Russell King - ARM Linux @ 2014-01-31 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EBC86D.1010509@st.com>
On Fri, Jan 31, 2014 at 04:59:41PM +0100, Fabrice Gasnier wrote:
> Is it a desired change in recent kernels ?
I think it was an unnoticed behavioural change.
> Is it possible to unmask imprecise data aborts earlier in the boot
> process (e.g. before PCIe bus enumeration, when drivers are being probed)
> ?
How about this patch?
diff --git a/arch/arm/kernel/traps.c b/arch/arm/kernel/traps.c
index 172ee18ff124..b0ff06f49cd0 100644
--- a/arch/arm/kernel/traps.c
+++ b/arch/arm/kernel/traps.c
@@ -900,6 +900,15 @@ void __init early_trap_init(void *vectors_base)
flush_icache_range(vectors, vectors + PAGE_SIZE * 2);
modify_domain(DOMAIN_USER, DOMAIN_CLIENT);
+
+ /* Enable imprecise aborts */
+ asm volatile(
+ "mrs %0, cpsr\n"
+ " bic %0, %0, %1\n"
+ " msr cpsr_c, %0"
+ : "=&r" (i)
+ : "r" (PSR_A_BIT));
+
#else /* ifndef CONFIG_CPU_V7M */
/*
* on V7-M there is no need to copy the vector table to a dedicated
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply related
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Felipe Balbi @ 2014-01-31 16:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EBC650.50305@ti.com>
On Fri, Jan 31, 2014 at 10:50:40AM -0500, Santosh Shilimkar wrote:
> On Friday 31 January 2014 10:47 AM, Felipe Balbi wrote:
> > On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote:
> >> On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote:
> >>> Hi,
> >>>
> >>> On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote:
> >>>> The Keystone PM management layer has been implemented using PM bus for
> >>>> power management clocks. As result, most of Keystone drivers don't need
> >>>> to manage clocks directly. They just need to enable runtime PM and use it
> >>>> to handle their PM state and clocks.
> >>>>
> >>>> Hence, remove clock management code and switch to use runtime PM.
> >>>>
> >>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> >>>
> >>> quite a few weeks back I sent a series enabling runtime pm for all glue
> >>> layers. I'll use that version instead, sorry.
> >>>
> >> That should be fine but you need to drop clk_*() related code
> >> from that patch. I assume you will send refresh version of it then.
> >
> > why ? it makes no difference if you enable twice and disable twice.
> >
> Sure but why do you want to have the clock node handling code in drivers
> if it is not needed. Isn't that better ?
It might, but then way that I wanted to see it is so that I can make
assumptions about the device state. From a driver perspective, what I
would love to see is the ability to assume that when my probe gets
called the device is already enabled. So if you can make sure that
clk_enable() happens before my probe and that you call
pm_runtime_set_active() before my probe too, then I can more than
hapilly remove clk_* calls from the driver ;-)
either that or maintain the driver like so:
probe()
{
...
clk_get(dev, "fck");
clk_prepare(clk);
clk_enable(clk);
pm_runtime_set_active(dev);
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
...
}
runtime_suspend()
{
clk_disable(dev);
}
runtime_resume()
{
clk_enable(dev);
}
note that because of pm_runtime_set_active() that first
pm_runtime_get_sync() in probe() will simply increase the reference
counter without calling my ->runtime_resume() callback, which is exactly
what we want, as that would completely avoid situations of bad context
being restored because of that initial pm_runtime_get_sync().
Then, we can even make pm_runtime completely async easily, because
clk_prepare() was called only on probe() (or before it, for that
matter).
Bottomline is, if you can guarantee me that clk_get(), clk_prepare(),
clk_enable() and pm_runtime_set_active() will be called properly before
my probe, i'll be more than happy to comply with your request above as
that will greatly simplify my driver.
Just make, also, that if this clock is shared between dwc3-keystone
wrapper and dwc3 core, you clk_get() on both driver's probe.
cheers
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/e709d095/attachment.sig>
^ permalink raw reply
* [PATCH v2 08/11] of: Increase MAX_PHANDLE_ARGS
From: Rob Herring @ 2014-01-31 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140130174546.GF13543@alberich>
On Thu, Jan 30, 2014 at 11:45 AM, Andreas Herrmann
<andreas.herrmann@calxeda.com> wrote:
> On Wed, Jan 29, 2014 at 12:26:35PM -0500, Suravee Suthikulanit wrote:
>> On 1/29/2014 11:16 AM, Andreas Herrmann wrote:
>> > On Wed, Jan 29, 2014 at 11:59:12AM -0500, Suravee Suthikulanit wrote:
>> >> On 1/29/2014 10:57 AM, Rob Herring wrote:
>> >>>>> diff --git a/include/linux/of.h b/include/linux/of.h
>> >>>>>>> index 276c546..24e1b28 100644
>> >>>>>>> --- a/include/linux/of.h
>> >>>>>>> +++ b/include/linux/of.h
>> >>>>>>> @@ -67,7 +67,7 @@ struct device_node {
>> >>>>>>> #endif
>> >>>>>>> };
>> >>>>>>>
>> >>>>>>> -#define MAX_PHANDLE_ARGS 8
>> >>>>>>> +#define MAX_PHANDLE_ARGS 16
>> >>>>>
>> >>>>>
>> >>>>> Since the MMU-500 specify "Number of SMRs" upto 128 registers, shouldn't
>> >>>>> this be changed to be able to support 128 StreamIDs as well? Although I am
>> >>>>> not sure if this would be too big to have on the stack per Rob's comment in
>> >>>>> the previous patch set.
>> >>> Do you actually need 128 now? If not, then we can deal with that when
>> >>> we get there. There are lots of things in spec's that are not actually
>> >>> implemented or supported.
>> >>
>> >> Actually, we are using 32 on the AMD system. So, do you think we can set
>> >> this to 32 instead?
>> >
>> > I think that's ok.
>> >
>> > But are we really talking about number of SMRs or number of StreamIDs
>> > per master device here? Ie. are you just having 32 SMRs for an SMMU on
>> > your AMD system or do you have master devices which have 32 StreamIDs?
>> >
>> > If it's just number of SMRs we don't need to modify this macro.
>
>> I am referring to the case where each mmu-master can have upto 32 streamID.
>
> Rob,
>
> Do you agree on increasing MAX_PHANDLE_ARGS to 32?
Yes, but more than that will require a closer look. Please get this
into next early in the cycle.
> Or should this be done when someone (e.g. Suravee) submits a DTS
> update with an SMMU node description containing more than 16 stream
> IDs for a master device?
Well, I am inclined to not care having seen no upstream activity for
AMD's platform.
Rob
^ permalink raw reply
* [PATCH 3/3] spi: switch to devm_spi_alloc_master
From: Stephen Warren @ 2014-01-31 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391163792-21819-4-git-send-email-maxime.ripard@free-electrons.com>
On 01/31/2014 03:23 AM, Maxime Ripard wrote:
> Make the existing users of devm_spi_register_master use the
> devm_spi_alloc_master function to avoid leaking memory.
> diff --git a/drivers/spi/spi-tegra114.c b/drivers/spi/spi-tegra114.c
> @@ -1087,14 +1085,13 @@ static int tegra_spi_probe(struct platform_device *pdev)
> if (ret < 0) {
> dev_err(&pdev->dev, "Failed to register ISR for IRQ %d\n",
> tspi->irq);
> - goto exit_free_master;
> + return ret;
> }
>
> tspi->clk = devm_clk_get(&pdev->dev, "spi");
> if (IS_ERR(tspi->clk)) {
> dev_err(&pdev->dev, "can not get clock\n");
> - ret = PTR_ERR(tspi->clk);
> - goto exit_free_irq;
> + return PTR_ERR(tspi->clk);
> }
>
> tspi->max_buf_size = SPI_FIFO_DEPTH << 2;
> @@ -1152,8 +1149,6 @@ exit_rx_dma_free:
> tegra_spi_deinit_dma_param(tspi, true);
> exit_free_irq:
> free_irq(spi_irq, tspi);
> -exit_free_master:
> - spi_master_put(master);
> return ret;
Doesn't that s/goto exit_free_irq/return/ leak spi_irq? It's only OK to
replace goto free_master with a direct return.
The other two Tegra drivers don't seem to have this problem.
^ permalink raw reply
* recommended action for bootloaders regarding modifying device-tree nodes
From: Jason Cooper @ 2014-01-31 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ+vNU2zis+1DUCzmegUFw+Z6XATBEPJ+yqMsttp4ENcckHUYA@mail.gmail.com>
On Thu, Jan 30, 2014 at 08:39:00PM -0800, Tim Harvey wrote:
> On Thu, Jan 30, 2014 at 12:45 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > Hi Tim,
> >
> > On Thu, Jan 30, 2014 at 01:11:18AM -0800, Tim Harvey wrote:
> >> My approach has been to define a per-baseboard device-tree in Linux
> >> for a 'fully loaded' board, then remove nodes which the EEPROM claims
> >> are not present in the bootloader before it passes the DTB to the
> >> kernel. I do this by defining aliases in the device-tree for the
> >> peripherals that are 'optional' so that the bootloader itself does not
> >> need to know the details about how the device is connected.
> >
> > This is more of a process question: Is there any information captured
> > in your EEPROM that can't be represented in the dtb? iow, at the point
> > when you write the EEPROM, why not write the dtb to it as configured?
> >
> > You could have pre-configured dtsi fragments for each config option, and
> > then dynamically create the board dts from the order.
> >
> > I only ask because it would solve the problem below. However, there's a
> > lot more to changing a manufacturing process than meets the eye. :)
> >
>
> our eeprom config section is only 40 bytes. It contains a SKU string,
> mac addrs, and some bitwise fields for the various optional components
> that we can subload.
Ok.
> >> Is it more appropriate for the bootloader to 'remove' nodes for
> >> devices that are not physically present or should I be setting their
> >> status property to 'disabled' instead? I'm not clear if either option
> >> really has any pros or cons.
> >
> > That depends on how you have it structured. Is it a valid dtb?
> > Meaning, do you have four nodes all at the same register address?
> > Perhaps you could provide an example dts?
>
> yes its a valid dtb - it is just the superset of everything the
> baseboard (ie schematic design) can support.
>
> A good example is a custom SKU of a baseboard with ethernet subloaded.
> If the EEPROM says there is no ethernet mac or phy, I would want to
> remove or disable the ethernet node from the devicetree.
>
> Another example would be a node for 'gpio-pps' (GPIO based
> pulse-per-second) support. A baseboard design that has a GPS with its
> PPS signal tied to a GPIO would define this in the device-tree, but if
> the EEPROM says the GPS isn't loaded, I would want to remove or
> disable the gps-pps node.
I think JasonG's approach is the way to go (inserting nops). But it's a
matter of preference as long as the output is a valid dtb.
on a side note: Do you still have to tie your dtb to a version of the
kernel?
thx,
Jason.
^ permalink raw reply
* [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
From: Mark Brown @ 2014-01-31 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131081147.GC2950@lukather>
On Fri, Jan 31, 2014 at 09:11:47AM +0100, Maxime Ripard wrote:
> Wouldn't it be better if it was suspended by default, and just waken
> up whenever the framework needs it?
The aim should be to come out of probe in that state if runtime PM is
enabled but don't do it with these hacks, do it by idling the device
at the end of probe for example. Apart from anything else this code
just looks ugly.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140131/2482bece/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: k2hk-evm: rename clock node to clocks
From: Grygorii Strashko @ 2014-01-31 16:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EBB4F6.3050202@ti.com>
On 01/31/2014 04:36 PM, Santosh Shilimkar wrote:
> On Friday 31 January 2014 08:31 AM, Grygorii Strashko wrote:
>> Fix type in clock(s) node name: "clock"-->"clocks".
>>
> s/type/typo ;-)
>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> ---
> No need to resend, I will fix it up while applying it
Thanks
>
>> arch/arm/boot/dts/k2hk-evm.dts | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/k2hk-evm.dts b/arch/arm/boot/dts/k2hk-evm.dts
>> index eaefdfe..c02c3a8 100644
>> --- a/arch/arm/boot/dts/k2hk-evm.dts
>> +++ b/arch/arm/boot/dts/k2hk-evm.dts
>> @@ -15,7 +15,7 @@
>> compatible = "ti,keystone-evm";
>>
>> soc {
>> - clock {
>> + clocks {
>> refclksys: refclksys {
>> #clock-cells = <0>;
>> compatible = "fixed-clock";
>>
>
^ permalink raw reply
* Why are imprecise external aborts masked on recent kernel while booting ?
From: Fabrice Gasnier @ 2014-01-31 15:59 UTC (permalink / raw)
To: linux-arm-kernel
Hi all,
I'm working on a PCIe driver that uses an "imprecise external abort"
handler to detect when a port is behind a switch.
This mechanism is used when enumerating PCIe bus upon kernel boot.
In prior kernel (3.4), I noticed it's possible to use an abort handler
registered by using hook_fault_code(16+6, ...);
These aborts are detected and the relevant handler is called as long as
it is registered, when probing the bus.
In more recent kernel (3.10), abort handler is no longer triggered
during kernel boot. At PCIe bus enumeration, imprecise aborts are not
enabled. It seems unmasked later when starting userland init process
(e.g. when CPSR.A bit on arm is cleared). Aborts are deferred until then.
I found another thread that looks like similar :
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/208641.html
I looked for where imprecise aborts were enabled on 3.4. I found out
that it was enabled when the first schedule() happens. More precisely in
kernel_thread_helper() when doing: "msr cpsr_c, r7".
There has been changes beetween 3.6 or 3.7, like in commit
9e14f828ee4a7a4a98703e380d180717a579fb35 (and others) that i believe
changes the behavior of unmasking CPSR.A bit. kernel_thread_helper has
been removed in that patch.
Is it a desired change in recent kernels ?
Is it possible to unmask imprecise data aborts earlier in the boot
process (e.g. before PCIe bus enumeration, when drivers are being probed) ?
Best regards,
Fabrice
^ permalink raw reply
* [PATCH] usb: dwc3: keystone: switch to use runtime pm
From: Santosh Shilimkar @ 2014-01-31 15:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140131154721.GD20736@saruman.home>
On Friday 31 January 2014 10:47 AM, Felipe Balbi wrote:
> On Fri, Jan 31, 2014 at 10:43:21AM -0500, Santosh Shilimkar wrote:
>> On Friday 31 January 2014 10:19 AM, Felipe Balbi wrote:
>>> Hi,
>>>
>>> On Fri, Jan 31, 2014 at 03:20:26PM +0200, Grygorii Strashko wrote:
>>>> The Keystone PM management layer has been implemented using PM bus for
>>>> power management clocks. As result, most of Keystone drivers don't need
>>>> to manage clocks directly. They just need to enable runtime PM and use it
>>>> to handle their PM state and clocks.
>>>>
>>>> Hence, remove clock management code and switch to use runtime PM.
>>>>
>>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>>>
>>> quite a few weeks back I sent a series enabling runtime pm for all glue
>>> layers. I'll use that version instead, sorry.
>>>
>> That should be fine but you need to drop clk_*() related code
>> from that patch. I assume you will send refresh version of it then.
>
> why ? it makes no difference if you enable twice and disable twice.
>
Sure but why do you want to have the clock node handling code in drivers
if it is not needed. Isn't that better ?
^ 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