[PATCH] ASoC: tlv320aic3x: Add support for tlv320aic3104
Disables GPIO support and LINE2 input and renames Mic3 input to Mic2,
if tlv320aic3104 mode is seleced. Devicetree binding document is
updated accordingly.
Signed-off-by: Jyri Sarha jsa...@ti.com
---
.../devicetree/bindings/sound/tlv320aic3x.txt | 10 +-
sound/soc/codecs/tlv320aic3x.c | 344 ++--
2 files changed, 252 insertions(+), 102 deletions(-)
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
index 5e6040c..47a213c 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
@@ -9,6 +9,7 @@ Required properties:
ti,tlv320aic33 - TLV320AIC33
ti,tlv320aic3007 - TLV320AIC3007
ti,tlv320aic3106 - TLV320AIC3106
+ti,tlv320aic3104 - TLV320AIC3104
- reg - int - I2C slave address
@@ -18,6 +19,7 @@ Optional properties:
- gpio-reset - gpio pin number used for codec reset
- ai3x-gpio-func - array of 2 int - AIC3X_GPIO1 AIC3X_GPIO2 Functionality
+ - Not supported on tlv320aic3104
- ai3x-micbias-vg - MicBias Voltage required.
1 - MICBIAS output is powered to 2.0V,
2 - MICBIAS output is powered to 2.5V,
@@ -36,7 +38,13 @@ CODEC output pins:
* HPLCOM
* HPRCOM
-CODEC input pins:
+CODEC input pins for TLV320AIC3104:
+ * MIC2L
+ * MIC2R
+ * LINE1L
+ * LINE1R
+
+CODEC input pins for other compatible codecs:
* MIC3L
* MIC3R
* LINE1L
diff --git a/sound/soc/codecs/tlv320aic3x.c b/sound/soc/codecs/tlv320aic3x.c
index b7ebce0..49ba3c7 100644
--- a/sound/soc/codecs/tlv320aic3x.c
+++ b/sound/soc/codecs/tlv320aic3x.c
@@ -87,6 +87,7 @@ struct aic3x_priv {
#define AIC3X_MODEL_3X 0
#define AIC3X_MODEL_33 1
#define AIC3X_MODEL_3007 2
+#define AIC3X_MODEL_3104 3
u16 model;
/* Selects the micbias voltage */
@@ -316,52 +317,37 @@ static const struct snd_kcontrol_new aic3x_snd_controls[]
= {
* only for swapped L-to-R and R-to-L routes. See below stereo controls
* for direct L-to-L and R-to-R routes.
*/
- SOC_SINGLE_TLV(Left Line Mixer Line2R Bypass Volume,
- LINE2R_2_LLOPM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Left Line Mixer PGAR Bypass Volume,
PGAR_2_LLOPM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Left Line Mixer DACR1 Playback Volume,
DACR1_2_LLOPM_VOL, 0, 118, 1, output_stage_tlv),
- SOC_SINGLE_TLV(Right Line Mixer Line2L Bypass Volume,
- LINE2L_2_RLOPM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Right Line Mixer PGAL Bypass Volume,
PGAL_2_RLOPM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Right Line Mixer DACL1 Playback Volume,
DACL1_2_RLOPM_VOL, 0, 118, 1, output_stage_tlv),
- SOC_SINGLE_TLV(Left HP Mixer Line2R Bypass Volume,
- LINE2R_2_HPLOUT_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Left HP Mixer PGAR Bypass Volume,
PGAR_2_HPLOUT_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Left HP Mixer DACR1 Playback Volume,
DACR1_2_HPLOUT_VOL, 0, 118, 1, output_stage_tlv),
- SOC_SINGLE_TLV(Right HP Mixer Line2L Bypass Volume,
- LINE2L_2_HPROUT_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Right HP Mixer PGAL Bypass Volume,
PGAL_2_HPROUT_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Right HP Mixer DACL1 Playback Volume,
DACL1_2_HPROUT_VOL, 0, 118, 1, output_stage_tlv),
- SOC_SINGLE_TLV(Left HPCOM Mixer Line2R Bypass Volume,
- LINE2R_2_HPLCOM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Left HPCOM Mixer PGAR Bypass Volume,
PGAR_2_HPLCOM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Left HPCOM Mixer DACR1 Playback Volume,
DACR1_2_HPLCOM_VOL, 0, 118, 1, output_stage_tlv),
- SOC_SINGLE_TLV(Right HPCOM Mixer Line2L Bypass Volume,
- LINE2L_2_HPRCOM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Right HPCOM Mixer PGAL Bypass Volume,
PGAL_2_HPRCOM_VOL, 0, 118, 1, output_stage_tlv),
SOC_SINGLE_TLV(Right HPCOM Mixer DACL1 Playback Volume,
DACL1_2_HPRCOM_VOL, 0, 118, 1, output_stage_tlv),
/* Stereo output controls for direct L-to-L and R-to-R routes */
- SOC_DOUBLE_R_TLV(Line Line2 Bypass Volume,
-LINE2L_2_LLOPM_VOL, LINE2R_2_RLOPM_VOL,
-0, 118, 1, output_stage_tlv),
SOC_DOUBLE_R_TLV(Line PGA Bypass Volume,
PGAL_2_LLOPM_VOL, PGAR_2_RLOPM_VOL,
0, 118, 1, output_stage_tlv),
@@ -369,9 +355,6 @@ static
Re: [PATCH v3 0/5] Add support for Fujitsu USB host controller
Hi, On Thu, Jan 29, 2015 at 10:23:12AM -0600, Felipe Balbi wrote: On Tue, Jan 27, 2015 at 09:22:50AM -0600, Felipe Balbi wrote: Hi, On Sun, Jan 25, 2015 at 04:13:23PM +0800, Sneeker Yeh wrote: These patches add support for XHCI compliant Host controller found on Fujitsu Socs, and are based on http://lwn.net/Articles/629162/ The first patch is to add Fujitsu glue layer of Synopsis DesignWare USB3 driver and last four patch is about quirk implementation of errata in Synopsis DesignWare USB3 IP. Patch 1 introduces a quirk with device disconnection management necessary Synopsys Designware USB3 IP with versions 3.00a and hardware configuration DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1. It solves a problem where without the quirk, that host controller will die after a usb device is disconnected from port of root hub. Patch 2 is to set Synopsis quirk in xhci platform driver based on xhci platform data. Patch 3 is to add a revison number 2.90a and 3.00a of Synopsis DesignWare USB3 IP core driver. Patch 4 introduces using a quirk based on a errata of Synopsis DesignWare USB3 IP which is versions 3.00a and has hardware configuration DWC_USB3_SUSPEND_ON_DISCONNECT_EN=1, which cannot be read from software. As a result this quirk has to be enabled via platform data or device tree. Patch 5 introduces Fujitsu Specific Glue layer in Synopsis DesignWare USB3 IP driver. Mathias, let me know how you want to handle this. Either I take them all, or you take them all. What do you prefer ? Mathias ? Mathias, a reminder on this series. -- balbi signature.asc Description: Digital signature
Re: [PATCH 03/14] drm/bridge: make bridge registration independent of drm flow
Hi, On 30 January 2015 at 15:37, Rob Clark robdcl...@gmail.com wrote: ok, so I probably should have had a closer look at this before it landed in drm-next, so if it is too late to revert (and deal w/ untangling subsequent patches that depend on this) some of these issues we'll just have to fix with follow-on patches. 1) needs headerdoc for new fxns in drm_bridge.c, and needs to be added in drm.tmpl 2) as far as I can tell, the new approach to cleaning up bridge objects is to just let them leak !?! I'll also need to update the new bridge in the msm edp code.. although that isn't such a big deal if I knew how this was *supposed* to work.. since what is there now at least doesn't look right.. Given how long these patches sat around doing being passively NACKed by discussions going around in circles, and how useful they are, I'd be much more in favour of fixing them up than reverting and going through the whole circus again ... Cheers, Daniel -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: i2c: add support for omnivision's ov2659 sensor
Hello, On Thu, Jan 15, 2015 at 11:39 PM, Lad, Prabhakar prabhakar.cse...@gmail.com wrote: From: Benoit Parrot bpar...@ti.com this patch adds support for omnivision's ov2659 sensor. Signed-off-by: Benoit Parrot bpar...@ti.com Signed-off-by: Lad, Prabhakar prabhakar.cse...@gmail.com --- .../devicetree/bindings/media/i2c/ov2659.txt | 33 + .../devicetree/bindings/vendor-prefixes.txt|1 + MAINTAINERS| 10 + drivers/media/i2c/Kconfig | 11 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/ov2659.c | 1623 include/media/ov2659.h | 33 + 7 files changed, 1712 insertions(+) create mode 100644 Documentation/devicetree/bindings/media/i2c/ov2659.txt create mode 100644 drivers/media/i2c/ov2659.c create mode 100644 include/media/ov2659.h gentle ping for review comments. Cheers, --Prabhakar Lad -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dtc: Use quotes to include header files
On Thu, 29 Jan 2015, Grant Likely wrote: On Tue, 16 Dec 2014 15:13:24 +1300 , Chris Packham chris.pack...@alliedtelesis.co.nz wrote: Currently in arch and driver code that needs early access to the flattened device tree it is necessary to add specific CFLAGS so that when scripts/dtc/libfdt/libfdt.h is included the C preprocessor is able to locate the libfdt versions of libfdt_env.h and fdt.h without generating an error. We already provide an alternative linux-specific version of libfdt_env.h and directly include scripts/dtc/libfdt/fdt.h so the inclusion by scripts/dtc/libfdt/libfdt.h is a no-op thanks to the inclusion guards. By using quotes in scripts/dtc/libfdt/libfdt.h it picks up fdt.h and libfdt_env.h from the source directory without needing to add CFLAGS for the sources that happen to include linux/libfdt.h. Signed-off-by: Chris Packham chris.pack...@alliedtelesis.co.nz --- Hi, This probably should come via git://git.jdl.com/software/dtc.git however this appears to be inaccessible at the moment. Is this still the canonical source for the device tree compiler and libfdt or has it been moved? How much deviation from the canonical source are we prepared to live with in the kernel? This came up on the arm-LKML[1]. Basically in the name of backwards compatibility I need to add a .dt_fixup to add some required nodes to the flattened device tree prior to the tree being un-flattened and processed. This is a trick powerpc makes use of fairly extensively and there are a few other instances of this. For the files that include linux/libfdt.h we currently also have to specify additional CFLAGS to satisfy the CPP. $ git grep 'linux/libfdt.h' arch/mips/cavium-octeon/octeon-platform.c:#include linux/libfdt.h arch/mips/cavium-octeon/setup.c:#include linux/libfdt.h arch/mips/mti-sead3/sead3-setup.c:#include linux/libfdt.h arch/powerpc/kernel/prom.c:#include linux/libfdt.h drivers/firmware/efi/libstub/fdt.c:#include linux/libfdt.h drivers/of/fdt.c:#include linux/libfdt.h drivers/of/fdt_address.c:#include linux/libfdt.h $ git grep -e '-I.*dtc/libfdt' arch/mips/cavium-octeon/Makefile:CFLAGS_octeon-platform.o = -I$(src)/../../../scripts/dtc/libfdt arch/mips/cavium-octeon/Makefile:CFLAGS_setup.o = -I$(src)/../../../scripts/dtc/libfdt arch/mips/mti-sead3/Makefile:CFLAGS_sead3-setup.o = -I$(src)/../../../scripts/dtc/libfdt arch/powerpc/kernel/Makefile:CFLAGS_prom.o = -I$(src)/../../../scripts/dtc/libfdt drivers/firmware/efi/libstub/Makefile:CFLAGS_fdt.o += -I$(srctree)/scripts/dtc/libfdt/ drivers/of/Makefile:CFLAGS_fdt.o = -I$(src)/../../scripts/dtc/libfdt drivers/of/Makefile:CFLAGS_fdt_address.o = -I$(src)/../../scripts/dtc/libfdt lib/Makefile: $(eval CFLAGS_$(file) = -I$(src)/../scripts/dtc/libfdt)) Simply by switching to using quotes we can avoid having this extra step. Assuming that this patch is acceptable a follow on clean up would be to remove the instances of CFLAGS_... listed above. Regards, Chris -- [1] - http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/310840.html scripts/dtc/libfdt/libfdt.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/dtc/libfdt/libfdt.h b/scripts/dtc/libfdt/libfdt.h index 73f4975..ea1ddcd 100644 --- a/scripts/dtc/libfdt/libfdt.h +++ b/scripts/dtc/libfdt/libfdt.h @@ -51,8 +51,8 @@ * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */ -#include libfdt_env.h -#include fdt.h +#include libfdt_env.h +#include fdt.h Until this is resolved with upstream DTC, what about adding dummy libfdt.h, libfdt_env.h and fdt.h to include/linux? That would get this out of the blocker path for merging this code. g. I'm traveling right now but I could work up an example patch next week. From the other discussions I think there are arguments in favor of keeping the angle brackets for the userspace libfdt usage. Any change in the kernel either adding dummy files in the system include path or performing a subsititution in an import script would probably be permanent. -- To unsubscribe from this list: send the line unsubscribe devicetree 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 1/2] clk: qcom: gcc-msm8960: add child devices support.
On Fri, Jan 30, 2015 at 2:17 AM, Srinivas Kandagatla srinivas.kandaga...@linaro.org wrote: This patch adds support to add child devices to gcc as some of the registers mapped by gcc are used by drivers like thermal sensors. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org --- drivers/clk/qcom/gcc-msm8960.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/clk/qcom/gcc-msm8960.c b/drivers/clk/qcom/gcc-msm8960.c index 0cd3e26..3ba77c5 100644 --- a/drivers/clk/qcom/gcc-msm8960.c +++ b/drivers/clk/qcom/gcc-msm8960.c @@ -15,6 +15,7 @@ #include linux/bitops.h #include linux/err.h #include linux/platform_device.h +#include linux/of_platform.h #include linux/module.h #include linux/of.h #include linux/of_device.h @@ -3658,6 +3659,7 @@ static int gcc_msm8960_probe(struct platform_device *pdev) struct clk *clk; struct device *dev = pdev-dev; const struct of_device_id *match; + int ret; match = of_match_device(gcc_msm8960_match_table, pdev-dev); if (!match) @@ -3677,12 +3679,18 @@ static int gcc_msm8960_probe(struct platform_device *pdev) if (IS_ERR(clk)) return PTR_ERR(clk); - return qcom_cc_probe(pdev, match-data); + ret = qcom_cc_probe(pdev, match-data); + if (ret) + return ret; + + return of_platform_populate(pdev-dev.of_node, NULL, NULL, pdev-dev); How about calling of_syscon_register() instead? That would give us a handle to a regmap that can be consumed in e.g. the thermal driver. I think this use case is exactly why that was introduced. Regards, Bjorn -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 1/6] of: iommu: add ptr to OF node arg to of_iommu_configure()
On 01/29/2015 07:24 PM, Laurent Pinchart wrote: Hi Rob, On Thursday 29 January 2015 10:49:38 Rob Herring wrote: On Wed, Jan 28, 2015 at 5:32 PM, Laurent Pinchart wrote: On Wednesday 28 January 2015 13:32:19 Will Deacon wrote: On Wed, Jan 28, 2015 at 01:15:10PM +, Laurent Pinchart wrote: On Wednesday 28 January 2015 12:29:42 Will Deacon wrote: On Wed, Jan 28, 2015 at 12:23:03PM +, Laurent Pinchart wrote: On Wednesday 28 January 2015 11:33:00 Will Deacon wrote: On Mon, Jan 26, 2015 at 06:49:01PM +, Murali Karicheri wrote: On 01/25/2015 08:32 AM, Laurent Pinchart wrote: On Friday 23 January 2015 17:32:34 Murali Karicheri wrote: Function of_iommu_configure() is called from of_dma_configure() to setup iommu ops using DT property. This API is currently used for platform devices for which DMA configuration (including iommu ops) may come from device's parent. To extend this functionality for PCI devices, this API need to take a parent node ptr as an argument instead of assuming device's parent. This is needed since for PCI, the dma configuration may be defined in the DT node of the root bus bridge's parent device. Currently only dma-range is used for PCI and iommu is not supported. So return error if the device is PCI. [...] If I understand Murali's patch set right (please correct me if that's not the case) the PCI code walks up the DT nodes hierarchy to the parent node that contains the iommus attribute and passes a pointer to that node to this function. It's thus a PCI-specific solution. As a temporary hack that's OK I suppose, but if implementing it right straight away isn't difficult that would be better. It looks to me like the code walks the PCI topology to get the DT node for the host controller, and passes *that* to of_dma_configure. That sounds like the right thing to do to me, especially since the PCI topology is likely not encoded in the device-tree. So actually, it is passing the first parent node afaict. Indeed, that's right. I forgot for a moment that we have non-DT devices ;-) Acked-by: Laurent Pinchartlaurent.pinch...@ideasonboard.com Murali, nitpicking a bit, shouldn't the iommu_np parameter be renamed ? It points to the node containing the iommus parameter, not to the iommu node, so the current name is slightly confusing. A brief kerneldoc above the function would also help. This can be the subject of a separate patch. It was more confusing having np and node within the function. Agreed. How about master_np or iommu_master_np ? The latter might be a bit long. Probabaly master_np suffice as this function is named of_iommu_configure(). I will update it. -- Murali Karicheri Linux Kernel, Texas Instruments -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support
On 01/30/2015 09:08 AM, Russell King - ARM Linux wrote: On Fri, Jan 30, 2015 at 07:03:03AM -0500, Peter Hurley wrote: On 01/30/2015 05:18 AM, Thierry Reding wrote: -ENODEV is certainly not the correct return value if a resource is not available. It translates to no such device, but the device must clearly be there, otherwise the -probe() shouldn't have been called. -ENODEV is the appropriate return from the probe(); there is no device. No it is not. no such device means the device is not present. If the device is not present, we wouldn't have a struct device associated with it. The missing resource is an error condition: what it's saying is that the device is there, but something has failed in providing the IO regions necessary to access it. That's really something very different from there is no device present. This is masking behavior changes behind what is essentially a refactor. For example, here's Felipe's changelog to omap-serial: commit d044d2356f8dd18c755e13f34318bc03ef9c6887 Author: Felipe Balbi ba...@ti.com Date: Wed Apr 23 09:58:33 2014 -0500 tty: serial: omap: switch over to devm_ioremap_resource just using helper function to remove some duplicated code a bit. While at that, also move allocation of struct uart_omap_port higher in the code so that we return much earlier in case of no memory. Signed-off-by: Felipe Balbi ba...@ti.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org No mention of correcting an error return value here. Why change the error return from probe() now? Before you say consistency, I think you should look at the stats below. IOW, if you want to change the error code return from probe() for consistency's sake, a tree-wide patch would be the appropriate way. Or if it really isn't there, then you'd at least need a memory region to probe, otherwise you can't determine whether it's there or not. So from the perspective of a device driver I think a missing, or NULL, resource, is indeed an invalid argument. Trying to argue that a missing host bus window is an invalid argument to probe() is just trying to make the shoe fit. As is arguing that -ENODEV is an appropriate return value for the missing resource. Moreover, returning -ENODEV is actually *bad* in this case - the kernel's generic probe handling does not report the failure of the driver to bind given this, so a missing resource potentially becomes a silent failure of a driver - leading users to wonder why their devices aren't found. If we /really/ have a problem with the error code, then why not invent a new error code to cater for this condition - maybe, EBADRES (bad resource). I understand that people might see some ambiguity there, and -EINVAL is certainly not a very accurate description, but such is the nature of error codes. You pick what fits best. -ENXIO and -EADDRNOTAVAIL had been under discussion as well if I remember correctly, but they both equally ambiguous. -ENODATA might have been a better fit, but that too has a different meaning in other contexts. Besides, there's an error message that goes along with the error code return, that should remove any ambiguity for people looking at dmesg. All of that said, the original assertion that the check is not required is still valid. We can argue at length about the specific error code but if we decide that it needs to change, then we should modify devm_ioremap_resource() rather than requiring all callers to perform the extra check again. None of the devm_ioremap_resource() changes have been submitted for serial drivers. $ grep devm_ioremap_resource drivers/tty/serial/ -r | wc -l 10 Ok, not 'none' but hardly tree-wide. And of those 10 drivers now using devm_ioremap_resource(), 3 drivers still return ENODEV for a missing resource [1]. (FWIW, I wrote 'none' on the basis of a grep of devm_ioremap_resource and looking at the last one, serial-tegra.c, which has exactly the construct objected to in the Spreadtrum driver). Another 9 drivers still use plain devm_ioremap(), even those with trivial conversions like samsung.c [2] Of the serial drivers which use platform_get_resource(), 10 return ENODEV 5 return EINVAL (not including those converted to devm_ioremap_resource()) 4 return ENXIO 3 return ENOMEM 2 return ENOENT 1 returns EBUSY 1 returns EFAULT So to recap, I see no reason to respin this driver submission when: 1. even drivers already using devm_ioremap_resource() aren't consistent 2. drivers which could trivially use devm_ioremap_resource, don't 3. there's no basis for requiring consistent return value _yet_ (or even what that value should be) 4. the platform_get_resource()/devm_ioremap_resource is an awkward code construct Regards, Peter Hurley [1] drivers/tty/serial/bcm63xx_uart.c- res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); drivers/tty/serial/bcm63xx_uart.c- if (!res_mem)
Re: Reading /sys with side effects (was Re: [PATCH 1/2] Documentation: leds: Add description of LED Flash class extension)
On Fri, Jan 30, 2015 at 09:55:30AM +0100, Jacek Anaszewski wrote: Hi Pavel, On 01/29/2015 10:14 PM, Pavel Machek wrote: Hi! + - flash_fault - list of flash faults that may have occurred: + * led-over-voltage - flash controller voltage to the flash LED + has exceededthe limit specific to the flash controller + * flash-timeout-exceeded - the flash strobe was still on when + the timeout set by the user has expired; not all flash + controllers may set this in all such conditions + * controller-over-temperature - the flash controller has + overheated + * controller-short-circuit - the short circuit protection + of the flash controller has been triggered + * led-power-supply-over-current - current in the LED power + supply has exceeded the limit specific to the flash + controller + * indicator-led-fault - the flash controller has detected + a short or open circuit condition on the indicator LED + * led-under-voltage - flash controller voltage to the flash + LED has been below the minimum limit specific to + the flash + * controller-under-voltage - the input voltage of the flash + controller is below the limit under which strobing the + flash at full current will not be possible. The condition + persists until this flag is no longer set + * led-over-temperature - the temperature of the LED has exceeded + its allowed upper limit + + Flash faults are cleared, if possible, by reading the attribute. That's bad. Now you can no longer present flash_fault file as readable to non-root users, and grep -ri foo /sys will interfere with your camera application. Bad interface, just fix it. In my opinion it isn't crucial for the user to be aware of the fact that some non-persistent fault happened right after strobing the flash (e.g. over temperature). I cannot see anything harmful in the situation when someone does grep on /sys and clears non-persistent fault on a flash LED device. So why export the faults at all? Faults may prevent strobing the flash in case of some devices. The example of such a device is ADP1663 (drivers/media/i2c/adp1653.c). This driver reads the faults before strobing the flash and if a fault preventing strobing has occurred it returns -EBUSY. If this driver was made a LED Flash class driver, then it would expose flash_faults attribute. The driver would probably need redesigning - checking the faults before strobing would have to be avoided and it should be left to the userspace. That's fine, but Pavel's point is that you shouldn't clear a fault by reading a sysfs file as you don't control who reads all sysfs files (hint, libudev might cache all attributes when they are found / change, which could prevent anyone else from seeing that fault.) So please fix this, make a write to clear a fault or some other such explicit action, not a simple read. That's not an acceptable api. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] pinctrl: Broadcom Cygnus pinctrl device tree binding
On 1/30/2015 6:18 AM, Linus Walleij wrote: On Fri, Jan 23, 2015 at 7:49 AM, Ray Jui r...@broadcom.com wrote: I dig into the pinctrl framework code a bit more and found that I can use pinctrl_request_gpio from the GPIO driver and implement gpio_request_enable in the pinctrl driver. Yep :) ain't it nice. The only problem I see now is that these APIs seem to expect the use of global GPIO numbers? No they don't, only if you use the deprecated pinctrl_add_gpio_range(). Instead, when you register your struct gpio_chip, use gpiochip_add_pin_range() and this will use relative offsets without relying on global GPIO numbers. This latter call replaces pinctrl_add_gpio_range(). I hope I'm not missing something here? You're missing gpiochip_add_pin_range() ;) Yours, Linus Walleij Yeah, I realized this while implementing the driver, :) I'm now in the final testing/cleaning phase of both Cygnus pinmux and gpio/pinconf driver. I really appreciate that the pinctrl framework allows the two to work seamlessly with each other and at the same time provides the necessary interface to bridge the two, :) I should be able to send out the patches of the two drivers for review sometime next week. Thanks for the help! Ray -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/14] drm/bridge: make bridge registration independent of drm flow
On Tue, Jan 20, 2015 at 11:38 AM, Ajay Kumar ajaykumar...@samsung.com wrote:
Currently, third party bridge drivers(ptn3460) are dependent
on the corresponding encoder driver init, since bridge driver
needs a drm_device pointer to finish drm initializations.
The encoder driver passes the drm_device pointer to the
bridge driver. Because of this dependency, third party drivers
like ptn3460 doesn't adhere to the driver model.
In this patch, we reframe the bridge registration framework
so that bridge initialization is split into 2 steps, and
bridge registration happens independent of drm flow:
--Step 1: gather all the bridge settings independent of drm and
add the bridge onto a global list of bridges.
--Step 2: when the encoder driver is probed, call drm_bridge_attach
for the corresponding bridge so that the bridge receives
drm_device pointer and continues with connector and other
drm initializations.
The old set of bridge helpers are removed, and a set of new helpers
are added to accomplish the 2 step initialization.
The bridge devices register themselves onto global list of bridges
when they get probed by calling drm_bridge_add.
The parent encoder driver waits till the bridge is available
in the lookup table(by calling of_drm_find_bridge) and then
continues with its initialization.
The encoder driver should also call drm_bridge_attach to pass
on the drm_device to the bridge object.
drm_bridge_attach inturn calls bridge-funcs-attach so that
bridge can continue with drm related initializations.
ok, so I probably should have had a closer look at this before it
landed in drm-next, so if it is too late to revert (and deal w/
untangling subsequent patches that depend on this) some of these
issues we'll just have to fix with follow-on patches.
1) needs headerdoc for new fxns in drm_bridge.c, and needs to be added
in drm.tmpl
2) as far as I can tell, the new approach to cleaning up bridge
objects is to just let them leak !?!
I'll also need to update the new bridge in the msm edp code..
although that isn't such a big deal if I knew how this was *supposed*
to work.. since what is there now at least doesn't look right..
BR,
-R
Signed-off-by: Ajay Kumar ajaykumar...@samsung.com
Acked-by: Inki Dae inki@samsung.com
Tested-by: Rahul Sharma rahul.sha...@samsung.com
Tested-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Tested-by: Gustavo Padovan gustavo.pado...@collabora.co.uk
Tested-by: Sjoerd Simons sjoerd.sim...@collabora.co.uk
---
drivers/gpu/drm/Makefile |2 +-
drivers/gpu/drm/bridge/ptn3460.c | 27 +-
drivers/gpu/drm/drm_bridge.c | 91
drivers/gpu/drm/drm_crtc.c | 67 ---
drivers/gpu/drm/msm/hdmi/hdmi.c|4 +-
drivers/gpu/drm/msm/hdmi/hdmi.h|1 +
drivers/gpu/drm/msm/hdmi/hdmi_bridge.c |6 +--
drivers/gpu/drm/sti/sti_hda.c | 10 +---
drivers/gpu/drm/sti/sti_hdmi.c | 10 +---
include/drm/bridge/ptn3460.h |8 +++
include/drm/drm_crtc.h | 26 -
11 files changed, 133 insertions(+), 119 deletions(-)
create mode 100644 drivers/gpu/drm/drm_bridge.c
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index e620807..c83ef2d 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -14,7 +14,7 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
- drm_modeset_lock.o drm_atomic.o
+ drm_modeset_lock.o drm_atomic.o drm_bridge.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/bridge/ptn3460.c
b/drivers/gpu/drm/bridge/ptn3460.c
index a2ddc8d..4a818c1 100644
--- a/drivers/gpu/drm/bridge/ptn3460.c
+++ b/drivers/gpu/drm/bridge/ptn3460.c
@@ -176,24 +176,11 @@ static void ptn3460_post_disable(struct drm_bridge
*bridge)
{
}
-static void ptn3460_bridge_destroy(struct drm_bridge *bridge)
-{
- struct ptn3460_bridge *ptn_bridge = bridge_to_ptn3460(bridge);
-
- drm_bridge_cleanup(bridge);
- if (gpio_is_valid(ptn_bridge-gpio_pd_n))
- gpio_free(ptn_bridge-gpio_pd_n);
- if (gpio_is_valid(ptn_bridge-gpio_rst_n))
- gpio_free(ptn_bridge-gpio_rst_n);
- /* Nothing else to free, we've got devm allocated memory */
-}
-
static struct drm_bridge_funcs ptn3460_bridge_funcs = {
.pre_enable = ptn3460_pre_enable,
.enable = ptn3460_enable,
.disable = ptn3460_disable,
.post_disable = ptn3460_post_disable,
- .destroy = ptn3460_bridge_destroy,
};
static int ptn3460_get_modes(struct
Re: [PATCH v10 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support
On Fri, Jan 30, 2015 at 10:32:54AM -0500, Peter Hurley wrote: Before you say consistency, I think you should look at the stats below. IOW, if you want to change the error code return from probe() for consistency's sake, a tree-wide patch would be the appropriate way. Now look outside the serial driver sub-tree. There are 1234 instances of platform_get_resource(, IORESOURCE_MEM, ) in the drivers/ sub-tree, with 700 instances of devm_ioremap_resource() being used there. Of the devm_ioremap_resource() instances: - 555 use platform_get_resource() in the preceding two lines - which is not enough to do anything but rely on the -EINVAL return value. - 16 mention ENODEV in the preceding three lines. There are 132 which use platform_get_resource() and return ENODEV within the following three lines (which may intersect with the above 16 number) and 88 which use EINVAL. So, there are in total 643 instances where a missing resource returns EINVAL, and between 132 and 148 instances which return ENODEV. Yes, 643 + 148 isn't 1234, but I'm not going to read through all 1234 locations just for the sake of this thread. What's clear though is that more than 50% of sites using platform_get_resource(, IORESOURCE_MEM, ) return EINVAL for the lack of a resource. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/14] drm/bridge: make bridge registration independent of drm flow
On Fri, Jan 30, 2015 at 10:37:19AM -0500, Rob Clark wrote: On Tue, Jan 20, 2015 at 11:38 AM, Ajay Kumar ajaykumar...@samsung.com wrote: I'll also need to update the new bridge in the msm edp code.. although that isn't such a big deal if I knew how this was *supposed* to work.. since what is there now at least doesn't look right.. I wonder whether the new dw-hdmi bridge code get fixed up too... -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support
On 01/30/2015 10:49 AM, Russell King - ARM Linux wrote: On Fri, Jan 30, 2015 at 10:32:54AM -0500, Peter Hurley wrote: Before you say consistency, I think you should look at the stats below. IOW, if you want to change the error code return from probe() for consistency's sake, a tree-wide patch would be the appropriate way. Now look outside the serial driver sub-tree. There are 1234 instances of platform_get_resource(, IORESOURCE_MEM, ) in the drivers/ sub-tree, with 700 instances of devm_ioremap_resource() being used there. Of the devm_ioremap_resource() instances: - 555 use platform_get_resource() in the preceding two lines - which is not enough to do anything but rely on the -EINVAL return value. - 16 mention ENODEV in the preceding three lines. There are 132 which use platform_get_resource() and return ENODEV within the following three lines (which may intersect with the above 16 number) and 88 which use EINVAL. So, there are in total 643 instances where a missing resource returns EINVAL, and between 132 and 148 instances which return ENODEV. Yes, 643 + 148 isn't 1234, but I'm not going to read through all 1234 locations just for the sake of this thread. What's clear though is that more than 50% of sites using platform_get_resource(, IORESOURCE_MEM, ) return EINVAL for the lack of a resource. Sure, now that they're using devm_ioremap_resource(). What about before they were converted? For example, of the 10 serial drivers now using devm_ioremap_resource(), _not 1 returned EINVAL_ prior to using devm_ioremap_resource(). And of those 10 commits, only 1 mentions changing the return codes on purpose. In fact, all of them but one returned ENODEV. Regards, Peter Hurley -- To unsubscribe from this list: send the line unsubscribe devicetree 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 1/6] soc: qcom: gsbi: Add support for ADM CRCI muxing
On Jan 30, 2015, at 12:25 AM, Andy Gross agr...@codeaurora.org wrote:
This patch adds automatic configuration for the ADM CRCI muxing required to
support DMA operations for GSBI clients. The GSBI mode and instance determine
the correct TCSR ADM CRCI MUX value that must be programmed so that the DMA
works properly.
Signed-off-by: Andy Gross agr...@codeaurora.org
---
.../devicetree/bindings/soc/qcom/qcom,gsbi.txt | 18 ++-
drivers/soc/qcom/Kconfig |1 +
drivers/soc/qcom/qcom_gsbi.c | 153
3 files changed, 171 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt
b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt
index 4ce24d4..8fe7b37 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt
@@ -6,7 +6,7 @@ configuration settings. The mode setting will govern the
input/output mode of
the 4 GSBI IOs.
Required properties:
-- compatible: must contain qcom,gsbi-v1.0.0 for APQ8064/IPQ8064
+- compatible:Should contain qcom,gsbi-v1.0.0
- reg: Address range for GSBI registers
- clocks: required clock
- clock-names: must contain iface entry
@@ -16,12 +16,16 @@ Required properties:
Optional properties:
- qcom,crci : indicates CRCI MUX value for QUP CRCI ports. Please reference
dt-bindings/soc/qcom,gsbi.h for valid CRCI mux values.
+- syscon-tcsr: indicates phandle of TCSR syscon node. Required if child uses
+ dma.
Required properties if child node exists:
- #address-cells: Must be 1
- #size-cells: Must be 1
- ranges: Must be present
+Note: Each GSBI should have an alias correctly numbered in aliases node.
+
Properties for children:
A GSBI controller node can contain 0 or more child nodes representing serial
@@ -37,6 +41,10 @@ Example for APQ8064:
#include dt-bindings/soc/qcom,gsbi.h
+ aliases {
+ gsbi4 = gsbi4;
+ };
You appear to be using the alias name to determine a index number for the gsbi,
if that is the case, than you should probably just add a cell-index node to the
gsbi’s for this purpose.
+
gsbi4@1630 {
compatible = qcom,gsbi-v1.0.0;
reg = 0x1630 0x100;
@@ -48,6 +56,8 @@ Example for APQ8064:
qcom,mode = GSBI_PROT_I2C_UART;
qcom,crci = GSBI_CRCI_QUP;
+ syscon-tcsr = tcsr;
+
/* child nodes go under here */
i2c_qup4: i2c@1638 {
@@ -76,3 +86,9 @@ Example for APQ8064:
};
};
+ tcsr: syscon@1a40 {
+ compatible = qcom,apq8064-tcsr, syscon;
+ reg = 0x1a40 0x100;
+ };
+
+
- k
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe devicetree 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/4] gpio: add parameter to allow the use named gpios
On Fri, Jan 30, 2015 at 02:16:00PM -0800, Dmitry Torokhov wrote: On Fri, Jan 30, 2015 at 11:12:53AM -0800, Bryan Wu wrote: On Fri, Jan 30, 2015 at 5:46 AM, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Jan 21, 2015 at 10:33 PM, Olliver Schinagl o.schin...@ultimaker.com wrote: From: Olliver Schinagl oli...@schinagl.nl The gpio binding document says that new code should always use named gpios. Patch 40b73183 added support to parse a list of gpios from child nodes, but does not make it possible to use named gpios. This patch adds the con_id property and implements it is done in gpiolib.c, where the old-style of using unnamed gpios still works. Signed-off-by: Olliver Schinagl oli...@schinagl.nl --- drivers/gpio/devres.c | 18 +- drivers/input/keyboard/gpio_keys_polled.c | 2 +- drivers/leds/leds-gpio.c | 2 +- include/linux/gpio/consumer.h | 1 + Alexandre: does this match your vision of how it should work, i.e. ACK? Bryan/Dmitry: can you ACK the oneliners in your subsystems? Sure, please take my Ack Acked-by: Bryan Wu coolo...@gmail.com Mine as well: Acked-by: Dmitry Torokhov dmitry.torok...@gmail.com Forgot to mention: the ack is for this patch only; the patch #4 is NAKed because: 1. The logic of handling old and new name AFAICS is broken and 2. gpio_keys_polled-gpios as name is plain ugly. Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe devicetree 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 12/13] ARM: shmobile: alt dts: Add chosen/stdout-path
Hello. On 10/03/2014 07:11 PM, Geert Uytterhoeven wrote: Add a stdout-path property so that automatic console selection works in the absence of a console= parameter on the kernel command line. Note that we have to keep the console=ttySC0,38400 parameter in chosen/bootargs, else the console will use the default setting of 115200 baud. I've looked at the code and it appears that one can still specify a baud rate after ':' even in the stdout-path prop. Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be WBR, Sergei -- To unsubscribe from this list: send the line unsubscribe devicetree 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 1/2] clk: qcom: gcc-msm8960: add child devices support.
On 01/30/15 14:00, Bjorn Andersson wrote: On Fri, Jan 30, 2015 at 1:16 PM, Stephen Boyd sb...@codeaurora.org wrote: On 01/30/15 10:06, Srinivas Kandagatla wrote: [..] Stephen Any comments? I don't understand any of this. We should be making a specific tsens device directly in the gcc driver probe and not doing any sort of of_platform_populate(). This is what I had, but it probably could be done better so that we can assign the struct device's of_node pointer before registering on the platform bus. platform_device_register_data(pdev-dev, tsens8960-tm, -1, pdev-dev.of_node, sizeof(pdev-dev.of_node)); Then if we need to add any properties like #sensor-cells or coefficients the tsens driver can use the same of_node that gcc is using. That makes sense and the dt will describe the hardware nicely, but how do you get access to the register space from the tsens driver? Will dev_get_regmap(pdev-dev.parent, NULL); find the mmio regmap of gcc perhaps? Yes that's the plan. We'll have to do slightly different stuff for 8974 where tsens is split out from gcc into its own space. That should still be easy enough though by checking the of_node against some compatible string. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/3] Documentation: DT bindings: add nvidia, tegra132-denver compatible string
Add a compatible string for the NVIDIA Denver CPU to the ARM CPU DT binding documentation file. The primary objective here is to keep checkpatch.pl from warning when the compatible string is used in an SoC DT file, per: http://marc.info/?l=linux-tegram=142201349727836w=2 This second version changes the string from nvidia,denver to nvidia,tegra132-denver to more precisely describe the revision of the Denver CPU complex that is present in the Tegra132 SoC. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Heiko Stuebner he...@sntech.de Cc: Arnd Bergmann a...@arndb.de Cc: Catalin Marinas catalin.mari...@arm.com Cc: Olof Johansson o...@lixom.net Cc: Maxime Ripard maxime.rip...@free-electrons.com Cc: Rohit Vaswani rvasw...@codeaurora.org Cc: Paul Walmsley pwalms...@nvidia.com Cc: Marc Carino marc.cee...@gmail.com Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com Cc: linux-ker...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org --- Documentation/devicetree/bindings/arm/cpus.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index b2aacbe16ed9..8b9e0a95de31 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -175,6 +175,7 @@ nodes to be present and contain the properties described below. marvell,pj4a marvell,pj4b marvell,sheeva-v5 + nvidia,tegra132-denver qcom,krait qcom,scorpion - enable-method -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] Documentation: DT bindings: add more Tegra chip compatible strings
Align compatible strings for several IP blocks present on Tegra chips with the latest doctrine from the DT maintainers: http://marc.info/?l=devicetreem=142255654213019w=2 The primary objective here is to avoid checkpatch warnings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 DT binding text files have been updated for the following IP blocks: - PCIe - SOR - SoC timers - AHB gizmo - APB_MISC - pinmux control - UART - PWM - I2C - SPI - RTC - PMC - eFuse - AHCI - HDA - XUSB_PADCTRL - SDHCI - SOC_THERM - AHUB - I2S - EHCI - USB PHY N.B. The nvidia,tegra20-timer compatible string is removed from the nvidia,tegra30-timer.txt documentation file because it's already mentioned in the nvidia,tegra20-timer.txt documentation file. This second version takes into account the following requests from Rob Herring robherri...@gmail.com: - Per-IP block patches have been combined into a single patch - Explicit documentation about which compatible strings are actually matched by the driver has been removed. In its place is implicit documentation that loosely follows Rob's prescribed format: Must contain 'nvidia,chip-pcie, nvidia,tegra20-pcie' where chip is tegra30, tegra132, ... [...] You should attempt to document known values of chip if you use it Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Alexandre Courbot gnu...@gmail.com Cc: Dylan Reid dgr...@chromium.org Cc: Eduardo Valentin edubez...@gmail.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Hans de Goede hdego...@redhat.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Jingchang Lu jingchang...@freescale.com Cc: John Crispin blo...@openwrt.org Cc: Kumar Gala ga...@codeaurora.org Cc: Linus Walleij linus.wall...@linaro.org Cc: Mark Rutland mark.rutl...@arm.com Cc: Mikko Perttunen mperttu...@nvidia.com Cc: Murali Karicheri m-kariche...@ti.com Cc: Paul Walmsley pwalms...@nvidia.com Cc: Pawel Moll pawel.m...@arm.com Cc: Peter De Schrijver pdeschrij...@nvidia.com Cc: Peter Hurley pe...@hurleysoftware.com Cc: Rob Herring robh...@kernel.org Cc: Sean Paul seanp...@chromium.org Cc: Stephen Warren swar...@wwwdotorg.org Cc: Takashi Iwai ti...@suse.de Cc: Tejun Heo t...@kernel.org Cc: Terje Bergström tbergst...@nvidia.com Cc: Thierry Reding thierry.red...@gmail.com Cc: Tuomas Tynkkynen ttynkky...@nvidia.com Cc: Wolfram Sang w...@the-dreams.de Cc: Zhang Rui rui.zh...@intel.com Cc: dri-de...@lists.freedesktop.org Cc: linux-...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: linux-...@vger.kernel.org Cc: linux-te...@vger.kernel.org --- .../bindings/arm/tegra/nvidia,tegra20-ahb.txt |5 - .../bindings/arm/tegra/nvidia,tegra20-pmc.txt |6 +- .../devicetree/bindings/ata/tegra-sata.txt |4 +++- .../bindings/fuse/nvidia,tegra20-fuse.txt | 10 +- .../bindings/gpu/nvidia,tegra20-host1x.txt |8 ++-- .../devicetree/bindings/i2c/nvidia,tegra20-i2c.txt | 10 +- .../bindings/misc/nvidia,tegra20-apbmisc.txt |9 - .../bindings/mmc/nvidia,tegra20-sdhci.txt |6 +- .../bindings/pci/nvidia,tegra20-pcie.txt |8 .../bindings/pinctrl/nvidia,tegra124-pinmux.txt|3 ++- .../pinctrl/nvidia,tegra124-xusb-padctl.txt|4 +++- .../devicetree/bindings/pwm/nvidia,tegra20-pwm.txt |7 --- .../devicetree/bindings/rtc/nvidia,tegra20-rtc.txt |4 +++- .../devicetree/bindings/serial/of-serial.txt |5 - .../bindings/sound/nvidia,tegra30-ahub.txt |5 - .../bindings/sound/nvidia,tegra30-hda.txt |4 +++- .../bindings/sound/nvidia,tegra30-i2s.txt |5 - .../bindings/spi/nvidia,tegra114-spi.txt |4 +++- .../devicetree/bindings/thermal/tegra-soctherm.txt |4 +++- .../bindings/timer/nvidia,tegra30-timer.txt|4 +++- .../bindings/usb/nvidia,tegra20-ehci.txt |5 - .../bindings/usb/nvidia,tegra20-usb-phy.txt|5 - 22 files changed, 85 insertions(+), 40 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt index 234406d41c12..067c9790062f 100644 --- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt +++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-ahb.txt @@ -1,7 +1,10 @@ NVIDIA Tegra AHB Required properties: -- compatible : nvidia,tegra20-ahb or nvidia,tegra30-ahb +- compatible : For Tegra20, must contain nvidia,tegra20-ahb. For + Tegra30, must contain nvidia,tegra30-ahb. Otherwise, must contain + 'nvidia,chip-ahb, nvidia,tegra30-ahb' where chip is tegra124, + tegra132, or tegra210. - reg : Should contain 1 register ranges(address and length) Example: diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
Re: [PATCH] ARM: dst: OMAP3-N900: Add microphone bias voltages
On Fri 2015-01-30 21:23:20, Jarkko Nikula wrote: From: Pavel Machek pa...@ucw.cz N900 audio recording needs that codec provides bias voltage for integrated digital microphone and headset microphone depending which one is used. Digital microphone uses 2 V bias and it comes from the codec A part. Codec B part drives the headset microphone bias and that is set to 2.5 V. Signed-off-by: Pavel Machek pa...@ucw.cz [Jarkko: Headset mic bias changed to 2 (2.5 V) as it was before commit e2e8bfdf6157 (ASoC: tlv320aic3x: Convert mic bias to a supply widget)] Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com --- Pavel: I hope you don't mind I took your diff from http://marc.info/?l=linux-kernelm=142249383224678w=2 and added your Signed-off-by? No problem, my patches are GPLed. Thanks! Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe devicetree 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 1/2] clk: qcom: gcc-msm8960: add child devices support.
On Fri, Jan 30, 2015 at 1:16 PM, Stephen Boyd sb...@codeaurora.org wrote: On 01/30/15 10:06, Srinivas Kandagatla wrote: [..] Stephen Any comments? I don't understand any of this. We should be making a specific tsens device directly in the gcc driver probe and not doing any sort of of_platform_populate(). This is what I had, but it probably could be done better so that we can assign the struct device's of_node pointer before registering on the platform bus. platform_device_register_data(pdev-dev, tsens8960-tm, -1, pdev-dev.of_node, sizeof(pdev-dev.of_node)); Then if we need to add any properties like #sensor-cells or coefficients the tsens driver can use the same of_node that gcc is using. That makes sense and the dt will describe the hardware nicely, but how do you get access to the register space from the tsens driver? Will dev_get_regmap(pdev-dev.parent, NULL); find the mmio regmap of gcc perhaps? Regards, Bjorn -- To unsubscribe from this list: send the line unsubscribe devicetree 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 1/6] soc: qcom: gsbi: Add support for ADM CRCI muxing
On Jan 30, 2015, at 3:37 PM, Stephen Boyd sb...@codeaurora.org wrote:
On 01/30/15 08:32, Kumar Gala wrote:
On Jan 30, 2015, at 12:25 AM, Andy Gross agr...@codeaurora.org wrote:
Required properties if child node exists:
- #address-cells: Must be 1
- #size-cells: Must be 1
- ranges: Must be present
+Note: Each GSBI should have an alias correctly numbered in aliases node.
+
Properties for children:
A GSBI controller node can contain 0 or more child nodes representing serial
@@ -37,6 +41,10 @@ Example for APQ8064:
#include dt-bindings/soc/qcom,gsbi.h
+ aliases {
+ gsbi4 = gsbi4;
+ };
You appear to be using the alias name to determine a index number for the
gsbi, if that is the case, than you should probably just add a cell-index
node to the gsbi’s for this purpose.
I thought cell-index was deprecated and referred more to things like
enumerating all the devices on a bus by assigning them a unique ID.
Aliases, on the other hand, allow us to enumerate a subset of devices
that share the same bus with other devices of different types. For
example, how would I know that a device is gsbi1 vs serial1 if they both
used cell-index and they both had the same parent node?
I think the problem was cell-index was never well understood and abused. For
the example you are giving you wouldn’t use cell-index because you are talking
about things that would have different compatibles. For what it appears we
really are enumerating the GSBI hardware to match some programming interface
convention. If that is the case than I think cell-index is proper.
- k
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: shmobile: alt dts: Drop console= bootargs parameter
Hello.
On 11/04/2014 07:23 AM, Simon Horman wrote:
Alt is booted from DT, so chosen/stdout-path is
always used, and we can drop the console= parameter from chosen/bootargs.
This change has a side-effect of changing the console speed from 38400
to 115200. This is intentional as 115200 is consistently used on
all other shmobile boards.
I'd say it's not very practical to change the console's baud rate from
U-Boot's default (AFAIR changing baud rate in U-Boot didn't work)...
Cc: Ulrich Hecht ulrich.hecht+rene...@gmail.com
Cc: Geert Uytterhoeven geert+rene...@glider.be
Cc: devicetree@vger.kernel.org
Signed-off-by: Simon Horman horms+rene...@verge.net.au
---
arch/arm/boot/dts/r8a7794-alt.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7794-alt.dts
b/arch/arm/boot/dts/r8a7794-alt.dts
index 8aec512..f2cf757 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -20,7 +20,7 @@
};
chosen {
- bootargs = console=ttySC0,38400 ignore_loglevel rw root=/dev/nfs
ip=dhcp;
+ bootargs = ignore_loglevel rw root=/dev/nfs ip=dhcp;
Hm, does this even work as intended? I've tried to boot another R8A7794
based board and I couldn't get any output with alike command line. Booting
with 'earlyprintk=serial' has shown that tty0 was enabled as a console which
is not what we wanted.
WBR, Sergei
--
To unsubscribe from this list: send the line unsubscribe devicetree 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/4] gpio: add parameter to allow the use named gpios
On Fri, Jan 30, 2015 at 11:12:53AM -0800, Bryan Wu wrote: On Fri, Jan 30, 2015 at 5:46 AM, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Jan 21, 2015 at 10:33 PM, Olliver Schinagl o.schin...@ultimaker.com wrote: From: Olliver Schinagl oli...@schinagl.nl The gpio binding document says that new code should always use named gpios. Patch 40b73183 added support to parse a list of gpios from child nodes, but does not make it possible to use named gpios. This patch adds the con_id property and implements it is done in gpiolib.c, where the old-style of using unnamed gpios still works. Signed-off-by: Olliver Schinagl oli...@schinagl.nl --- drivers/gpio/devres.c | 18 +- drivers/input/keyboard/gpio_keys_polled.c | 2 +- drivers/leds/leds-gpio.c | 2 +- include/linux/gpio/consumer.h | 1 + Alexandre: does this match your vision of how it should work, i.e. ACK? Bryan/Dmitry: can you ACK the oneliners in your subsystems? Sure, please take my Ack Acked-by: Bryan Wu coolo...@gmail.com Mine as well: Acked-by: Dmitry Torokhov dmitry.torok...@gmail.com Thanks. -- Dmitry -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: shmobile: silk: initial device tree
Add the initial device tree for the R8A7794 SoC based SILK low cost board.
SCIF2 serial port support is included, so that the serial console can work.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
This patch is against the 'renesas-devel-20150129-v3.19-rc6' tag of Simon
Horman's 'renesas.git' repo.
arch/arm/boot/dts/Makefile |1
arch/arm/boot/dts/r8a7794-silk.dts | 41 +
2 files changed, 42 insertions(+)
Index: renesas/arch/arm/boot/dts/Makefile
===
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -421,6 +421,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += eme
r8a7791-koelsch.dtb \
r8a7791-porter.dtb \
r8a7794-alt.dtb \
+ r8a7794-silk.dtb \
sh73a0-kzm9g.dtb
dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_arria5_socdk.dtb \
socfpga_arria10_socdk.dtb \
Index: renesas/arch/arm/boot/dts/r8a7794-silk.dts
===
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7794-silk.dts
@@ -0,0 +1,41 @@
+/*
+ * Device Tree Source for the SILK board
+ *
+ * Copyright (C) 2014 Renesas Electronics Corporation
+ * Copyright (C) 2014-2015 Renesas Solutions Corp.
+ * Copyright (C) 2014-2015 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include r8a7794.dtsi
+
+/ {
+ model = SILK;
+ compatible = renesas,silk, renesas,r8a7794;
+
+ aliases {
+ serial0 = scif2;
+ };
+
+ chosen {
+ bootargs = console=ttySC0,38400 ignore_loglevel;
+ stdout-path = scif2;
+ };
+
+ memory@4000 {
+ device_type = memory;
+ reg = 0 0x4000 0 0x4000;
+ };
+};
+
+extal_clk {
+ clock-frequency = 2000;
+};
+
+scif2 {
+ status = okay;
+};
--
To unsubscribe from this list: send the line unsubscribe devicetree 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 1/2] clk: qcom: gcc-msm8960: add child devices support.
On 01/30/15 10:06, Srinivas Kandagatla wrote: On 30/01/15 16:57, Bjorn Andersson wrote: On Fri, Jan 30, 2015 at 2:17 AM, Srinivas Kandagatla srinivas.kandaga...@linaro.org wrote: This patch adds support to add child devices to gcc as some of the registers mapped by gcc are used by drivers like thermal sensors. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org --- drivers/clk/qcom/gcc-msm8960.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/clk/qcom/gcc-msm8960.c b/drivers/clk/qcom/gcc-msm8960.c index 0cd3e26..3ba77c5 100644 --- a/drivers/clk/qcom/gcc-msm8960.c +++ b/drivers/clk/qcom/gcc-msm8960.c @@ -15,6 +15,7 @@ #include linux/bitops.h #include linux/err.h #include linux/platform_device.h +#include linux/of_platform.h #include linux/module.h #include linux/of.h #include linux/of_device.h @@ -3658,6 +3659,7 @@ static int gcc_msm8960_probe(struct platform_device *pdev) struct clk *clk; struct device *dev = pdev-dev; const struct of_device_id *match; + int ret; match = of_match_device(gcc_msm8960_match_table, pdev-dev); if (!match) @@ -3677,12 +3679,18 @@ static int gcc_msm8960_probe(struct platform_device *pdev) if (IS_ERR(clk)) return PTR_ERR(clk); - return qcom_cc_probe(pdev, match-data); + ret = qcom_cc_probe(pdev, match-data); + if (ret) + return ret; + + return of_platform_populate(pdev-dev.of_node, NULL, NULL, pdev-dev); How about calling of_syscon_register() instead? That would give us a handle to a regmap that can be consumed in e.g. the thermal driver. Two things: - Are you sure, this looks like of_syscon_register() is a static function - gcc node would be required to add syscon compatible Unless am missing some patches, Am not sure if going via syscon is right thing here? Stephen Any comments? I don't understand any of this. We should be making a specific tsens device directly in the gcc driver probe and not doing any sort of of_platform_populate(). This is what I had, but it probably could be done better so that we can assign the struct device's of_node pointer before registering on the platform bus. platform_device_register_data(pdev-dev, tsens8960-tm, -1, pdev-dev.of_node, sizeof(pdev-dev.of_node)); Then if we need to add any properties like #sensor-cells or coefficients the tsens driver can use the same of_node that gcc is using. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line unsubscribe devicetree 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] MAINTAINERS: Add entry for Maxim PMICs on Samsung boards
Quoting Krzysztof Kozlowski (2015-01-30 02:10:35) Add myself and Chanwoo Choi as supporters to help in reviewing patches for Maxim 77686 PMIC and Maxim 14577/77693 MUIC drivers: - mfd (all of them), - extcon (extcon-max14577.c, extcon-max77693.c), - regulator (all of them), - clock (clk-max77686.c), - RTC (rtc-max77686.c). Lately I am the author of contributors to them. These drivers are used on Exynos-based boards (Trats 2, Gear 1 and Gear 2). Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: MyungJoo Ham myungjoo@samsung.com cc: Chanwoo Choi cw00.c...@samsung.com Cc: Samuel Ortiz sa...@linux.intel.com Cc: Lee Jones lee.jo...@linaro.org Cc: Liam Girdwood lgirdw...@gmail.com Cc: Mark Brown broo...@kernel.org Cc: Mike Turquette mturque...@linaro.org Acked-by: Michael Turquette mturque...@linaro.org Cc: Stephen Boyd sb...@codeaurora.org Cc: Alessandro Zummo a.zu...@towertech.it Acked-by: Mark Brown broo...@kernel.org Acked-by: Lee Jones lee.jo...@linaro.org --- Changes since v1: 1. Add also Chanwoo Choi as supporter on his request [1]. 2. Move out chargers (power supply) to separate patch (applied already by Sebastian Reichel [2]). Patch is rebased on next which includes this. 3. Add acks from Mark Brown and Lee Jones. [1] https://lkml.org/lkml/2015/1/16/571 [2] http://git.infradead.org/battery-2.6.git/commit/f8f847b51a0e1cb0c96e706d5da0ac507d96c605 --- MAINTAINERS | 20 1 file changed, 20 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5d7404add7ed..775a631118ef 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6191,6 +6191,26 @@ S: Supported F: drivers/power/max14577_charger.c F: drivers/power/max77693_charger.c +MAXIM PMIC AND MUIC DRIVERS FOR EXYNOS BASED BOARDS +M: Chanwoo Choi cw00.c...@samsung.com +M: Krzysztof Kozlowski k.kozlow...@samsung.com +L: linux-ker...@vger.kernel.org +S: Supported +F: drivers/*/max14577.c +F: drivers/*/max77686.c +F: drivers/*/max77693.c +F: drivers/extcon/extcon-max14577.c +F: drivers/extcon/extcon-max77693.c +F: drivers/rtc/rtc-max77686.c +F: drivers/clk/clk-max77686.c +F: Documentation/devicetree/bindings/mfd/max14577.txt +F: Documentation/devicetree/bindings/mfd/max77686.txt +F: Documentation/devicetree/bindings/mfd/max77693.txt +F: Documentation/devicetree/bindings/clock/maxim,max77686.txt +F: include/linux/mfd/max14577*.h +F: include/linux/mfd/max77686*.h +F: include/linux/mfd/max77693*.h + MAXIRADIO FM RADIO RECEIVER DRIVER M: Hans Verkuil hverk...@xs4all.nl L: linux-me...@vger.kernel.org -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree 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 1/6] soc: qcom: gsbi: Add support for ADM CRCI muxing
On 01/30/15 08:32, Kumar Gala wrote:
On Jan 30, 2015, at 12:25 AM, Andy Gross agr...@codeaurora.org wrote:
Required properties if child node exists:
- #address-cells: Must be 1
- #size-cells: Must be 1
- ranges: Must be present
+Note: Each GSBI should have an alias correctly numbered in aliases node.
+
Properties for children:
A GSBI controller node can contain 0 or more child nodes representing serial
@@ -37,6 +41,10 @@ Example for APQ8064:
#include dt-bindings/soc/qcom,gsbi.h
+aliases {
+gsbi4 = gsbi4;
+};
You appear to be using the alias name to determine a index number for the
gsbi, if that is the case, than you should probably just add a cell-index
node to the gsbi’s for this purpose.
I thought cell-index was deprecated and referred more to things like
enumerating all the devices on a bus by assigning them a unique ID.
Aliases, on the other hand, allow us to enumerate a subset of devices
that share the same bus with other devices of different types. For
example, how would I know that a device is gsbi1 vs serial1 if they both
used cell-index and they both had the same parent node?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] Documentation: DT: document compatible string existence requirement
DT maintainers require all compatible strings used in chip or board DTS file to be previously documented somewhere in Documentation/devicetree/bindings, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Document this requirement in the DT patch submission requirements text file. This second version updates the documentation to align with Rob's comments here: http://marc.info/?l=devicetreem=142255654213019w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk Cc: Jonathan Corbet cor...@lwn.net Cc: Paul Walmsley pwalms...@nvidia.com Cc: linux-ker...@vger.kernel.org --- .../devicetree/bindings/submitting-patches.txt | 23 1 file changed, 23 insertions(+) diff --git a/Documentation/devicetree/bindings/submitting-patches.txt b/Documentation/devicetree/bindings/submitting-patches.txt index b7ba01ad1426..56742bc70218 100644 --- a/Documentation/devicetree/bindings/submitting-patches.txt +++ b/Documentation/devicetree/bindings/submitting-patches.txt @@ -15,6 +15,29 @@ I. For patch submitters 3) The Documentation/ portion of the patch should come in the series before the code implementing the binding. + 4) Any compatible strings used in a chip or board DTS file must be + previously documented in the corresponding DT binding text file + in Documentation/devicetree/bindings. This rule applies even if + the Linux device driver does not yet match on the compatible + string. [ checkpatch will emit warnings if this step is not + followed as of commit bff5da4335256513497cc8c79f9a9d1665e09864 + (checkpatch: add DT compatible string documentation checks). ] + + 5) The wildcard chip may be used in compatible strings, as in + the following example: + + - compatible: Must contain 'nvidia,chip-pcie, + nvidia,tegra20-pcie' where chip is tegra30, tegra132, ... + + As in the above example, the known values of chip should be + documented if it is used. + + 6) If a documented compatible string is not yet matched by the + driver, the documentation should also include a compatible + string that is matched by the driver (as in the nvidia,tegra20-pcie + example above). + + II. For kernel maintainers 1) If you aren't comfortable reviewing a given binding, reply to it and ask -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/3] Documentation: DT bindings: update DT binding docs with Tegra chips
Update some of the DT binding documentation text files, per Mark's comments at: http://marc.info/?l=linux-tegram=142201349727836w=2 The primary goal with this series is to avoid checkpatch.pl warnings and align to the policy that Mark described. This series also updates Documentation/devicetree/bindings/submitting-patches.txt to formally document this policy. These patches apply on next-20150123. This second version incorporates some revisions based on feedback from Rob Herring. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 6/8] input: touchscreen: imx25 tcq driver
On Thu, Jan 29, 2015 at 07:56:40PM +0530, Varka Bhadram wrote:
Hi,
On Thursday 29 January 2015 07:39 PM, Markus Pargmann wrote:
This is a driver for the imx25 ADC/TSC module. It controls the
touchscreen conversion queue and creates a touchscreen input device.
The driver currently only supports 4 wire touchscreens. The driver uses
a simple conversion queue of precharge, touch detection, X measurement,
Y measurement, precharge and another touch detection.
This driver uses the regmap from the parent to setup some touch specific
settings in the core driver and setup a idle configuration with touch
detection.
Signed-off-by: Markus Pargmann m...@pengutronix.de
Signed-off-by: Denis Carikli de...@eukrea.com
Acked-by: Dmitry Torokhov d...@vmware.com
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/input/touchscreen/Kconfig | 6 +
drivers/input/touchscreen/Makefile| 1 +
drivers/input/touchscreen/fsl-imx25-tcq.c | 587
++
3 files changed, 594 insertions(+)
create mode 100644 drivers/input/touchscreen/fsl-imx25-tcq.c
(...)
+ret = request_threaded_irq(priv-irq, mx25_tcq_irq, mx25_tcq_irq_thread,
+ IRQF_ONESHOT, pdev-name, priv);
We can use devres API for request_thread_irq()...
+if (ret) {
+dev_err(dev, Failed requesting IRQ\n);
+goto err_clk_unprepare;
+}
+
+ret = mx25_tcq_init(priv);
+if (ret) {
+dev_err(dev, Failed to init tcq\n);
+goto error_free_irq;
+}
+
+platform_set_drvdata(pdev, priv);
+
+return 0;
+
+error_free_irq:
+free_irq(priv-irq, priv);
This is not required if we use devres API
Yes it does - you do not really want to stop clocks in the middle of
servicing interrupt.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 24/24] Documentation: DT bindings: add nvidia, denver compatible string
Hi Rob On Thu, 29 Jan 2015, Rob Herring wrote: On Wed, Jan 28, 2015 at 5:49 PM, Paul Walmsley p...@pwsan.com wrote: Add a compatible string for the NVIDIA Denver CPU to the ARM CPU DT binding documentation file. The primary objective here is to keep checkpatch.pl from warning when the compatible string is used in an SoC DT file, per: http://marc.info/?l=linux-tegram=142201349727836w=2 Signed-off-by: Paul Walmsley p...@pwsan.com Cc: Rob Herring robh...@kernel.org Cc: Pawel Moll pawel.m...@arm.com Cc: Mark Rutland mark.rutl...@arm.com Cc: Ian Campbell ijc+devicet...@hellion.org.uk Cc: Kumar Gala ga...@codeaurora.org Cc: Heiko Stuebner he...@sntech.de Cc: Arnd Bergmann a...@arndb.de Cc: Catalin Marinas catalin.mari...@arm.com Cc: Olof Johansson o...@lixom.net Cc: Maxime Ripard maxime.rip...@free-electrons.com Cc: Rohit Vaswani rvasw...@codeaurora.org Cc: Paul Walmsley pwalms...@nvidia.com Cc: Marc Carino marc.cee...@gmail.com Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com Cc: devicetree@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org --- Documentation/devicetree/bindings/arm/cpus.txt |1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt index b2aacbe16ed9..4ea31f0b7764 100644 --- a/Documentation/devicetree/bindings/arm/cpus.txt +++ b/Documentation/devicetree/bindings/arm/cpus.txt @@ -175,6 +175,7 @@ nodes to be present and contain the properties described below. marvell,pj4a marvell,pj4b marvell,sheeva-v5 + nvidia,denver (not yet matched in the code) There's not variations or versions of Denver cores or plans to change from the codename? Hard to say what the future will bring. I'll change it to nvidia,tegra132-denver. - Paul -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: dst: OMAP3-N900: Add microphone bias voltages
From: Pavel Machek pa...@ucw.cz
N900 audio recording needs that codec provides bias voltage for integrated
digital microphone and headset microphone depending which one is used.
Digital microphone uses 2 V bias and it comes from the codec A part. Codec
B part drives the headset microphone bias and that is set to 2.5 V.
Signed-off-by: Pavel Machek pa...@ucw.cz
[Jarkko: Headset mic bias changed to 2 (2.5 V) as it was before commit
e2e8bfdf6157 (ASoC: tlv320aic3x: Convert mic bias to a supply widget)]
Signed-off-by: Jarkko Nikula jarkko.nik...@bitmer.com
---
Pavel: I hope you don't mind I took your diff from
http://marc.info/?l=linux-kernelm=142249383224678w=2
and added your Signed-off-by?
---
arch/arm/boot/dts/omap3-n900.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index b550c41b46f1..f7858f5974e3 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -478,6 +478,8 @@
DRVDD-supply = vmmc2;
IOVDD-supply = vio;
DVDD-supply = vio;
+
+ ai3x-micbias-vg = 1;
};
tlv320aic3x_aux: tlv320aic3x@19 {
@@ -489,6 +491,8 @@
DRVDD-supply = vmmc2;
IOVDD-supply = vio;
DVDD-supply = vio;
+
+ ai3x-micbias-vg = 2;
};
tsl2563: tsl2563@29 {
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe devicetree 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 1/2] clk: qcom: gcc-msm8960: add child devices support.
On 30/01/15 16:57, Bjorn Andersson wrote: On Fri, Jan 30, 2015 at 2:17 AM, Srinivas Kandagatla srinivas.kandaga...@linaro.org wrote: This patch adds support to add child devices to gcc as some of the registers mapped by gcc are used by drivers like thermal sensors. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org --- drivers/clk/qcom/gcc-msm8960.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/clk/qcom/gcc-msm8960.c b/drivers/clk/qcom/gcc-msm8960.c index 0cd3e26..3ba77c5 100644 --- a/drivers/clk/qcom/gcc-msm8960.c +++ b/drivers/clk/qcom/gcc-msm8960.c @@ -15,6 +15,7 @@ #include linux/bitops.h #include linux/err.h #include linux/platform_device.h +#include linux/of_platform.h #include linux/module.h #include linux/of.h #include linux/of_device.h @@ -3658,6 +3659,7 @@ static int gcc_msm8960_probe(struct platform_device *pdev) struct clk *clk; struct device *dev = pdev-dev; const struct of_device_id *match; + int ret; match = of_match_device(gcc_msm8960_match_table, pdev-dev); if (!match) @@ -3677,12 +3679,18 @@ static int gcc_msm8960_probe(struct platform_device *pdev) if (IS_ERR(clk)) return PTR_ERR(clk); - return qcom_cc_probe(pdev, match-data); + ret = qcom_cc_probe(pdev, match-data); + if (ret) + return ret; + + return of_platform_populate(pdev-dev.of_node, NULL, NULL, pdev-dev); How about calling of_syscon_register() instead? That would give us a handle to a regmap that can be consumed in e.g. the thermal driver. Two things: - Are you sure, this looks like of_syscon_register() is a static function - gcc node would be required to add syscon compatible Unless am missing some patches, Am not sure if going via syscon is right thing here? Stephen Any comments? --srini I think this use case is exactly why that was introduced. Regards, Bjorn -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/6] of: fix size when dma-range is not used
On 01/28/2015 12:30 PM, Catalin Marinas wrote:
On Wed, Jan 28, 2015 at 03:55:57PM +, Robin Murphy wrote:
On 28/01/15 11:05, Catalin Marinas wrote:
On Tue, Jan 27, 2015 at 06:55:15PM +, Murali Karicheri wrote:
How about having the logic like this?
ret = of_dma_get_range(np,dma_addr,paddr,size);
if (ret 0) {
dma_addr = offset = 0;
size = dev-coherent_dma_mask + 1;
} else {
offset = PFN_DOWN(paddr - dma_addr);
dev_dbg(dev, dma_pfn_offset(%#08lx)\n, offset);
}
if (is_power_of_2(size + 1))
size = size + 1;
else if (!is_power_of_2(size))
{
dev_err(dev, invalid size\n);
return;
}
In of_dma_configure(), we currently assume that the default coherent
mask is 32-bit. In this thread:
http://article.gmane.org/gmane.linux.kernel/1835096
we talked about setting the coherent mask based on size automatically.
I'm not sure about the size but I think we can assume is 32-bit mask + 1
if it is not specified in the DT. Instead of just assuming a default
mask, let's assume a default size and create the mask based on this
(untested):
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 5b33c6a21807..9ff8d1286b44 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -170,10 +170,10 @@ static void of_dma_configure(struct device *dev)
struct iommu_ops *iommu;
/*
-* Set default dma-mask to 32 bit. Drivers are expected to setup
-* the correct supported dma_mask.
+* Set default size to cover the 32-bit. Drivers are expected to setup
+* the correct size and dma_mask.
*/
- dev-coherent_dma_mask = DMA_BIT_MASK(32);
+ size = 1ULL 32;
/*
* Set it to coherent_dma_mask by default if the architecture
@@ -185,13 +185,24 @@ static void of_dma_configure(struct device *dev)
ret = of_dma_get_range(dev-of_node,dma_addr,paddr,size);
if (ret 0) {
dma_addr = offset = 0;
- size = dev-coherent_dma_mask;
} else {
offset = PFN_DOWN(paddr - dma_addr);
dev_dbg(dev, dma_pfn_offset(%#08lx)\n, dev-dma_pfn_offset);
}
dev-dma_pfn_offset = offset;
+ /*
+* Workaround for DTs setting the size to a mask or 0.
+*/
+ if (is_power_of_2(size + 1))
+ size += 1;
In fact, since the ilog2 below ends up effectively rounding down, we
might as well do away with this check as well and just add 1
unconditionally. The only time it makes any difference is when we want
it to anyway!
Well, we could simply ignore the is_power_of_2() check but without
incrementing size as we don't know what arch_setup_dma_ops() does with
it.
I think we can remove this check altogether (we leaved without it for a
while) but we need to add 1 when calculating the mask:
dev-coherent_dma_mask = min(DMA_BIT_MASK(32),
DMA_BIT_MASK(ilog2(size + 1)));
For Keystone, the dma_addr is to be taken care as well to determine the
mask. The above will not work.
Based on the discussion so far, this is the function I have come up with
incorporating the suggestions. Please review this and see if I have
missed out any. This works fine on Keystone.
void of_dma_configure(struct device *dev, struct device_node *np)
{
u64 dma_addr = 0, paddr, size;
int ret;
bool coherent;
unsigned long offset = 0;
struct iommu_ops *iommu;
/*
* Set default size to cover the 32-bit. Drivers are expected to setup
* the correct size and dma_mask.
*/
size = 1ULL 32;
ret = of_dma_get_range(np, dma_addr, paddr, size);
if (!ret) {
offset = PFN_DOWN(paddr - dma_addr);
if (!size) {
dev_err(dev, Invalid size (%llx)\n,
size);
return;
}
if (size 1) {
size = size + 1;
dev_warn(dev, Incorrect usage of size (%llx)\n,
size);
}
dev_dbg(dev, dma_pfn_offset(%#08lx)\n, offset);
}
dev-dma_pfn_offset = offset;
/*
* Coherent DMA masks larger than 32-bit must be explicitly set by the
* driver.
*/
dev-coherent_dma_mask = min(DMA_BIT_MASK(32),
DMA_BIT_MASK(ilog2(dma_addr + size)));
/*
* Set dma_mask to coherent_dma_mask by default if the architecture
* code has not set it.
*/
if (!dev-dma_mask)
dev-dma_mask = dev-coherent_dma_mask;
coherent = of_dma_is_coherent(np);
dev_dbg(dev, device is%sdma coherent\n,
coherent ? : not
Re: [PATCH v2 2/4] gpio: add parameter to allow the use named gpios
On Fri, Jan 30, 2015 at 5:46 AM, Linus Walleij linus.wall...@linaro.org wrote: On Wed, Jan 21, 2015 at 10:33 PM, Olliver Schinagl o.schin...@ultimaker.com wrote: From: Olliver Schinagl oli...@schinagl.nl The gpio binding document says that new code should always use named gpios. Patch 40b73183 added support to parse a list of gpios from child nodes, but does not make it possible to use named gpios. This patch adds the con_id property and implements it is done in gpiolib.c, where the old-style of using unnamed gpios still works. Signed-off-by: Olliver Schinagl oli...@schinagl.nl --- drivers/gpio/devres.c | 18 +- drivers/input/keyboard/gpio_keys_polled.c | 2 +- drivers/leds/leds-gpio.c | 2 +- include/linux/gpio/consumer.h | 1 + Alexandre: does this match your vision of how it should work, i.e. ACK? Bryan/Dmitry: can you ACK the oneliners in your subsystems? Sure, please take my Ack Acked-by: Bryan Wu coolo...@gmail.com Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock
On Fri, Jan 16, 2015 at 4:46 PM, Ohad Ben-Cohen o...@wizery.com wrote: Mark, On Fri, Jan 16, 2015 at 12:17 PM, Mark Rutland mark.rutl...@arm.com wrote: The hwlock is a basic hardware primitive that allow synchronization between different processors in the system, which may be running Linux as well as other operating systems, and may have no other means of communication. The hwlock id numbers are predefined, global and static across the entire system: Linux may boot well after other operating systems are already running and using these hwlocks to communicate, and therefore, in order to use these hardware devices, it must not enumerate them differently than the rest of the system. That's not true. In order to communicate it must agree with the other users as to the meaning of each instance, and the protocol for use. That doesn't necessarily mean that Linux needs to know the numerical ID from a datasheet, and regardless that ID is separate from the logical ID Linux uses internally. Let me describe hwspinlocks a bit more so we all get to know it better and can then agree on a proper solution. - What makes handling of hwspinlock ID numbers convenient is the fact that it's not based on random datasheet numbers. In fact, hwspinlocks is just special memory: usually datasheets just define the base address and the size of the hwspinlock area. So any numerical ID we use to call the locks themselves are already logical and sane, similar to the way we handle memory (i.e. if we have 32 locks we'll always use 0..31). So hwlocks ids are very much like memory addressing, and not irq numbers. But that's exactly how irqs or gpios work as well. If you have 32 gpios in a system they used to be numbered 0-31 and people would reference them directly by that number. Every one of the systems that was designed in this way is moving away from it. - Sometimes Linux will have to dynamically allocate a hwlock, and send the ID of the allocated lock to a remote processor (which may not be running Linux). In a system where you have two hwlock blocks lckA and lckB, each consisting of 8 locks and you have dspB that can only access lckB; will you tell the firmware engineers to always subtract 8 from the numbers you pass them? Wouldn't it make much more sense to have local indexes here and pass them e.g lckB:2? - Sometimes a remote processor, which may not be running Linux, will have to dynamically allocate a hwlock, and send the ID of the allocated lock to us (another processor running Linux) I'm sorry but you cannot have a system on both sides that is allowed to do dynamic allocation from a limited set of resources. Further more this dynamic allocation leads to interesting race conditions as what happens if you dynamically allocate a hwlock that is statically allocated by another part of the system? The only solution I can think of is to have a static allocation of ids that the dynamic allocator might use, and then we're just carrying extra code when the system is already statically configured... We cannot tell in advance what kind of IPC is going to be used for sending and receiving this hwlock ID. Some are handled by Linux (kernel) and some by the user space. So we must be able to expose an ID the system will understand as well as receive one. Designing this interface to take into consideration that someone might send us something completely crazy isn't productive. The only reason for having num-locks and base-id in device tree is because of the current Linux implementation. base-id is not a property of the hardware and num-locks is not needed for anything but book keeping of base-id's in the hwlock framework. This is why I preferred Sumans earlier suggestion of having the binding consist of #hwlock-cells = X and the necessary accessor functions for resolving a hwlock based on a dt reference. Regards, Bjorn -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: shmobile: alt dts: Drop console= bootargs parameter
Hi Sergei,
On Sat, Jan 31, 2015 at 12:49:23AM +0300, Sergei Shtylyov wrote:
Hello.
On 11/04/2014 07:23 AM, Simon Horman wrote:
Alt is booted from DT, so chosen/stdout-path is
always used, and we can drop the console= parameter from chosen/bootargs.
This change has a side-effect of changing the console speed from 38400
to 115200. This is intentional as 115200 is consistently used on
all other shmobile boards.
I'd say it's not very practical to change the console's baud rate from
U-Boot's default
It is consistent with the handling of all other boards with
renesas SoCs that are present in mainline.
(AFAIR changing baud rate in U-Boot didn't work)...
Perhaps that relates to the version of built of uboot.
On the board I have access to I see:
ver=U-Boot 2013.01.01-g5df9446 (Oct 01 2014 - 14:59:23)
And the following setting altered the baud rate of u-boot (IIRC).
baudrate=115200
Cc: Ulrich Hecht ulrich.hecht+rene...@gmail.com
Cc: Geert Uytterhoeven geert+rene...@glider.be
Cc: devicetree@vger.kernel.org
Signed-off-by: Simon Horman horms+rene...@verge.net.au
---
arch/arm/boot/dts/r8a7794-alt.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7794-alt.dts
b/arch/arm/boot/dts/r8a7794-alt.dts
index 8aec512..f2cf757 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -20,7 +20,7 @@
};
chosen {
-bootargs = console=ttySC0,38400 ignore_loglevel rw
root=/dev/nfs ip=dhcp;
+bootargs = ignore_loglevel rw root=/dev/nfs ip=dhcp;
Hm, does this even work as intended? I've tried to boot another R8A7794
based board and I couldn't get any output with alike command line. Booting
with 'earlyprintk=serial' has shown that tty0 was enabled as a console which
is not what we wanted.
If you are backporting this change then I believe it has some dependencies
that I can follow up on if it is useful to you.
If you are using mainline (e.g. next or renesas-next) then yes,
it works. I have tested it numerous times since the patch was merged.
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/4] Documentation: dt: add common bindings for hwspinlock
On Sat, Jan 31, 2015 at 1:29 AM, Bjorn Andersson bj...@kryo.se wrote: In a system where you have two hwlock blocks lckA and lckB, each consisting of 8 locks and you have dspB that can only access lckB This is a good example - thanks. To be able to cope with such cases we will have to pass a hwlock block reference and its relative lock id. The DT binding should definitely be prepared for such cases (just kill the base-id field?), but let's see what it means about the Linux implementation. Since the existence of several hwblocks is still fictional (Bjorn, please confirm too?), we may prefer to introduce changes to support it only when it shows up; it all depends on the amount of changes needed. Suman, care to take a look please? - Sometimes a remote processor, which may not be running Linux, will have to dynamically allocate a hwlock, and send the ID of the allocated lock to us (another processor running Linux) I'm sorry but you cannot have a system on both sides that is allowed to do dynamic allocation from a limited set of resources. Of course not. On such systems, Linux is not the one responsible for allocating the hwlocks, at least not during part of the time or from part of the hwlocks. There were a few different use cases, with different semantics, that required communicating to Linux an hwlock id, but since none of them have reached mainline, we should only remember they may show up one day, but not put too much effort to support them right now. Thanks, Ohad. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: shmobile: silk: initial device tree
On Sat, Jan 31, 2015 at 01:52:16AM +0300, Sergei Shtylyov wrote:
Add the initial device tree for the R8A7794 SoC based SILK low cost board.
SCIF2 serial port support is included, so that the serial console can work.
Signed-off-by: Sergei Shtylyov sergei.shtyl...@cogentembedded.com
---
This patch is against the 'renesas-devel-20150129-v3.19-rc6' tag of Simon
Horman's 'renesas.git' repo.
arch/arm/boot/dts/Makefile |1
arch/arm/boot/dts/r8a7794-silk.dts | 41
+
2 files changed, 42 insertions(+)
Index: renesas/arch/arm/boot/dts/Makefile
===
--- renesas.orig/arch/arm/boot/dts/Makefile
+++ renesas/arch/arm/boot/dts/Makefile
@@ -421,6 +421,7 @@ dtb-$(CONFIG_ARCH_SHMOBILE_MULTI) += eme
r8a7791-koelsch.dtb \
r8a7791-porter.dtb \
r8a7794-alt.dtb \
+ r8a7794-silk.dtb \
sh73a0-kzm9g.dtb
dtb-$(CONFIG_ARCH_SOCFPGA) += socfpga_arria5_socdk.dtb \
socfpga_arria10_socdk.dtb \
Index: renesas/arch/arm/boot/dts/r8a7794-silk.dts
===
--- /dev/null
+++ renesas/arch/arm/boot/dts/r8a7794-silk.dts
@@ -0,0 +1,41 @@
+/*
+ * Device Tree Source for the SILK board
+ *
+ * Copyright (C) 2014 Renesas Electronics Corporation
+ * Copyright (C) 2014-2015 Renesas Solutions Corp.
+ * Copyright (C) 2014-2015 Cogent Embedded, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ */
+
+/dts-v1/;
+#include r8a7794.dtsi
+
+/ {
+ model = SILK;
+ compatible = renesas,silk, renesas,r8a7794;
+
+ aliases {
+ serial0 = scif2;
+ };
+
+ chosen {
+ bootargs = console=ttySC0,38400 ignore_loglevel;
Please remove console= for consistency with other boards
based on Renesas SoCs.
+ stdout-path = scif2;
+ };
+
+ memory@4000 {
+ device_type = memory;
+ reg = 0 0x4000 0 0x4000;
+ };
+};
+
+extal_clk {
+ clock-frequency = 2000;
+};
+
+scif2 {
+ status = okay;
+};
--
To unsubscribe from this list: send the line unsubscribe linux-sh in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
+Thomas (for irq/dummychip.c question)
Hi,
On 30/01/15 13:09, Roger Quadros wrote:
Chanwoo,
On 30/01/15 02:06, Chanwoo Choi wrote:
Hi Roger,
On 01/29/2015 08:26 PM, Roger Quadros wrote:
Chanwoo,
On 29/01/15 03:49, Chanwoo Choi wrote:
Hi Roger,
We need to discuss one point about 'id_irqwake'.
I don't recommend to use 'id_irqwake' field.
And I catch build warning by using select keywork in Kconfig.
It is my wrong guide of select keyword. So, I'll change it
as 'depends on' keyword.
Looks good to me except for 'id_irqwake'.
I'll apply this patch on 3.21 queue after completing this discussion.
On 01/28/2015 09:15 PM, Roger Quadros wrote:
This driver observes the USB ID pin connected over a GPIO and
updates the USB cable extcon states accordingly.
The existing GPIO extcon driver is not suitable for this purpose
as it needs to be taught to understand USB cable states and it
can't handle more than one cable per instance.
For the USB case we need to handle 2 cable states.
1) USB (attach/detach)
2) USB-Host (attach/detach)
This driver can be easily updated in the future to handle VBUS
events in case it happens to be available on GPIO for any platform.
Signed-off-by: Roger Quadros rog...@ti.com
---
v3:
- removed IRQF_NO_SUSPEND flag. Added IRQF_TRIGGER_RISING and
IRQF_TRIGGER_FALLING
- Added disable_irq() to suspend() and enable_irq() to resume()
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 18 ++
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-usb-gpio.c | 233
+
4 files changed, 259 insertions(+)
create mode 100644
Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
create mode 100644 drivers/extcon/extcon-usb-gpio.c
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
new file mode 100644
index 000..85fe6b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -0,0 +1,18 @@
+USB GPIO Extcon device
+
+This is a virtual device used to generate USB cable states from the USB
ID pin
+connected to a GPIO pin.
+
+Required properties:
+- compatible: Should be linux,extcon-usb-gpio
+- id-gpio: gpio for USB ID pin. See gpio binding.
+
+Example:
+ extcon_usb1 {
+ compatible = linux,extcon-usb-gpio;
+ id-gpio = gpio6 1 GPIO_ACTIVE_HIGH;
+ }
+
+ omap_dwc3_1 {
+ extcon = extcon_usb1;
+ };
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..fd11536 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -93,4 +93,11 @@ config EXTCON_SM5502
Silicon Mitus SM5502. The SM5502 is a USB port accessory
detector and switch.
+config EXTCON_USB_GPIO
+ tristate USB GPIO extcon support
+ select GPIOLIB
I catch the build warning if using 'select' instead of 'depends on' as
following:
It is my wrong guide to you. So, I'll modify it by using depends on as
your original patch.
OK. Thanks.
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- zImage -j 8
scripts/kconfig/conf --silentoldconfig Kconfig
drivers/gpio/Kconfig:34:error: recursive dependency detected!
drivers/gpio/Kconfig:34: symbol GPIOLIB is selected by EXTCON_USB_GPIO
drivers/extcon/Kconfig:96: symbol EXTCON_USB_GPIO depends on EXTCON
drivers/extcon/Kconfig:1: symbol EXTCON is selected by CHARGER_MANAGER
drivers/power/Kconfig:316: symbol CHARGER_MANAGER depends on POWER_SUPPLY
drivers/power/Kconfig:1: symbol POWER_SUPPLY is selected by HID_SONY
drivers/hid/Kconfig:670: symbol HID_SONY depends on NEW_LEDS
drivers/leds/Kconfig:8:symbol NEW_LEDS is selected by BCMA_DRIVER_GPIO
drivers/bcma/Kconfig:75: symbol BCMA_DRIVER_GPIO depends on GPIOLIB
+ help
+ Say Y here to enable GPIO based USB cable detection extcon support.
+ Used typically if GPIO is used for USB ID pin detection.
+
endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..6a08a98 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997)+= extcon-max8997.o
obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
obj-$(CONFIG_EXTCON_SM5502) += extcon-sm5502.o
+obj-$(CONFIG_EXTCON_USB_GPIO)+= extcon-usb-gpio.o
diff --git a/drivers/extcon/extcon-usb-gpio.c
b/drivers/extcon/extcon-usb-gpio.c
new file mode 100644
index 000..99a58b2
--- /dev/null
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -0,0 +1,233 @@
+/**
+ * drivers/extcon/extcon-usb-gpio.c - USB GPIO extcon driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros rog...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ *
Re: [PATCH v10 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support
On Fri, Jan 30, 2015 at 07:03:03AM -0500, Peter Hurley wrote: On 01/30/2015 05:18 AM, Thierry Reding wrote: -ENODEV is certainly not the correct return value if a resource is not available. It translates to no such device, but the device must clearly be there, otherwise the -probe() shouldn't have been called. -ENODEV is the appropriate return from the probe(); there is no device. No it is not. no such device means the device is not present. If the device is not present, we wouldn't have a struct device associated with it. The missing resource is an error condition: what it's saying is that the device is there, but something has failed in providing the IO regions necessary to access it. That's really something very different from there is no device present. Or if it really isn't there, then you'd at least need a memory region to probe, otherwise you can't determine whether it's there or not. So from the perspective of a device driver I think a missing, or NULL, resource, is indeed an invalid argument. Trying to argue that a missing host bus window is an invalid argument to probe() is just trying to make the shoe fit. As is arguing that -ENODEV is an appropriate return value for the missing resource. Moreover, returning -ENODEV is actually *bad* in this case - the kernel's generic probe handling does not report the failure of the driver to bind given this, so a missing resource potentially becomes a silent failure of a driver - leading users to wonder why their devices aren't found. If we /really/ have a problem with the error code, then why not invent a new error code to cater for this condition - maybe, EBADRES (bad resource). I understand that people might see some ambiguity there, and -EINVAL is certainly not a very accurate description, but such is the nature of error codes. You pick what fits best. -ENXIO and -EADDRNOTAVAIL had been under discussion as well if I remember correctly, but they both equally ambiguous. -ENODATA might have been a better fit, but that too has a different meaning in other contexts. Besides, there's an error message that goes along with the error code return, that should remove any ambiguity for people looking at dmesg. All of that said, the original assertion that the check is not required is still valid. We can argue at length about the specific error code but if we decide that it needs to change, then we should modify devm_ioremap_resource() rather than requiring all callers to perform the extra check again. None of the devm_ioremap_resource() changes have been submitted for serial drivers. $ grep devm_ioremap_resource drivers/tty/serial/ -r | wc -l 10 It seems that statement is false. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] pinctrl: Broadcom Cygnus pinctrl device tree binding
On Fri, Jan 23, 2015 at 7:49 AM, Ray Jui r...@broadcom.com wrote: I dig into the pinctrl framework code a bit more and found that I can use pinctrl_request_gpio from the GPIO driver and implement gpio_request_enable in the pinctrl driver. Yep :) ain't it nice. The only problem I see now is that these APIs seem to expect the use of global GPIO numbers? No they don't, only if you use the deprecated pinctrl_add_gpio_range(). Instead, when you register your struct gpio_chip, use gpiochip_add_pin_range() and this will use relative offsets without relying on global GPIO numbers. This latter call replaces pinctrl_add_gpio_range(). I hope I'm not missing something here? You're missing gpiochip_add_pin_range() ;) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] pinctrl: Broadcom Cygnus pinctrl device tree binding
On Fri, Jan 23, 2015 at 3:14 AM, Ray Jui r...@broadcom.com wrote:
I have another question here. In the B0 revision of our Cygnus chip, the
ASIC team added a feature to allow individual pins to be muxed to GPIO.
The pinmux controller can still only do group-based muxing in general,
but at the same time, you can override most (but not all) individual
pins to GPIO.
I believe this HW design actually forces us to mix use groups and
pins in DT.
For example, assuming we mux pins 1 - 10 as MMC (one cmd line, one clk
line, and 8 data lines). One might make the decision that he only needs
4 data lines instead of 8 data lines, and he wants to free up the 4 data
lines and uses as GPIO.
I would split the 8 available data lines in two groups,
like data-1-4 and data-5-8 since the use case is such
that either you use four or eight lines, not 6 or 7, either
just data-1-4 or both data-1-4 and data-5-8.
Based on this example, is the following DT
configuration valid?
sd_node {
function = sd;
groups = sd_grps;
};
gpio_node {
function = gpio;
pins = gpio_7, gpio_8, gpio_9, gpio_10; /* assuming 1:1
mapping between gpio and pin number to make this example simple */
};
Muxing an individual GPIO from the device tree is seldom a
good idea as you realized in your follow-up mail ;)
But this:
sd_node {
function = sd;
groups = data-1-4, data-5-8, other-pin-group;
};
Is perfectly fine. One function, several groups.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
On 30/01/15 02:11, Chanwoo Choi wrote:
Hi Roger,
On 01/28/2015 09:15 PM, Roger Quadros wrote:
This driver observes the USB ID pin connected over a GPIO and
updates the USB cable extcon states accordingly.
The existing GPIO extcon driver is not suitable for this purpose
as it needs to be taught to understand USB cable states and it
can't handle more than one cable per instance.
For the USB case we need to handle 2 cable states.
1) USB (attach/detach)
2) USB-Host (attach/detach)
This driver can be easily updated in the future to handle VBUS
events in case it happens to be available on GPIO for any platform.
Signed-off-by: Roger Quadros rog...@ti.com
---
v3:
- removed IRQF_NO_SUSPEND flag. Added IRQF_TRIGGER_RISING and
IRQF_TRIGGER_FALLING
- Added disable_irq() to suspend() and enable_irq() to resume()
.../devicetree/bindings/extcon/extcon-usb-gpio.txt | 18 ++
drivers/extcon/Kconfig | 7 +
drivers/extcon/Makefile| 1 +
drivers/extcon/extcon-usb-gpio.c | 233
+
4 files changed, 259 insertions(+)
create mode 100644
Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
create mode 100644 drivers/extcon/extcon-usb-gpio.c
diff --git a/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
new file mode 100644
index 000..85fe6b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-usb-gpio.txt
@@ -0,0 +1,18 @@
+USB GPIO Extcon device
+
+This is a virtual device used to generate USB cable states from the USB ID
pin
+connected to a GPIO pin.
+
+Required properties:
+- compatible: Should be linux,extcon-usb-gpio
+- id-gpio: gpio for USB ID pin. See gpio binding.
+
+Example:
+extcon_usb1 {
+compatible = linux,extcon-usb-gpio;
+id-gpio = gpio6 1 GPIO_ACTIVE_HIGH;
+}
+
+omap_dwc3_1 {
+extcon = extcon_usb1;
+};
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 6a1f7de..fd11536 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -93,4 +93,11 @@ config EXTCON_SM5502
Silicon Mitus SM5502. The SM5502 is a USB port accessory
detector and switch.
+config EXTCON_USB_GPIO
+tristate USB GPIO extcon support
+select GPIOLIB
+help
+ Say Y here to enable GPIO based USB cable detection extcon support.
+ Used typically if GPIO is used for USB ID pin detection.
+
endif # MULTISTATE_SWITCH
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 0370b42..6a08a98 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
obj-$(CONFIG_EXTCON_RT8973A)+= extcon-rt8973a.o
obj-$(CONFIG_EXTCON_SM5502) += extcon-sm5502.o
+obj-$(CONFIG_EXTCON_USB_GPIO) += extcon-usb-gpio.o
diff --git a/drivers/extcon/extcon-usb-gpio.c
b/drivers/extcon/extcon-usb-gpio.c
new file mode 100644
index 000..99a58b2
--- /dev/null
+++ b/drivers/extcon/extcon-usb-gpio.c
@@ -0,0 +1,233 @@
+/**
+ * drivers/extcon/extcon-usb-gpio.c - USB GPIO extcon driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Roger Quadros rog...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/extcon.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of_gpio.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/workqueue.h
+
+#define USB_GPIO_DEBOUNCE_MS20 /* ms */
+
+struct usb_extcon_info {
+struct device *dev;
+struct extcon_dev *edev;
+
+struct gpio_desc *id_gpiod;
+int id_irq;
+bool id_irqwake;/* ID wakeup enabled flag */
+
+unsigned long debounce_jiffies;
+struct delayed_work wq_detcable;
+};
+
+/* List of detectable cables */
+enum {
+EXTCON_CABLE_USB = 0,
+EXTCON_CABLE_USB_HOST,
+
+EXTCON_CABLE_END,
+};
+
+static const char *usb_extcon_cable[] = {
+[EXTCON_CABLE_USB] = USB,
+[EXTCON_CABLE_USB_HOST] = USB-Host,
I'll use the defined name for extcon cable name as soon because
it has potential isseu about the conflict of extcon cable name between
subsystems.
So, I recommend to use a captical letter as USB-HOST
Re: [PATCH v2 2/7] usb: extcon: Fix USB-Host cable name
Hi, On 30/01/15 13:04, Roger Quadros wrote: Felipe Chanwoo, On 26/01/15 14:15, Roger Quadros wrote: The recommended name for USB-Host cable state is USB-Host and not USB-HOST as per drivers/extcon/extcon-class.c extcon_cable_name. Change all instances of USB-HOST to USB-Host. Signed-off-by: Roger Quadros rog...@ti.com Reviewed-by: Felipe Balbi ba...@ti.com Acked-by: Felipe Balbi ba...@ti.com This patch has no dependency to the rest so can be picked up as soon as possible. Do you think it is better to go via the USB tree? If yes then Chanwoo, can you please Ack this one? Thanks. This would mean that only the first patch needs to go through extcon tree as Tony will pick the rest. Hold on. Let's first decide what we really want to go ahead with USB-Host or USB-HOST. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v5, 5/6] powerpc/mpc85xx: Add FSL QorIQ DPAA BMan support to device tree(s)
Hello Scott,
On 01/29/2015 11:03 PM, Scott Wood wrote:
On Mon, Dec 08, 2014 at 04:29:20AM -0600, Emil Medve wrote:
From: Kumar Gala ga...@kernel.crashing.org
Change-Id: If643fa5ba0a903aef8f5056a2c90ebecc995b760
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
Signed-off-by: Geoff Thorpe geoff.tho...@freescale.com
Signed-off-by: Hai-Ying Wang haiying.w...@freescale.com
Signed-off-by: Chunhe Lan chunhe@freescale.com
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
[Emil Medve: Sync with the upstream binding]
Signed-off-by: Emil Medve emilian.me...@freescale.com
Doesn't apply cleanly
@@ -408,6 +415,8 @@ crypto: crypto@30 {
fsl,iommu-parent = pamu1;
};
+/include/ qoriq-bman1.dtsi
+
/include/ qoriq-fman-0.dtsi
/include/ qoriq-fman-0-1g-0.dtsi
/include/ qoriq-fman-0-1g-1.dtsi
What tree did you base these patches on? There's no fman in the upstream
device trees yet (just a binding).
They were based on this patch series:
http://patchwork.ozlabs.org/patch/370866. Will re-send
Cheers,
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC V3] OPP: Redefine bindings to overcome shortcomings
Current OPP (Operating performance point) DT bindings are proven to be
insufficient at multiple instances.
There had been multiple band-aid approaches to get them fixed (The latest one
being: http://www.mail-archive.com/devicetree@vger.kernel.org/msg53398.html).
For obvious reasons Rob rejected them and shown the right path forward.
The shortcomings we are trying to solve here:
- How to select which driver to probe for a platform, when multiple drivers are
available. For example: how to choose between cpufreq-dt and arm_big_little
drivers.
- Getting clock sharing information between CPUs. Single shared clock vs
independent clock per core vs shared clock per cluster.
- Support for turbo modes
- Support for intermediate frequencies or OPPs we can switch to.
- Other per OPP settings: transition latencies, disabled status, etc.?
Please see the below bindings for further details.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
V2-V3:
- drop list-nodes
- opp-microvolt is an array now, also is optional.
- New shared-opp property
- compatible property clearly defined
- opp-next instead of intermediate-property
I will circulate code as well, once this is accepted/applied.
Documentation/devicetree/bindings/power/opp.txt | 407 +++-
1 file changed, 403 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/power/opp.txt
b/Documentation/devicetree/bindings/power/opp.txt
index 74499e5033fc..a64621819d7c 100644
--- a/Documentation/devicetree/bindings/power/opp.txt
+++ b/Documentation/devicetree/bindings/power/opp.txt
@@ -1,8 +1,407 @@
-* Generic OPP Interface
+Generic OPP (Operating Performance Points) Bindings
+
-SoCs have a standard set of tuples consisting of frequency and
-voltage pairs that the device will support per voltage domain. These
-are called Operating Performance Points or OPPs.
+Devices work at voltage-frequency pairs and some implementations have the
+liberty of choosing these pairs. These pairs are called Operating Performance
+Points aka OPPs. This document defines bindings for these OPPs applicable
across
+wide range of devices. For illustration purpose, this document uses CPU as a
+device.
+
+
+* Property: operating-points-v2
+
+Devices supporting OPPs must set their operating-points-v2 property with
+phandle to a OPP descriptor in their DT node. The OPP core will use this
phandle
+to find the operating points for the device.
+
+
+* OPP Descriptor Node
+
+This describes the OPPs belonging to a device. This node can have following
+properties:
+
+Required properties:
+- compatible: Allow OPPs to express their compatibility. It should be:
+ operating-points-v2.
+- OPP nodes: One or more OPP nodes describing frequency-voltage pairs. Their
+ name isn't significant but their phandles can be used to reference an OPP.
+
+Optional properties:
+- shared-opp: Indicates that device nodes using this OPP descriptor's phandle
+ switch their DVFS state together, i.e. they share clock lines. Missing
+ property means devices have independent clock lines, but they share OPPs.
+
+
+* OPP Node
+
+This defines frequency-voltage pairs along with other related properties.
+
+Required properties:
+- opp-khz: Frequency in kHz
+
+Optional properties:
+- opp-microvolt: voltage in micro Volts. Its an array with size one or three.
+ Single entry is for target voltage and three entries are for (in the
specified
+ order) target min max voltage.
+- clock-latency-ns: Specifies the maximum possible transition latency (in
+ nanoseconds) for switching to this OPP from any other OPP.
+- opp-next: It contains a list of phandles of other OPPs, to which we can
switch
+ directly from this OPP (Explained later with examples). Missing property
means
+ no restriction on switching to other OPPs.
+- turbo-mode: Marks the OPP to be used only for turbo modes.
+- status: Marks the node enabled/disabled.
+
+Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
+
+/ {
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ cpu@0 {
+ compatible = arm,cortex-a9;
+ reg = 0;
+ next-level-cache = L2;
+ clocks = clk_controller 0;
+ clock-names = cpu;
+ opp-supply = cpu_supply0;
+ operating-points-v2 = cpu0_opp;
+ };
+
+ cpu@1 {
+ compatible = arm,cortex-a9;
+ reg = 1;
+ next-level-cache = L2;
+ clocks = clk_controller 0;
+ clock-names = cpu;
+ opp-supply = cpu_supply0;
+ operating-points-v2 = cpu0_opp;
+ };
+ };
+
+ cpu0_opp: opp0 {
+ compatible = operating-points-v2;
+
[PATCH v4 0/3] irqchip: vf610-mscm: add support for MSCM interrupt router
So far the MSCM interrupt router was initialized by the boot loader and configured all interrupts for the Cortex-A5 CPU. There are two use cases where a proper driver is necessary: - To run Linux on the Cortex-M4. When the kernel is running on the non-preconfigured CPU, the interrupt router need to be configured properly. - To support deeper sleep modes: LPSTOP clears the interrupt router configuration, hence a driver needs to restore the configuration on resume. Due to the concernes of using syscon for the interrupt router this 4th version uses device tree bindings which split the MSCM module into sub-modules. In detail, the registers inside the MSCM module are grouped: - 0x40001000-0x4000105C: Processor information e.g. CPU ID - 0x40001800-0x40001820: CPU2CPU directed interrupt registers - 0x40001880-0x4000195E: The interrupt router registers - 0x40001C00-0x40001DDC: ACTZS TrustZone registers This version of the patchset defines bindings for the first submodule and combines the second and third submodule into one block. However, the driver currently does not support the CPU2CPU interrupts. The fourth submodule is completely left out for now. Due to this and the better documentation the patchset grew by ~40 lines. I think this bindings honer the quite individual functionality inside the MSCM better. Changes since v3 - Splitted MSCM bindings: MSCM CPU configuration and interrupt router - Use syscon to access the CPU configuration registers - Renamed the driver (irq-vf610-mscm = irq-vf610-mscm-ir) - Extended general and property description of the bindings - Rebased on v3.19-rc6 Changes since v2 - Use two cell layout for MSCM interrupt router - Move peripheral interrupt properties to base device tree vfxxx.dtsi - Use generic two cell xlate (irq_domain_xlate_twocell) - Add syscon to compatible string - Remove some line breaks for better readability Changes since v1 (part of Vybrid Cortex-M4 support) - Rewrite with irqdomain hierarchy - Implemented as proper irqchip and move to driver/irqchip/ - Doesn't work on Cortex-M4 anymore (NVIC as parent is not yet implemented) Stefan Agner (3): irqchip: vf610-mscm-ir: add support for MSCM interrupt router irqchip: vf610-mscm: dt-bindings: add MSCM bindings ARM: dts: vf610: add Miscellaneous System Control Module (MSCM) .../arm/freescale/fsl,vf610-mscm-cpucfg.txt| 14 ++ .../bindings/arm/freescale/fsl,vf610-mscm-ir.txt | 33 arch/arm/boot/dts/vf500.dtsi | 128 + arch/arm/boot/dts/vfxxx.dtsi | 48 + arch/arm/mach-imx/Kconfig | 1 + drivers/irqchip/Kconfig| 11 ++ drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-vf610-mscm-ir.c| 206 + 8 files changed, 318 insertions(+), 124 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt create mode 100644 Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt create mode 100644 drivers/irqchip/irq-vf610-mscm-ir.c -- 2.2.2 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 3/3] ARM: dts: vf610: add Miscellaneous System Control Module (MSCM)
Add the Miscellaneous System Control Module (MSCM) to the base
device tree for Vybrid SoC's. This module contains registers
to get information of the individual and current (accessing)
CPU. In a second block, there is an interrupt router, which
handles the routing of the interrupts between the two CPU cores
on VF6xx variants of the SoC. However, also on single core
variants the interrupt router needs to be configured in order
to receive interrupts on the CPU's interrupt controller. Almost
all peripheral interrupts are routed through the router, hence
the MSCM module is the default interrupt parent for this SoC.
In a earlier commit the interrupt nodes were moved out of the
peripheral nodes and specified in the CPU specific vf500.dtsi
device tree. This allowed to use the base device tree vfxxx.dtsi
also for a Cortex-M4 specific device tree, which uses different
interrupt nodes due to the NVIC interrupt controller. However,
since the interrupt parent for peripherals is the MSCM module
independently which CPU the device tree is used for, we can move
the interrupt nodes into the base device tree vfxxx.dtsi again.
Depending on which CPU this base device tree will be used with,
the correct parent interrupt controller has to be assigned to
the MSCM-IR node (GIC or NVIC). The driver takes care of the
parent interrupt controller specific needs (interrupt-cells).
Acked-by: Marc Zyngier marc.zyng...@arm.com
Signed-off-by: Stefan Agner ste...@agner.ch
---
arch/arm/boot/dts/vf500.dtsi | 128 ++-
arch/arm/boot/dts/vfxxx.dtsi | 48
2 files changed, 52 insertions(+), 124 deletions(-)
diff --git a/arch/arm/boot/dts/vf500.dtsi b/arch/arm/boot/dts/vf500.dtsi
index de67005..9747f97 100644
--- a/arch/arm/boot/dts/vf500.dtsi
+++ b/arch/arm/boot/dts/vf500.dtsi
@@ -24,14 +24,13 @@
};
soc {
- interrupt-parent = intc;
-
aips-bus@4000 {
intc: interrupt-controller@40002000 {
compatible = arm,cortex-a9-gic;
#interrupt-cells = 3;
interrupt-controller;
+ interrupt-parent = intc;
reg = 0x40003000 0x1000,
0x40002100 0x100;
};
@@ -40,132 +39,13 @@
compatible = arm,cortex-a9-global-timer;
reg = 0x40002200 0x20;
interrupts = GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH;
+ interrupt-parent = intc;
clocks = clks VF610_CLK_PLATFORM_BUS;
};
};
};
};
-adc0 {
- interrupts = GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH;
-};
-
-adc1 {
- interrupts = GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH;
-};
-
-can0 {
- interrupts = GIC_SPI 58 IRQ_TYPE_LEVEL_HIGH;
-};
-
-can1 {
- interrupts = GIC_SPI 59 IRQ_TYPE_LEVEL_HIGH;
-};
-
-dspi0 {
- interrupts = GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH;
-};
-
-edma0 {
- interrupts = GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH,
- GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH;
- interrupt-names = edma-tx, edma-err;
-};
-
-edma1 {
- interrupts = GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH,
- GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
- interrupt-names = edma-tx, edma-err;
-};
-
-esdhc1 {
- interrupts = GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH;
-};
-
-fec0 {
- interrupts = GIC_SPI 78 IRQ_TYPE_LEVEL_HIGH;
-};
-
-fec1 {
- interrupts = GIC_SPI 79 IRQ_TYPE_LEVEL_HIGH;
-};
-
-ftm {
- interrupts = GIC_SPI 44 IRQ_TYPE_LEVEL_HIGH;
-};
-
-gpio1 {
- interrupts = GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH;
-};
-
-gpio2 {
- interrupts = GIC_SPI 108 IRQ_TYPE_LEVEL_HIGH;
-};
-
-gpio3 {
- interrupts = GIC_SPI 109 IRQ_TYPE_LEVEL_HIGH;
-};
-
-gpio4 {
- interrupts = GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH;
-};
-
-gpio5 {
- interrupts = GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH;
-};
-
-i2c0 {
- interrupts = GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH;
-};
-
-pit {
- interrupts = GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH;
-};
-
-qspi0 {
- interrupts = GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH;
-};
-
-sai2 {
- interrupts = GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH;
-};
-
-uart0 {
- interrupts = GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH;
-};
-
-uart1 {
- interrupts = GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH;
-};
-
-uart2 {
- interrupts = GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH;
-};
-
-uart3 {
- interrupts = GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH;
-};
-
-uart4 {
- interrupts = GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH;
-};
-
-uart5 {
- interrupts = GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH;
-};
-
-usbdev0 {
- interrupts = GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH;
-};
-
-usbh1 {
- interrupts = GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH;
-};
-
-usbphy0 {
- interrupts = GIC_SPI 50 IRQ_TYPE_LEVEL_HIGH;
-};
-
-usbphy1 {
-
[PATCH v4 2/3] irqchip: vf610-mscm: dt-bindings: add MSCM bindings
Add binding documentation for CPU configuration and interrupt router
submodule of the Miscellaneous System Control Module. The MSCM is
used in all variants of Freescale Vybrid SoC's.
Acked-by: Marc Zyngier marc.zyng...@arm.com
Signed-off-by: Stefan Agner ste...@agner.ch
---
.../arm/freescale/fsl,vf610-mscm-cpucfg.txt| 14 +
.../bindings/arm/freescale/fsl,vf610-mscm-ir.txt | 33 ++
2 files changed, 47 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt
create mode 100644
Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt
diff --git
a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt
b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt
new file mode 100644
index 000..44aa3c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-cpucfg.txt
@@ -0,0 +1,14 @@
+Freescale Vybrid Miscellaneous System Control - CPU Configuration
+
+The MSCM IP contains multiple sub modules, this binding describes the first
+block of registers which contains CPU configuration information.
+
+Required properties:
+- compatible: fsl,vf610-mscm-cpucfg, syscon
+- reg: the register range of the MSCM CPU configuration registers
+
+Example:
+ mscm_cpucfg: cpucfg@40001000 {
+ compatible = fsl,vf610-mscm-cpucfg, syscon;
+ reg = 0x40001000 0x800;
+ }
diff --git
a/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt
b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt
new file mode 100644
index 000..669808b2a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,vf610-mscm-ir.txt
@@ -0,0 +1,33 @@
+Freescale Vybrid Miscellaneous System Control - Interrupt Router
+
+The MSCM IP contains multiple sub modules, this binding describes the second
+block of registers which control the interrupt router. The interrupt router
+allows to configure the recipient of each peripheral interrupt. Furthermore
+it controls the directed processor interrupts. The module is available in all
+Vybrid SoC's but is only really useful in dual core configurations (VF6xx
+which comes with a Cortex-A5/Cortex-M4 combination).
+
+Required properties:
+- compatible: fsl,vf610-mscm-ir
+- reg: the register range of the MSCM Interrupt Router
+- fsl,cpucfg: The handle to the MSCM CPU configuration node, required
+ to get the current CPU ID
+- interrupt-controller:Identifies the node as an interrupt controller
+- #interrupt-cells:Two cells, interrupt number and cells.
+ The hardware interrupt number according to interrupt
+ assignment of the interrupt router is required.
+ Flags get passed only when using GIC as parent. Flags
+ encoding as documented by the GIC bindings.
+- interrupt-parent:Should be the phandle for the interrupt controller of
+ the CPU the device tree is intended to be used on. This
+ is either the node of the GIC or NVIC controller.
+
+Example:
+ mscm_ir: interrupt-controller@40001800 {
+ compatible = fsl,vf610-mscm-ir;
+ reg = 0x40001800 0x400;
+ fsl,cpucfg = mscm_cpucfg;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ interrupt-parent = intc;
+ }
--
2.2.2
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line
Hello, On 2015-01-29 11:56, Javier Martinez Canillas wrote: On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: Also, I wonder whether we could extend the mmc-pwrseq to cover your case? Did you consider that as an option? I didn't consider mmc-pwrseq yet. For me it looked straightforward to I agree with Ulf that using mmc-pwrseq would be a good solution and in fact I think the pwrseq_simple [0] driver will fit your use case since it supports a reset GPIO pin which is what many WLAN chips attached to a SDIO interface use. Ok, I've checked mmc-prwseq and mmc-pwrseq-simple. I also checked the hardware and it mmc-pwrseq-simple cannot be used directly. Although the signal is called RSTN (on Odroid U3 schema), the eMMC card gets resetted not on low line level, but during the rising edge. This RSTN line is also pulled up by the external resistor. However, the strangest thing is the fact that the default SoC configuration (which is applied during hw reset) for this GPIO line is input, pulled-down. The SoC internal pull-down is stronger than the external pull up, so in the end, during the SoC reboot the RSTN signal is set to zero. Later bootloader disables the internal pull-down. To sum up - to perform proper reboot on Odroid U3/XU3, one need to set RSTN to zero, wait a while and the set it back to 1. To achieve this with mmc-pwrseq-simple, I would need to modify the power_off callback to toggle reset line to zero and back to one. This however might not be desired to other sd/mmc cards used with mmc-pwrseq-simple. I can also provide separate mmc-pwrsrq-odroid driver, which will be very similar to mmc-pwrseq-simple. Ulf - which approach would you prefer? implement it just like card detect or write-protection gpio pins. I already noticed that there is code for some mmc host driver, which perform mmc hardware reset. If you think that extending pwrseq is the better approach, I will try to update my patches. This will add reboot handler to mmc-pwrseq then. The only question is I don't think that adding a reboot handler to mmc-pwrseq is needed. AFAICT the call chain is: sys_reboot() - kernel_restart() - device_shutdown() - mmc_bus_shutdown() - _mmc_suspend() - mmc_power_off() - mmc_pwrseq_power_off() - struct mmc_pwrseq_ops .power_off So since the pwrseq_simple already asserts the reset GPIO in .power_off, it should be enough to ensure the eMMC will be reset to its default configuration for the iROM to work properly. It also asserts the GPIO pin in .pre_power_on and de-asserts in .post_power_on which should be needed as well for the other case you mentioned when a broken bootloader left the emmc card in some unknown state. emergency_restart() doesn't call device_shutdown(), so I think it still makes sense to add real reset handler to mmc-pwrseq to ensure that power_off will be called even during emergency_restart(). Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe devicetree 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/2] DT: iio: vadc: document dt binding
On Wed, 2015-01-28 at 18:45 +, Jonathan Cameron wrote: On 20/01/15 10:15, Ivan T. Ivanov wrote: From: Stanimir Varbanov svarba...@mm-sol.com Document DT binding for Qualcomm SPMI PMIC voltage ADC driver. Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com Given the only changes since the previous version (back in November are trivial typo corrections) I'm deeming this to have met the 3 weeks waiting for any DT responses and taking it through IIO. Applied to the togreg branch of iio.git - initially pushed out as testing. Thank you, Ivan -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/2] Imagination Technologies PWM support
On Thu, Jan 29, 2015 at 01:32:09PM -0300, Ezequiel Garcia wrote: On 01/20/2015 07:52 AM, Ezequiel Garcia wrote: On 01/09/2015 02:54 PM, Ezequiel Garcia wrote: A new round for the IMG PWM driver. The IMG PWM controller is muxed with a PDM controller, through a shared so-called periph register bit, which sets the output as PWM or PDM. Because this register is not part of the pin controller block, but rather PWM/PDM specific, and because the register is also used to set the PDM value, it is simpler to use a regmap-based syscon to deal with it. This time, I'm removing the PDM driver from the submission and submitting the PWM alone. The PDM was written as a misc driver, but had some design issues, so for now I'm proposing to merge the PWM only. The series is based on v3.19-rc3. If at all possible I'd like to see this merged for v3.20. Thierry, Any comments on this? Any chance we merge it in time for v3.20? It's -rc5 already and I've started to worry. Thierry, I'm very sorry to be so bothering, but I got no news from you and it's -rc6 already. I'd say I'll resend this series to Andrew Morton, hoping we can merge this for v3.20. Please let me know if you'll be able to pick this. I can pick it up if you make up your mind about the license. The header comment says GPL v2 or later, but MODULE_LICENSE has GPL v2, which does not include the or later part. Also you're making it especially difficult to build-test by not providing even the basic bits of your SoC support first. All even linux-next seems to have for the Pistachio SoC is the addition of a compatible string to the dw-mmc driver. I'll take the PWM driver, but I'll assume that you'll eventually have more pieces available, in which case I'd appreciate a note so I can update my build scripts. Thierry pgp9wcJM0QzHO.pgp Description: PGP signature
Re: [PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board
[added MVEBU maintainers and Gabriel to Cc]
On 30.01.2015 07:06, Jean-Francois Moine wrote:
This patch enables the ethernet device by default, permitting CM-A510
boards to access the network when an ethernet connector is present.
Signed-off-by: Jean-Francois Moine moin...@free.fr
Tested-by: Gabriel Dobato doba...@gmail.com
Jean-Francois,
great you are helping out Gabriel to get his CM-A510 up and running!
I had a closer look on the Compulab website of the SoM [1] and think
that we'll have to convert it to dove-cm-a510.dtsi and the baseboard
Gabriel is using (maybe SBC-A510 [2]).
The dove-cm-a510.dts was a blind port of what was in mach-dove when
we started with DT, so most of it is probably bogus.
For the ethernet port this patch is about, the PHY (RTL8211) is part
of the SoM, the jack is not. So, we cannot really tell, if that port
can ever be used on a specific baseboard. I suggest to put the
corresponding nodes into the dtsi, but leave them status = disabled.
The baseboard dts should enable them like your patch does, if the
ethernet jack is available. The same is true for the sdio0 and sata0
nodes you can see below. However, sdio1 is connected to a USI WiFi
module with Marvel 8686 on the SoM.
Can you take over and prepare the necessary patches? That would
be great!
BTW, I wouldn't mind if the cm510 related dts files you are touching
move over to dual-license [3] now :)
Sebastian
[1] http://www.compulab.co.il/products/computer-on-modules/cm-a510/#diagram
[2] www.compulab.co.il/products/sbcs/sbc-a510/
[3] http://permalink.gmane.org/gmane.linux.ports.arm.kernel/389206
---
arch/arm/boot/dts/dove-cm-a510.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dove-cm-a510.dts
b/arch/arm/boot/dts/dove-cm-a510.dts
index 50c0d69..404e983 100644
--- a/arch/arm/boot/dts/dove-cm-a510.dts
+++ b/arch/arm/boot/dts/dove-cm-a510.dts
@@ -21,6 +21,8 @@
sdio0 { status = okay; };
sdio1 { status = okay; };
sata0 { status = okay; };
+eth { status = okay; };
+mdio { status =okay;};
spi0 {
status = okay;
--
To unsubscribe from this list: send the line unsubscribe devicetree 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] clk: qcom: gcc bindings: Update to add child node support.
This patch adds note in the bindings about the optional child nodes
which are currently possible with SOCs like MSM8960, APQ8064.
These child device nodes are typically for drivers like thermal sensor
which fall under the memory-map of gcc.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
Documentation/devicetree/bindings/clock/qcom,gcc.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index aba3d25..c79225b 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -17,6 +17,11 @@ Required properties :
- #clock-cells : shall contain 1
- #reset-cells : shall contain 1
+Optional child nodes:
+ Child nodes could be any device nodes with its own bindings which
+ fall inside the memory-map of the Clock controller, for example
+ thermal sensor driver.
+
Example:
clock-controller@90 {
compatible = qcom,gcc-msm8960;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/2] Imagination Technologies PWM support
On Fri, Jan 30, 2015 at 09:50:46AM +, Andrew Bresticker wrote:
Also you're making it especially difficult to build-test by not
providing even the basic bits of your SoC support first. All even
linux-next seems to have for the Pistachio SoC is the addition of a
compatible string to the dw-mmc driver.
I'll take the PWM driver, but I'll assume that you'll eventually have
more pieces available, in which case I'd appreciate a note so I can
update my build scripts.
FYI, I'm hoping to post Pistachio platform support for 3.21.
That'd be great. I can switch over to a proper defconfig then and not
jump through extra hoops to build test patches.
Also, I'm seeing a bunch of weird errors from building MIPS, mostly
things like this:
CC net/ipv4/netfilter/arp_tables.mod.o
{standard input}: Assembler messages:
{standard input}: Warning: .gnu_attribute 4,3 requires `softfloat'
or this later on:
mips-linux-gnu-ld: Warning: vmlinuz uses -mhard-float (set by
arch/mips/boot/compressed/head.o), arch/mips/boot/compressed/decompress.o uses
-msoft-float
This is essentially a gpr_defconfig (because it select MIPS_ALCHEMY,
which in turns pulls in COMMON_CLK that PWM_IMG depends on) and then
enabling MFD_SYSCON on top so that all dependencies are met.
What am I doing wrong?
Thierry
pgp1iZLKE3qOC.pgp
Description: PGP signature
Re: [PATCH v8 0/2] Imagination Technologies PWM support
Also you're making it especially difficult to build-test by not providing even the basic bits of your SoC support first. All even linux-next seems to have for the Pistachio SoC is the addition of a compatible string to the dw-mmc driver. I'll take the PWM driver, but I'll assume that you'll eventually have more pieces available, in which case I'd appreciate a note so I can update my build scripts. FYI, I'm hoping to post Pistachio platform support for 3.21. -- To unsubscribe from this list: send the line unsubscribe devicetree 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] clk: qcom: gcc: Add support to child devices.
This patchset adds support to child devices whose memory registers fall insider gcc memory map. For example on APQ8064 whose thermal sensor registers are inside gcc memory range. Thanks, srini Srinivas Kandagatla (2): clk: qcom: gcc-msm8960: add child devices support. clk: qcom: gcc bindings: Update to add child node support. Documentation/devicetree/bindings/clock/qcom,gcc.txt | 5 + drivers/clk/qcom/gcc-msm8960.c | 7 ++- 2 files changed, 11 insertions(+), 1 deletion(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] MAINTAINERS: Add entry for Maxim PMICs on Samsung boards
Add myself and Chanwoo Choi as supporters to help in reviewing patches for Maxim 77686 PMIC and Maxim 14577/77693 MUIC drivers: - mfd (all of them), - extcon (extcon-max14577.c, extcon-max77693.c), - regulator (all of them), - clock (clk-max77686.c), - RTC (rtc-max77686.c). Lately I am the author of contributors to them. These drivers are used on Exynos-based boards (Trats 2, Gear 1 and Gear 2). Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Cc: MyungJoo Ham myungjoo@samsung.com cc: Chanwoo Choi cw00.c...@samsung.com Cc: Samuel Ortiz sa...@linux.intel.com Cc: Lee Jones lee.jo...@linaro.org Cc: Liam Girdwood lgirdw...@gmail.com Cc: Mark Brown broo...@kernel.org Cc: Mike Turquette mturque...@linaro.org Cc: Stephen Boyd sb...@codeaurora.org Cc: Alessandro Zummo a.zu...@towertech.it Acked-by: Mark Brown broo...@kernel.org Acked-by: Lee Jones lee.jo...@linaro.org --- Changes since v1: 1. Add also Chanwoo Choi as supporter on his request [1]. 2. Move out chargers (power supply) to separate patch (applied already by Sebastian Reichel [2]). Patch is rebased on next which includes this. 3. Add acks from Mark Brown and Lee Jones. [1] https://lkml.org/lkml/2015/1/16/571 [2] http://git.infradead.org/battery-2.6.git/commit/f8f847b51a0e1cb0c96e706d5da0ac507d96c605 --- MAINTAINERS | 20 1 file changed, 20 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 5d7404add7ed..775a631118ef 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6191,6 +6191,26 @@ S: Supported F: drivers/power/max14577_charger.c F: drivers/power/max77693_charger.c +MAXIM PMIC AND MUIC DRIVERS FOR EXYNOS BASED BOARDS +M: Chanwoo Choi cw00.c...@samsung.com +M: Krzysztof Kozlowski k.kozlow...@samsung.com +L: linux-ker...@vger.kernel.org +S: Supported +F: drivers/*/max14577.c +F: drivers/*/max77686.c +F: drivers/*/max77693.c +F: drivers/extcon/extcon-max14577.c +F: drivers/extcon/extcon-max77693.c +F: drivers/rtc/rtc-max77686.c +F: drivers/clk/clk-max77686.c +F: Documentation/devicetree/bindings/mfd/max14577.txt +F: Documentation/devicetree/bindings/mfd/max77686.txt +F: Documentation/devicetree/bindings/mfd/max77693.txt +F: Documentation/devicetree/bindings/clock/maxim,max77686.txt +F: include/linux/mfd/max14577*.h +F: include/linux/mfd/max77686*.h +F: include/linux/mfd/max77693*.h + MAXIRADIO FM RADIO RECEIVER DRIVER M: Hans Verkuil hverk...@xs4all.nl L: linux-me...@vger.kernel.org -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] clk: qcom: gcc bindings: Update to add child node support.
This patch adds note in the bindings about the optional child nodes
which are currently possible with SOCs like MSM8960, APQ8064.
These child device nodes are typically for drivers like thermal sensor
which fall under the memory-map of gcc.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
Documentation/devicetree/bindings/clock/qcom,gcc.txt | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index aba3d25..c79225b 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -17,6 +17,11 @@ Required properties :
- #clock-cells : shall contain 1
- #reset-cells : shall contain 1
+Optional child nodes:
+ Child nodes could be any device nodes with its own bindings which
+ fall inside the memory-map of the Clock controller, for example
+ thermal sensor driver.
+
Example:
clock-controller@90 {
compatible = qcom,gcc-msm8960;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support
On Thu, Jan 29, 2015 at 04:05:53PM +, Russell King - ARM Linux wrote: On Thu, Jan 29, 2015 at 10:49:34AM -0500, Peter Hurley wrote: Hi Varka, On 01/29/2015 10:26 AM, Varka Bhadram wrote: This check is not required. It will be done by devm_ioremap_resource() I disagree. devm_ioremap_resource() interprets the NULL resource as a bad parameter and returns -EINVAL which is then forwarded as the return value from the probe. -ENODEV is the correct return value from the probe if the expected resource is not available (either because it doesn't exist or was already claimed by another driver). (Adding Thierry as the author of this function.) I believe devm_ioremap_resource() was explicitly designed to remove such error handling from drivers, and to give drivers a unified error response to such things as missing resources. See the comments for this function in lib/devres.c. Right. Before the introduction of this function drivers would copy the same boilerplate but would use completely inconsistent return codes. Well, to be correct devm_request_and_ioremap() was introduced first to reduce the boilerplate, but one of the problems was that it returned a NULL pointer on failure, so it was impossible to distinguish between specific error conditions. It also had the negative side-effect of not giving drivers any directions on what to do with the NULL return value other than the example in the kerneldoc. But most people just didn't seem to look at that, so instead of using -EADDRNOTAVAIL they'd again go and do completely inconsistent things everywhere. When we introduced devm_ioremap_resource(), the idea was to remove any of these inconsistencies once and for all. You call the function and if it fails you simply propagate the error code, so you get consistent behaviour everywhere. If I remember correctly the error codes for the various conditions were discussed quite extensively, and what we currently have is what we got by concensus. -ENODEV is certainly not the correct return value if a resource is not available. It translates to no such device, but the device must clearly be there, otherwise the -probe() shouldn't have been called. Or if it really isn't there, then you'd at least need a memory region to probe, otherwise you can't determine whether it's there or not. So from the perspective of a device driver I think a missing, or NULL, resource, is indeed an invalid argument. I understand that people might see some ambiguity there, and -EINVAL is certainly not a very accurate description, but such is the nature of error codes. You pick what fits best. -ENXIO and -EADDRNOTAVAIL had been under discussion as well if I remember correctly, but they both equally ambiguous. -ENODATA might have been a better fit, but that too has a different meaning in other contexts. Besides, there's an error message that goes along with the error code return, that should remove any ambiguity for people looking at dmesg. All of that said, the original assertion that the check is not required is still valid. We can argue at length about the specific error code but if we decide that it needs to change, then we should modify devm_ioremap_resource() rather than requiring all callers to perform the extra check again. Thierry pgpwx5n6Zizo3.pgp Description: PGP signature
Re: [PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board
On Fri, 30 Jan 2015 10:44:07 +0100 Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote: I had a closer look on the Compulab website of the SoM [1] and think that we'll have to convert it to dove-cm-a510.dtsi and the baseboard Gabriel is using (maybe SBC-A510 [2]). Sebastian, I don't understand why the A510 contained in the cm-a510 should be different from the one of the other boards (I just noticed a second ethernet and a WiFi device - but, is the Compulab document up to date?). If it is the same, the dove.dtsi should work (and it seems to work for Gabriel). The only difference with the cm-a510 is the presence or not of the connectors. So, all the Dove devices could be enabled in the DT, and, if some room is needed in the board, the .config could be adapted removing the useless drivers and have a minimal kernel. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/3] powerpc/pmac: Fix DT refcount imbalance in pmac_pic_probe_oldstyle
Hi Michael,
On Fri, Jan 30, 2015 at 5:09 AM, Michael Ellerman m...@ellerman.id.au wrote:
On Wed, 2015-14-01 at 13:51:57 UTC, Geert Uytterhoeven wrote:
of_find_node_by_name() calls of_node_put() on its from parameter,
which must not be done on master, as it's still in use, and will be
released manually later. This may cause a zero kref refcount.
Use of_get_child_by_name() instead to fix this.
But of_find_node_by_name() searches *all* nodes, not just the children of the
parameter.
That's correct. However, I guess the second mac-io will just be a direct child.
So this is a logic change AFAICS, and I have no idea what machines we'd need
to
test on to check it.
Originally it comes from arch/ppc/platforms/pmac_pic.c, added in 2002 in
full-history-linux commit 5ea3254844ae344a
(Import arch/ppc and include/asm-ppc changes from linuxppc_2_5 tree).
I've also checked my linuxppc mail archives from 1997-2002, but couldn't find
the actual patch and a description.
So I don't know on which machines it's needed.
So I think an of_node_get(master) would be safer and also fix the refcounting.
If no one can confirm the above, that may indeed be the best solution.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe devicetree 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 2/2] iio: vadc: Qualcomm SPMI PMIC voltage ADC driver
On Wed, 2015-01-28 at 18:46 +, Jonathan Cameron wrote:
On 20/01/15 10:15, Ivan T. Ivanov wrote:
From: Stanimir Varbanov svarba...@mm-sol.com
The voltage ADC is peripheral of Qualcomm SPMI PMIC chips. It has
15bits resolution and register space inside PMIC accessible across
SPMI bus.
The vadc driver registers itself through IIO interface.
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
One minor comment inline. Looks good to me.
Applied to the togreg branch of iio.git - initially pushed out as testing.
Glad to have this one out of the pending list ;)
Thank you.
+
+ irq_eoc = platform_get_irq(pdev, 0);
+ if (irq_eoc 0) {
+ if (irq_eoc == -EPROBE_DEFER || irq_eoc == -EINVAL)
+ return irq_eoc;
This does feel a little backwards. I'd normally expect to see those
errors that indicate one is not specified tested against, rather than
trying to guess all the reasons it might fail otherwise
This way round strikes me as probably more fragile as additional errors
may turn up in that function over time..
Agree, would it be better if driver just check for EPROBE_DEFER
and treat all other error codes as no interrupt defined?
I could send followup patch if you like.
Regards,
Ivan
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 5/5] drivers: bus: Add Simple Power-Managed Bus Driver
On 26 January 2015 at 17:16, Geert Uytterhoeven geert+rene...@glider.be wrote:
Add a driver for transparent busses that don't need a real driver, but
where the bus controller is part of a PM domain, or under the control of
a functional clock. Typically, the bus controller's PM domain and/or
clock must be enabled for child devices connected to the bus (either
on-SoC or externally) to function.
Hence the sole purpose of this driver is to enable its clock and PM
domain (if exist(s)), which are specified in the DT and managed from
platform and PM domain code, and to probe for child devices.
Due to the child-parent relationship with devices connected to the bus,
PM domain and clock state transitions are handled in the correct order.
Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be
Tested-by: Ulrich Hecht ulrich.hecht+rene...@gmail.com
---
v4:
- Bind against the generic simple-pm-bus instead of renesas,bsc,
- Explicitly call of_platform_populate() after pm_runtime_enable() to
enforce ordering, instead of depending on claimed compatibility with
simple-bus,
v3:
- Add Tested-by,
v2:
- Rename from Renesas Bus State Controller Driver (renesas-bsc) to
Simple Power-Managed Bus Driver (simple-pm-bus),
- Change module license to GPL v2,
- Change email address to geert+rene...@glider.be.
---
drivers/bus/Kconfig | 13 ++
drivers/bus/Makefile| 1 +
drivers/bus/simple-pm-bus.c | 58
+
3 files changed, 72 insertions(+)
create mode 100644 drivers/bus/simple-pm-bus.c
diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 626960819e6df16c..7e9c2674af81d6e9 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -58,6 +58,19 @@ config OMAP_OCP2SCP
OCP2SCP and in OMAP5, both USB PHY and SATA PHY is connected via
OCP2SCP.
+config SIMPLE_PM_BUS
+ bool Simple Power-Managed Bus Driver
+ depends on OF PM
+ depends on ARCH_SHMOBILE || COMPILE_TEST
+ help
+ Driver for transparent busses that don't need a real driver, but
+ where the bus controller is part of a PM domain, or under the
control
+ of a functional clock, and thus relies on runtime PM for managing
+ this PM domain and/or clock.
+ An example of such a bus controller is the Renesas Bus State
+ Controller (BSC, sometimes called LBSC within Bus Bridge, or
+ External Bus Interface) as found on several Renesas ARM SoCs.
+
config VEXPRESS_CONFIG
bool Versatile Express configuration bus
default y if ARCH_VEXPRESS
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index 3cfaf2c7f25ac4f0..e023a2bec664d900 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -14,4 +14,5 @@ obj-$(CONFIG_MVEBU_MBUS) += mvebu-mbus.o
obj-$(CONFIG_OMAP_INTERCONNECT)+= omap_l3_smx.o omap_l3_noc.o
obj-$(CONFIG_OMAP_OCP2SCP) += omap-ocp2scp.o
+obj-$(CONFIG_SIMPLE_PM_BUS)+= simple-pm-bus.o
obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o
diff --git a/drivers/bus/simple-pm-bus.c b/drivers/bus/simple-pm-bus.c
new file mode 100644
index ..c5eb46cbf388b507
--- /dev/null
+++ b/drivers/bus/simple-pm-bus.c
@@ -0,0 +1,58 @@
+/*
+ * Simple Power-Managed Bus Driver
+ *
+ * Copyright (C) 2014-2015 Glider bvba
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ */
+
+#include linux/module.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+
+
+static int simple_pm_bus_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+
+ dev_dbg(pdev-dev, %s\n, __func__);
+
+ pm_runtime_enable(pdev-dev);
+
+ if (np)
+ of_platform_populate(np, NULL, NULL, pdev-dev);
+
I am not sure my comments is valid in this initial step. Yet, you
state in the DT documentation, that this driver supports clocks and PM
domains.
How you are going add that support it quite interesting. :-) I also
especially interested how the interaction (child to parents) through
runtime PM will look like.
Overall, I like the idea in patchset, but I would like to understand a
bit more around the above.
Kind regards
Uffe
+ return 0;
+}
+
+static int simple_pm_bus_remove(struct platform_device *pdev)
+{
+ dev_dbg(pdev-dev, %s\n, __func__);
+
+ pm_runtime_disable(pdev-dev);
+ return 0;
+}
+
+static const struct of_device_id simple_pm_bus_of_match[] = {
+ { .compatible = simple-pm-bus, },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, simple_pm_bus_of_match);
+
+static struct platform_driver simple_pm_bus_driver = {
+ .probe = simple_pm_bus_probe,
+ .remove =
[PATCH 1/2] clk: qcom: gcc-msm8960: add child devices support.
This patch adds support to add child devices to gcc as some of the
registers mapped by gcc are used by drivers like thermal sensors.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
drivers/clk/qcom/gcc-msm8960.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/gcc-msm8960.c b/drivers/clk/qcom/gcc-msm8960.c
index 0cd3e26..2315b64 100644
--- a/drivers/clk/qcom/gcc-msm8960.c
+++ b/drivers/clk/qcom/gcc-msm8960.c
@@ -15,6 +15,7 @@
#include linux/bitops.h
#include linux/err.h
#include linux/platform_device.h
+#include linux/of_platform.h
#include linux/module.h
#include linux/of.h
#include linux/of_device.h
@@ -3677,12 +3678,16 @@ static int gcc_msm8960_probe(struct platform_device
*pdev)
if (IS_ERR(clk))
return PTR_ERR(clk);
- return qcom_cc_probe(pdev, match-data);
+ qcom_cc_probe(pdev, match-data);
+
+ return of_platform_populate(pdev-dev.of_node, NULL, NULL, pdev-dev);
}
static int gcc_msm8960_remove(struct platform_device *pdev)
{
qcom_cc_remove(pdev);
+ of_platform_depopulate(pdev-dev);
+
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] pinctrl: qcom: increase variable size for register offsets
From: Joonwoo Park joonw...@codeaurora.org
On newer TLMM hardware blocks the registers are spread and
we need an offsets upper than 16 bits to address them. Increase
the register offset variables to 32 bits size.
Signed-off-by: Joonwoo Park joonw...@codeaurora.org
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
Reviewed-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
drivers/pinctrl/qcom/pinctrl-msm.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.h
b/drivers/pinctrl/qcom/pinctrl-msm.h
index b952c4b..54fdd04 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.h
+++ b/drivers/pinctrl/qcom/pinctrl-msm.h
@@ -70,11 +70,11 @@ struct msm_pingroup {
unsigned *funcs;
unsigned nfuncs;
- s16 ctl_reg;
- s16 io_reg;
- s16 intr_cfg_reg;
- s16 intr_status_reg;
- s16 intr_target_reg;
+ u32 ctl_reg;
+ u32 io_reg;
+ u32 intr_cfg_reg;
+ u32 intr_status_reg;
+ u32 intr_target_reg;
unsigned mux_bit:5;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] pinctrl: Qualcomm msm8916 pinctrl driver
Changes since v2: - addressed all Andy's comments --- Changes since v1: - correct the subject and description in 1/3 - not break the fields in msm8916_groups[] array in 3/3 - added Reviewed-by tags on all three patches --- This series adds a pinctrl driver for Snapdragon 410 (msm8916) SoC. The first patch increase the register address variable size, next adds a binding document and the last patch adds the pinctrl driver Comments are welcome! regards, Stan Joonwoo Park (2): pinctrl: qcom: increase variable size for register offsets pinctrl: qcom: Add msm8916 pinctrl driver Stanimir Varbanov (1): DT: pinctrl: Document Qualcomm MSM8916 pinctrl binding .../bindings/pinctrl/qcom,msm8916-pinctrl.txt | 186 drivers/pinctrl/qcom/Kconfig |8 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-msm.h | 10 +- drivers/pinctrl/qcom/pinctrl-msm8916.c | 1005 5 files changed, 1205 insertions(+), 5 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt create mode 100644 drivers/pinctrl/qcom/pinctrl-msm8916.c -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/3] DT: pinctrl: Document Qualcomm MSM8916 pinctrl binding
Adds devicetree binding documentation. Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com Reviewed-by: Bjorn Andersson bjorn.anders...@sonymobile.com --- .../bindings/pinctrl/qcom,msm8916-pinctrl.txt | 186 1 files changed, 186 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt new file mode 100644 index 000..498caff --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8916-pinctrl.txt @@ -0,0 +1,186 @@ +Qualcomm MSM8916 TLMM block + +This binding describes the Top Level Mode Multiplexer block found in the +MSM8916 platform. + +- compatible: + Usage: required + Value type: string + Definition: must be qcom,msm8916-pinctrl + +- reg: + Usage: required + Value type: prop-encoded-array + Definition: the base address and size of the TLMM register space. + +- interrupts: + Usage: required + Value type: prop-encoded-array + Definition: should specify the TLMM summary IRQ. + +- interrupt-controller: + Usage: required + Value type: none + Definition: identifies this node as an interrupt controller + +- #interrupt-cells: + Usage: required + Value type: u32 + Definition: must be 2. Specifying the pin number and flags, as defined + in dt-bindings/interrupt-controller/irq.h + +- gpio-controller: + Usage: required + Value type: none + Definition: identifies this node as a gpio controller + +- #gpio-cells: + Usage: required + Value type: u32 + Definition: must be 2. Specifying the pin number and flags, as defined + in dt-bindings/gpio/gpio.h + +Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for +a general description of GPIO and interrupt bindings. + +Please refer to pinctrl-bindings.txt in this directory for details of the +common pinctrl bindings used by client devices, including the meaning of the +phrase pin configuration node. + +The pin configuration nodes act as a container for an arbitrary number of +subnodes. Each of these subnodes represents some desired configuration for a +pin, a group, or a list of pins or groups. This configuration can include the +mux function to select on those pin(s)/group(s), and various pin configuration +parameters, such as pull-up, drive strength, etc. + + +PIN CONFIGURATION NODES: + +The name of each subnode is not important; all subnodes should be enumerated +and processed purely based on their content. + +Each subnode only affects those parameters that are explicitly listed. In +other words, a subnode that lists a mux function but no pin configuration +parameters implies no information about any pin configuration parameters. +Similarly, a pin subnode that describes a pullup parameter implies no +information about e.g. the mux function. + + +The following generic properties as defined in pinctrl-bindings.txt are valid +to specify in a pin configuration subnode: + +- pins: + Usage: required + Value type: string-array + Definition: List of gpio pins affected by the properties specified in + this subnode. Valid pins are: + gpio0-gpio121, + sdc1_clk, + sdc1_cmd, + sdc1_data + sdc2_clk, + sdc2_cmd, + sdc2_data, + qdsd_cmd, + qdsd_data0, + qdsd_data1, + qdsd_data2, + qdsd_data3 + +- function: + Usage: required + Value type: string + Definition: Specify the alternative function to be configured for the + specified pins. Functions are only valid for gpio pins. + Valid values are: + adsp_ext, alsp_int, atest_bbrx0, atest_bbrx1, atest_char, atest_char0, + atest_char1, atest_char2, atest_char3, atest_combodac, atest_gpsadc0, + atest_gpsadc1, atest_tsens, atest_wlan0, atest_wlan1, backlight_en, + bimc_dte0,bimc_dte1, blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4, + blsp_i2c5, blsp_i2c6, blsp_spi1, blsp_spi1_cs1, blsp_spi1_cs2, + blsp_spi1_cs3, blsp_spi2, blsp_spi2_cs1, blsp_spi2_cs2, blsp_spi2_cs3, + blsp_spi3, blsp_spi3_cs1, blsp_spi3_cs2, blsp_spi3_cs3, blsp_spi4, + blsp_spi5, blsp_spi6, blsp_uart1, blsp_uart2, blsp_uim1, blsp_uim2, + cam1_rst, cam1_standby, cam_mclk0, cam_mclk1, cci_async, cci_i2c, + cci_timer0, cci_timer1, cci_timer2, cdc_pdm0, codec_mad, dbg_out, + display_5v, dmic0_clk, dmic0_data, dsi_rst, ebi0_wrcdc, euro_us, + ext_lpass, flash_strobe, gcc_gp1_clk_a, gcc_gp1_clk_b, gcc_gp2_clk_a, + gcc_gp2_clk_b, gcc_gp3_clk_a, gcc_gp3_clk_b, gpio,
[PATCH v3 3/3] pinctrl: qcom: Add msm8916 pinctrl driver
From: Joonwoo Park joonw...@codeaurora.org
Add initial pinctrl driver to support pin configuration with
pinctrl framework for msm8916.
Signed-off-by: Joonwoo Park joonw...@codeaurora.org
Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com
Reviewed-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
drivers/pinctrl/qcom/Kconfig |8 +
drivers/pinctrl/qcom/Makefile |1 +
drivers/pinctrl/qcom/pinctrl-msm8916.c | 1005
3 files changed, 1014 insertions(+), 0 deletions(-)
create mode 100644 drivers/pinctrl/qcom/pinctrl-msm8916.c
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index 3cd243c..ea575f6 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -47,6 +47,14 @@ config PINCTRL_MSM8X74
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm 8974 platform.
+config PINCTRL_MSM8916
+ tristate Qualcomm 8916 pin controller driver
+ depends on GPIOLIB OF
+ select PINCTRL_MSM
+ help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm TLMM block found on the Qualcomm 8916 platform.
+
config PINCTRL_QCOM_SPMI_PMIC
tristate Qualcomm SPMI PMIC pin controller driver
depends on GPIOLIB OF SPMI
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index bfd79af..6895870 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -5,5 +5,6 @@ obj-$(CONFIG_PINCTRL_APQ8084) += pinctrl-apq8084.o
obj-$(CONFIG_PINCTRL_IPQ8064) += pinctrl-ipq8064.o
obj-$(CONFIG_PINCTRL_MSM8960) += pinctrl-msm8960.o
obj-$(CONFIG_PINCTRL_MSM8X74) += pinctrl-msm8x74.o
+obj-$(CONFIG_PINCTRL_MSM8916) += pinctrl-msm8916.o
obj-$(CONFIG_PINCTRL_QCOM_SPMI_PMIC) += pinctrl-spmi-gpio.o
obj-$(CONFIG_PINCTRL_QCOM_SPMI_PMIC) += pinctrl-spmi-mpp.o
diff --git a/drivers/pinctrl/qcom/pinctrl-msm8916.c
b/drivers/pinctrl/qcom/pinctrl-msm8916.c
new file mode 100644
index 000..20ebf24
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-msm8916.c
@@ -0,0 +1,1005 @@
+/*
+ * Copyright (c) 2015, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/pinctrl/pinctrl.h
+
+#include pinctrl-msm.h
+
+static const struct pinctrl_pin_desc msm8916_pins[] = {
+ PINCTRL_PIN(0, GPIO_0),
+ PINCTRL_PIN(1, GPIO_1),
+ PINCTRL_PIN(2, GPIO_2),
+ PINCTRL_PIN(3, GPIO_3),
+ PINCTRL_PIN(4, GPIO_4),
+ PINCTRL_PIN(5, GPIO_5),
+ PINCTRL_PIN(6, GPIO_6),
+ PINCTRL_PIN(7, GPIO_7),
+ PINCTRL_PIN(8, GPIO_8),
+ PINCTRL_PIN(9, GPIO_9),
+ PINCTRL_PIN(10, GPIO_10),
+ PINCTRL_PIN(11, GPIO_11),
+ PINCTRL_PIN(12, GPIO_12),
+ PINCTRL_PIN(13, GPIO_13),
+ PINCTRL_PIN(14, GPIO_14),
+ PINCTRL_PIN(15, GPIO_15),
+ PINCTRL_PIN(16, GPIO_16),
+ PINCTRL_PIN(17, GPIO_17),
+ PINCTRL_PIN(18, GPIO_18),
+ PINCTRL_PIN(19, GPIO_19),
+ PINCTRL_PIN(20, GPIO_20),
+ PINCTRL_PIN(21, GPIO_21),
+ PINCTRL_PIN(22, GPIO_22),
+ PINCTRL_PIN(23, GPIO_23),
+ PINCTRL_PIN(24, GPIO_24),
+ PINCTRL_PIN(25, GPIO_25),
+ PINCTRL_PIN(26, GPIO_26),
+ PINCTRL_PIN(27, GPIO_27),
+ PINCTRL_PIN(28, GPIO_28),
+ PINCTRL_PIN(29, GPIO_29),
+ PINCTRL_PIN(30, GPIO_30),
+ PINCTRL_PIN(31, GPIO_31),
+ PINCTRL_PIN(32, GPIO_32),
+ PINCTRL_PIN(33, GPIO_33),
+ PINCTRL_PIN(34, GPIO_34),
+ PINCTRL_PIN(35, GPIO_35),
+ PINCTRL_PIN(36, GPIO_36),
+ PINCTRL_PIN(37, GPIO_37),
+ PINCTRL_PIN(38, GPIO_38),
+ PINCTRL_PIN(39, GPIO_39),
+ PINCTRL_PIN(40, GPIO_40),
+ PINCTRL_PIN(41, GPIO_41),
+ PINCTRL_PIN(42, GPIO_42),
+ PINCTRL_PIN(43, GPIO_43),
+ PINCTRL_PIN(44, GPIO_44),
+ PINCTRL_PIN(45, GPIO_45),
+ PINCTRL_PIN(46, GPIO_46),
+ PINCTRL_PIN(47, GPIO_47),
+ PINCTRL_PIN(48, GPIO_48),
+ PINCTRL_PIN(49, GPIO_49),
+ PINCTRL_PIN(50, GPIO_50),
+ PINCTRL_PIN(51, GPIO_51),
+ PINCTRL_PIN(52, GPIO_52),
+ PINCTRL_PIN(53, GPIO_53),
+ PINCTRL_PIN(54, GPIO_54),
+ PINCTRL_PIN(55, GPIO_55),
+ PINCTRL_PIN(56, GPIO_56),
+ PINCTRL_PIN(57, GPIO_57),
+ PINCTRL_PIN(58, GPIO_58),
+ PINCTRL_PIN(59, GPIO_59),
+ PINCTRL_PIN(60, GPIO_60),
+ PINCTRL_PIN(61,
[PATCH v2 0/2] clk: qcom: gcc: Add support to child devices.
This patchset adds support to child devices whose memory registers fall insider gcc memory map. For example on APQ8064 whose thermal sensor registers are inside gcc memory range. Changes since v1: - Check return value of qcom_cc_probe spotted by Pramod. Thanks, srini Srinivas Kandagatla (2): clk: qcom: gcc-msm8960: add child devices support. clk: qcom: gcc bindings: Update to add child node support. Documentation/devicetree/bindings/clock/qcom,gcc.txt | 5 + drivers/clk/qcom/gcc-msm8960.c | 10 +- 2 files changed, 14 insertions(+), 1 deletion(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] clk: qcom: gcc-msm8960: add child devices support.
This patch adds support to add child devices to gcc as some of the
registers mapped by gcc are used by drivers like thermal sensors.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
drivers/clk/qcom/gcc-msm8960.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/gcc-msm8960.c b/drivers/clk/qcom/gcc-msm8960.c
index 0cd3e26..3ba77c5 100644
--- a/drivers/clk/qcom/gcc-msm8960.c
+++ b/drivers/clk/qcom/gcc-msm8960.c
@@ -15,6 +15,7 @@
#include linux/bitops.h
#include linux/err.h
#include linux/platform_device.h
+#include linux/of_platform.h
#include linux/module.h
#include linux/of.h
#include linux/of_device.h
@@ -3658,6 +3659,7 @@ static int gcc_msm8960_probe(struct platform_device *pdev)
struct clk *clk;
struct device *dev = pdev-dev;
const struct of_device_id *match;
+ int ret;
match = of_match_device(gcc_msm8960_match_table, pdev-dev);
if (!match)
@@ -3677,12 +3679,18 @@ static int gcc_msm8960_probe(struct platform_device
*pdev)
if (IS_ERR(clk))
return PTR_ERR(clk);
- return qcom_cc_probe(pdev, match-data);
+ ret = qcom_cc_probe(pdev, match-data);
+ if (ret)
+ return ret;
+
+ return of_platform_populate(pdev-dev.of_node, NULL, NULL, pdev-dev);
}
static int gcc_msm8960_remove(struct platform_device *pdev)
{
qcom_cc_remove(pdev);
+ of_platform_depopulate(pdev-dev);
+
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/3] irqchip: vf610-mscm-ir: add support for MSCM interrupt router
This adds support for Vybrid's interrupt router. On VF6xx models,
almost all peripherals can be used by either of the two CPU's,
the Cortex-A5 or the Cortex-M4. The interrupt router routes the
peripheral interrupts to the configured CPU.
This IRQ chip driver configures the interrupt router to route
the requested interrupt to the CPU the kernel is running on.
The driver makes use of the irqdomain hierarchy support. The
parent is given by the device tree. This should be one of the
two possible parents either ARM GIC or the ARM NVIC interrupt
controller. The latter is currently not yet supported.
Note that there is no resource control mechnism implemented to
avoid concurrent access of the same peripheral. The user needs
to make sure to use device trees which assign the peripherals
orthogonally. However, this driver warns the user in case the
interrupt is already configured for the other CPU. This provides
a poor man's resource controller.
Acked-by: Marc Zyngier marc.zyng...@arm.com
Signed-off-by: Stefan Agner ste...@agner.ch
---
arch/arm/mach-imx/Kconfig | 1 +
drivers/irqchip/Kconfig | 11 ++
drivers/irqchip/Makefile| 1 +
drivers/irqchip/irq-vf610-mscm-ir.c | 206
4 files changed, 219 insertions(+)
create mode 100644 drivers/irqchip/irq-vf610-mscm-ir.c
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index e8627e0..3c5859e 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -631,6 +631,7 @@ config SOC_IMX6SX
config SOC_VF610
bool Vybrid Family VF610 support
+ select VF610_MSCM
select ARM_GIC
select PINCTRL_VF610
select PL310_ERRATA_769419 if CACHE_L2X0
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index cc79d2a..9c13d81 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -136,6 +136,17 @@ config IRQ_CROSSBAR
a free irq and configures the IP. Thus the peripheral interrupts are
routed to one of the free irqchip interrupt lines.
+config VF610_MSCM_IR
+ bool
+ help
+ Support for MSCM interrupt router available on Vybrid SoC's. The
+ interrupt router is between the CPU's interrupt controller and the
+ peripheral. The router allows to route the peripheral interrupts to
+ one of the two available CPU's on Vybrid VF6xx SoC's (Cortex-A5 or
+ Cortex-M4). The router will be configured transparently on a IRQ
+ request.
+ select IRQ_DOMAIN_HIERARCHY
+
config KEYSTONE_IRQ
tristate Keystone 2 IRQ controller IP
depends on ARCH_KEYSTONE
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 9516a32..04595f5 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_TB10X_IRQC) += irq-tb10x.o
obj-$(CONFIG_XTENSA) += irq-xtensa-pic.o
obj-$(CONFIG_XTENSA_MX)+= irq-xtensa-mx.o
obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
+obj-$(CONFIG_VF610_MSCM_IR)+= irq-vf610-mscm-ir.o
obj-$(CONFIG_BCM7120_L2_IRQ) += irq-bcm7120-l2.o
obj-$(CONFIG_BRCMSTB_L2_IRQ) += irq-brcmstb-l2.o
obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
diff --git a/drivers/irqchip/irq-vf610-mscm-ir.c
b/drivers/irqchip/irq-vf610-mscm-ir.c
new file mode 100644
index 000..e5f0347
--- /dev/null
+++ b/drivers/irqchip/irq-vf610-mscm-ir.c
@@ -0,0 +1,206 @@
+/*
+ * Copyright (C) 2014-2015 Toradex AG
+ * Author: Stefan Agner ste...@agner.ch
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Interrupt controller driver for the MSCM Interrupt Router.
+ *
+ * o All peripheral interrupts of the Vybrid SoC can be routed to
+ * CPU 0, CPU 1 or both. The routing is useful for dual-core
+ * variants of Vybrid SoC such as VF6xx. This driver routes the
+ * requested interrupt to the CPU currently running on.
+ *
+ * o It is necessary to setup the interrupt route even on single-core
+ * variants of Vybrid.
+ */
+
+#include linux/cpu_pm.h
+#include linux/io.h
+#include linux/irq.h
+#include linux/irqdomain.h
+#include linux/mfd/syscon.h
+#include dt-bindings/interrupt-controller/arm-gic.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/slab.h
+#include linux/regmap.h
+
+#include irqchip.h
+
+#define MSCM_CPxNUM0x4
+
+#define MSCM_IRSPRC(n) (0x80 + 2 * (n))
+#define MSCM_IRSPRC_CPEN_MASK 0x3
+
+#define MSCM_IRSPRC_NUM112
+
+struct vf610_mscm_ir_chip_data {
+ void __iomem *mscm_ir_base;
+ u16 cpu_mask;
+ u16 saved_irsprc[MSCM_IRSPRC_NUM];
+};
+
+static struct vf610_mscm_ir_chip_data *mscm_ir_data;
+
+static inline void vf610_mscm_ir_save(struct vf610_mscm_ir_chip_data *data)
+{
+ int
Re: [PATCH v2 2/7] phy: miphy365x: Pass sysconfig register offsets via syscfg dt property.
Hi,
On Wednesday 07 January 2015 08:34 PM, Peter Griffin wrote:
Based on Arnds review comments here https://lkml.org/lkml/2014/11/13/161,
update the miphy365 phy driver to access sysconfig register offsets via
syscfg dt property.
This is because the reg property should not be mixing address spaces
like it does currently for miphy365. This change then also aligns us
to how other platforms such as keystone and bcm7445 pass there syscon
offsets via DT.
This patch breaks DT compatibility, but this platform is considered WIP,
and is only used by a few developers who are upstreaming support for it.
This change has been done as a single atomic commit to ensure it is
bisectable.
I'm dropping this from my tree since I didn't get Ack from
arch/arm/boot/dts/stih416.dtsi Maintainer.
Thanks
Kishon
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Reviewed-by: Arnd Bergmann a...@arndb.de
---
.../devicetree/bindings/phy/phy-miphy365x.txt | 15 +--
arch/arm/boot/dts/stih416.dtsi | 10
drivers/phy/phy-miphy365x.c| 29
--
3 files changed, 23 insertions(+), 31 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
index 42c8808..9802d5d 100644
--- a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -6,8 +6,10 @@ for SATA and PCIe.
Required properties (controller (parent) node):
- compatible: Should be st,miphy365x-phy
-- st,syscfg : Should be a phandle of the system configuration register
group
- which contain the SATA, PCIe mode setting bits
+- st,syscfg : Phandle / integer array property. Phandle of sysconfig
group
+ containing the miphy registers and integer array should
contain
+ an entry for each port sub-node, specifying the control
+ register offset inside the sysconfig group.
Required nodes : A sub-node is required for each channel the
controller
provides. Address range information including the usual
@@ -26,7 +28,6 @@ Required properties (port (child) node):
registers filled in reg:
- sata: For SATA devices
- pcie: For PCIe devices
- - syscfg: To specify the syscfg based config register
Optional properties (port (child) node):
- st,sata-gen : Generation of locally attached SATA IP.
Expected values
@@ -39,20 +40,20 @@ Example:
miphy365x_phy: miphy365x@fe382000 {
compatible = st,miphy365x-phy;
- st,syscfg = syscfg_rear;
+ st,syscfg = syscfg_rear 0x824 0x828;
#address-cells = 1;
#size-cells = 1;
ranges;
phy_port0: port@fe382000 {
- reg = 0xfe382000 0x100, 0xfe394000 0x100, 0x824
0x4;
- reg-names = sata, pcie, syscfg;
+ reg = 0xfe382000 0x100, 0xfe394000 0x100;
+ reg-names = sata, pcie;
#phy-cells = 1;
st,sata-gen = 3;
};
phy_port1: port@fe38a000 {
- reg = 0xfe38a000 0x100, 0xfe804000 0x100, 0x828
0x4;;
+ reg = 0xfe38a000 0x100, 0xfe804000 0x100;;
reg-names = sata, pcie, syscfg;
#phy-cells = 1;
st,pcie-tx-pol-inv;
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index fad9073..85afe01 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -283,21 +283,21 @@
miphy365x_phy: phy@fe382000 {
compatible = st,miphy365x-phy;
- st,syscfg = syscfg_rear;
+ st,syscfg = syscfg_rear 0x824 0x828;
#address-cells = 1;
#size-cells = 1;
ranges;
phy_port0: port@fe382000 {
#phy-cells = 1;
- reg = 0xfe382000 0x100, 0xfe394000 0x100,
0x824 0x4;
- reg-names = sata, pcie, syscfg;
+ reg = 0xfe382000 0x100, 0xfe394000 0x100;
+ reg-names = sata, pcie;
};
phy_port1: port@fe38a000 {
#phy-cells = 1;
- reg = 0xfe38a000 0x100, 0xfe804000 0x100,
0x828 0x4;
- reg-names = sata, pcie, syscfg;
+ reg = 0xfe38a000 0x100, 0xfe804000 0x100;
+
Re: [PATCH v6 5/8] iio: adc: fsl,imx25-gcq driver
Hi,
On Thu, Jan 29, 2015 at 08:00:49PM +0530, Varka Bhadram wrote:
Hi,
On Thursday 29 January 2015 07:39 PM, Markus Pargmann wrote:
This is a conversion queue driver for the mx25 SoC. It uses the central
ADC which is used by two seperate independent queues. This driver
prepares different conversion configurations for each possible input.
For a conversion it creates a conversionqueue of one item with the
correct configuration for the chosen channel. It then executes the queue
once and disables the conversion queue afterwards.
The reference voltages are configurable through devicetree subnodes,
depending on the connections of the ADC inputs.
Signed-off-by: Markus Pargmann m...@pengutronix.de
Signed-off-by: Denis Carikli de...@eukrea.com
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
drivers/iio/adc/Kconfig | 7 +
drivers/iio/adc/Makefile| 1 +
drivers/iio/adc/fsl-imx25-gcq.c | 361
include/dt-bindings/iio/adc/fsl-imx25-gcq.h | 18 ++
4 files changed, 387 insertions(+)
create mode 100644 drivers/iio/adc/fsl-imx25-gcq.c
create mode 100644 include/dt-bindings/iio/adc/fsl-imx25-gcq.h
(...)
+static int mx25_gcq_probe(struct platform_device *pdev)
+{
+struct iio_dev *indio_dev;
+struct mx25_gcq_priv *priv;
+struct mx25_tsadc *tsadc = dev_get_drvdata(pdev-dev.parent);
+struct device *dev = pdev-dev;
+struct resource *res;
+void __iomem *mem;
+int ret;
+
+indio_dev = devm_iio_device_alloc(pdev-dev, sizeof(*priv));
+if (!indio_dev)
+return -ENOMEM;
+
+priv = iio_priv(indio_dev);
+
+res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+mem = devm_ioremap_resource(dev, res);
+if (!mem)
+return -ENOMEM;
+
+priv-regs = devm_regmap_init_mmio(dev, mem, mx25_gcq_regconfig);
+if (IS_ERR(priv-regs)) {
+dev_err(dev, Failed to initialize regmap\n);
+return PTR_ERR(priv-regs);
+}
+
+init_completion(priv-completed);
+
+/* Optional external regulator */
+priv-ext_vref = devm_regulator_get(pdev-dev, vref);
+if (!IS_ERR_OR_NULL(priv-ext_vref)) {
+ret = regulator_enable(priv-ext_vref);
+if (ret)
+return ret;
+}
+
+ret = mx25_gcq_setup_cfgs(pdev, priv);
+if (ret)
+return ret;
+
+priv-clk = tsadc-clk;
+ret = clk_prepare_enable(priv-clk);
+if (ret) {
+dev_err(dev, Failed to enable clock\n);
+return ret;
+}
+
+priv-irq = platform_get_irq(pdev, 0);
+if (priv-irq = 0) {
+dev_err(dev, Failed to get IRQ\n);
+ret = priv-irq;
+goto err_clk_unprepare;
+}
+
+ret = request_irq(priv-irq, mx25_gcq_irq, 0, pdev-name, priv);
Use of devm_* API
It seems to be save to use it here, as the interrupt handler only uses
memory allocated for this driver and not the iio framework. So I will
probably change it to devm_*.
Thanks,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
Re: [RFC PATCH 1/1] PM / domains: Add support for virtual power domains
Hi Karol,
I guess this patch series is not complete and use case implementation
will be more helpful for clarity. Also I can think of another way in
which this complete implementation can be done with pd name as
something pd-virt. This pd can be handled differently inside the
platform specific exynos power off/on function.
Regards,
Amit D
On Thu, Jan 29, 2015 at 11:42 PM, Karol Wrona k.wr...@samsung.com wrote:
There are the power domains which are turned off or put to retention only
during
suspend or special processor states. In such case there is a need to register
some devices which belong to such domain that PM core could know the state of
such devices and decide which power mode should be chosen i.e. the domain can
not be put to retention if some devices are active. Virtual power domain has
empty power_on/off callbacks as there is no need to gate anything.
Signed-off-by: Karol Wrona k.wr...@samsung.com
---
drivers/base/power/Makefile |3 +-
drivers/base/power/pm_domains_virt.c | 54
++
2 files changed, 56 insertions(+), 1 deletion(-)
create mode 100644 drivers/base/power/pm_domains_virt.c
diff --git a/drivers/base/power/Makefile b/drivers/base/power/Makefile
index 1cb8544..360a0e2 100644
--- a/drivers/base/power/Makefile
+++ b/drivers/base/power/Makefile
@@ -2,7 +2,8 @@ obj-$(CONFIG_PM)+= sysfs.o generic_ops.o common.o
qos.o runtime.o
obj-$(CONFIG_PM_SLEEP) += main.o wakeup.o
obj-$(CONFIG_PM_TRACE_RTC) += trace.o
obj-$(CONFIG_PM_OPP) += opp.o
-obj-$(CONFIG_PM_GENERIC_DOMAINS) += domain.o domain_governor.o
+obj-$(CONFIG_PM_GENERIC_DOMAINS) += domain.o domain_governor.o \
+ pm_domains_virt.o
obj-$(CONFIG_HAVE_CLK) += clock_ops.o
ccflags-$(CONFIG_DEBUG_DRIVER) := -DDEBUG
diff --git a/drivers/base/power/pm_domains_virt.c
b/drivers/base/power/pm_domains_virt.c
new file mode 100644
index 000..bd4d6b6
--- /dev/null
+++ b/drivers/base/power/pm_domains_virt.c
@@ -0,0 +1,54 @@
+/*
+ * Copyright (C) 2015, Samsung Electronics Co. Ltd. All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/err.h
+#include linux/of.h
+#include linux/pm_domain.h
+#include linux/slab.h
+
+static int pd_power_off(struct generic_pm_domain *domain)
+{
+ return 0;
+}
+
+static int pd_power_on(struct generic_pm_domain *domain)
+{
+ return 0;
+}
+
+int __init virt_pm_domains_init(void)
+{
+ struct device_node *np;
+
+ for_each_compatible_node(np, NULL, linux,virtual-pm-domains) {
+ struct generic_pm_domain *pd;
+
+ pd = kzalloc(sizeof(*pd), GFP_KERNEL);
+ if (!pd)
+ return -ENOMEM;
+
+ pd-power_off = pd_power_off;
+ pd-power_on = pd_power_on;
+ pd-name = kstrdup(np-name, GFP_KERNEL);
+ if (!pd-name)
+ return -ENOMEM;
+
+ pm_genpd_init(pd, NULL, false);
+ of_genpd_add_provider_simple(np, pd);
+ }
+
+ return 0;
+}
+arch_initcall(virt_pm_domains_init);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-pm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Reading /sys with side effects (was Re: [PATCH 1/2] Documentation: leds: Add description of LED Flash class extension)
Hi Pavel, On 01/29/2015 10:14 PM, Pavel Machek wrote: Hi! + - flash_fault - list of flash faults that may have occurred: + * led-over-voltage - flash controller voltage to the flash LED + has exceededthe limit specific to the flash controller + * flash-timeout-exceeded - the flash strobe was still on when + the timeout set by the user has expired; not all flash + controllers may set this in all such conditions + * controller-over-temperature - the flash controller has + overheated + * controller-short-circuit - the short circuit protection + of the flash controller has been triggered + * led-power-supply-over-current - current in the LED power + supply has exceeded the limit specific to the flash + controller + * indicator-led-fault - the flash controller has detected + a short or open circuit condition on the indicator LED + * led-under-voltage - flash controller voltage to the flash + LED has been below the minimum limit specific to + the flash + * controller-under-voltage - the input voltage of the flash + controller is below the limit under which strobing the + flash at full current will not be possible. The condition + persists until this flag is no longer set + * led-over-temperature - the temperature of the LED has exceeded + its allowed upper limit + + Flash faults are cleared, if possible, by reading the attribute. That's bad. Now you can no longer present flash_fault file as readable to non-root users, and grep -ri foo /sys will interfere with your camera application. Bad interface, just fix it. In my opinion it isn't crucial for the user to be aware of the fact that some non-persistent fault happened right after strobing the flash (e.g. over temperature). I cannot see anything harmful in the situation when someone does grep on /sys and clears non-persistent fault on a flash LED device. So why export the faults at all? Faults may prevent strobing the flash in case of some devices. The example of such a device is ADP1663 (drivers/media/i2c/adp1653.c). This driver reads the faults before strobing the flash and if a fault preventing strobing has occurred it returns -EBUSY. If this driver was made a LED Flash class driver, then it would expose flash_faults attribute. The driver would probably need redesigning - checking the faults before strobing would have to be avoided and it should be left to the userspace. I mean... another user can just read the file in loop, and the camera application will not get any useful information. If the fault is no longer valid at the time of access from camera application, then why it should be reported then? Also, not all devices may be able to report the faults that happened earlier but are not valid at the time of I2C readout. In that case the user will never now that the fault has ever occurred, unless they read the flash_fault attribute at the proper moment. In this case we cannot enforce consistent policy for all devices. Too bad. But lets do a good job at least for devices where we can do a good job, ok? Please describe the use case when clearing the fault on read can be harmful, if you have any. while true; grep -ri foo /sys; done And no, your application trying to read the faults will very probably read nothing. And this is OK. If a non-persistent fault was read by grep, then it will not be reported anymore. If someone wanted to maintain the history of flash faults for a device, then they are free to do it on their own by periodically reading the attribute, however I don't think it would be practical during every day use. -- Best Regards, Jacek Anaszewski -- To unsubscribe from this list: send the line unsubscribe devicetree 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/7] phy: miphy365x: Pass sysconfig register offsets via syscfg dt property.
Hi Kishon,
On 01/30/2015 11:35 AM, Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 07 January 2015 08:34 PM, Peter Griffin wrote:
Based on Arnds review comments here https://lkml.org/lkml/2014/11/13/161,
update the miphy365 phy driver to access sysconfig register offsets via
syscfg dt property.
This is because the reg property should not be mixing address spaces
like it does currently for miphy365. This change then also aligns us
to how other platforms such as keystone and bcm7445 pass there syscon
offsets via DT.
This patch breaks DT compatibility, but this platform is considered WIP,
and is only used by a few developers who are upstreaming support for it.
This change has been done as a single atomic commit to ensure it is
bisectable.
I'm dropping this from my tree since I didn't get Ack from
arch/arm/boot/dts/stih416.dtsi Maintainer.
Sorry, on cover letter, I replied the series looked good to me.
So you can add:
Acked-by: Maxime Coquelin maxime.coque...@st.com
And even:
Tested-by: Maxime Coquelin maxime.coque...@st.com
Kind regards,
Maxime
Thanks
Kishon
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Reviewed-by: Arnd Bergmann a...@arndb.de
---
.../devicetree/bindings/phy/phy-miphy365x.txt | 15 +--
arch/arm/boot/dts/stih416.dtsi | 10
drivers/phy/phy-miphy365x.c| 29 --
3 files changed, 23 insertions(+), 31 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
index 42c8808..9802d5d 100644
--- a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -6,8 +6,10 @@ for SATA and PCIe.
Required properties (controller (parent) node):
- compatible: Should be st,miphy365x-phy
-- st,syscfg : Should be a phandle of the system configuration register
group
- which contain the SATA, PCIe mode setting bits
+- st,syscfg : Phandle / integer array property. Phandle of sysconfig group
+ containing the miphy registers and integer array should
contain
+ an entry for each port sub-node, specifying the control
+ register offset inside the sysconfig group.
Required nodes : A sub-node is required for each channel the controller
provides. Address range information including the usual
@@ -26,7 +28,6 @@ Required properties (port (child) node):
registers filled in reg:
- sata: For SATA devices
- pcie: For PCIe devices
- - syscfg: To specify the syscfg based config register
Optional properties (port (child) node):
- st,sata-gen : Generation of locally attached SATA IP. Expected values
@@ -39,20 +40,20 @@ Example:
miphy365x_phy: miphy365x@fe382000 {
compatible = st,miphy365x-phy;
- st,syscfg = syscfg_rear;
+ st,syscfg = syscfg_rear 0x824 0x828;
#address-cells = 1;
#size-cells = 1;
ranges;
phy_port0: port@fe382000 {
- reg = 0xfe382000 0x100, 0xfe394000 0x100, 0x824
0x4;
- reg-names = sata, pcie, syscfg;
+ reg = 0xfe382000 0x100, 0xfe394000 0x100;
+ reg-names = sata, pcie;
#phy-cells = 1;
st,sata-gen = 3;
};
phy_port1: port@fe38a000 {
- reg = 0xfe38a000 0x100, 0xfe804000 0x100, 0x828
0x4;;
+ reg = 0xfe38a000 0x100, 0xfe804000 0x100;;
reg-names = sata, pcie, syscfg;
#phy-cells = 1;
st,pcie-tx-pol-inv;
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index fad9073..85afe01 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -283,21 +283,21 @@
miphy365x_phy: phy@fe382000 {
compatible = st,miphy365x-phy;
- st,syscfg = syscfg_rear;
+ st,syscfg = syscfg_rear 0x824 0x828;
#address-cells = 1;
#size-cells = 1;
ranges;
phy_port0: port@fe382000 {
#phy-cells = 1;
- reg = 0xfe382000 0x100, 0xfe394000 0x100,
0x824 0x4;
- reg-names = sata, pcie, syscfg;
+ reg = 0xfe382000 0x100, 0xfe394000 0x100;
+ reg-names = sata, pcie;
};
phy_port1: port@fe38a000 {
#phy-cells = 1;
- reg = 0xfe38a000 0x100,
Re: [PATCH v2 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
On 29/01/15 18:56, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [150129 03:34]: On 28/01/15 19:09, Tony Lindgren wrote: * Roger Quadros rog...@ti.com [150128 04:15]: On 28/01/15 04:19, Chanwoo Choi wrote: I still fail to understand that we need to call disable_irq() in .suspend() and enable_irq() in .resume() can you point me to any other drivers doing so? You can refer the suspend function in drivers/mfd/max14577.c or drivers/mfd/max77693.c. The max14577_suspend() includes the detailed comment for why using disable_irq() in suspend function. In max14577 case, max14577_suspend() use disable_irq() function because of i2c dependency. If max14577 device is wake-up from suspend state before completing the resume sequence of i2c, max14577 may fail to read/write i2c communication. Thanks for this information. I will add disable/enable_irq() in suspend/resume(). Are the .dts changes safe for me to apply already? Yes Tony, you can pick them. Thanks. OK will apply the dts changes into omap-for-v3.20/dt thanks. I have also the defconfig changes tagged, will apply those a bit later probably as a fix after the driver is merged. Sounds good to me. Thanks Tony. cheers, -roger -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/2] Imagination Technologies PWM support
+linux-mips
On Fri, Jan 30, 2015 at 10:26 AM, Thierry Reding
thierry.red...@gmail.com wrote:
On Fri, Jan 30, 2015 at 09:50:46AM +, Andrew Bresticker wrote:
Also you're making it especially difficult to build-test by not
providing even the basic bits of your SoC support first. All even
linux-next seems to have for the Pistachio SoC is the addition of a
compatible string to the dw-mmc driver.
I'll take the PWM driver, but I'll assume that you'll eventually have
more pieces available, in which case I'd appreciate a note so I can
update my build scripts.
FYI, I'm hoping to post Pistachio platform support for 3.21.
That'd be great. I can switch over to a proper defconfig then and not
jump through extra hoops to build test patches.
Also, I'm seeing a bunch of weird errors from building MIPS, mostly
things like this:
CC net/ipv4/netfilter/arp_tables.mod.o
{standard input}: Assembler messages:
{standard input}: Warning: .gnu_attribute 4,3 requires `softfloat'
or this later on:
mips-linux-gnu-ld: Warning: vmlinuz uses -mhard-float (set by
arch/mips/boot/compressed/head.o), arch/mips/boot/compressed/decompress.o
uses -msoft-float
This is essentially a gpr_defconfig (because it select MIPS_ALCHEMY,
which in turns pulls in COMMON_CLK that PWM_IMG depends on) and then
enabling MFD_SYSCON on top so that all dependencies are met.
What am I doing wrong?
What version of binutils are you using? I believe the latter error
should be fixed by commit 842dfc11ea9a (MIPS: Fix build with binutils
2.24.51+), but perhaps the decompressor Makefile requires a fix as
well? Unfortunately I'm traveling for the next couple of days, but I
may be able to take a look at it on Monday.
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] Add multiple GPIO and external clock to MMC pwrseq_simple
On 29 January 2015 at 16:00, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Hello Ulf, Many WLAN chips attached to an SDIO interface needs more than one GPIO for their reset sequence and also an external clock to be operational. Since this is very common, this series extend the simple MMC power sequence to support more than one reset GPIO and also an optional external clock. This is the third version of the series that addressed issues pointed out in the previous versions. The series depend on v4 mmc: core: Add support for MMC power sequences: http://comments.gmane.org/gmane.linux.kernel.mmc/30665 Javier Martinez Canillas (6): mmc: pwrseq: Document that simple sequence support more than one GPIO mmc: pwrseq_simple: Extend to support more pins mmc: pwrseq: Document optional clock for the simple power sequence mmc: pwrseq_simple: Add optional reference clock support ARM: dts: exynos5250-snow: Enable wifi power-on ARM: dts: exynos5250-snow: Add cap-sdio-irq to wifi mmc node .../devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 11 ++- arch/arm/boot/dts/exynos5250-snow.dts | 26 ++- drivers/mmc/core/pwrseq_simple.c | 89 ++ 3 files changed, 107 insertions(+), 19 deletions(-) Patch #1 extends the simple MMC power sequence DT binding to support more than one GPIO and patch #2 adds the actual implementation. In the same way, patch #3 and #4 extend the simple MMC power sequence DT binding and pwrseq_simple driver to support an optional external clock. Finally as an example, patch #5 and patch #6 adds support for the wifi chip in the Exynos5250 Snow that needs all these resources. These two patches were added to the series only for completeness and should be picked by Kukjin through his linux-samsung tree. Best regards, Javier Thanks Javier! I have applied patch 1 - 4 for my next branch. I made some minor fix to patch4, I send a separate response to that patch so you know. Kind regards Uffe -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/6] mmc: pwrseq_simple: Add optional reference clock support
On 29 January 2015 at 16:00, Javier Martinez Canillas
javier.marti...@collabora.co.uk wrote:
Some WLAN chips attached to a SDIO interface, need a reference clock.
Since this is very common, extend the prseq_simple driver to support
an optional clock that is enabled prior the card power up procedure.
Note: the external clock is optional. Thus an error is not returned
if the clock is not found.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v2:
- Add a clk_enabled bool to struct mmc_pwrseq_simple to track clock
gate/ungate since .power_off can be called prior to .pre_power_on.
Suggested by Ulf Hansson.
- clk_get() does not return -ENOSYS so don't check for that.
Suggested by Ulf Hansson.
Changes since v1:
- Rebase on top of latest changes.
- Use IS_ERR() instead of checking for NULL to see if the clock exists.
---
drivers/mmc/core/pwrseq_simple.c | 38 --
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/pwrseq_simple.c
b/drivers/mmc/core/pwrseq_simple.c
index e53d3c7e059c..50d09d920430 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -7,6 +7,7 @@
*
* Simple MMC power sequence management
*/
+#include linux/clk.h
#include linux/kernel.h
#include linux/slab.h
#include linux/device.h
@@ -20,6 +21,8 @@
struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
+ bool clk_enabled;
+ struct clk *ext_clk;
int nr_gpios;
struct gpio_desc *reset_gpios[0];
};
@@ -39,6 +42,11 @@ static void mmc_pwrseq_simple_pre_power_on(struct mmc_host
*host)
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+ if (!IS_ERR(pwrseq-ext_clk)) {
This should be:
if (!IS_ERR(pwrseq-ext_clk) !pwrseq-clk_enabled) {
+ clk_prepare_enable(pwrseq-ext_clk);
+ pwrseq-clk_enabled = true;
+ }
+
mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
}
@@ -50,6 +58,19 @@ static void mmc_pwrseq_simple_post_power_on(struct
mmc_host *host)
mmc_pwrseq_simple_set_gpios_value(pwrseq, 0);
}
+static void mmc_pwrseq_simple_power_off(struct mmc_host *host)
+{
+ struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
+ struct mmc_pwrseq_simple, pwrseq);
+
+ mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
+
+ if (pwrseq-clk_enabled) {
I changed this as well, but that was just to make code clearer.
if (!IS_ERR(pwrseq-ext_clk) pwrseq-clk_enabled) {
+ clk_disable_unprepare(pwrseq-ext_clk);
+ pwrseq-clk_enabled = false;
+ }
+}
+
static void mmc_pwrseq_simple_free(struct mmc_host *host)
{
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
@@ -60,6 +81,9 @@ static void mmc_pwrseq_simple_free(struct mmc_host *host)
if (!IS_ERR(pwrseq-reset_gpios[i]))
gpiod_put(pwrseq-reset_gpios[i]);
+ if (!IS_ERR(pwrseq-ext_clk))
+ clk_put(pwrseq-ext_clk);
+
kfree(pwrseq);
host-pwrseq = NULL;
}
@@ -67,7 +91,7 @@ static void mmc_pwrseq_simple_free(struct mmc_host *host)
static struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
.pre_power_on = mmc_pwrseq_simple_pre_power_on,
.post_power_on = mmc_pwrseq_simple_post_power_on,
- .power_off = mmc_pwrseq_simple_pre_power_on,
+ .power_off = mmc_pwrseq_simple_power_off,
.free = mmc_pwrseq_simple_free,
};
@@ -85,6 +109,13 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct
device *dev)
if (!pwrseq)
return -ENOMEM;
+ pwrseq-ext_clk = clk_get(dev, ext_clock);
+ if (IS_ERR(pwrseq-ext_clk)
+ PTR_ERR(pwrseq-ext_clk) != -ENOENT) {
+ ret = PTR_ERR(pwrseq-ext_clk);
+ goto free;
+ }
+
for (i = 0; i nr_gpios; i++) {
pwrseq-reset_gpios[i] = gpiod_get_index(dev, reset, i,
GPIOD_OUT_HIGH);
@@ -96,7 +127,7 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct
device *dev)
while (--i)
gpiod_put(pwrseq-reset_gpios[i]);
- goto free;
+ goto clk_put;
}
}
@@ -105,6 +136,9 @@ int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct
device *dev)
host-pwrseq = pwrseq-pwrseq;
return 0;
+clk_put:
+ if (!IS_ERR(pwrseq-ext_clk))
+ clk_put(pwrseq-ext_clk);
free:
kfree(pwrseq);
return ret;
--
2.1.3
As I stated in the response to he coverletter for the patchset, this
patch is applied for next with above changes.
Re: [PATCH v8 0/2] Imagination Technologies PWM support
On Fri, Jan 30, 2015 at 11:08:46AM +, Andrew Bresticker wrote:
+linux-mips
On Fri, Jan 30, 2015 at 10:26 AM, Thierry Reding
thierry.red...@gmail.com wrote:
On Fri, Jan 30, 2015 at 09:50:46AM +, Andrew Bresticker wrote:
Also you're making it especially difficult to build-test by not
providing even the basic bits of your SoC support first. All even
linux-next seems to have for the Pistachio SoC is the addition of a
compatible string to the dw-mmc driver.
I'll take the PWM driver, but I'll assume that you'll eventually have
more pieces available, in which case I'd appreciate a note so I can
update my build scripts.
FYI, I'm hoping to post Pistachio platform support for 3.21.
That'd be great. I can switch over to a proper defconfig then and not
jump through extra hoops to build test patches.
Also, I'm seeing a bunch of weird errors from building MIPS, mostly
things like this:
CC net/ipv4/netfilter/arp_tables.mod.o
{standard input}: Assembler messages:
{standard input}: Warning: .gnu_attribute 4,3 requires `softfloat'
or this later on:
mips-linux-gnu-ld: Warning: vmlinuz uses -mhard-float (set by
arch/mips/boot/compressed/head.o), arch/mips/boot/compressed/decompress.o
uses -msoft-float
This is essentially a gpr_defconfig (because it select MIPS_ALCHEMY,
which in turns pulls in COMMON_CLK that PWM_IMG depends on) and then
enabling MFD_SYSCON on top so that all dependencies are met.
What am I doing wrong?
What version of binutils are you using? I believe the latter error
should be fixed by commit 842dfc11ea9a (MIPS: Fix build with binutils
2.24.51+), but perhaps the decompressor Makefile requires a fix as
well? Unfortunately I'm traveling for the next couple of days, but I
may be able to take a look at it on Monday.
I use binutils 2.25, and indeed building the correct branch gets rid of
those errors. Sorry for the noise.
Thierry
pgpxW9W4ugnmv.pgp
Description: PGP signature
Re: [PATCH v2 2/7] phy: miphy365x: Pass sysconfig register offsets via syscfg dt property.
On 01/30/2015 12:08 PM, Kishon Vijay Abraham I wrote:
Hi,
On Friday 30 January 2015 04:18 PM, Maxime Coquelin wrote:
Hi Kishon,
On 01/30/2015 11:35 AM, Kishon Vijay Abraham I wrote:
Hi,
On Wednesday 07 January 2015 08:34 PM, Peter Griffin wrote:
Based on Arnds review comments here https://lkml.org/lkml/2014/11/13/161,
update the miphy365 phy driver to access sysconfig register offsets via
syscfg dt property.
This is because the reg property should not be mixing address spaces
like it does currently for miphy365. This change then also aligns us
to how other platforms such as keystone and bcm7445 pass there syscon
offsets via DT.
This patch breaks DT compatibility, but this platform is considered WIP,
and is only used by a few developers who are upstreaming support for it.
This change has been done as a single atomic commit to ensure it is
bisectable.
I'm dropping this from my tree since I didn't get Ack from
arch/arm/boot/dts/stih416.dtsi Maintainer.
Sorry, on cover letter, I replied the series looked good to me.
So you can add:
Acked-by: Maxime Coquelin maxime.coque...@st.com
And even:
Tested-by: Maxime Coquelin maxime.coque...@st.com
Thanks. I'll merge them now.
I'd assume there won't be any conflicts when it gets merged to linus tree.
Thanks Kishon,
I have merged this patch with the last DT pull-request I sent for v3.20,
and didn't had any conflicts.
So I'm confident there won't be any issue.
Br,
Maxime
Cheers
Kishon
Kind regards,
Maxime
Thanks
Kishon
Signed-off-by: Peter Griffin peter.grif...@linaro.org
Reviewed-by: Arnd Bergmann a...@arndb.de
---
.../devicetree/bindings/phy/phy-miphy365x.txt | 15 +--
arch/arm/boot/dts/stih416.dtsi | 10
drivers/phy/phy-miphy365x.c| 29
--
3 files changed, 23 insertions(+), 31 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
index 42c8808..9802d5d 100644
--- a/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
+++ b/Documentation/devicetree/bindings/phy/phy-miphy365x.txt
@@ -6,8 +6,10 @@ for SATA and PCIe.
Required properties (controller (parent) node):
- compatible: Should be st,miphy365x-phy
-- st,syscfg : Should be a phandle of the system configuration register
group
- which contain the SATA, PCIe mode setting bits
+- st,syscfg : Phandle / integer array property. Phandle of sysconfig group
+ containing the miphy registers and integer array should contain
+ an entry for each port sub-node, specifying the control
+ register offset inside the sysconfig group.
Required nodes: A sub-node is required for each channel the controller
provides. Address range information including the usual
@@ -26,7 +28,6 @@ Required properties (port (child) node):
registers filled in reg:
- sata: For SATA devices
- pcie: For PCIe devices
-- syscfg: To specify the syscfg based config register
Optional properties (port (child) node):
- st,sata-gen :Generation of locally attached SATA IP.
Expected values
@@ -39,20 +40,20 @@ Example:
miphy365x_phy: miphy365x@fe382000 {
compatible = st,miphy365x-phy;
-st,syscfg = syscfg_rear;
+st,syscfg = syscfg_rear 0x824 0x828;
#address-cells= 1;
#size-cells= 1;
ranges;
phy_port0: port@fe382000 {
-reg = 0xfe382000 0x100, 0xfe394000 0x100, 0x824 0x4;
-reg-names = sata, pcie, syscfg;
+reg = 0xfe382000 0x100, 0xfe394000 0x100;
+reg-names = sata, pcie;
#phy-cells = 1;
st,sata-gen = 3;
};
phy_port1: port@fe38a000 {
-reg = 0xfe38a000 0x100, 0xfe804000 0x100, 0x828 0x4;;
+reg = 0xfe38a000 0x100, 0xfe804000 0x100;;
reg-names = sata, pcie, syscfg;
#phy-cells = 1;
st,pcie-tx-pol-inv;
diff --git a/arch/arm/boot/dts/stih416.dtsi b/arch/arm/boot/dts/stih416.dtsi
index fad9073..85afe01 100644
--- a/arch/arm/boot/dts/stih416.dtsi
+++ b/arch/arm/boot/dts/stih416.dtsi
@@ -283,21 +283,21 @@
miphy365x_phy: phy@fe382000 {
compatible = st,miphy365x-phy;
-st,syscfg = syscfg_rear;
+st,syscfg= syscfg_rear 0x824 0x828;
#address-cells= 1;
#size-cells= 1;
ranges;
phy_port0: port@fe382000 {
#phy-cells = 1;
-reg = 0xfe382000 0x100, 0xfe394000 0x100, 0x824 0x4;
-reg-names = sata, pcie, syscfg;
+reg = 0xfe382000 0x100, 0xfe394000 0x100;
+reg-names = sata, pcie;
};
phy_port1: port@fe38a000 {
Re: [PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board
On 30.01.2015 12:41, Jean-Francois Moine wrote: On Fri, 30 Jan 2015 12:00:16 +0100 Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote: Adapting the .config and removing drivers is actually not an option. IMHO, introducing DT was meant for a single multi-arch kernel that can be shipped with common Linux distros. Therefore, DT is the place you enable/disable available resources. You leave most of the SoC (and SoM) nodes disabled as long as you cannot tell if there is a corresponding connector available. Well, I don't know too much about the hardware, and less about the hardware modules (SoM?). Sorry, SoM is for System-on-Module, i.e. the CM-A510 itself. You can see from the block diagram that it comprises the Dove SoC, power circuitry, touch-screen controller, WiFi, GbE PHY for GbE-0, GbE controller on PCIe for GbE-1, I2S audio codec, RS232 Level Shifter for UART0, an USB2 Hub, SPI flash, NAND and RAM. That basically is what will be represented in the som.dtsi. If any of the functions above and the SoC will be _accessible_ on the baseboard is another story. As seen in the Compulab documents, there are a lot of hardware modules. For the DT, do you mean that there would be as many .dts's as the whole number of connection possibilities? Nope. One dove.dtsi, one dove-cm-a510.dtsi, and one baseboard.dts including dove-cm-a510.dtsi for every baseboard we stumble upon. I'd have better seen the inverted case as the actual empty cm-board dts: enable every option in the (generic) .dts and let the vendor/user create a specific .dts from this one for the board according to the installed modules. That what dtsi's are made for with one exception: the dtsi cannot run on its own but needs at least one baseboard.dts that includes it. We could create a bare-baseboard that represents what is (easily) accessible on the SoM itself. Given the fact that even UART0 needs a baseboard that grabs it from the SoM connector, I see no value in that. In any case, any real cm-a510 board should work with the generic/full .dts even if some hardware modules are lacking. No? Nope. The cm-a510 is just an add-on for a baseboard, it does not make a working board. Just think of it as a feature-improved SoC. Sebastian -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board
On 30.01.2015 13:39, Jean-Francois Moine wrote: On Fri, 30 Jan 2015 13:03:59 +0100 Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote: Nope. The cm-a510 is just an add-on for a baseboard, it does not make a working board. Just think of it as a feature-improved SoC. Well, I understand a bit, but I don't see clearly the physical system, nor how each part gets its configuration for booting. TBH, I completely missed that the cm-a510 can come in different configurations, e.g. with or without WiFi. Nevertheless, considering that there are only a handful of configurations available, IMHO the right thing would be a dtsi with all possible options described by corresponding but disabled nodes. The actual physical system has to be determined at runtime in any way and it should be done by the bootloader. However, even the bootloader would be happy to find the right nodes to enable instead of creating them from scratch. As you know better than I, it seems that you are the right person to create the .dtsi/.dts's :) and to explain Gabriel how to use them! Well, nothing that should stop you from improving your skills :) I'd be happy to take over, but I admit that my current lack of spare time would only allow me to support Gabriel and you. Let's wait for Gabriel's response on how he can help improving Dove mainline with his cm-a510 and baseboard. Sebastian -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/6] mmc: pwrseq_simple: Add optional reference clock support
Hello Ulf,
On 01/30/2015 12:17 PM, Ulf Hansson wrote:
};
@@ -39,6 +42,11 @@ static void mmc_pwrseq_simple_pre_power_on(struct
mmc_host *host)
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+ if (!IS_ERR(pwrseq-ext_clk)) {
This should be:
if (!IS_ERR(pwrseq-ext_clk) !pwrseq-clk_enabled) {
Oh, I thought that it was not possible to enter mmc_pwrseq_pre_power_on()
twice without a prior call to mmc_pwrseq_power_off() but I guess I didn't
read the MMC core code carefully...
+ clk_prepare_enable(pwrseq-ext_clk);
+ pwrseq-clk_enabled = true;
+ }
+
mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
}
@@ -50,6 +58,19 @@ static void mmc_pwrseq_simple_post_power_on(struct
mmc_host *host)
mmc_pwrseq_simple_set_gpios_value(pwrseq, 0);
}
+static void mmc_pwrseq_simple_power_off(struct mmc_host *host)
+{
+ struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
+ struct mmc_pwrseq_simple, pwrseq);
+
+ mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
+
+ if (pwrseq-clk_enabled) {
I changed this as well, but that was just to make code clearer.
if (!IS_ERR(pwrseq-ext_clk) pwrseq-clk_enabled) {
Yeah, if IS_ERR(pwrseq-ext_clk) then clk_enabled will always be false but I
agree that the change makes the code to be more consistent.
As I stated in the response to he coverletter for the patchset, this
patch is applied for next with above changes.
Thanks!
Thanks a lot for your help and for fixing these things!
Kind regards
Uffe
Best regards,
Javier
--
To unsubscribe from this list: send the line unsubscribe devicetree in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/6] Add multiple GPIO and external clock to MMC pwrseq_simple
Hello Ulf, On 01/30/2015 12:13 PM, Ulf Hansson wrote: Patch #1 extends the simple MMC power sequence DT binding to support more than one GPIO and patch #2 adds the actual implementation. In the same way, patch #3 and #4 extend the simple MMC power sequence DT binding and pwrseq_simple driver to support an optional external clock. Finally as an example, patch #5 and patch #6 adds support for the wifi chip in the Exynos5250 Snow that needs all these resources. These two patches were added to the series only for completeness and should be picked by Kukjin through his linux-samsung tree. Best regards, Javier Thanks Javier! I have applied patch 1 - 4 for my next branch. I made some minor fix to patch4, I send a separate response to that patch so you know. Great, thanks a lot! Kukjin, Could you please pick patches #5 and #6 then now that Ulf picked the others? Kind regards Uffe Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe devicetree 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 1/4] gpio: use sizeof() instead of hardcoded values
On Wed, Jan 21, 2015 at 10:33 PM, Olliver Schinagl o.schin...@ultimaker.com wrote: From: Olliver Schinagl oli...@schinagl.nl gpiolib uses a fixed string for the suffixes and defines it at 32 bytes. Later in the code snprintf is used with this fixed value of 32. Using sizeof() is safer in case the size for the suffixes is ever changed. Signed-off-by: Olliver Schinagl oli...@schinagl.nl OK looks nice. Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe devicetree 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/4] gpio: add parameter to allow the use named gpios
On Wed, Jan 21, 2015 at 10:33 PM, Olliver Schinagl o.schin...@ultimaker.com wrote: From: Olliver Schinagl oli...@schinagl.nl The gpio binding document says that new code should always use named gpios. Patch 40b73183 added support to parse a list of gpios from child nodes, but does not make it possible to use named gpios. This patch adds the con_id property and implements it is done in gpiolib.c, where the old-style of using unnamed gpios still works. Signed-off-by: Olliver Schinagl oli...@schinagl.nl --- drivers/gpio/devres.c | 18 +- drivers/input/keyboard/gpio_keys_polled.c | 2 +- drivers/leds/leds-gpio.c | 2 +- include/linux/gpio/consumer.h | 1 + Alexandre: does this match your vision of how it should work, i.e. ACK? Bryan/Dmitry: can you ACK the oneliners in your subsystems? Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: mvebu: add ethernet to the cm-a510 board
[Re-adding the most obvious People to Cc] On 30.01.2015 13:44, David Goodenough wrote: On Friday 30 January 2015 13:03:59 Sebastian Hesselbarth wrote: On 30.01.2015 12:41, Jean-Francois Moine wrote: On Fri, 30 Jan 2015 12:00:16 +0100 Sebastian Hesselbarth sebastian.hesselba...@gmail.com wrote: That what dtsi's are made for with one exception: the dtsi cannot run on its own but needs at least one baseboard.dts that includes it. We could create a bare-baseboard that represents what is (easily) accessible on the SoM itself. Given the fact that even UART0 needs a baseboard that grabs it from the SoM connector, I see no value in that. In any case, any real cm-a510 board should work with the generic/full .dts even if some hardware modules are lacking. No? Nope. The cm-a510 is just an add-on for a baseboard, it does not make a working board. Just think of it as a feature-improved SoC. This sounds like capes on the BeagleBoard. Are these extension boards self-identifying? If so then the approach used with the capes might work here too. David, IMHO capes are a different thing. The BB can run just fine without any cape installed, the cm-a510 cannot run without a baseboard. Also, once you have your SoM installed it cannot change over runtime, there is no need for any dynamic overlays and such. You can build some 5 or 10 different configurations given the SoM and a specific baseboard but not hundreds of possible combinations. Besides, Gabriel is the first in almost 2 years that actually has an cm-a510 - so, I doubt we'll have to mainline dozens of baseboards using the cm-a510 in the near future. Regarding the self-identification, it would be great if the actual SoM configuration would be stored in the (always available) SPI flash, but from my experience with the boards I have seen so far, I have a bad feeling about it ;) A quick look at the sb-a510 (the compulab baseboard for cm-a510) suggests that there is more configuration available but by jumpers that (hopefully) can be read out by GPIOs at least. The best similar board available in mainline I can remember is the SolidRun Hummingboard, i.e. one baseboard that can be equipped with 3-4 different SoMs. Sebastian -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/3] DT: pinctrl: Document Qualcomm MSM8916 pinctrl binding
On Fri, Jan 30, 2015 at 11:04 AM, Stanimir Varbanov svarba...@mm-sol.com wrote: Adds devicetree binding documentation. Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com Reviewed-by: Bjorn Andersson bjorn.anders...@sonymobile.com Patch applied, as you're obviously working on enabling the generic bindings in another patch series, I'm not gonna whine about that right now :) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] pinctrl: qcom: increase variable size for register offsets
On Fri, Jan 30, 2015 at 11:03 AM, Stanimir Varbanov svarba...@mm-sol.com wrote: From: Joonwoo Park joonw...@codeaurora.org On newer TLMM hardware blocks the registers are spread and we need an offsets upper than 16 bits to address them. Increase the register offset variables to 32 bits size. Signed-off-by: Joonwoo Park joonw...@codeaurora.org Signed-off-by: Stanimir Varbanov svarba...@mm-sol.com Reviewed-by: Bjorn Andersson bjorn.anders...@sonymobile.com Patch applied. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Re: [PATCH v4 1/3] pinctrl: add driver for Amlogic Meson SoCs
On Fri, Jan 23, 2015 at 3:25 AM, 48169172 48169...@163.com wrote: Hi Linus， I do not find the meson dir, https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-pinctrl.git/tree/drivers/pinctrl?h=devel Is there something wrong? Maybe I took time pushing it out? It's certainly there now, even on the link you sent. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/2] Imagination Technologies PWM support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Thierry, On 01/30/2015 06:18 AM, Thierry Reding wrote: On Thu, Jan 29, 2015 at 01:32:09PM -0300, Ezequiel Garcia wrote: On 01/20/2015 07:52 AM, Ezequiel Garcia wrote: On 01/09/2015 02:54 PM, Ezequiel Garcia wrote: A new round for the IMG PWM driver. The IMG PWM controller is muxed with a PDM controller, through a shared so-called periph register bit, which sets the output as PWM or PDM. Because this register is not part of the pin controller block, but rather PWM/PDM specific, and because the register is also used to set the PDM value, it is simpler to use a regmap-based syscon to deal with it. This time, I'm removing the PDM driver from the submission and submitting the PWM alone. The PDM was written as a misc driver, but had some design issues, so for now I'm proposing to merge the PWM only. The series is based on v3.19-rc3. If at all possible I'd like to see this merged for v3.20. Thierry, Any comments on this? Any chance we merge it in time for v3.20? It's -rc5 already and I've started to worry. Thierry, I'm very sorry to be so bothering, but I got no news from you and it's -rc6 already. I'd say I'll resend this series to Andrew Morton, hoping we can merge this for v3.20. Please let me know if you'll be able to pick this. I can pick it up if you make up your mind about the license. The header comment says GPL v2 or later, but MODULE_LICENSE has GPL v2, which does not include the or later part. License should be GPL v2, sorry about that. Need me to fix it and resend or can you amend it before pushing this? Also you're making it especially difficult to build-test by not providing even the basic bits of your SoC support first. All even linux-next seems to have for the Pistachio SoC is the addition of a compatible string to the dw-mmc driver. Well, we've added COMPILE_TEST for precisely this reason, so you only need to select COMPILE_TEST on any arch and you'll be able to build test the driver. I'll take the PWM driver, but I'll assume that you'll eventually have more pieces available, in which case I'd appreciate a note so I can update my build scripts. If you can pick it, it would be great. I understand it's hard to accept patches for drivers, when there's little testing possibilities. But on the other side, isn't it a positive thing that a vendor is pushing drivers this early? Thanks a lot, - -- Ezequiel -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJUy2RhAAoJEIOKbhOEIHKiWB0QAKc4h+YLjxLLa7y0/NfoEiqV gwipBbrfO4leAB6RUiDOGil53Ir0Pxg87IbCHV5A0Gzxahv47GG41DYPVzbU3lHm DGkGqyXDf0BNQqJkCXmDWV9/8pnjFfUMDlSrs15pxXTaRjZ7m6CrxCoZof5UVt91 4cmeDYHg4lr+YzT3oXuyiKFlrIRrT5heD3gfyL5IB9qQypR2KPnpDrCwMcmT6+ag zI6sg6OAi8de7ZvSWEZSK7WkymhgduR9Rt0WRQBC3EKF2dCsUxhmZt14RJsDcpEK LWn5z1FxImtJq8vWOq/E2F9AWtQ/o9gUeII2myNDaL2SIrVoggUP+yKV51J8bidl G2HXU8NEIHCaqcKl5sdbeEbB4diXVqGJu+d9SOM2lrW2PlwWN63jgnGfyYc2RadH 60adajBgNjs9Ujfo5nFy+aYXJtJZk+4b1M0UMI+2qKV4G9PBfDrrpUMBRCRt8il4 A15lUoHTwTeLQp8m7YmNuoKLhLmeVrBgbzBagFLUZgpJs7TEYIWefrh/jos37n2s aNlVW55c5CXDMDX9Bef4ar6Ch95TOxPqiED70e2/lNM0ckRzd7viQandUxquvc9q mSWhSxYuT62/B6innSbuWLdifKtCsqX+QQIo2NBC3AB+NVybEmC89gB8jx+Py7pX YS0wpCGXivYm3AIWhhyT =qi1N -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe devicetree 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/7] usb: extcon: Fix USB-Host cable name
Felipe Chanwoo,
On 26/01/15 14:15, Roger Quadros wrote:
The recommended name for USB-Host cable state is USB-Host and not
USB-HOST as per drivers/extcon/extcon-class.c extcon_cable_name.
Change all instances of USB-HOST to USB-Host.
Signed-off-by: Roger Quadros rog...@ti.com
Reviewed-by: Felipe Balbi ba...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
This patch has no dependency to the rest so can be picked up as soon as
possible.
Do you think it is better to go via the USB tree?
If yes then Chanwoo, can you please Ack this one? Thanks.
This would mean that only the first patch needs to go through extcon tree as
Tony
will pick the rest.
cheers,
-roger
---
drivers/extcon/extcon-palmas.c | 18 +-
drivers/usb/dwc3/dwc3-omap.c | 6 +++---
drivers/usb/phy/phy-omap-otg.c | 4 ++--
drivers/usb/phy/phy-tahvo.c| 8
4 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index 11c6757..6d002c3 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -31,7 +31,7 @@
static const char *palmas_extcon_cable[] = {
[0] = USB,
- [1] = USB-HOST,
+ [1] = USB-Host,
NULL,
};
@@ -93,26 +93,26 @@ static irqreturn_t palmas_id_irq_handler(int irq, void
*_palmas_usb)
PALMAS_USB_ID_INT_LATCH_CLR,
PALMAS_USB_ID_INT_EN_HI_CLR_ID_GND);
palmas_usb-linkstat = PALMAS_USB_STATE_ID;
- extcon_set_cable_state(palmas_usb-edev, USB-HOST, true);
- dev_info(palmas_usb-dev, USB-HOST cable is attached\n);
+ extcon_set_cable_state(palmas_usb-edev, USB-Host, true);
+ dev_info(palmas_usb-dev, USB-Host cable is attached\n);
} else if ((set PALMAS_USB_ID_INT_SRC_ID_FLOAT)
(id_src PALMAS_USB_ID_INT_SRC_ID_FLOAT)) {
palmas_write(palmas_usb-palmas, PALMAS_USB_OTG_BASE,
PALMAS_USB_ID_INT_LATCH_CLR,
PALMAS_USB_ID_INT_EN_HI_CLR_ID_FLOAT);
palmas_usb-linkstat = PALMAS_USB_STATE_DISCONNECT;
- extcon_set_cable_state(palmas_usb-edev, USB-HOST, false);
- dev_info(palmas_usb-dev, USB-HOST cable is detached\n);
+ extcon_set_cable_state(palmas_usb-edev, USB-Host, false);
+ dev_info(palmas_usb-dev, USB-Host cable is detached\n);
} else if ((palmas_usb-linkstat == PALMAS_USB_STATE_ID)
(!(set PALMAS_USB_ID_INT_SRC_ID_GND))) {
palmas_usb-linkstat = PALMAS_USB_STATE_DISCONNECT;
- extcon_set_cable_state(palmas_usb-edev, USB-HOST, false);
- dev_info(palmas_usb-dev, USB-HOST cable is detached\n);
+ extcon_set_cable_state(palmas_usb-edev, USB-Host, false);
+ dev_info(palmas_usb-dev, USB-Host cable is detached\n);
} else if ((palmas_usb-linkstat == PALMAS_USB_STATE_DISCONNECT)
(id_src PALMAS_USB_ID_INT_SRC_ID_GND)) {
palmas_usb-linkstat = PALMAS_USB_STATE_ID;
- extcon_set_cable_state(palmas_usb-edev, USB-HOST, true);
- dev_info(palmas_usb-dev, USB-HOST cable is attached\n);
+ extcon_set_cable_state(palmas_usb-edev, USB-Host, true);
+ dev_info(palmas_usb-dev, USB-Host cable is attached\n);
}
return IRQ_HANDLED;
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 172d64e..6713ad9 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -445,14 +445,14 @@ static int dwc3_omap_extcon_register(struct dwc3_omap
*omap)
omap-id_nb.notifier_call = dwc3_omap_id_notifier;
ret = extcon_register_interest(omap-extcon_id_dev,
-edev-name, USB-HOST,
+edev-name, USB-Host,
omap-id_nb);
if (ret 0)
- dev_vdbg(omap-dev, failed to register notifier for
USB-HOST\n);
+ dev_vdbg(omap-dev, failed to register notifier for
USB-Host\n);
if (extcon_get_cable_state(edev, USB) == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_VBUS_VALID);
- if (extcon_get_cable_state(edev, USB-HOST) == true)
+ if (extcon_get_cable_state(edev, USB-Host) == true)
dwc3_omap_set_mailbox(omap, OMAP_DWC3_ID_GROUND);
}
diff --git a/drivers/usb/phy/phy-omap-otg.c b/drivers/usb/phy/phy-omap-otg.c
index 56ee760..53cba3f 100644
--- a/drivers/usb/phy/phy-omap-otg.c
+++ b/drivers/usb/phy/phy-omap-otg.c
@@ -119,7 +119,7 @@ static int omap_otg_probe(struct platform_device *pdev)
otg_dev-vbus_nb.notifier_call = omap_otg_vbus_notifier;
ret =
Re: [PATCH 1/4] mmc: core: add support for hardware reset gpio line
On 30 January 2015 at 11:37, Marek Szyprowski m.szyprow...@samsung.com wrote: Hello, On 2015-01-29 11:56, Javier Martinez Canillas wrote: On Thu, Jan 29, 2015 at 10:15 AM, Marek Szyprowski m.szyprow...@samsung.com wrote: Also, I wonder whether we could extend the mmc-pwrseq to cover your case? Did you consider that as an option? I didn't consider mmc-pwrseq yet. For me it looked straightforward to I agree with Ulf that using mmc-pwrseq would be a good solution and in fact I think the pwrseq_simple [0] driver will fit your use case since it supports a reset GPIO pin which is what many WLAN chips attached to a SDIO interface use. Ok, I've checked mmc-prwseq and mmc-pwrseq-simple. I also checked the hardware and it mmc-pwrseq-simple cannot be used directly. Although the signal is called RSTN (on Odroid U3 schema), the eMMC card gets resetted not on low line level, but during the rising edge. This RSTN line is also pulled up by the external resistor. However, the strangest thing is the fact that the default SoC configuration (which is applied during hw reset) for this GPIO line is input, pulled-down. The SoC internal pull-down is stronger than the external pull up, so in the end, during the SoC reboot the RSTN signal is set to zero. Later bootloader disables the internal pull-down. To sum up - to perform proper reboot on Odroid U3/XU3, one need to set RSTN to zero, wait a while and the set it back to 1. To achieve this with mmc-pwrseq-simple, I would need to modify the power_off callback to toggle reset line to zero and back to one. This however might not be desired to other sd/mmc cards used with mmc-pwrseq-simple. I can also provide separate mmc-pwrsrq-odroid driver, which will be very similar to mmc-pwrseq-simple. Ulf - which approach would you prefer? To me this seems like a quite generic eMMC hw-reset thing, thus we should maybe add a new pwrseq driver for it. In principle you need to toogle a GPIO in the -pre_power_on() callback, right? And you are also proposing to register a restart handler from the -alloc() callback!? I suppose this should work nicely. Kind regards Uffe implement it just like card detect or write-protection gpio pins. I already noticed that there is code for some mmc host driver, which perform mmc hardware reset. If you think that extending pwrseq is the better approach, I will try to update my patches. This will add reboot handler to mmc-pwrseq then. The only question is I don't think that adding a reboot handler to mmc-pwrseq is needed. AFAICT the call chain is: sys_reboot() - kernel_restart() - device_shutdown() - mmc_bus_shutdown() - _mmc_suspend() - mmc_power_off() - mmc_pwrseq_power_off() - struct mmc_pwrseq_ops .power_off So since the pwrseq_simple already asserts the reset GPIO in .power_off, it should be enough to ensure the eMMC will be reset to its default configuration for the iROM to work properly. It also asserts the GPIO pin in .pre_power_on and de-asserts in .post_power_on which should be needed as well for the other case you mentioned when a broken bootloader left the emmc card in some unknown state. emergency_restart() doesn't call device_shutdown(), so I think it still makes sense to add real reset handler to mmc-pwrseq to ensure that power_off will be called even during emergency_restart(). Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/3] dmaengine: APM X-Gene SoC DMA engine driver support
Hi All, Any comments on this patch set. Thanks, with regards, Ram On Wed, Jan 21, 2015 at 4:31 PM, Rameshwar Prasad Sahu rs...@apm.com wrote: This patch set implements the APM X-Gene SoC DMA driver support to offload the DMA operations such as memory copy(memcpy), scatter gathering. v4 changes: 1. Fixed dma-ranges property on DTS. Signed-off-by: Rameshwar Prasad Sahu rs...@apm.com Signed-off-by: Loc Ho l...@apm.com --- Rameshwar Prasad Sahu (3): dmaengine: Add support for APM X-Gene SoC DMA engine driver arm64: dts: Add APM X-Gene DMA device and DMA clock DTS nodes Documentation: dma: Add APM X-Gene SoC DMA engine driver documentation .../devicetree/bindings/dma/apm-xgene-dma.txt | 49 + arch/arm64/boot/dts/apm/apm-storm.dtsi | 26 + drivers/dma/Kconfig|8 + drivers/dma/Makefile |1 + drivers/dma/xgene-dma.c| 1566 5 files changed, 1650 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/apm-xgene-dma.txt create mode 100644 drivers/dma/xgene-dma.c -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
