Re: [PATCHv4 2/4] ARM: msm: Add support for APQ8074 Dragonboard
Hi Rohit, On Thu, 2013-10-03 at 16:05 -0700, Rohit Vaswani wrote: This patch adds basic board support for APQ8074 Dragonboard which belongs to the Snapdragon 800 family. For now, just support a basic machine with device tree. Signed-off-by: Rohit Vaswani rvasw...@codeaurora.org --- arch/arm/boot/dts/Makefile | 3 ++- arch/arm/boot/dts/qcom-apq8074-dragonboard.dts | 6 + arch/arm/boot/dts/qcom-msm8974.dtsi| 35 ++ arch/arm/mach-msm/Kconfig | 13 ++ arch/arm/mach-msm/board-dt.c | 9 +++ 5 files changed, 65 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts create mode 100644 arch/arm/boot/dts/qcom-msm8974.dtsi diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 000cf76..e71a3ec 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -102,7 +102,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \ kirkwood-openblocks_a6.dtb dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \ - msm8960-cdp.dtb + msm8960-cdp.dtb \ + qcom-apq8074-dragonboard.dtb dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \ armada-370-mirabox.dtb \ armada-370-netgear-rn102.dtb \ diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts new file mode 100644 index 000..bb6f3c4 --- /dev/null +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts @@ -0,0 +1,6 @@ +/include/ qcom-msm8974.dtsi Please, could you replace /include/ by #include. This will allow us to use of #define features from C header files. Since[1] we have clocks indexes definitions shared between C code and DT files. Thanks, Ivan [1] http://www.spinics.net/lists/arm-kernel/msg276937.html -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/4] ARM: msm: Add support for APQ8074 Dragonboard
On 10/4/2013 1:28 AM, Ivan T. Ivanov wrote: Hi Rohit, On Thu, 2013-10-03 at 16:05 -0700, Rohit Vaswani wrote: This patch adds basic board support for APQ8074 Dragonboard which belongs to the Snapdragon 800 family. For now, just support a basic machine with device tree. Signed-off-by: Rohit Vaswani rvasw...@codeaurora.org --- arch/arm/boot/dts/Makefile | 3 ++- arch/arm/boot/dts/qcom-apq8074-dragonboard.dts | 6 + arch/arm/boot/dts/qcom-msm8974.dtsi| 35 ++ arch/arm/mach-msm/Kconfig | 13 ++ arch/arm/mach-msm/board-dt.c | 9 +++ 5 files changed, 65 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/qcom-apq8074-dragonboard.dts create mode 100644 arch/arm/boot/dts/qcom-msm8974.dtsi diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 000cf76..e71a3ec 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -102,7 +102,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \ kirkwood-openblocks_a6.dtb dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \ - msm8960-cdp.dtb + msm8960-cdp.dtb \ + qcom-apq8074-dragonboard.dtb dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \ armada-370-mirabox.dtb \ armada-370-netgear-rn102.dtb \ diff --git a/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts new file mode 100644 index 000..bb6f3c4 --- /dev/null +++ b/arch/arm/boot/dts/qcom-apq8074-dragonboard.dts @@ -0,0 +1,6 @@ +/include/ qcom-msm8974.dtsi Please, could you replace /include/ by #include. This will allow us to use of #define features from C header files. Since[1] we have clocks indexes definitions shared between C code and DT files. Will do. Thanks, Ivan [1] http://www.spinics.net/lists/arm-kernel/msg276937.html Thanks, Rohit Vaswani -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use of drivers/platform and matching include?
On Thu, Oct 03, 2013 at 06:54:07PM +0100, Olof Johansson wrote: On Thu, Oct 3, 2013 at 10:09 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Thu, Oct 03, 2013 at 09:46:30AM -0700, Olof Johansson wrote: I don't have a good answer though. If it wasn't for the arm64 fork, locating these under arch/arm somewhere would really be the reasonable answer, like we used to do on powerpc. :( Sounds like yet-another-good reason why there shouldn't be an arm64 fork at all :( Doing a fork gives a chance at a clean slate refresh of platform support, which is in itself quite useful. But indeed it causes some things to be more complicated. Also note that arm64 work started (internally) before the arm-soc was formed and it was nearing upstreaming at a time when the arm-soc was still undergoing heavy clean-up. Of course, there is always a balance between advantages and disadvantages but the main benefits are a clean implementation of AArch64 architecture support (without legacy baggage) and forcing SoC people to clean up the code for AArch64 (e.g. default single Image, decoupling booting protocols from SoC initialisation, firmware interface standardisation, resisting the urge to add SoC code under arch/arm64/). It's a common complaint that everybody who ever forked for 64-bit have later merged, and that's true, but that doesn't mean there's no value in forking (and perhaps later merging), instead of adding on top to start with. Exactly. Later merging is possible, but such process, to produce clean/maintainable/shareable code, needs additional clean-up in the 32-bit ARM architecture code (at least breaking recent ARMv7 support from legacy architectures). Otherwise we end up with either a less than clean arm64 re-port on top of arm or just completely separate files artificially forced under the same arch directory. Where code sharing makes sense (e.g. ARM KVM and Xen), the arm64 Makefiles already reference arch/arm/. It's not ideal but it's a trade-off for the time being. The arm community created this mess, you all can fix it up, it's not too late. It wouldn't be a huge deal to add something like arch/arm/syslib and give some of the system library-type code a home there -- stuff like resource allocation libraries, etc. I don't think we want to collect all the back-end drivers in there though, just libraries. On the SoC part, we need to analyse what exactly needs sharing, whether it's a library used by multiple drivers (and arguably the library could also go under drivers/) or whether it's some SoC initialisation that could be better done before Linux is started. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use of drivers/platform and matching include?
On Thu, Oct 03, 2013 at 09:46:30AM -0700, Olof Johansson wrote: I don't have a good answer though. If it wasn't for the arm64 fork, locating these under arch/arm somewhere would really be the reasonable answer, like we used to do on powerpc. :( Are you seriously suggesting going back to having drivers under arch/arm because we can't find a home for them in the drivers subtree? Having made a big thing about things as small as clock source drivers, IRQ drivers and such like which shouldn't be under arch/arm and moving them out, to then say about finding somewhere under arch/arm for drivers is very much a case of double-standards. I've heard this accusation that we have too many drivers in arch/arm many times, and although we've made some progress getting things like clock and IRQ drivers out of arch/arm, we're still a long way from sorting that out. Or maybe that original accusation was baseless for modern kernels, based on the old 1.x days when we had a arch/arm/drivers subdirectory which people have a hard time forgetting? So, no, there will be no new drivers under arch/arm. They must be in the drivers subtree somewhere. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use of drivers/platform and matching include?
On Thu, Oct 03, 2013 at 10:09:14AM -0700, Greg Kroah-Hartman wrote: On Thu, Oct 03, 2013 at 09:46:30AM -0700, Olof Johansson wrote: I don't have a good answer though. If it wasn't for the arm64 fork, locating these under arch/arm somewhere would really be the reasonable answer, like we used to do on powerpc. :( Sounds like yet-another-good reason why there shouldn't be an arm64 fork at all :( The arm community created this mess, you all can fix it up, it's not too late. I said at the time, way before arm64 was merged that it should not be a separate arch. Every bit of feedback I gave on arm64 got shouted down by Catalin. ARM64 is Catalin's baby and he wants to protect it at all costs. I'm surprised Linus even pulled it in with no argument. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use of drivers/platform and matching include?
On Thu, Oct 03, 2013 at 10:54:07AM -0700, Olof Johansson wrote: It wouldn't be a huge deal to add something like arch/arm/syslib and give some of the system library-type code a home there -- stuff like resource allocation libraries, etc. I don't think we want to collect all the back-end drivers in there though, just libraries. We don't need yet another subdirectory in arch/arm - yes, that's a favourite way of avoiding any issues, but really it's not the right answer. We already have a place for shared cross-platform code, and it's called arch/arm/common. I think many of us are hesitant to introduce something that runs the risk of becoming a dumping ground for all these I don't know where to put them, so here you go drivers, since we've spent so much time cleaning them all up and de-forking per-vendor implementations of similar things. Drivers go under drivers/ is what we've decided. If we want to change that, then we should move all those IRQ, gpio and clock drivers back out of the drivers/ subtree, because many of them are SoC specific. Please, think back to why we made the original decision(s) to move this stuff out of arch/arm. -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use of drivers/platform and matching include?
On Fri, Oct 04, 2013 at 12:43:40PM +0100, Russell King - ARM Linux wrote: On Thu, Oct 03, 2013 at 10:09:14AM -0700, Greg Kroah-Hartman wrote: On Thu, Oct 03, 2013 at 09:46:30AM -0700, Olof Johansson wrote: I don't have a good answer though. If it wasn't for the arm64 fork, locating these under arch/arm somewhere would really be the reasonable answer, like we used to do on powerpc. :( Sounds like yet-another-good reason why there shouldn't be an arm64 fork at all :( The arm community created this mess, you all can fix it up, it's not too late. I said at the time, way before arm64 was merged that it should not be a separate arch. Every bit of feedback I gave on arm64 got shouted down by Catalin. ARM64 is Catalin's baby and he wants to protect it at all costs. My counter arguments weren't probably clear to you. I want to protect a clean, legacy-free AArch64 implementation at all costs. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use of drivers/platform and matching include?
On Fri, Oct 04, 2013 at 12:41:28PM +0100, Russell King - ARM Linux wrote: So, no, there will be no new drivers under arch/arm. They must be in the drivers subtree somewhere. I have no objection with this, and encourage it. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/3] usb: dwc3: msm: Add device tree binding information
On Wed, Aug 21, 2013 at 04:29:44PM +0300, Ivan T. Ivanov wrote: From: Ivan T. Ivanov iiva...@mm-sol.com MSM USB3.0 core wrapper consist of USB3.0 IP from Synopsys (SNPS) and HS, SS PHY's control and configuration registers. It could operate in device mode (SS, HS, FS) and host mode (SS, HS, FS, LS). Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com these patches were sent *ages* and nobody from DT mailing list has reviewed. Unless someone steps up now, I'll be queueing these patches next week. -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/2] Add support for Qualcomm's PRNG
Hi Ted, On 10/03/2013 07:51 PM, Theodore Ts'o wrote: On Thu, Oct 03, 2013 at 05:52:33PM +0300, Stanimir Varbanov wrote: This patch set adds hardware RNG driver wich is used to control the Qualcomm's PRNG hardware block. The first patch document the DT bindings needed to sucessfuly probe the driver and the second patch adds the driver. Is this really a PRNG (pseudo-random number generator)? What are the guarantees which Qualcomm is providing for the PRNG? If it's really a PRNG such as AES(i++, NSA_KEY), then kudo to Qualcomm for being honest. If it is supposed to be (or at least claimed to be) a secure random number generator ala RDRAND suitable for use in cryptographic applications, calling it a PRNG is going to be a bit misleading. I guess that it should follow NIST 800-90 recommendation, but I'm not aware what DRBG mechanism is used. To be honest I really don't know the hardware implementation details. I put PRNG abbreviation in the cover letter just because I saw that defines for register offsets are prefixed with PRNG_*. I could rename all occurrences of PRNG to RNG. Is that will be enough to avoid confusions? regadrs, Stan -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] hwrng: msm: Add PRNG support for MSM SoC's
Hi Stephen,
Thanks for the quick review!
On 10/03/2013 10:25 PM, Stephen Boyd wrote:
On 10/03/13 07:52, Stanimir Varbanov wrote:
+#define PRNG_CONFIG_MASK0x0002
+#define PRNG_CONFIG_HW_ENABLE BIT(1)
These two are the same so please drop the PRNG_CONFIG_MASK define and
just use the PRNG_CONFIG_HW_ENABLE define.
OK I will drop the mask and rework the code related to it.
+#define PRNG_STATUS_DATA_AVAIL BIT(0)
+
+#define MAX_HW_FIFO_DEPTH 16
+#define MAX_HW_FIFO_SIZE(MAX_HW_FIFO_DEPTH * 4)
+#define WORD_SZ 4
+
+struct msm_rng {
+void __iomem *base;
+struct clk *clk;
+};
+
+static int msm_rng_enable(struct msm_rng *rng, int enable)
+{
+u32 val;
+int ret;
+
+ret = clk_prepare_enable(rng-clk);
+if (ret)
+return ret;
+
+if (enable) {
+/* Enable PRNG only if it is not already enabled */
+val = readl_relaxed(rng-base + PRNG_CONFIG);
+if (val PRNG_CONFIG_HW_ENABLE)
+goto already_enabled;
+
+/* PRNG is not enabled */
+val = readl_relaxed(rng-base + PRNG_LFSR_CFG);
+val = ~PRNG_LFSR_CFG_MASK;
+val |= PRNG_LFSR_CFG_CLOCKS;
+writel(val, rng-base + PRNG_LFSR_CFG);
+
+val = readl_relaxed(rng-base + PRNG_CONFIG);
+val = ~PRNG_CONFIG_MASK;
+val |= PRNG_CONFIG_HW_ENABLE;
+writel(val, rng-base + PRNG_CONFIG);
This could just be
val = readl_relaxed(rng-base + PRNG_CONFIG);
val |= PRNG_CONFIG_HW_ENABLE;
writel(val, rng-base + PRNG_CONFIG);
+} else {
+val = readl_relaxed(rng-base + PRNG_CONFIG);
+val = ~PRNG_CONFIG_MASK;
+writel(val, rng-base + PRNG_CONFIG);
+}
+
+already_enabled:
+clk_disable_unprepare(rng-clk);
+return 0;
+}
+
[...]
+static int msm_rng_probe(struct platform_device *pdev)
+{
+struct msm_rng *rng;
+struct device_node *np;
+struct resource res;
+int ret;
+
+np = of_node_get(pdev-dev.of_node);
+if (!np)
+return -ENODEV;
This is unnecessary.
I used this call because CONFIG_OF_DYNAMIC could be enabled at some
time. Isn't that possible? I saw that of_node_get|put is used in .probe
on few places in drivers.
+
+rng = devm_kzalloc(pdev-dev, sizeof(*rng), GFP_KERNEL);
+if (!rng) {
+ret = -ENOMEM;
+goto err_exit;
+}
+
+ret = of_address_to_resource(np, 0, res);
+if (ret)
+goto err_exit;
We should just do
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
rng-base = devm_ioremap_resource(pdev-dev, res);
if (IS_ERR(rng-base))
return PTR_ERR(rng-base);
+
+rng-base = devm_ioremap_resource(pdev-dev, res);
+if (IS_ERR(rng-base)) {
+ret = PTR_ERR(rng-base);
+goto err_exit;
+}
+
+rng-clk = devm_clk_get(pdev-dev, prng);
+if (IS_ERR(rng-clk)) {
+ret = PTR_ERR(rng-clk);
+goto err_exit;
+}
+
+msm_rng_ops.priv = (unsigned long) rng;
+ret = hwrng_register(msm_rng_ops);
+if (ret)
+dev_err(pdev-dev, failed to register hwrng\n);
+
+err_exit:
Doing all that should make this goto exit path unnecessary.
+of_node_put(np);
+return ret;
+}
+
+static int msm_rng_remove(struct platform_device *pdev)
+{
+hwrng_unregister(msm_rng_ops);
+return 0;
+}
+
+static struct of_device_id msm_rng_of_match[] = {
const?
+{ .compatible = qcom,prng, },
+{}
+};
+MODULE_DEVICE_TABLE(of, msm_rng_of_match);
+
+static struct platform_driver msm_rng_driver = {
+.probe = msm_rng_probe,
+.remove = msm_rng_remove,
+.driver = {
+.name = KBUILD_MODNAME,
+.owner = THIS_MODULE,
+.of_match_table = of_match_ptr(msm_rng_of_match),
+}
+};
+module_platform_driver(msm_rng_driver);
+
+MODULE_AUTHOR(The Linux Foundation);
+MODULE_DESCRIPTION(Qualcomm MSM random number generator driver);
+MODULE_LICENSE(GPL v2);
regards,
Stan
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] hwrng: msm: Add PRNG support for MSM SoC's
On 10/04/13 09:31, Stanimir Varbanov wrote:
+static int msm_rng_probe(struct platform_device *pdev)
+{
+ struct msm_rng *rng;
+ struct device_node *np;
+ struct resource res;
+ int ret;
+
+ np = of_node_get(pdev-dev.of_node);
+ if (!np)
+ return -ENODEV;
This is unnecessary.
I used this call because CONFIG_OF_DYNAMIC could be enabled at some
time. Isn't that possible? I saw that of_node_get|put is used in .probe
on few places in drivers.
So far we aren't selecting that config on ARM.
If you look at of_device_alloc() you'll see
dev-dev.of_node = of_node_get(np);
so any platform devices created from of_platform_populate won't have
their of_node go away.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-arm-msm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use of drivers/platform and matching include?
On Fri, Oct 4, 2013 at 6:22 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Fri, Oct 04, 2013 at 12:41:28PM +0100, Russell King - ARM Linux wrote: So, no, there will be no new drivers under arch/arm. They must be in the drivers subtree somewhere. I have no objection with this, and encourage it. Ok, so these are some of the requirements as far as I see it: * No per-vendor driver dumping ground under drivers/* (i.e. no drivers/platform/soc vendor/) * No weirdly constructed single-driver directories directly under drivers/* (we already have a few and should look at moving those) because nothing else fits * We need some sort of convention on dependencies. Several of these are more libraries than drivers, i.e. we'll have cross-calls for things like queue management, resource allocation, etc. So having a single location to hold most of these makes sense instead of everything cross-depending on everything else. Based on the above, how about we create something like drivers/resourcemgr to hold these? I think at least parts of the mvebu-mbus driver that ended up under drivers/bus might be a fit to move there. The APM queue allocator would likely be a fit, and maybe some of the qualcomm stuff. Kumar, what are your thoughts on that? Greg? -Olof -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] Add support for Qualcomm's PRNG
On Fri, Oct 04, 2013 at 07:23:50PM +0300, Stanimir Varbanov wrote: I guess that it should follow NIST 800-90 recommendation, but I'm not aware what DRBG mechanism is used. To be honest I really don't know the hardware implementation details. I put PRNG abbreviation in the cover letter just because I saw that defines for register offsets are prefixed with PRNG_*. I could rename all occurrences of PRNG to RNG. Is that will be enough to avoid confusions? If that's what the Qualcomm documentation uses, maybe we should stick with it, and add some explanatory comments. Is there any documentation for this block that is public that you can either send me a a pointer to? Thanks, - Ted -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Use of drivers/platform and matching include?
On Friday 04 October 2013 12:48 PM, Olof Johansson wrote: On Fri, Oct 4, 2013 at 6:22 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Fri, Oct 04, 2013 at 12:41:28PM +0100, Russell King - ARM Linux wrote: So, no, there will be no new drivers under arch/arm. They must be in the drivers subtree somewhere. I have no objection with this, and encourage it. Ok, so these are some of the requirements as far as I see it: * No per-vendor driver dumping ground under drivers/* (i.e. no drivers/platform/soc vendor/) * No weirdly constructed single-driver directories directly under drivers/* (we already have a few and should look at moving those) because nothing else fits * We need some sort of convention on dependencies. Several of these are more libraries than drivers, i.e. we'll have cross-calls for things like queue management, resource allocation, etc. So having a single location to hold most of these makes sense instead of everything cross-depending on everything else. Based on the above, how about we create something like drivers/resourcemgr to hold these? I think at least parts of the mvebu-mbus driver that ended up under drivers/bus might be a fit to move there. The APM queue allocator would likely be a fit, and maybe some of the qualcomm stuff. Kumar, what are your thoughts on that? Slightly different question but relevant to th thread w.r.t the Queue allocator/manager. We are also interested for TI Keystone SOCs. Currently we have generic drivers/hwqueue/ with core hwqueue layer implementing the standard hardware queue descriptor push/pop and notification mechanisms and then Keystone specific driver using those core functionalities. I read most of the networking SOCs has some sort of hwqueues but not sure about the its implementations. So just thought of bringing it into the thread discussion to see if hwqueue core layer is of any interest to other SOCs. Regards, Santosh -- To unsubscribe from this list: send the line unsubscribe linux-arm-msm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
