Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism
On 09/30/2014 07:04 PM, Marc Kleine-Budde wrote: On 09/30/2014 05:25 PM, Wolfram Sang wrote: Yes, but syscon_regmap_lookup_by_phandle() doesn't need any support for additional parameters. Have a look at: drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c First get the regmap, then the 1st argument is the offset in the regmap, the 2nd and 3rd could be the bits. So, for one driver the extra arguments are: reg start_bit stop_bit For another driver (the stmmac example): reg_offset reg_shift The DCAN's reg is a reg_offset as in the stmmc. Roger, can we derive both start and done bit from a common reg_shift? I'm sorry I didn't understand what you meant. syscon_phandl reg offset start bit stop bit should work well for us. Even though reg offset is the same for both the DCAN instances. Phew... Then we should really have a syscon-raminit property probably, so that at least plain syscon has a consistent syntax? I think^whope we can have the same syntax as the stmmc :D I agree too. So, I'd rather drop additional arguments. Why would you like to have it encoded in DT? Where put the information then? Into the driver, but where do you get the reference which instance of the DCAN you are, so that you can look up the correct bits? Agreed. I thought we had this information in the driver already, but we haven't... The current driver relies on the of_alias_get_id(), which isn't considered best practice, is it? So I want to avoid this when switching to syscon. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism
On 10/01/2014 10:45 AM, Roger Quadros wrote: On 09/30/2014 07:04 PM, Marc Kleine-Budde wrote: On 09/30/2014 05:25 PM, Wolfram Sang wrote: Yes, but syscon_regmap_lookup_by_phandle() doesn't need any support for additional parameters. Have a look at: drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c First get the regmap, then the 1st argument is the offset in the regmap, the 2nd and 3rd could be the bits. So, for one driver the extra arguments are: reg start_bit stop_bit For another driver (the stmmac example): reg_offset reg_shift The DCAN's reg is a reg_offset as in the stmmc. Roger, can we derive both start and done bit from a common reg_shift? I'm sorry I didn't understand what you meant. syscon_phandl reg offset start bit stop bit should work well for us. Even though reg offset is the same for both the DCAN instances. What's start bit and stop bit for instance 0 and 1 on that SoC that has two instances?? Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism
On 10/01/2014 11:47 AM, Marc Kleine-Budde wrote: On 10/01/2014 10:45 AM, Roger Quadros wrote: On 09/30/2014 07:04 PM, Marc Kleine-Budde wrote: On 09/30/2014 05:25 PM, Wolfram Sang wrote: Yes, but syscon_regmap_lookup_by_phandle() doesn't need any support for additional parameters. Have a look at: drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c First get the regmap, then the 1st argument is the offset in the regmap, the 2nd and 3rd could be the bits. So, for one driver the extra arguments are: reg start_bit stop_bit For another driver (the stmmac example): reg_offset reg_shift The DCAN's reg is a reg_offset as in the stmmc. Roger, can we derive both start and done bit from a common reg_shift? I'm sorry I didn't understand what you meant. syscon_phandl reg offset start bit stop bit should work well for us. Even though reg offset is the same for both the DCAN instances. What's start bit and stop bit for instance 0 and 1 on that SoC that has two instances?? we have 3 SoCs at the moment, all have 2 DCAN instances. AM33xx AM43xx instancestart stop 1 0 8 2 1 9 DRA7xx instancestart stop 1 3 1 2 5 2 cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism
On 10/01/2014 11:06 AM, Roger Quadros wrote: On 10/01/2014 11:47 AM, Marc Kleine-Budde wrote: On 10/01/2014 10:45 AM, Roger Quadros wrote: On 09/30/2014 07:04 PM, Marc Kleine-Budde wrote: On 09/30/2014 05:25 PM, Wolfram Sang wrote: Yes, but syscon_regmap_lookup_by_phandle() doesn't need any support for additional parameters. Have a look at: drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c First get the regmap, then the 1st argument is the offset in the regmap, the 2nd and 3rd could be the bits. So, for one driver the extra arguments are: reg start_bit stop_bit For another driver (the stmmac example): reg_offset reg_shift The DCAN's reg is a reg_offset as in the stmmc. Roger, can we derive both start and done bit from a common reg_shift? I'm sorry I didn't understand what you meant. syscon_phandl reg offset start bit stop bit should work well for us. Even though reg offset is the same for both the DCAN instances. What's start bit and stop bit for instance 0 and 1 on that SoC that has two instances? we have 3 SoCs at the moment, all have 2 DCAN instances. AM33xx AM43xx instance start stop 1 0 8 2 1 9 If we use a 0-based numbering for the instances: instancestart stop 0 (0 instance) (8 instance) 1 (0 instance) (8 instance) DRA7xx instance start stop 1 3 1 2 5 2 ^ 5 or 4? Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism
On 10/01/2014 01:01 PM, Marc Kleine-Budde wrote: On 10/01/2014 11:06 AM, Roger Quadros wrote: On 10/01/2014 11:47 AM, Marc Kleine-Budde wrote: On 10/01/2014 10:45 AM, Roger Quadros wrote: On 09/30/2014 07:04 PM, Marc Kleine-Budde wrote: On 09/30/2014 05:25 PM, Wolfram Sang wrote: Yes, but syscon_regmap_lookup_by_phandle() doesn't need any support for additional parameters. Have a look at: drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c First get the regmap, then the 1st argument is the offset in the regmap, the 2nd and 3rd could be the bits. So, for one driver the extra arguments are: reg start_bit stop_bit For another driver (the stmmac example): reg_offset reg_shift The DCAN's reg is a reg_offset as in the stmmc. Roger, can we derive both start and done bit from a common reg_shift? I'm sorry I didn't understand what you meant. syscon_phandl reg offset start bit stop bit should work well for us. Even though reg offset is the same for both the DCAN instances. What's start bit and stop bit for instance 0 and 1 on that SoC that has two instances? we have 3 SoCs at the moment, all have 2 DCAN instances. AM33xx AM43xx instance start stop 10 8 21 9 If we use a 0-based numbering for the instances: instance start stop 0 (0 instance) (8 instance) 1 (0 instance) (8 instance) How does the instance number get set? What happens on boards where the first instance is unused while the second one is in use? DRA7xx instance start stop 13 1 25 2 ^ 5 or 4? Unfortunately it is 5 ;) We have display IP related bit in between 3 and 5 :P cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism
On 10/01/2014 12:12 PM, Roger Quadros wrote: On 10/01/2014 01:01 PM, Marc Kleine-Budde wrote: On 10/01/2014 11:06 AM, Roger Quadros wrote: On 10/01/2014 11:47 AM, Marc Kleine-Budde wrote: On 10/01/2014 10:45 AM, Roger Quadros wrote: On 09/30/2014 07:04 PM, Marc Kleine-Budde wrote: On 09/30/2014 05:25 PM, Wolfram Sang wrote: Yes, but syscon_regmap_lookup_by_phandle() doesn't need any support for additional parameters. Have a look at: drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c First get the regmap, then the 1st argument is the offset in the regmap, the 2nd and 3rd could be the bits. So, for one driver the extra arguments are: reg start_bit stop_bit For another driver (the stmmac example): reg_offset reg_shift The DCAN's reg is a reg_offset as in the stmmc. Roger, can we derive both start and done bit from a common reg_shift? I'm sorry I didn't understand what you meant. syscon_phandl reg offset start bit stop bit should work well for us. Even though reg offset is the same for both the DCAN instances. What's start bit and stop bit for instance 0 and 1 on that SoC that has two instances? we have 3 SoCs at the moment, all have 2 DCAN instances. AM33xx AM43xx instancestart stop 1 0 8 2 1 9 If we use a 0-based numbering for the instances: instance start stop 0(0 instance) (8 instance) 1(0 instance) (8 instance) How does the instance number get set? What happens on boards where the first instance is unused while the second one is in use? Via a single instance parameter of the syscon phandle DRA7xx instancestart stop 1 3 1 2 5 2 ^ 5 or 4? Unfortunately it is 5 ;) We have display IP related bit in between 3 and 5 :P What on earth were the HW engineers thinking ...if we just have the instance parameter in the syscon phandle, we have to put the mapping into the driver, which makes IMHO no sense, because you have to touch the driver, if there is another SoC with the DCAN core. AFAICS we have these options: 1) syscon phandle with three parameters: reg offset, start bit shift, stop bit shift (the name of the syscon phandle is a different topic) 2) a single ti,start-stop-bit option with two parameter 3) two ti,* entries with a single parameter each (as in Roger's initial patch) Wolfram, which solution do you prefer? I'm in favour of 3 (+ plus a phandle with a reg offset parameter). puzzled, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism
Unfortunately it is 5 ;) We have display IP related bit in between 3 and 5 :P What on earth were the HW engineers thinking Let's test my RNG on the bit-placement of this register :) ...if we just have the instance parameter in the syscon phandle, we have to put the mapping into the driver, which makes IMHO no sense, because you have to touch the driver, if there is another SoC with the DCAN core. ... which would be my preferred solution. I think new SoCs should have some kind of: compatible = commodore,c64ultra, bosch,d_can; in the DT anyhow to allow for SoC specific quirks/adjustments. And custom raminit belongs to that IMO (see the ti routine getting more and more specific). signature.asc Description: Digital signature
Re: [PATCH 12/17] iommu/omap: Integrate omap-iommu-debug into omap-iommu
Hi Suman,
Thank you for the patch.
On Tuesday 30 September 2014 16:16:07 Suman Anna wrote:
The debugfs support for OMAP IOMMU is currently implemented
as a module, warranting certain OMAP-specific IOMMU API to
be exported. The OMAP IOMMU, when enabled, can only be built-in
into the kernel, so integrate the OMAP IOMMU debug module
into the OMAP IOMMU driver. This helps in eliminating the
need to export most of the current OMAP IOMMU API.
The following are the main changes:
- The OMAP_IOMMU_DEBUG Kconfig option is eliminated, and
the OMAP IOMMU debugfs support is built alongside the OMAP
IOMMU driver, and enabled automatically only when debugfs
is enabled.
That's the part I'm unsure about. We're loosing the ability to save space by
not building the omap-iommu debugfs support when debugfs is enabled.
For the rest of the series,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
- The debugfs directory and entry creation logic is reversed,
the calls are invoked by the OMAP IOMMU driver now.
- The current iffy circular logic of adding IOMMU archdata
to the IOMMU devices itself to get a pointer to the omap_iommu
object in the debugfs support code is replaced by directly
using the omap_iommu structure while creating the debugfs
entries.
- The debugfs root directory is renamed from the generic name
iommu to a specific name omap_iommu.
- Unneeded headers have also been cleaned up while at this.
- There will no longer be a omap-iommu-debug.ko module after
this patch.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/iommu/Kconfig| 9
drivers/iommu/Makefile | 3 +-
drivers/iommu/omap-iommu-debug.c | 102
--- drivers/iommu/omap-iommu.c |
11 +++--
drivers/iommu/omap-iommu.h | 7 +++
5 files changed, 45 insertions(+), 87 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index dd51122..9724d4a 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -143,15 +143,6 @@ config OMAP_IOMMU
depends on ARCH_OMAP2PLUS
select IOMMU_API
-config OMAP_IOMMU_DEBUG
- tristate Export OMAP IOMMU internals in DebugFS
- depends on OMAP_IOMMU DEBUG_FS
- help
- Select this to see extensive information about
- the internal state of OMAP IOMMU in debugfs.
-
- Say N unless you know you need this.
-
config TEGRA_IOMMU_GART
bool Tegra GART IOMMU Support
depends on ARCH_TEGRA_2x_SOC
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 18fa446..e0a4fed 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -10,8 +10,7 @@ obj-$(CONFIG_DMAR_TABLE) += dmar.o
obj-$(CONFIG_INTEL_IOMMU) += iova.o intel-iommu.o
obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
-obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
-obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
+obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o omap-iommu-debug.o
obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o
obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
diff --git a/drivers/iommu/omap-iommu-debug.c
b/drivers/iommu/omap-iommu-debug.c index 28de657..54a0dc6 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -10,15 +10,11 @@
* published by the Free Software Foundation.
*/
-#include linux/module.h
#include linux/err.h
-#include linux/clk.h
#include linux/io.h
#include linux/slab.h
#include linux/uaccess.h
-#include linux/platform_device.h
#include linux/debugfs.h
-#include linux/omap-iommu.h
#include linux/platform_data/iommu-omap.h
#include omap-iopgtable.h
@@ -31,8 +27,7 @@ static struct dentry *iommu_debug_root;
static ssize_t debug_read_regs(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
- struct device *dev = file-private_data;
- struct omap_iommu *obj = dev_to_omap_iommu(dev);
+ struct omap_iommu *obj = file-private_data;
char *p, *buf;
ssize_t bytes;
@@ -55,8 +50,7 @@ static ssize_t debug_read_regs(struct file *file, char
__user *userbuf, static ssize_t debug_read_tlb(struct file *file, char
__user *userbuf, size_t count, loff_t *ppos)
{
- struct device *dev = file-private_data;
- struct omap_iommu *obj = dev_to_omap_iommu(dev);
+ struct omap_iommu *obj = file-private_data;
char *p, *buf;
ssize_t bytes, rest;
@@ -141,8 +135,7 @@ out:
static ssize_t debug_read_pagetable(struct file *file, char __user
*userbuf, size_t count, loff_t *ppos)
{
- struct device *dev = file-private_data;
- struct omap_iommu *obj = dev_to_omap_iommu(dev);
+ struct omap_iommu *obj = file-private_data;
char *p, *buf;
size_t bytes;
@@ -181,93 +174,58 @@
Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism
On 10/01/2014 01:43 PM, Wolfram Sang wrote: Unfortunately it is 5 ;) We have display IP related bit in between 3 and 5 :P What on earth were the HW engineers thinking Let's test my RNG on the bit-placement of this register :) :D ...if we just have the instance parameter in the syscon phandle, we have to put the mapping into the driver, which makes IMHO no sense, because you have to touch the driver, if there is another SoC with the DCAN core. My guess is that TI won't come up with a 3rd variant so we won't have to touch the driver, but you never know for sure. ... which would be my preferred solution. I think new SoCs should have some kind of: compatible = commodore,c64ultra, bosch,d_can; in the DT anyhow to allow for SoC specific quirks/adjustments. And custom raminit belongs to that IMO (see the ti routine getting more and more specific). Right. For now we need 2 start/stop definations for the existing TI Socs. but where to store the raminit start/stop bits? The driver_data currently seems to contain the CAN type C_CAN vs D_CAN without containing it in a platform_data structure. Is it OK to create a new platform_data structure for CAN and put the type and raminit start/stop bits there? cheers, -roger -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism
On 10/01/2014 12:57 PM, Roger Quadros wrote: ...if we just have the instance parameter in the syscon phandle, we have to put the mapping into the driver, which makes IMHO no sense, because you have to touch the driver, if there is another SoC with the DCAN core. My guess is that TI won't come up with a 3rd variant so we won't have to touch the driver, but you never know for sure. When I comes to 99% compatible hardware I've seen some. ... which would be my preferred solution. I think new SoCs should have some kind of: compatible = commodore,c64ultra, bosch,d_can; in the DT anyhow to allow for SoC specific quirks/adjustments. And custom raminit belongs to that IMO (see the ti routine getting more and more specific). Right. For now we need 2 start/stop definations for the existing TI Socs. but where to store the raminit start/stop bits? The driver_data currently seems to contain the CAN type C_CAN vs D_CAN without containing it in a platform_data structure. Is it OK to create a new platform_data structure for CAN and put the type and raminit start/stop bits there? Yes, have a look how it's handled in the flexcan driver. regards, Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism
Is it OK to create a new platform_data structure for CAN and put the type and raminit start/stop bits there? I'd say yes, don't see a reason not to. signature.asc Description: Digital signature
Re: [PATCH v2 2/3] net: can: c_can: Add syscon/regmap RAMINIT mechanism
On 10/01/2014 12:43 PM, Wolfram Sang wrote: compatible = commodore,c64ultra, bosch,d_can; \o/ -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
Re: [PATCH] regmap: Allow read_reg_mask to be 0
On Tue, Sep 30, 2014 at 11:29:34PM +0200, Lars-Peter Clausen wrote: On 09/30/2014 11:18 PM, Dan Murphy wrote: Dan, please fix your mail client to word wrap within paragraphs. The device, which is already in production, has a specific control register that sets either the reading or writing of the rest of the registers. Here is the data sheet http://www.ti.com/lit/ds/symlink/afe4403.pdf See page 61 control0. Driver is written for this part just want to get this lead patch in or maybe an alternate solution. Looking at this the generic SPI regmap implementation might not necessarily be the best thing to use here and you are probably better of implementing either your own regmap bus or reg_read/reg_write callbacks that automatically set/clear the SPI_READ bit in the control register depending on the operation. It definitely needs more than just this change at any rate - any generic infrastructure that tries to work with the regmap is not going to know about this read/write register. signature.asc Description: Digital signature
[PATCH v2 1/2] mtd: nand: Force omap_elm to be built as a module if omap2_nand is a module
From: Ezequiel Garcia ezequ...@vanguardiasur.com.ar This commit adds a hidden option to build the omap_elm as a module, if omap2_nand is a module (and similarly in the built-in case). This fixes the following build error when omap2_nand is chosen built-in, and omap_elm is chosen as a module: drivers/built-in.o: In function `omap_nand_probe': drivers/mtd/nand/omap2.c:2010: undefined reference to `elm_config' drivers/mtd/nand/omap2.c:1980: undefined reference to `elm_config' drivers/mtd/nand/omap2.c:1927: undefined reference to `elm_config' drivers/built-in.o: In function `omap_elm_correct_data': drivers/mtd/nand/omap2.c:1444: undefined reference to `elm_decode_bch_error_page' Reported-by: Arnd Bergmann a...@arndb.de Signed-off-by: Ezequiel Garcia ezequ...@vanguardiasur.com.ar Signed-off-by: Roger Quadros rog...@ti.com --- drivers/mtd/nand/Kconfig | 5 - drivers/mtd/nand/Makefile | 2 +- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index f1cf503..1cb4b1b 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -96,7 +96,7 @@ config MTD_NAND_OMAP2 config MTD_NAND_OMAP_BCH depends on MTD_NAND_OMAP2 - tristate Support hardware based BCH error correction + bool Support hardware based BCH error correction default n select BCH help @@ -106,6 +106,9 @@ config MTD_NAND_OMAP_BCH legacy OMAP families like OMAP2xxx, OMAP3xxx do not have ELM engine so they should not enable this config symbol. +config MTD_NAND_OMAP_BCH_BUILD + def_tristate MTD_NAND_OMAP2 MTD_NAND_OMAP_BCH + config MTD_NAND_IDS tristate diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index b3237b7..9c847e4 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -27,7 +27,7 @@ obj-$(CONFIG_MTD_NAND_NDFC) += ndfc.o obj-$(CONFIG_MTD_NAND_ATMEL) += atmel_nand.o obj-$(CONFIG_MTD_NAND_GPIO)+= gpio.o obj-$(CONFIG_MTD_NAND_OMAP2) += omap2.o -obj-$(CONFIG_MTD_NAND_OMAP_BCH)+= omap_elm.o +obj-$(CONFIG_MTD_NAND_OMAP_BCH_BUILD) += omap_elm.o obj-$(CONFIG_MTD_NAND_CM_X270) += cmx270_nand.o obj-$(CONFIG_MTD_NAND_PXA3xx) += pxa3xx_nand.o obj-$(CONFIG_MTD_NAND_TMIO)+= tmio_nand.o -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] mtd: nand: omap: Fix build with CONFIG_MTD_NAND_OMAP_BCH=m
Hi, Patch 1 fixes build with OMAP nand driver as built-in and the BCH driver as a module. Ezequiel, I took the liberty to address an issue with your original patch so this is v2. Patch 2 fixes the help message for CONFIG_MTD_NAND_OMAP_BCH to avoid user confusion. CONFIG_MTD_NAND_OMAP_BCH is optional but doesn't harm on legacy OMAP platforms not having the ELM/BCH hardware. -- cheers, -roger Ezequiel Garcia (1): mtd: nand: Force omap_elm to be built as a module if omap2_nand is a module Roger Quadros (1): mtd: nand: omap: Correct CONFIG_MTD_NAND_OMAP_BCH help message drivers/mtd/nand/Kconfig | 7 +-- drivers/mtd/nand/Makefile | 2 +- 2 files changed, 6 insertions(+), 3 deletions(-) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] mtd: nand: omap: Correct CONFIG_MTD_NAND_OMAP_BCH help message
The MTD_NAND_OMAP_BCH doesn't harm on legacy OMAP platforms so don't state that it should be disabled for them. Signed-off-by: Roger Quadros rog...@ti.com --- drivers/mtd/nand/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 1cb4b1b..dd10646 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -104,7 +104,7 @@ config MTD_NAND_OMAP_BCH locate and correct errors when using BCH ECC scheme. This offloads the cpu from doing ECC error searching and correction. However some legacy OMAP families like OMAP2xxx, OMAP3xxx do not have ELM engine - so they should not enable this config symbol. + so this is optional for them. config MTD_NAND_OMAP_BCH_BUILD def_tristate MTD_NAND_OMAP2 MTD_NAND_OMAP_BCH -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] regmap: Allow read_reg_mask to be 0
Lars On 09/30/2014 04:29 PM, Lars-Peter Clausen wrote: On 09/30/2014 11:18 PM, Dan Murphy wrote: Lars On 09/30/2014 04:03 PM, Lars-Peter Clausen wrote: On 09/30/2014 06:07 PM, Dan Murphy wrote: There may be spi devices that do not require a register read mask to read the registers. Currently the code sets the read mask based on a non-zero value passed in from the driver or if that value is 0 sets the read mask to 0x80. It only sets it to the bus default if both read_flag_mask and write_flag_mask are 0. The assumption is that both of them being zero is a invalid configuration and either of them (or both) have to be non-zero for proper operation, since otherwise the device can't tell the difference between a read and a write. Do you have a device where both the read and the write mask is 0? - Lars Yes I do have a device that the read/write mask are both 0. The device, which is already in production, has a specific control register that sets either the reading or writing of the rest of the registers. Here is the data sheet http://www.ti.com/lit/ds/symlink/afe4403.pdf See page 61 control0. Driver is written for this part just want to get this lead patch in or maybe an alternate solution. Looking at this the generic SPI regmap implementation might not necessarily be the best thing to use here and you are probably better of implementing either your own regmap bus or reg_read/reg_write callbacks that automatically set/clear the SPI_READ bit in the control register depending on the operation. - Lars I am not sure implementing a different SPI regmap implementation is really the best thing. I am handling this control bit toggling in the peripheral driver. The device only needs to be written at init and then during calibration. Other then that it is read read read. Dan -- -- Dan Murphy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 09/13] dmaengine: edma: check for echan-edesc = NULL in edma_dma_pause()
On 09/29/2014 09:06 PM, Sebastian Andrzej Siewior wrote:
I added book keeping of whether or not the 8250-dma driver has an RX
transfer pending or not so we don't BUG here if it calls
dmaengine_pause() on a channel which has not a pending transfer. Guess
what, this is not enough.
The following can be triggered with a busy RX channel and hackbench in
background:
- DMA transfer completes. The callback is delayed via
vchan_cookie_complete() into a tasklet so it das not happen asap.
- hackbench keeps the system busy so the tasklet does not run soon.
- the UART collected enough data and generates an timeout-interrupt.
Since 8250-dma *thinks* the DMA-transfer is still pending it tries to
cancel it via invoking dmaengine_pause() first. This causes the segfault
because echan-edesc is NULL now that the transfer completed (however
the callback did not run yet).
With this patch we don't BUG in the scenario described.
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
Cc: vinod.k...@intel.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/dma/edma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7b65633f495e..123f578d6dd3 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -288,7 +288,7 @@ static int edma_slave_config(struct edma_chan *echan,
static int edma_dma_pause(struct edma_chan *echan)
{
/* Pause/Resume only allowed with cyclic mode */
- if (!echan-edesc-cyclic)
+ if (!echan-edesc || !echan-edesc-cyclic)
return -EINVAL;
edma_pause(echan-ch_num);
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/17] iommu/omap: Integrate omap-iommu-debug into omap-iommu
Hi Laurent,
On Tuesday 30 September 2014 16:16:07 Suman Anna wrote:
The debugfs support for OMAP IOMMU is currently implemented
as a module, warranting certain OMAP-specific IOMMU API to
be exported. The OMAP IOMMU, when enabled, can only be built-in
into the kernel, so integrate the OMAP IOMMU debug module
into the OMAP IOMMU driver. This helps in eliminating the
need to export most of the current OMAP IOMMU API.
The following are the main changes:
- The OMAP_IOMMU_DEBUG Kconfig option is eliminated, and
the OMAP IOMMU debugfs support is built alongside the OMAP
IOMMU driver, and enabled automatically only when debugfs
is enabled.
That's the part I'm unsure about. We're loosing the ability to save space by
not building the omap-iommu debugfs support when debugfs is enabled.
Yeah, I thought about it a bit, and went in favor of eliminating the
Kconfig. I don't have a strong opinion on this, but if saving space is
what is preferred, I can easily rework this patch to add it back.
Joerg, any preference which way we should go here?
For the rest of the series,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Thank you for reviewing the patches.
regards
Suman
- The debugfs directory and entry creation logic is reversed,
the calls are invoked by the OMAP IOMMU driver now.
- The current iffy circular logic of adding IOMMU archdata
to the IOMMU devices itself to get a pointer to the omap_iommu
object in the debugfs support code is replaced by directly
using the omap_iommu structure while creating the debugfs
entries.
- The debugfs root directory is renamed from the generic name
iommu to a specific name omap_iommu.
- Unneeded headers have also been cleaned up while at this.
- There will no longer be a omap-iommu-debug.ko module after
this patch.
Signed-off-by: Suman Anna s-a...@ti.com
---
drivers/iommu/Kconfig| 9
drivers/iommu/Makefile | 3 +-
drivers/iommu/omap-iommu-debug.c | 102
--- drivers/iommu/omap-iommu.c |
11 +++--
drivers/iommu/omap-iommu.h | 7 +++
5 files changed, 45 insertions(+), 87 deletions(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index dd51122..9724d4a 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -143,15 +143,6 @@ config OMAP_IOMMU
depends on ARCH_OMAP2PLUS
select IOMMU_API
-config OMAP_IOMMU_DEBUG
- tristate Export OMAP IOMMU internals in DebugFS
- depends on OMAP_IOMMU DEBUG_FS
- help
- Select this to see extensive information about
- the internal state of OMAP IOMMU in debugfs.
-
- Say N unless you know you need this.
-
config TEGRA_IOMMU_GART
bool Tegra GART IOMMU Support
depends on ARCH_TEGRA_2x_SOC
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 18fa446..e0a4fed 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -10,8 +10,7 @@ obj-$(CONFIG_DMAR_TABLE) += dmar.o
obj-$(CONFIG_INTEL_IOMMU) += iova.o intel-iommu.o
obj-$(CONFIG_IPMMU_VMSA) += ipmmu-vmsa.o
obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o
-obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o
-obj-$(CONFIG_OMAP_IOMMU_DEBUG) += omap-iommu-debug.o
+obj-$(CONFIG_OMAP_IOMMU) += omap-iommu.o omap-iommu-debug.o
obj-$(CONFIG_TEGRA_IOMMU_GART) += tegra-gart.o
obj-$(CONFIG_TEGRA_IOMMU_SMMU) += tegra-smmu.o
obj-$(CONFIG_EXYNOS_IOMMU) += exynos-iommu.o
diff --git a/drivers/iommu/omap-iommu-debug.c
b/drivers/iommu/omap-iommu-debug.c index 28de657..54a0dc6 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -10,15 +10,11 @@
* published by the Free Software Foundation.
*/
-#include linux/module.h
#include linux/err.h
-#include linux/clk.h
#include linux/io.h
#include linux/slab.h
#include linux/uaccess.h
-#include linux/platform_device.h
#include linux/debugfs.h
-#include linux/omap-iommu.h
#include linux/platform_data/iommu-omap.h
#include omap-iopgtable.h
@@ -31,8 +27,7 @@ static struct dentry *iommu_debug_root;
static ssize_t debug_read_regs(struct file *file, char __user *userbuf,
size_t count, loff_t *ppos)
{
-struct device *dev = file-private_data;
-struct omap_iommu *obj = dev_to_omap_iommu(dev);
+struct omap_iommu *obj = file-private_data;
char *p, *buf;
ssize_t bytes;
@@ -55,8 +50,7 @@ static ssize_t debug_read_regs(struct file *file, char
__user *userbuf, static ssize_t debug_read_tlb(struct file *file, char
__user *userbuf, size_t count, loff_t *ppos)
{
-struct device *dev = file-private_data;
-struct omap_iommu *obj = dev_to_omap_iommu(dev);
+struct omap_iommu *obj = file-private_data;
char *p, *buf;
ssize_t bytes, rest;
@@ -141,8 +135,7 @@ out:
static ssize_t debug_read_pagetable(struct file *file, char __user
*userbuf,
Re: [PATCH] regmap: Allow read_reg_mask to be 0
On 10/01/2014 01:39 PM, Dan Murphy wrote: Lars On 09/30/2014 04:29 PM, Lars-Peter Clausen wrote: On 09/30/2014 11:18 PM, Dan Murphy wrote: Lars On 09/30/2014 04:03 PM, Lars-Peter Clausen wrote: On 09/30/2014 06:07 PM, Dan Murphy wrote: There may be spi devices that do not require a register read mask to read the registers. Currently the code sets the read mask based on a non-zero value passed in from the driver or if that value is 0 sets the read mask to 0x80. It only sets it to the bus default if both read_flag_mask and write_flag_mask are 0. The assumption is that both of them being zero is a invalid configuration and either of them (or both) have to be non-zero for proper operation, since otherwise the device can't tell the difference between a read and a write. Do you have a device where both the read and the write mask is 0? - Lars Yes I do have a device that the read/write mask are both 0. The device, which is already in production, has a specific control register that sets either the reading or writing of the rest of the registers. Here is the data sheet http://www.ti.com/lit/ds/symlink/afe4403.pdf See page 61 control0. Driver is written for this part just want to get this lead patch in or maybe an alternate solution. Looking at this the generic SPI regmap implementation might not necessarily be the best thing to use here and you are probably better of implementing either your own regmap bus or reg_read/reg_write callbacks that automatically set/clear the SPI_READ bit in the control register depending on the operation. - Lars I am not sure implementing a different SPI regmap implementation is really the best thing. I am handling this control bit toggling in the peripheral driver. This is the very thing that regmap is supposed to hide, the specifics of how the read or write access happens. regmap_read() is supposed to do a read, regmap_write() is supposed to do a write. If regmap_read() only does a write if you previously did a regmap_write(regmap, CTRL0, SPI_READ); then the semantics of the interface are broken. This means you can't use generic infrastructure and it will confuse people who read and review your code. - Lars -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 3.17-rc6 on ODROID: ERROR: Bad of_node_put() on /ehci@12580000/port@1
3.17-rc7 boots on ODROID-U3 Ubuntu 14.04.
I deleted references to of_node_put in drivers/usb/host/ehci-exynos.c as
recommended.
# make exynos_defconfig
# make menuconfig
root@odroidu3:/b2/linux-3.17.0-rc7# grep DTB .config
CONFIG_ARM_APPENDED_DTB=y
CONFIG_ARM_ATAG_DTB_COMPAT=y
CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_EXTEND is not set
# make-kpkg -j 4 --initrd linux_headers linux_image
root@odroidu3:/b2/linux-3.17.0-rc7# ls -l ../linux*-3.17.0-rc7*.deb
-rw-r--r-- 1 root root 6410252 Oct 1 20:47
../linux-headers-3.17.0-rc7-6-gaad7fb9-dirty_3.17.0-rc7-6-gaad7fb9-dirty-10.00.Custom_armhf.deb
-rw-r--r-- 1 root root 5124364 Oct 1 20:48
../linux-image-3.17.0-rc7-6-gaad7fb9-dirty_3.17.0-rc7-6-gaad7fb9-dirty-10.00.Custom_armhf.deb
Installed the packages and generated a uInitrd
# make exynos4412-odroidu3.dtb
# root@odroidu3:/b2/linux-3.17.0-rc7# ls -l
arch/arm/boot/dts/exynos4412-odroidu3.dtb
-rw-r--r-- 1 root root 35543 Oct 1 23:01
arch/arm/boot/dts/exynos4412-odroidu3.dtb
# cat zImage exynos4412-odroidu3.dtb /media/boot/zImage+dtb
Made the necessary changes to /media/boot - cp zImage+dtb zImage and
cp uInitrd-3.17.0-rc7 uInitrrd
The kernel boots - no screens found in X. All my USB devices show and
USB hard drives mounted.
recompiled and installed xf86-video-armsoc-r4p0
root@odroidu3:~# uname -r
3.17.0-rc7-6-gaad7fb9-dirty
root@odroidu3:~# lsusb
Bus 001 Device 006: ID 13fd:1840 Initio Corporation INIC-1608 SATA bridge
Bus 001 Device 008: ID 0b95:7720 ASIX Electronics Corp. AX88772
Bus 001 Device 015: ID 0ccd:0028 TerraTec Electronic GmbH Aureon 5.1 MkII
Bus 001 Device 021: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 009: ID 0e8f:0022 GreenAsia Inc.
Bus 001 Device 007: ID 050d:0307 Belkin Components USB 2.0 - 7 ports Hub
[FSU307]
Bus 001 Device 005: ID 1a40:0101 Terminus Technology Inc. 4-Port HUB
Bus 001 Device 004: ID 13fd:1840 Initio Corporation INIC-1608 SATA bridge
Bus 001 Device 003: ID 0424:3503 Standard Microsystems Corp.
Bus 001 Device 002: ID 0424:9730 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Regards
Sid.
On 01/10/14 16:38, Grant Likely wrote:
On Wed, Oct 1, 2014 at 4:12 PM, Daniel Drake dr...@endlessm.com wrote:
On Wed, Oct 1, 2014 at 12:36 AM, Vivek Gautam gautam.vi...@samsung.com wrote:
One reason i doubt why it could be coming is because we are
specifically putting the
child after doing everything with it.
When we are getting the child node using for_each_available_child_of_node(),
which calls for of_get_next_available_child(). So of_get_next_available_child()
does a of_node_put() on the prev node, in case we have siblings to the child.
Can you see if the below change helps ?
diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
index 7189f2e..1b726bf 100644
--- a/drivers/usb/host/ehci-exynos.c
+++ b/drivers/usb/host/ehci-exynos.c
@@ -74,7 +74,6 @@ static int exynos_ehci_get_phy(struct device *dev,
phy = devm_of_phy_get(dev, child, NULL);
exynos_ehci-phy[phy_number] = phy;
- of_node_put(child);
if (IS_ERR(phy)) {
ret = PTR_ERR(phy);
if (ret == -EPROBE_DEFER) {
This is on top of usb-next.
If you are testing on rc6 only, then probably you will have to cherrypick two
patches each for ehci-exynos and ohci-exynos:
usb: host: ehci-exynos: Remove unnecessary usb-phy support
usb: host: ohci-exynos: Remove unnecessary usb-phy support
I made the equivalent change to 3.17-rc7 (right now 3.17 is my main
interest), i.e. removed all of_node_put calls from
exynos_ehci_get_phy(). Same change is needed in exynos_ohci_get_phy().
Now the warnings are gone.
BTW, I think the warning only appeared when CONFIG_OF_SELFTEST=y
I didn't check the implementation details like you did, but I looked
at a few other users of for_each_available_child_of_node and it looks
like indeed you do not need to call of_node_put() on the children in
the normal case, or at least, nobody else does.
CONFIG_OF_SELFTEST enables CONFIG_OF_DYNAMIC, and reference counting
is only implemented when OF_DYNAMIC is enabled. That's probably why
selftest exposes the problem.
g.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks
--
To unsubscribe from this list:
Re: [PATCH V3 3/3] mfd: palmas: Add support for optional wakeup
Hi Thomas,
* Thomas Gleixner t...@linutronix.de [140919 12:47]:
The wakeup handler is supposed to bring the thing out of deep sleep
and nothing else. All you want it to do is to mask itself and save the
information that the real device irq is pending.
A stub handler for the wakeup irq is enough. We can have that in the
irq/pm core and all it would do is simply:
Here's a patch along the lines of what you described, hopefully that's
fairly close to what you had in mind.
I also did play with the replaying of the interrupts but I don't think
that's needed. Well at least not for the omap case. I added some
comments about that to the code.
So far I've tested with the omap-serial and omap_hsmmc drivers. The
serial driver does not have any status as the device is powered off.
So replaying of the interrupt does not help there, we need to wait for
the next event anyways.
Then with omap_hsmmc the SDIO interrupt on dat1 line is level
sensitive and is noticed after the MMC controller is powered on
again. So no replaying of the device interrupt needed here either.
I still have not tested the MMC remux lines to GPIO for wake-up
events that's also needed for some omaps.
Regards,
Tony
8---
From: Tony Lindgren t...@atomide.com
Date: Wed, 1 Oct 2014 14:56:35 -0700
Subject: [PATCH] genirq: Add support for wake-up interrupts to fix irq reentry
issues in drivers
As pointed out by Thomas Gleixner, at least omap wake-up interrupts
have an issue with re-entrant interrupts because the wake-up interrupts
are now handled as a secondary interrupt controller. Further, the
wake-up interrupt just needs wake the system at least for omaps. So we
should just make the wake-up interrupt handling generic.
Note that at least initially we are keeping things simple by assuming the
wake-up interrupt is level sensitive, and the device pm_runtime_resume()
can deal with the situation, and no replaying of the lost device interrupts
is needed.
After tinkering with replaying of the lost device interrupts, my opinion is
that it should be avoided because of the issues listed in the comments of
this patch.
Signed-off-by: Tony Lindgren t...@atomide.com
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -139,11 +139,15 @@ extern int __must_check
request_percpu_irq(unsigned int irq, irq_handler_t handler,
const char *devname, void __percpu *percpu_dev_id);
+struct device;
+
+extern int __must_check
+request_wake_irq(struct device *dev, unsigned int wakeirq,
+unsigned long irqflags);
+
extern void free_irq(unsigned int, void *);
extern void free_percpu_irq(unsigned int, void __percpu *);
-struct device;
-
extern int __must_check
devm_request_threaded_irq(struct device *dev, unsigned int irq,
irq_handler_t handler, irq_handler_t thread_fn,
@@ -163,6 +167,10 @@ devm_request_any_context_irq(struct device *dev, unsigned
int irq,
irq_handler_t handler, unsigned long irqflags,
const char *devname, void *dev_id);
+extern int __must_check
+devm_request_wake_irq(struct device *dev, unsigned int wakeirq,
+ unsigned long irqflags);
+
extern void devm_free_irq(struct device *dev, unsigned int irq, void *dev_id);
/*
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -14,6 +14,7 @@
#include linux/module.h
#include linux/random.h
#include linux/interrupt.h
+#include linux/pm_runtime.h
#include linux/slab.h
#include linux/sched.h
#include linux/sched/rt.h
@@ -1578,6 +1579,111 @@ int request_any_context_irq(unsigned int irq,
irq_handler_t handler,
}
EXPORT_SYMBOL_GPL(request_any_context_irq);
+/**
+ * handle_wakeirq_thread - call device runtime pm calls on wake-up
interrupt
+ * @wakeirq: device specific wake-up interrupt
+ * @dev_id: struct device entry
+ */
+static irqreturn_t handle_wakeirq_thread(int wakeirq, void *dev_id)
+{
+ struct device *dev = dev_id;
+ irqreturn_t ret = IRQ_NONE;
+
+ if (pm_runtime_suspended(dev)) {
+ pm_runtime_mark_last_busy(dev);
+ pm_request_resume(dev);
+ ret = IRQ_HANDLED;
+ }
+
+ return ret;
+}
+
+/**
+ * setup_wakeirq - allocate a wake-up interrupt for a device
+ * @dev: device to wake up
+ * @wakeirq: interrupt that wakes up the device
+ * @wakeflags: flags to pass to the interrupt handler
+ * @devm: use devm
+ *
+ * Note that the wake-up interrupt starts disabled. The wake-up interrupt
+ * is typically enabled from the device pm_runtime_suspend() and disabled
+ * again in the device pm_runtime_resume(). For runtime PM, the wake-up
+ * interrupt should be always enabled, and for device suspend and resume,
+ * the wake-up interrupt should be enabled depending on the device specific
+ * configuration for device_can_wakeup().
+ *
+ * Note also that we are not resending the lost device interrupts.
+ * We assume that the
