Re: [PATCH v7 0/3] iio: Add Cosmic Circuits ADC support
Hi Jonathan, On 01/20/2015 05:37 PM, Jonathan Cameron wrote: [..] Hi, I'm afraid that I'm a little stalled on sending it on because Greg hasn't yet picked up my last pull request. In the mean time I've applied it to the branch that will get rebased once he's taken that and pushed it out as testing. I can't find your second pull anywhere. Any chance we can get this driver in v3.20? Also, I can't find the driver anywhere in your testing branch here: https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/ Seems like patches 2 and 3 are there, but not patch 1/3 of the series: iio: adc: Cosmic Circuits 10001 ADC driver. Please let me know if you need anything at all from me! Thanks a lot, -- Ezequiel -- 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, Jan 29, 2015 at 9:56 AM, Grant Likely grant.lik...@linaro.org 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. [...] 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. 2 of those already exist. Is it only a matter of adding fdt.h or is there more to it? This could also be carried as part of the import script to fix up. Rob -- 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/29/2015 11:05 AM, 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. Maybe the purpose would be better served by wrapping the idiom in a single function. 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 v8 0/2] Imagination Technologies PWM support
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. Thanks, -- Ezequiel -- 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 01/24] Documentation: DT: document compatible string existence requirement
Hello Paul, On 01/29/2015 12:49 AM, Paul Walmsley wrote: 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 I would had preferred if checkpatch.pl didn't warn about the most specific variants of the IP blocks tbh. Since afaiu those were only added to the compatible string as a way to make it future proof in case there is going to be needed later. So in that sense I thought they were not part of the DT ABI. Now, dumping the unused specific strings in binding docs only to make checkpatch happy, will have the effect of making those unused strings become part of the DT ABI. Which mean that couldn't be dropped later if those are found to not be needed since there won't be a way to know if an OS following the DT binding will be matching those or not. But since the decision is to warn for all strings in a compatible property even if those are not used, I agree with you that it should be documented. Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk 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 02/24] Documentation: DT bindings: add more chip compatible strings for Tegra PCIe
On Thu, Jan 29, 2015 at 9:45 AM, Paul Walmsley p...@pwsan.com wrote: 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 compatible strings for the PCIe IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: [...] + - nvidia,tegra132-pcie (not yet matched in the driver) + - nvidia,tegra210-pcie (not yet matched in the driver) Whether the driver matches or not is irrelevant to the binding and may change over time. Does this mean the driver matches on something else or Tegra132 is not yet supported in the driver? It means that the driver currently matches on one of the first three strings that don't carry that annotation. If the former, what is important is what are the valid combinations of compatible properties and that is not captured here. In other words, what is the fallback compatible string for each chip? The intention was to try to be helpful: to document that anyone adding a nvidia,tegra132-pcie compatible string would also need to add one of the other strings as a fallback. Would you like that to be documented in a different way, or removed? Then you should say something like 'must contain nvidia,tegra20-pcie and one of: ...' You can also use nvidia,chip-pcie if you want. checkpatch will check for that pattern too. Then your documentation can be something like: Must contain 'nvidia,chip-pcie, nvidia,tegra20-pcie' where chip is tegra30, tegra132, ... We don't enforce that the chip part is documented ATM and not likely until we have a schema if ever. Rob -- 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 2/2 v3 RESEND] mtd: fsl_upm: Support NAND ECC DTS properties
- Original Message - From: Brian Norris computersforpe...@gmail.com Sent: Wednesday, January 28, 2015 7:20:42 PM On Wed, Jan 28, 2015 at 06:37:36PM -0600, Aaron Sierra wrote: - Original Message - From: Brian Norris computersforpe...@gmail.com I was thinking about this a bit more, and it seems like we could really just factor this all into the core nand_base code with something like the following patch. It could possibly use some smarter logic to rule out certain combinations (but some of those are already caught in nand_scan_tail() anyway). What do you think? Brian, If the NAND device tree property fetching were moved out of fsl_upm, I think it should not be called within nand_scan(). I think that it's imperative that each driver be able to access these properties before handing off to nand_scan(), since there are hardware ECC modes that only drivers will know how to error check. That's why nand_scan() is broken into nand_scan_ident() and nand_scan_tail() functions which can be called individually. This allows drivers to do the up-front initialization in nand_scan_ident(), do their own error checking and handling of these parameters, and then call nand_scan_tail(). See, for example, drivers/mtd/nand/omap2.c. Thanks for pointing that out; I'll take a look. Also, catching errors in nand_scan_tail() tends to result in BUG()s. Well, some of those can be changed. Feel free to propose changes. I'd prefer to make nand_scan_tail() play nicer than to compensate in individual drivers. That said, this could be useful as a publicly exported function that individual drivers are responsible for calling (maybe in of_mtd.c). I don't think of_mtd.c should really contain a lot of mtd_info / nand_chip knowledge, if we can avoid it. I really do think that the nand_scan() option is a better idea, if we can work out the other details (BUG(), error checking, and keeping it flexible enough). I think it provides the best place to flesh out any other common DT handling for all NAND drivers. Related: I believe the question came up recently about how to support a generic DT binding for using a GPIO as a NAND write-protect line. This would be another candidate for handling transparently in nand_scan_ident() and would then immediately apply to all NAND drivers, not just those that were rewritten to call another specialized init function. I really don't want to encourage the anti-pattern of each driver reimplementing code that might as well be shared, if at all possible. Adding more decentralized helpers to of_mtd.c does not really help that cause. Understood. [ snipped function prototype discussion ] You hinted at implementing stronger error checking. If we went this route, would it make sense to only error check the software ECC modes? Yes. I just elided some of the details for now, since it's not actually necessary to do some of it (many other drivers can use SW ECC without the extra error checks). OK, I'll rework the fsl_upm patch to work with your proposed patch. -Aaron -- 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 Wed, Jan 28, 2015 at 5:32 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Will, 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 Pinchart laurent.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. Rob -- 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 01/24] Documentation: DT: document compatible string existence requirement
Hello Javier, On 01/29/2015 09:43 AM, Javier Martinez Canillas wrote: Hello Paul, On 01/29/2015 12:49 AM, Paul Walmsley wrote: 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 I would had preferred if checkpatch.pl didn't warn about the most specific variants of the IP blocks tbh. Since afaiu those were only added to the compatible string as a way to make it future proof in case there is going to be needed later. So in that sense I thought they were not part of the DT ABI. Now, dumping the unused specific strings in binding docs only to make checkpatch happy, will have the effect of making those unused strings become part of the DT ABI. Which mean that couldn't be dropped later if those are found to not be needed since there won't be a way to know if an OS following the DT binding will be matching those or not. But since the decision is to warn for all strings in a compatible property even if those are not used, I agree with you that it should be documented. Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk Thanks for the review. For what it's worth, I agree with almost everything you wrote. - 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 2/2] DT: leds: Add led-sources property
Hi Rob,
Have we achieved consensus concerning this patch?
If so, can you give your ack?
On 01/27/2015 09:07 AM, Jacek Anaszewski wrote:
Add a property for defining device outputs the LED
represented by the DT child node is connected to.
Signed-off-by: Jacek Anaszewski j.anaszew...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Bryan Wu coolo...@gmail.com
Cc: Richard Purdie rpur...@rpsys.net
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: devicetree@vger.kernel.org
---
Documentation/devicetree/bindings/leds/common.txt | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/leds/common.txt
b/Documentation/devicetree/bindings/leds/common.txt
index a2c3f7a..34811c5 100644
--- a/Documentation/devicetree/bindings/leds/common.txt
+++ b/Documentation/devicetree/bindings/leds/common.txt
@@ -1,6 +1,19 @@
Common leds properties.
+LED and flash LED devices provide the same basic functionality as current
+regulators, but extended with LED and flash LED specific features like
+blinking patterns, flash timeout, flash faults and external flash strobe mode.
+
+Many LED devices expose more than one current output that can be connected
+to one or more discrete LED component. Since the arrangement of connections
+can influence the way of the LED device initialization, the LED components
+have to be tightly coupled with the LED device binding. They are represented
+by child nodes of the parent LED device binding.
+
Optional properties for child nodes:
+- led-sources : List of device current outputs the LED is connected to. The
+ outputs are identified by the numbers that must be defined
+ in the LED device binding documentation.
- label : The label for this LED. If omitted, the label is
taken from the node name (excluding the unit address).
@@ -33,7 +46,8 @@ system-status {
camera-flash {
label = Flash;
+ led-sources = 0, 1;
max-microamp = 5;
flash-max-microamp = 32;
flash-timeout-us = 50;
-}
+};
--
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
[PATCH v3 5/6] ARM: dts: exynos5250-snow: Enable wifi power-on
The Snow board has a MMC/SDIO wifi chip that is always powered but it
needs a power sequence involving a reset (active low) and an enable
(active high) pins. Both pins are marked as active low since the MMC
simple power sequence driver asserts the pins prior to the card power
up procedure and de-asserts the pins after the card has been powered.
So the reset line will be left de-asserted and the enable pin will be
left asserted.
The chip also needs an external 32kHz reference clock to be operational
that is by the MAX77686 PMIC clock.
Add a simple MMC power sequence provider for the wifi MMC/SDIO slot.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
---
Changes since v2: None.
Changes since v1:
- Remove cap-sdio-irq from mmc3 dev node since is a separate change.
Suggested by Arend van Spriel.
---
arch/arm/boot/dts/exynos5250-snow.dts | 25 -
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos5250-snow.dts
b/arch/arm/boot/dts/exynos5250-snow.dts
index b9aeec430527..b78712058903 100644
--- a/arch/arm/boot/dts/exynos5250-snow.dts
+++ b/arch/arm/boot/dts/exynos5250-snow.dts
@@ -229,6 +229,14 @@
power-supply = fet6;
backlight = backlight;
};
+
+ mmc3_pwrseq: mmc3_pwrseq {
+ compatible = mmc-pwrseq-simple;
+ reset-gpios = gpx0 2 GPIO_ACTIVE_LOW, /* WIFI_RSTn */
+ gpx0 1 GPIO_ACTIVE_LOW; /* WIFI_EN */
+ clocks = max77686 MAX77686_CLK_PMIC;
+ clock-names = ext_clock;
+ };
};
dp {
@@ -536,12 +544,27 @@
samsung,dw-mshc-sdr-timing = 2 3;
samsung,dw-mshc-ddr-timing = 1 2;
pinctrl-names = default;
- pinctrl-0 = sd3_clk sd3_cmd sd3_bus4;
+ pinctrl-0 = sd3_clk sd3_cmd sd3_bus4 wifi_en wifi_rst;
bus-width = 4;
cap-sd-highspeed;
+ mmc-pwrseq = mmc3_pwrseq;
};
pinctrl_0 {
+ wifi_en: wifi-en {
+ samsung,pins = gpx0-1;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
+ wifi_rst: wifi-rst {
+ samsung,pins = gpx0-2;
+ samsung,pin-function = 1;
+ samsung,pin-pud = 0;
+ samsung,pin-drv = 0;
+ };
+
power_key_irq: power-key-irq {
samsung,pins = gpx1-3;
samsung,pin-function = 0xf;
--
2.1.3
--
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 6/6] ARM: dts: exynos5250-snow: Add cap-sdio-irq to wifi mmc node
Enabling SDIO IRQ signalling for the wifi MMC/SDIO slot doubles the transmission transfer rate. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v2: None. Changes since v1: None, new patch. --- arch/arm/boot/dts/exynos5250-snow.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/exynos5250-snow.dts b/arch/arm/boot/dts/exynos5250-snow.dts index b78712058903..909edc3448d3 100644 --- a/arch/arm/boot/dts/exynos5250-snow.dts +++ b/arch/arm/boot/dts/exynos5250-snow.dts @@ -539,6 +539,7 @@ status = okay; num-slots = 1; broken-cd; + cap-sdio-irq; card-detect-delay = 200; samsung,dw-mshc-ciu-div = 3; samsung,dw-mshc-sdr-timing = 2 3; -- 2.1.3 -- 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/6] Add multiple GPIO and external clock to MMC pwrseq_simple
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 -- 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/28/2015 06:32 PM, Laurent Pinchart wrote:
Hi Will,
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.
Cc: Joerg Roedelj...@8bytes.org
Cc: Grant Likelygrant.lik...@linaro.org
Cc: Rob Herringrobh...@kernel.org
Cc: Bjorn Helgaasbhelg...@google.com
Cc: Will Deaconwill.dea...@arm.com
Cc: Russell Kingli...@arm.linux.org.uk
Cc: Arnd Bergmanna...@arndb.de
Cc: Suravee Suthikulpanitsuravee.suthikulpa...@amd.com
Signed-off-by: Murali Karicherim-kariche...@ti.com
---
drivers/iommu/of_iommu.c | 10 --
drivers/of/platform.c|2 +-
include/linux/of_iommu.h |6 --
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index af1dc6a..439235b 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -133,19 +133,25 @@ struct iommu_ops *of_iommu_get_ops(struct
device_node *np)
return ops;
}
-struct iommu_ops *of_iommu_configure(struct device *dev)
+struct iommu_ops *of_iommu_configure(struct device *dev,
+struct device_node *iommu_np)
{
struct of_phandle_args iommu_spec;
struct device_node *np;
struct iommu_ops *ops = NULL;
int idx = 0;
+ if (dev_is_pci(dev)) {
+ dev_err(dev, iommu is currently not supported for PCI\n);
+ return NULL;
+ }
+
/*
* We don't currently walk up the tree looking for a parent
IOMMU.
* See the `Notes:' section of
* Documentation/devicetree/bindings/iommu/iommu.txt
*/
Wouldn't it be better to fix this rather than passing the device
node pointer to the function ? The solution would be more generic.
Will Deacon (Copied here) is working on this as we alteady discussed
in this thread. So it will be addressed by him in another series.
Well, working on this equates to has it somewhere near the bottom
of a very long list :)
What's your opinion on this patch then, do you think adding the
iommu_np argument makes sense as a temporary hack, or should we instead
walk up the tree looking for an iommus attribute in parent nodes ? I
don't expect that to be insanely difficult to code.
If walking up the tree is useful, then I think we should do that and
update the Documentation to reflect the new behaviour.
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.
Probably the doc part can be added by Will. The iommu_np was a
suggestion from Rob, if I recollect. Isn't the iommu_np points to the
iommu device, and if so, iommu_np make sense.
Murali
The part I'm more interested in is the mapping of RequesterID (PCI dma
alias) to IOMMU ID when we transition from the PCI topology to the DT
topology. Currently, it seems to be 1:1 on the platforms I have, but I
doubt this will always be the case.
--
Murali Karicheri
Linux Kernel, Texas
[PATCH v3 4/6] mmc: pwrseq_simple: Add optional reference clock support
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)) {
+ 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) {
+ 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
--
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 3/6] mmc: pwrseq: Document optional clock for the simple power sequence
Some WLAN chips attached to a SDIO interface, need an external clock to be operational. Since this is very common, extend the simple MMC power sequence DT binding to support an optional clock. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v2: None. Changes since v1: None. --- Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt index eaae652213ae..a462c50f19a8 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt @@ -12,6 +12,10 @@ Optional properties: at initialization and prior we start the power up procedure of the card. They will be de-asserted right after the power has been provided to the card. +- clocks : Must contain an entry for the entry in clock-names. + See ../clocks/clock-bindings.txt for details. +- clock-names : Must include the following entry: + ext_clock (External clock provided to the card). Example: -- 2.1.3 -- 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/6] mmc: pwrseq_simple: Extend to support more pins
Many WLAN attached to a SDIO/MMC interface, needs more than one pin for
their reset sequence. For example, is very common for chips to have two
pins: one for reset and one for power enable.
This patch adds support for more reset pins to the pwrseq_simple driver
and instead hardcoding a fixed number, it uses the of_gpio_named_count()
since the MMC power sequence is only built when CONFIG_OF is enabled.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
Changes since v2: None.
Changes since v1:
- Many code cleanups suggested by Srinivas Kandagatla
* Rename reset_gpio array to reset_gpios.
* Use a zero length array for reset_gpios to avoid a kmalloc.
* Refactor GPIO assert and de-ssert logic into a common function.
* Simplify gpiod_put logic in case of gpiod_get error.
---
drivers/mmc/core/pwrseq_simple.c | 55 +---
1 file changed, 40 insertions(+), 15 deletions(-)
diff --git a/drivers/mmc/core/pwrseq_simple.c b/drivers/mmc/core/pwrseq_simple.c
index 0958c696137f..e53d3c7e059c 100644
--- a/drivers/mmc/core/pwrseq_simple.c
+++ b/drivers/mmc/core/pwrseq_simple.c
@@ -11,6 +11,7 @@
#include linux/slab.h
#include linux/device.h
#include linux/err.h
+#include linux/of_gpio.h
#include linux/gpio/consumer.h
#include linux/mmc/host.h
@@ -19,16 +20,26 @@
struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
- struct gpio_desc *reset_gpio;
+ int nr_gpios;
+ struct gpio_desc *reset_gpios[0];
};
+static void mmc_pwrseq_simple_set_gpios_value(struct mmc_pwrseq_simple *pwrseq,
+ int value)
+{
+ int i;
+
+ for (i = 0; i pwrseq-nr_gpios; i++)
+ if (!IS_ERR(pwrseq-reset_gpios[i]))
+ gpiod_set_value_cansleep(pwrseq-reset_gpios[i], value);
+}
+
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-reset_gpio))
- gpiod_set_value_cansleep(pwrseq-reset_gpio, 1);
+ mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
}
static void mmc_pwrseq_simple_post_power_on(struct mmc_host *host)
@@ -36,17 +47,18 @@ static void mmc_pwrseq_simple_post_power_on(struct mmc_host
*host)
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
- if (!IS_ERR(pwrseq-reset_gpio))
- gpiod_set_value_cansleep(pwrseq-reset_gpio, 0);
+ mmc_pwrseq_simple_set_gpios_value(pwrseq, 0);
}
static void mmc_pwrseq_simple_free(struct mmc_host *host)
{
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
struct mmc_pwrseq_simple, pwrseq);
+ int i;
- if (!IS_ERR(pwrseq-reset_gpio))
- gpiod_put(pwrseq-reset_gpio);
+ for (i = 0; i pwrseq-nr_gpios; i++)
+ if (!IS_ERR(pwrseq-reset_gpios[i]))
+ gpiod_put(pwrseq-reset_gpios[i]);
kfree(pwrseq);
host-pwrseq = NULL;
@@ -62,20 +74,33 @@ static struct mmc_pwrseq_ops mmc_pwrseq_simple_ops = {
int mmc_pwrseq_simple_alloc(struct mmc_host *host, struct device *dev)
{
struct mmc_pwrseq_simple *pwrseq;
- int ret = 0;
+ int i, nr_gpios, ret = 0;
- pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple), GFP_KERNEL);
+ nr_gpios = of_gpio_named_count(dev-of_node, reset-gpios);
+ if (nr_gpios 0)
+ nr_gpios = 0;
+
+ pwrseq = kzalloc(sizeof(struct mmc_pwrseq_simple) + nr_gpios *
+sizeof(struct gpio_desc *), GFP_KERNEL);
if (!pwrseq)
return -ENOMEM;
- pwrseq-reset_gpio = gpiod_get_index(dev, reset, 0, GPIOD_OUT_HIGH);
- if (IS_ERR(pwrseq-reset_gpio)
- PTR_ERR(pwrseq-reset_gpio) != -ENOENT
- PTR_ERR(pwrseq-reset_gpio) != -ENOSYS) {
- ret = PTR_ERR(pwrseq-reset_gpio);
- goto free;
+ for (i = 0; i nr_gpios; i++) {
+ pwrseq-reset_gpios[i] = gpiod_get_index(dev, reset, i,
+GPIOD_OUT_HIGH);
+ if (IS_ERR(pwrseq-reset_gpios[i])
+ PTR_ERR(pwrseq-reset_gpios[i]) != -ENOENT
+ PTR_ERR(pwrseq-reset_gpios[i]) != -ENOSYS) {
+ ret = PTR_ERR(pwrseq-reset_gpios[i]);
+
+ while (--i)
+ gpiod_put(pwrseq-reset_gpios[i]);
+
+ goto free;
+ }
}
+ pwrseq-nr_gpios = nr_gpios;
pwrseq-pwrseq.ops = mmc_pwrseq_simple_ops;
host-pwrseq = pwrseq-pwrseq;
--
2.1.3
--
To unsubscribe from this
[PATCH v3 1/6] mmc: pwrseq: Document that simple sequence support more than one GPIO
Many SDIO/MMC attached WLAN chips need more than one ping for their reset sequence. Extend the pwrseq_simple binding to support more than one pin. Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Changes since v2: None. Changes since v1: - Make the explanation clearer by adding an explicit they. Suggested by Srinivas Kandagatla. --- Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt index da333d9ed94c..eaae652213ae 100644 --- a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt +++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.txt @@ -8,9 +8,10 @@ Required properties: - compatible : contains mmc-pwrseq-simple. Optional properties: -- reset-gpios : contains a GPIO specifier. The reset GPIO is asserted at - initialization and prior we start the power up procedure of the card. It - will be de-asserted right after the power has been provided to the card. +- reset-gpios : contains a list of GPIO specifiers. The reset GPIOs are asserted + at initialization and prior we start the power up procedure of the card. + They will be de-asserted right after the power has been provided to the + card. Example: -- 2.1.3 -- 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 02/24] Documentation: DT bindings: add more chip compatible strings for Tegra PCIe
Hi Rob On Thu, 29 Jan 2015, Rob Herring wrote: On Thu, Jan 29, 2015 at 9:45 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 29 Jan 2015, Rob Herring wrote: On Wed, Jan 28, 2015 at 5:49 PM, Paul Walmsley p...@pwsan.com wrote: Add compatible strings for the PCIe IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: [...] + - nvidia,tegra132-pcie (not yet matched in the driver) + - nvidia,tegra210-pcie (not yet matched in the driver) Whether the driver matches or not is irrelevant to the binding and may change over time. Does this mean the driver matches on something else or Tegra132 is not yet supported in the driver? It means that the driver currently matches on one of the first three strings that don't carry that annotation. If the former, what is important is what are the valid combinations of compatible properties and that is not captured here. In other words, what is the fallback compatible string for each chip? The intention was to try to be helpful: to document that anyone adding a nvidia,tegra132-pcie compatible string would also need to add one of the other strings as a fallback. Would you like that to be documented in a different way, or removed? Then you should say something like 'must contain nvidia,tegra20-pcie and one of: ...' You can also use nvidia,chip-pcie if you want. checkpatch will check for that pattern too. Then your documentation can be something like: Must contain 'nvidia,chip-pcie, nvidia,tegra20-pcie' where chip is tegra30, tegra132, ... We don't enforce that the chip part is documented ATM and not likely until we have a schema if ever. OK, thanks for the explanation. So would it be acceptable to you to skip the attempt to document which strings are actually supported by the current driver, and to simply use the chip wildcard? - 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 02/24] Documentation: DT bindings: add more chip compatible strings for Tegra PCIe
On Thu, 29 Jan 2015, Paul Walmsley wrote: Hi Rob On Thu, 29 Jan 2015, Rob Herring wrote: On Thu, Jan 29, 2015 at 9:45 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 29 Jan 2015, Rob Herring wrote: On Wed, Jan 28, 2015 at 5:49 PM, Paul Walmsley p...@pwsan.com wrote: Add compatible strings for the PCIe IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: [...] + - nvidia,tegra132-pcie (not yet matched in the driver) + - nvidia,tegra210-pcie (not yet matched in the driver) Whether the driver matches or not is irrelevant to the binding and may change over time. Does this mean the driver matches on something else or Tegra132 is not yet supported in the driver? It means that the driver currently matches on one of the first three strings that don't carry that annotation. If the former, what is important is what are the valid combinations of compatible properties and that is not captured here. In other words, what is the fallback compatible string for each chip? The intention was to try to be helpful: to document that anyone adding a nvidia,tegra132-pcie compatible string would also need to add one of the other strings as a fallback. Would you like that to be documented in a different way, or removed? Then you should say something like 'must contain nvidia,tegra20-pcie and one of: ...' You can also use nvidia,chip-pcie if you want. checkpatch will check for that pattern too. Then your documentation can be something like: Must contain 'nvidia,chip-pcie, nvidia,tegra20-pcie' where chip is tegra30, tegra132, ... We don't enforce that the chip part is documented ATM and not likely until we have a schema if ever. OK, thanks for the explanation. So would it be acceptable to you to skip the attempt to document which strings are actually supported by the current driver, and to simply use the chip wildcard? (Just in case it wasn't clear, I mean for the purposes of the current patch series, not necessarily in general) - 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 v2 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
* 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. Regards, Tony -- 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 2/2] mmc: dw_mmc: wait until card ready if tuning fails
On 26 January 2015 at 12:19, Addy Ke addy...@rock-chips.com wrote:
This patch based on Alex's patch:
https://patchwork.kernel.org/patch/5516411/
This above patch was rejected, since it doesn't use mmc_send_tuning().
Please base you work on my latest next branch.
If you need other patches which has been posted recently, which hasn’t
been reviewed nor merged you can just included them in your patchset
as well.
Kind regards
Uffe
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/core/mmc_ops.h | 1 -
drivers/mmc/host/dw_mmc.c | 48
--
include/linux/mmc/card.h | 2 ++
3 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/core/mmc_ops.h b/drivers/mmc/core/mmc_ops.h
index 6f4b00e..c5be9ce 100644
--- a/drivers/mmc/core/mmc_ops.h
+++ b/drivers/mmc/core/mmc_ops.h
@@ -20,7 +20,6 @@ int mmc_send_op_cond(struct mmc_host *host, u32 ocr, u32
*rocr);
int mmc_all_send_cid(struct mmc_host *host, u32 *cid);
int mmc_set_relative_addr(struct mmc_card *card);
int mmc_send_csd(struct mmc_card *card, u32 *csd);
-int mmc_send_status(struct mmc_card *card, u32 *status);
int mmc_send_cid(struct mmc_host *host, u32 *cid);
int mmc_spi_read_ocr(struct mmc_host *host, int highcap, u32 *ocrp);
int mmc_spi_set_crc(struct mmc_host *host, int use_crc);
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index e54e656..4a31a5e 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1317,10 +1317,38 @@ static void dw_mci_enable_sdio_irq(struct mmc_host
*mmc, int enb)
spin_unlock_irqrestore(host-irq_lock, irqflags);
}
-static int dw_mci_tuning_test(struct dw_mci_slot *slot, u32 opcode,
- struct dw_mci_tuning_data *tuning_data,
- u8 *blk_test)
+static int dw_mci_card_busy(u32 status)
{
+ return !(status R1_READY_FOR_DATA) ||
+ (R1_CURRENT_STATE(status) == R1_STATE_PRG);
+}
+
+static int dw_mci_wait_for_card_ready(struct mmc_card *card)
+{
+ struct mmc_host *mmc = card-host;
+ struct dw_mci_slot *slot = mmc_priv(mmc);
+ struct dw_mci *host = slot-host;
+ int err = 0;
+ u32 status;
+
+ do {
+ err = mmc_send_status(card, status);
+ if (err) {
+ dev_err(host-dev,
+ Get card status fail in tuning state\n);
+ break;
+ }
+ } while (dw_mci_card_busy(status));
+
+ return err;
+}
+
+static int dw_mci_tuning_test(struct mmc_card *card, u32 opcode,
+ struct dw_mci_tuning_data *tuning_data,
+ u8 *blk_test)
+{
+ struct mmc_host *mmc = card-host;
+ struct dw_mci_slot *slot = mmc_priv(mmc);
struct dw_mci *host = slot-host;
struct mmc_host *mmc = slot-mmc;
const u8 *blk_pattern = tuning_data-blk_pattern;
@@ -1330,6 +1358,7 @@ static int dw_mci_tuning_test(struct dw_mci_slot *slot,
u32 opcode,
struct mmc_command stop = {0};
struct mmc_data data = {0};
struct scatterlist sg;
+ int err;
memset(blk_test, 0, blksz);
@@ -1365,6 +1394,11 @@ static int dw_mci_tuning_test(struct dw_mci_slot
*slot, u32 opcode,
dev_dbg(host-dev,
Tuning error: cmd.error:%d, data.error:%d\n,
cmd.error, data.error);
+
+ err = dw_mci_wait_for_card_ready(card);
+ if (err)
+ return err;
+
if (cmd.error)
return cmd.error;
else
@@ -1372,9 +1406,11 @@ static int dw_mci_tuning_test(struct dw_mci_slot
*slot, u32 opcode,
}
}
-static int dw_mci_execute_generic_tuning(struct dw_mci_slot *slot, u32
opcode,
+static int dw_mci_execute_generic_tuning(struct mmc_card *card, u32 opcode,
struct dw_mci_tuning_data
*tuning_data)
{
+ struct mmc_host *mmc = card-host;
+ struct dw_mci_slot *slot = mmc_priv(mmc);
struct dw_mci *host = slot-host;
unsigned int blksz = tuning_data-blksz;
u8 *blk_test;
@@ -1412,7 +1448,7 @@ static int dw_mci_execute_generic_tuning(struct
dw_mci_slot *slot, u32 opcode,
for (i = 0; i NUM_PHASES; i++) {
clk_set_phase(host-sample_clk, i * PHASE_INCREMENT);
- v = !dw_mci_tuning_test(slot, opcode, tuning_data, blk_test);
+ v = !dw_mci_tuning_test(card, opcode, tuning_data, blk_test);
if ((!prev_v) v) {
range_count++;
@@ -1496,7 +1532,7 @@ static int dw_mci_execute_tuning(struct mmc_card *card,
u32 opcode)
if (drv_data drv_data-execute_tuning)
err = drv_data-execute_tuning(slot, opcode,
Re: [PATCH v2 1/7] mmc: sdhci-pxav3: Fix SDR50 and DDR50 capabilities for the Armada 38x flavor
[...]
Seems like this function can be void instead of always returning 0.
In patch 4 mmc: sdhci-pxav3: Modify clock settings for the SDR50 and
DDR50 modes, this function can return other values than 0.
I could change the prototype in patch 4, but it would also imply
removing the test of the return value in this patch and adding in back
patch 4. By returning a value in this patch, it reduced the amount of
change over the patches.
But if you still prefer than I this function return void in this
patch, I can do it.
No worries, let's keep it as an int. But then I have a few other
comments, see below.
Thanks,
Gregory
+{
+ host-quirks |= SDHCI_QUIRK_MISSING_CAPS;
+ /*
+* According to erratum 'FE-2946959' both SDR50 and DDR50
+* modes require specific clock adjustments in SDIO3
+* Configuration register, if the adjustment is not done,
+* remove them from the capabilities.
+*/
+ host-caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+ host-caps1 = ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
+ return 0;
+}
+
static void pxav3_reset(struct sdhci_host *host, u8 mask)
{
struct platform_device *pdev =
to_platform_device(mmc_dev(host-mmc));
@@ -319,6 +333,9 @@ static int sdhci_pxav3_probe(struct platform_device
*pdev)
clk_prepare_enable(pxa-clk_core);
if (of_device_is_compatible(np, marvell,armada-380-sdhci)) {
+ ret = armada_38x_quirks(host);
+ if (ret 0)
Since in patch 4 you return a proper error code, let's also adopt to
that here by changing to:
if (IS_ERR(ret))
+ goto err_quirks;
ret = mv_conf_mbus_windows(pdev, mv_mbus_dram_info());
if (ret 0)
goto err_mbus_win;
@@ -400,6 +417,7 @@ err_mbus_win:
if (!IS_ERR(pxa-clk_core))
clk_disable_unprepare(pxa-clk_core);
err_clk_get:
+err_quirks:
You don't need the new label, you could use err_clk_get.
sdhci_pltfm_free(pdev);
return ret;
}
--
2.1.0
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 v2 1/7] mmc: sdhci-pxav3: Fix SDR50 and DDR50 capabilities for the Armada 38x flavor
Hi Ulf,
On 29/01/2015 10:31, Ulf Hansson wrote:
[...]
Seems like this function can be void instead of always returning 0.
In patch 4 mmc: sdhci-pxav3: Modify clock settings for the SDR50 and
DDR50 modes, this function can return other values than 0.
I could change the prototype in patch 4, but it would also imply
removing the test of the return value in this patch and adding in back
patch 4. By returning a value in this patch, it reduced the amount of
change over the patches.
But if you still prefer than I this function return void in this
patch, I can do it.
No worries, let's keep it as an int. But then I have a few other
comments, see below.
OK
Thanks,
Gregory
+{
+ host-quirks |= SDHCI_QUIRK_MISSING_CAPS;
+ /*
+* According to erratum 'FE-2946959' both SDR50 and DDR50
+* modes require specific clock adjustments in SDIO3
+* Configuration register, if the adjustment is not done,
+* remove them from the capabilities.
+*/
+ host-caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+ host-caps1 = ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
+ return 0;
+}
+
static void pxav3_reset(struct sdhci_host *host, u8 mask)
{
struct platform_device *pdev =
to_platform_device(mmc_dev(host-mmc));
@@ -319,6 +333,9 @@ static int sdhci_pxav3_probe(struct platform_device
*pdev)
clk_prepare_enable(pxa-clk_core);
if (of_device_is_compatible(np, marvell,armada-380-sdhci)) {
+ ret = armada_38x_quirks(host);
+ if (ret 0)
Since in patch 4 you return a proper error code, let's also adopt to
that here by changing to:
if (IS_ERR(ret))
The function returns an int and IS_ERR expects a pointer. I am not sure
this macro would be appropriate here.
+ goto err_quirks;
ret = mv_conf_mbus_windows(pdev, mv_mbus_dram_info());
if (ret 0)
goto err_mbus_win;
@@ -400,6 +417,7 @@ err_mbus_win:
if (!IS_ERR(pxa-clk_core))
clk_disable_unprepare(pxa-clk_core);
err_clk_get:
+err_quirks:
You don't need the new label, you could use err_clk_get.
Right.
Thanks,
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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/7] mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes
Hi Ulf, [...] + dev_warn(pdev-dev, conf-sdio3 register not found\n); + dev_warn(pdev-dev, disabling SDR50 and DDR50 modes\n); + dev_warn(pdev-dev, consider updating your dtb\n); One dev_warn() should be enough. Also I don't think checkpatch complains about long lines for dev_warn(). Right. Once you will have told if you sill want a change or not in patch 1, I will send a new version with this change. Thanks, Gregory -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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/7] mmc: sdhci-pxav3: Fix SDR50 and DDR50 capabilities for the Armada 38x flavor
Hi Ulf,
On 28/01/2015 21:36, Ulf Hansson wrote:
On 23 January 2015 at 11:56, Gregory CLEMENT
gregory.clem...@free-electrons.com wrote:
According to erratum 'FE-2946959' both SDR50 and DDR50 modes require
specific clock adjustments in SDIO3 Configuration register. However,
this register was not part of the device tree binding. Even if the
binding can (and will) be extended we still need handling the case
where this register was not available. In this case we use the
SDHCI_QUIRK_MISSING_CAPS quirk remove them from the capabilities.
This commit is based on the work done by Marcin Wojtasm...@semihalf.com
Fixes: 5491ce3f79ee (mmc: sdhci-pxav3: add support for the Armada 38x SDHCI
controller)
Cc: sta...@vger.kernel.org # v3.15+
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Marcin Wojtas m...@semihalf.com
---
drivers/mmc/host/sdhci-pxav3.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index ca3424e7ef71..7b07325b4fba 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -118,6 +118,20 @@ static int mv_conf_mbus_windows(struct platform_device
*pdev,
return 0;
}
+static int armada_38x_quirks(struct sdhci_host *host)
Seems like this function can be void instead of always returning 0.
In patch 4 mmc: sdhci-pxav3: Modify clock settings for the SDR50 and
DDR50 modes, this function can return other values than 0.
I could change the prototype in patch 4, but it would also imply
removing the test of the return value in this patch and adding in back
patch 4. By returning a value in this patch, it reduced the amount of
change over the patches.
But if you still prefer than I this function return void in this
patch, I can do it.
Thanks,
Gregory
+{
+ host-quirks |= SDHCI_QUIRK_MISSING_CAPS;
+ /*
+* According to erratum 'FE-2946959' both SDR50 and DDR50
+* modes require specific clock adjustments in SDIO3
+* Configuration register, if the adjustment is not done,
+* remove them from the capabilities.
+*/
+ host-caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+ host-caps1 = ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
+ return 0;
+}
+
static void pxav3_reset(struct sdhci_host *host, u8 mask)
{
struct platform_device *pdev =
to_platform_device(mmc_dev(host-mmc));
@@ -319,6 +333,9 @@ static int sdhci_pxav3_probe(struct platform_device
*pdev)
clk_prepare_enable(pxa-clk_core);
if (of_device_is_compatible(np, marvell,armada-380-sdhci)) {
+ ret = armada_38x_quirks(host);
+ if (ret 0)
+ goto err_quirks;
ret = mv_conf_mbus_windows(pdev, mv_mbus_dram_info());
if (ret 0)
goto err_mbus_win;
@@ -400,6 +417,7 @@ err_mbus_win:
if (!IS_ERR(pxa-clk_core))
clk_disable_unprepare(pxa-clk_core);
err_clk_get:
+err_quirks:
sdhci_pltfm_free(pdev);
return ret;
}
--
2.1.0
Kind regards
Uffe
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
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-28 15:24, Ulf Hansson wrote: On 28 January 2015 at 14:59, Marek Szyprowski m.szyprow...@samsung.com wrote: There are boards (like Hardkernel's Odroid boards) on which eMMC card's reset line is connected to GPIO line instead of the hardware reset logic. In case of such boards, if first stage of bootloader is loaded from such eMMC card, before performing system reboot, additional reset of eMMC card is required to properly boot the whole system again. This patch adds code for handling reset gpio lines defined in device tree. I don't follow the above sequence. Can you try to elaborate and describe for what exact scenario we require the hardware reset to be done? Odroid boards uses multi stage bootloaders. The very first stage is in SoC ROM. That code loads next stages (called bl1, bl2, tz) from either eMMC or SD card (depending on jumper configuration or some card detect pins). This ROM code is very simple and assumes that the mmc card has been reset to the default configuration. However, eMMC card is not being reset by the board 'reboot' logic. Instead the nreset line from emmc card is connected to gpio line of SoC. Thus to perform full system reboot procedure, before triggering reboot inside the SoC, one need to manually toggle nreset line of this emmc card to 'zero' for a while. Only then the card is put back to the default state, so ROM code is able to read bootloaders from it. My patch adds code for managing gpio line connected to nreset signal of emmc card. It registers reset handler, which is being triggered from Linux reboot code. This handler toggles such gpio line before the final reboot is triggered. My patch also provides a function for registering as a mmc host hw_reset callback, so it can be used to reset mmc card before initializing it with kernel driver (this is already implemented), which also might help to get it working if broken bootloader left the emmc card in some unknown/broken state (already observed such issue, but it has been fixed finally by patching bootloader). 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 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 weather to use it always when mmc-pwrseq has been enabled or only if some additional property like 'reset-on-reboot' has been provided. 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 3/3] dt: paz00: define nvec as child of i2c bus
Am Donnerstag, 29. Januar 2015, 10:20:22 schrieb Andrey Danin:
NVEC driver was reimplemented to use tegra i2c. Use common i2c bindings
for NVEC node.
Signed-off-by: Andrey Danin danind...@mail.ru
---
.../devicetree/bindings/nvec/nvidia,nvec.txt | 19 ++-
arch/arm/boot/dts/tegra20-paz00.dts| 22
+- 2 files changed, 11 insertions(+), 30 deletions(-)
diff --git a/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
b/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt index
5ae601e..d82c125 100644
--- a/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
+++ b/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
@@ -2,20 +2,5 @@ NVIDIA compliant embedded controller
Required properties:
- compatible : should be nvidia,nvec.
based on the earlier discussion with Wolfram, this should be nvidia,nvec-
slave to distunguish it from a possible nvec master driver.
-- reg : the iomem of the i2c slave controller
-- interrupts : the interrupt line of the i2c slave controller
-- clock-frequency : the frequency of the i2c bus
-- gpios : the gpio used for ec request
-- slave-addr: the i2c address of the slave controller
-- clocks : Must contain an entry for each entry in clock-names.
- See ../clocks/clock-bindings.txt for details.
-- clock-names : Must include the following entries:
- Tegra20/Tegra30:
- - div-clk
- - fast-clk
- Tegra114:
- - div-clk
-- resets : Must contain an entry for each entry in reset-names.
- See ../reset/reset.txt for details.
-- reset-names : Must include the following entries:
- - i2c
+- request-gpios : the gpio used for ec request
+- reg: the i2c address of the slave controller
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
b/arch/arm/boot/dts/tegra20-paz00.dts index ed7e100..65e247b 100644
--- a/arch/arm/boot/dts/tegra20-paz00.dts
+++ b/arch/arm/boot/dts/tegra20-paz00.dts
@@ -288,20 +288,16 @@
clock-frequency = 10;
};
- nvec@7000c500 {
- compatible = nvidia,nvec;
- reg = 0x7000c500 0x100;
- interrupts = GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH;
- #address-cells = 1;
- #size-cells = 0;
+ i2c@7000c500 {
+ status = okay;
clock-frequency = 8;
- request-gpios = gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH;
- slave-addr = 138;
- clocks = tegra_car TEGRA20_CLK_I2C3,
- tegra_car TEGRA20_CLK_PLL_P_OUT3;
- clock-names = div-clk, fast-clk;
- resets = tegra_car 67;
- reset-names = i2c;
+
+ nvec: nvec@45 {
+ compatible = nvidia,nvec;
+ request-gpios = gpio TEGRA_GPIO(V, 2)
+ GPIO_ACTIVE_HIGH;
+ reg = 0x45;
+ };
};
i2c@7000d000 {
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH v2 1/7] mmc: sdhci-pxav3: Fix SDR50 and DDR50 capabilities for the Armada 38x flavor
On 29 January 2015 at 10:42, Gregory CLEMENT
gregory.clem...@free-electrons.com wrote:
Hi Ulf,
On 29/01/2015 10:31, Ulf Hansson wrote:
[...]
Seems like this function can be void instead of always returning 0.
In patch 4 mmc: sdhci-pxav3: Modify clock settings for the SDR50 and
DDR50 modes, this function can return other values than 0.
I could change the prototype in patch 4, but it would also imply
removing the test of the return value in this patch and adding in back
patch 4. By returning a value in this patch, it reduced the amount of
change over the patches.
But if you still prefer than I this function return void in this
patch, I can do it.
No worries, let's keep it as an int. But then I have a few other
comments, see below.
OK
Thanks,
Gregory
+{
+ host-quirks |= SDHCI_QUIRK_MISSING_CAPS;
+ /*
+* According to erratum 'FE-2946959' both SDR50 and DDR50
+* modes require specific clock adjustments in SDIO3
+* Configuration register, if the adjustment is not done,
+* remove them from the capabilities.
+*/
+ host-caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+ host-caps1 = ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
+ return 0;
+}
+
static void pxav3_reset(struct sdhci_host *host, u8 mask)
{
struct platform_device *pdev =
to_platform_device(mmc_dev(host-mmc));
@@ -319,6 +333,9 @@ static int sdhci_pxav3_probe(struct platform_device
*pdev)
clk_prepare_enable(pxa-clk_core);
if (of_device_is_compatible(np, marvell,armada-380-sdhci)) {
+ ret = armada_38x_quirks(host);
+ if (ret 0)
Since in patch 4 you return a proper error code, let's also adopt to
that here by changing to:
if (IS_ERR(ret))
The function returns an int and IS_ERR expects a pointer. I am not sure
this macro would be appropriate here.
You are right. Don't know what I was thinking. :-)
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 2/3] clocksource: versatile: adapt for Versatile AB and PB boards
On Wed, Jan 28, 2015 at 05:56:31PM +, Rob Herring wrote: The same 24MHz counter is also present on Versatile AB and PB boards, so add the compatible string for them. Signed-off-by: Rob Herring r...@kernel.org Cc: Liviu Dudau liviu.du...@arm.com Cc: Sudeep Holla sudeep.ho...@arm.com Cc: Lorenzo Pieralisi lorenzo.pieral...@arm.com Cc: Daniel Lezcano daniel.lezc...@linaro.org Cc: Thomas Gleixner t...@linutronix.de --- drivers/clocksource/versatile.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/clocksource/versatile.c b/drivers/clocksource/versatile.c index 2798e74..0a26d3d 100644 --- a/drivers/clocksource/versatile.c +++ b/drivers/clocksource/versatile.c @@ -36,5 +36,7 @@ static void __init versatile_sched_clock_init(struct device_node *node) sched_clock_register(versatile_sys_24mhz_read, 32, 2400); } -CLOCKSOURCE_OF_DECLARE(versatile, arm,vexpress-sysreg, +CLOCKSOURCE_OF_DECLARE(vexpress, arm,vexpress-sysreg, +versatile_sched_clock_init); +CLOCKSOURCE_OF_DECLARE(versatile, arm,versatile-sysreg, versatile_sched_clock_init); Acked-by: Liviu Dudau liviu.du...@arm.com -- 2.1.0 -- | I would like to | | fix the world, | | but they're not | | giving me the | \ source code! / --- ¯\_(ツ)_/¯ -- 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 Marek, 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. 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. weather to use it always when mmc-pwrseq has been enabled or only if some additional property like 'reset-on-reboot' has been provided. Having a reset GPIO is optional AFAIK so I don't think there is a need for an additional reset-on-reboot propery. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland Best regards, Javier [0]: FYI, these are the relevant commits in linux-next: fe1922d5d4d0 mmc: pwrseq_simple: Add support for a reset GPIO pin ec2017f2491f mmc: pwrseq: Initial support for the simple MMC power sequence provider fe1686658f9c mmc: pwrseq: Document DT bindings for the simple MMC power sequence 1b745e8a4627 mmc: core: Initial support for MMC power sequences -- 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/2] watchdog: jz4740: Add DT support
Hi, Here are two simple patches that add DT support to the jz4740 watchdog driver. Patches are based on 3.19-rc6. Quite disjoint and stay within jz4740 so should apply easily on other trees. If you would like to have them rebased to a different tree, please tell. V2 Changes Renamed binding to jz4740 instead of jz47xx Removed clk bindings. They can be added later when the clock tree is fixed. Rather than add bindings now and change later. Added MODULE_DEVICE_TABLE() Thank-you ZubairLK Zubair Lutfullah Kakakhel (2): dt: watchdog: Add DT binding documentation for jz4740 watchdog timer watchdog: jz4740: Add DT support .../devicetree/bindings/watchdog/ingenic,jz4740-wdt.txt | 12 drivers/watchdog/jz4740_wdt.c| 10 ++ 2 files changed, 22 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/ingenic,jz4740-wdt.txt -- 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] dt: watchdog: Add DT binding documentation for jz4740 watchdog timer
Add binding for jz4740 watchdog timer. It is a simple watchdog timer.
Signed-off-by: Zubair Lutfullah Kakakhel zubair.kakak...@imgtec.com
---
The jz4740 is platform only at the moment.
But DT support is being added
See http://patchwork.linux-mips.org/bundle/paulburton/ci20-v3.20/
V2 Changes
Removed clock binding because of pending work in clock tree. Will add
binding later. Rather than introduce a bad binding now and change later.
Renamed to jz4740 instead of jz47xx.
---
.../devicetree/bindings/watchdog/ingenic,jz4740-wdt.txt | 12
1 file changed, 12 insertions(+)
create mode 100644
Documentation/devicetree/bindings/watchdog/ingenic,jz4740-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/ingenic,jz4740-wdt.txt
b/Documentation/devicetree/bindings/watchdog/ingenic,jz4740-wdt.txt
new file mode 100644
index 000..e27763e
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/ingenic,jz4740-wdt.txt
@@ -0,0 +1,12 @@
+Ingenic Watchdog Timer (WDT) Controller for JZ4740
+
+Required properties:
+compatible: ingenic,jz4740-watchdog
+reg: Register address and length for watchdog registers
+
+Example:
+
+watchdog: jz4740-watchdog@0x10002000 {
+ compatible = ingenic,jz4740-watchdog;
+ reg = 0x10002000 0x100;
+};
--
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] watchdog: jz4740: Add DT support
Add DT support to the jz4740 driver. Simple of_match_ptr. No other
modification for probe needed
Signed-off-by: Zubair Lutfullah Kakakhel zubair.kakak...@imgtec.com
Reviewed-by: Guenetr Roeck li...@roeck-us.net
---
V2 changes
Add module device table. Even though we are moving to non-dt for jz4740.
Lets try and not break things while at it.
Renamed jz4740_of_match to jz4740_wdt_of_match
---
drivers/watchdog/jz4740_wdt.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
index 18e41af..4c2cc09 100644
--- a/drivers/watchdog/jz4740_wdt.c
+++ b/drivers/watchdog/jz4740_wdt.c
@@ -24,6 +24,7 @@
#include linux/clk.h
#include linux/slab.h
#include linux/err.h
+#include linux/of.h
#include asm/mach-jz4740/timer.h
@@ -142,6 +143,14 @@ static const struct watchdog_ops jz4740_wdt_ops = {
.set_timeout = jz4740_wdt_set_timeout,
};
+#ifdef CONFIG_OF
+static const struct of_device_id jz4740_wdt_of_matches[] = {
+ { .compatible = ingenic,jz4740-watchdog, },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, jz4740_wdt_of_matches)
+#endif
+
static int jz4740_wdt_probe(struct platform_device *pdev)
{
struct jz4740_wdt_drvdata *drvdata;
@@ -211,6 +220,7 @@ static struct platform_driver jz4740_wdt_driver = {
.remove = jz4740_wdt_remove,
.driver = {
.name = jz4740-wdt,
+ .of_match_table = of_match_ptr(jz4740_wdt_of_matches),
},
};
--
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: [RFC V2] OPP: Redefine bindings to overcome shortcomings
On Thu, Jan 29, 2015 at 07:09:23AM +0530, Viresh Kumar wrote: On 29 January 2015 at 01:36, Mark Brown broo...@kernel.org wrote: + Required properties: + - compatible: allow OPPs to express their compatibility. + - opp-list: phandle to opp-list defined above. I don't understand what that compatible property is intended to mean and I expect other readers might be similarly confused - is it a standard compatbile property meaning this noe corresponds to some sort of device? The goal is to choose the driver which we want to probe for a platform. There can be multiple DT enabled cpufreq drivers present in a build and the platform needs some way to choose one of them. So you need to document this as a platform device then if that's what you're doing here; there's more than just specifying a compatible string involved. signature.asc Description: Digital signature
Re: [RFC V2] OPP: Redefine bindings to overcome shortcomings
On 29 January 2015 at 16:37, Mark Brown broo...@kernel.org wrote: On Thu, Jan 29, 2015 at 07:09:23AM +0530, Viresh Kumar wrote: The goal is to choose the driver which we want to probe for a platform. There can be multiple DT enabled cpufreq drivers present in a build and the platform needs some way to choose one of them. So you need to document this as a platform device then if that's what you're doing here; there's more than just specifying a compatible string involved. Will elaborate more on this to make it crystal clear.. -- 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/5] genirq: Authorize chained handlers to remain disabled when initialized
Currently there is no way to keep a chained handler disabled when
registering it.
This might be annoying for irq demuxer that want to keep the source irq
disabled until at least one of their child irq is requested.
Replace the is_chained argument of __irq_set_handler by an enum, thus
adding a new CHAINED_NOSTARTUP mode which explicitly ask for the
interruption to remain disabled.
Update all __irq_set_handler users to use the enum value instead of a
numerical one and add a new irq_set_chained_handler_nostartup helper
function (as done for irq_set_handler and irq_set_chained_handler).
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
include/linux/irq.h| 26 ++
kernel/irq/chip.c | 12 +++-
kernel/irq/irqdomain.c | 2 +-
kernel/irq/msi.c | 3 ++-
4 files changed, 32 insertions(+), 11 deletions(-)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index d09ec7a..247b2d1 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -489,25 +489,43 @@ static inline void irq_set_chip_and_handler(unsigned int
irq, struct irq_chip *c
extern int irq_set_percpu_devid(unsigned int irq);
+enum chained_mode {
+ IRQ_CHAINED_NONE,
+ IRQ_CHAINED_STARTUP,
+ IRQ_CHAINED_NOSTARTUP,
+};
+
extern void
-__irq_set_handler(unsigned int irq, irq_flow_handler_t handle, int is_chained,
+__irq_set_handler(unsigned int irq, irq_flow_handler_t handle,
+ enum chained_mode chained_mode,
const char *name);
static inline void
irq_set_handler(unsigned int irq, irq_flow_handler_t handle)
{
- __irq_set_handler(irq, handle, 0, NULL);
+ __irq_set_handler(irq, handle, IRQ_CHAINED_NONE, NULL);
}
/*
* Set a highlevel chained flow handler for a given IRQ.
- * (a chained handler is automatically enabled and set to
+ * (this chained handler is automatically enabled and set to
* IRQ_NOREQUEST, IRQ_NOPROBE, and IRQ_NOTHREAD)
*/
static inline void
irq_set_chained_handler(unsigned int irq, irq_flow_handler_t handle)
{
- __irq_set_handler(irq, handle, 1, NULL);
+ __irq_set_handler(irq, handle, IRQ_CHAINED_STARTUP, NULL);
+}
+
+/*
+ * Set a highlevel chained flow handler for a given IRQ without starting it.
+ * (this chained handler is kept disabled and set to IRQ_NOREQUEST,
+ * IRQ_NOPROBE, and IRQ_NOTHREAD)
+ */
+static inline void
+irq_set_chained_handler_nostartup(unsigned int irq, irq_flow_handler_t handle)
+{
+ __irq_set_handler(irq, handle, IRQ_CHAINED_NOSTARTUP, NULL);
}
void irq_modify_status(unsigned int irq, unsigned long clr, unsigned long set);
diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index 6f1c7a5..5de82dc0 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -719,7 +719,8 @@ void handle_percpu_devid_irq(unsigned int irq, struct
irq_desc *desc)
}
void
-__irq_set_handler(unsigned int irq, irq_flow_handler_t handle, int is_chained,
+__irq_set_handler(unsigned int irq, irq_flow_handler_t handle,
+ enum chained_mode chained_mode,
const char *name)
{
unsigned long flags;
@@ -748,7 +749,7 @@ __irq_set_handler(unsigned int irq, irq_flow_handler_t
handle, int is_chained,
* and the interrrupt supposed to be started
* right away.
*/
- if (WARN_ON(is_chained))
+ if (WARN_ON(chained_mode != IRQ_CHAINED_NONE))
goto out;
/* Try the parent */
irq_data = irq_data-parent_data;
@@ -768,11 +769,12 @@ __irq_set_handler(unsigned int irq, irq_flow_handler_t
handle, int is_chained,
desc-handle_irq = handle;
desc-name = name;
- if (handle != handle_bad_irq is_chained) {
+ if (handle != handle_bad_irq chained_mode != IRQ_CHAINED_NONE) {
irq_settings_set_noprobe(desc);
irq_settings_set_norequest(desc);
irq_settings_set_nothread(desc);
- irq_startup(desc, true);
+ if (chained_mode == IRQ_CHAINED_STARTUP)
+ irq_startup(desc, true);
}
out:
irq_put_desc_busunlock(desc, flags);
@@ -784,7 +786,7 @@ irq_set_chip_and_handler_name(unsigned int irq, struct
irq_chip *chip,
irq_flow_handler_t handle, const char *name)
{
irq_set_chip(irq, chip);
- __irq_set_handler(irq, handle, 0, name);
+ __irq_set_handler(irq, handle, IRQ_CHAINED_NONE, name);
}
EXPORT_SYMBOL_GPL(irq_set_chip_and_handler_name);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 7fac311..d5aee6c 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -943,7 +943,7 @@ void irq_domain_set_info(struct irq_domain *domain,
unsigned int virq,
void *handler_data, const char *handler_name)
{
Re: [PATCH v2 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
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. 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
[PATCH v4 6/7] ARM: mvebu: Update the SDHCI node on Armada 38x
The binding of the armada-380-sdhci has been extended with a new
register in order to be able to use the SDR50 and DDR50 mode. This
commit add the resource associated to this new register for the
Armada 38x.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
arch/arm/boot/dts/armada-38x.dtsi | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-38x.dtsi
b/arch/arm/boot/dts/armada-38x.dtsi
index 71d4eca5b497..474b2ebf4a82 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -515,7 +515,10 @@
sdhci@d8000 {
compatible = marvell,armada-380-sdhci;
- reg = 0xd8000 0x1000, 0xdc000 0x100;
+ reg-names = sdhci, mbus, conf-sdio3;
+ reg = 0xd8000 0x1000,
+ 0xdc000 0x100,
+ 0x18454 0x4;
interrupts = GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH;
clocks = gateclk 17;
mrvl,clk-delay-cycles = 0x1F;
--
2.1.0
--
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 4/7] mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes
From: Marcin Wojtas m...@semihalf.com
According to erratum 'FE-2946959' both SDR50 and DDR50 modes require
specific clock adjustments in SDIO3 Configuration register.
This commit add the support of this register and for SDR50 or DDR50
mode use it as suggested by the erratum:
- Set the SDIO3 Clock Inv field in SDIO3 Configuration register to not
inverted.
- Set the Sample FeedBack Clock field to 0x1
[gregory.clem...@free-electrons.com: port from 3.10]
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
drivers/mmc/host/sdhci-pxav3.c | 58 --
1 file changed, 50 insertions(+), 8 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index c6394d81e120..0f3f597a1c60 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -62,6 +62,7 @@ struct sdhci_pxa {
struct clk *clk_core;
struct clk *clk_io;
u8 power_mode;
+ void __iomem *sdio3_conf_reg;
};
/*
@@ -72,6 +73,14 @@ struct sdhci_pxa {
#define SDHCI_WINDOW_BASE(i) (0x84 + ((i) 3))
#define SDHCI_MAX_WIN_NUM 8
+/*
+ * Fields below belong to SDIO3 Configuration Register (third register
+ * region for the Armada 38x flavor)
+ */
+
+#define SDIO3_CONF_CLK_INV BIT(0)
+#define SDIO3_CONF_SD_FB_CLK BIT(2)
+
static int mv_conf_mbus_windows(struct platform_device *pdev,
const struct mbus_dram_target_info *dram)
{
@@ -122,16 +131,29 @@ static int armada_38x_quirks(struct platform_device *pdev,
struct sdhci_host *host)
{
struct device_node *np = pdev-dev.of_node;
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_pxa *pxa = pltfm_host-priv;
+ struct resource *res;
host-quirks |= SDHCI_QUIRK_MISSING_CAPS;
- /*
-* According to erratum 'FE-2946959' both SDR50 and DDR50
-* modes require specific clock adjustments in SDIO3
-* Configuration register, if the adjustment is not done,
-* remove them from the capabilities.
-*/
- host-caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
- host-caps1 = ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
+ res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+ conf-sdio3);
+ if (res) {
+ pxa-sdio3_conf_reg = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(pxa-sdio3_conf_reg))
+ return PTR_ERR(pxa-sdio3_conf_reg);
+ } else {
+ /*
+* According to erratum 'FE-2946959' both SDR50 and DDR50
+* modes require specific clock adjustments in SDIO3
+* Configuration register, if the adjustment is not done,
+* remove them from the capabilities.
+*/
+ host-caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+ host-caps1 = ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
+
+ dev_warn(pdev-dev, conf-sdio3 register not found: disabling
SDR50 and DDR50 modes.\nConsider updating your dtb\n);
+ }
/*
* According to erratum 'ERR-7878951' Armada 38x SDHCI
@@ -226,6 +248,8 @@ static void pxav3_gen_init_74_clocks(struct sdhci_host
*host, u8 power_mode)
static void pxav3_set_uhs_signaling(struct sdhci_host *host, unsigned int uhs)
{
+ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+ struct sdhci_pxa *pxa = pltfm_host-priv;
u16 ctrl_2;
/*
@@ -255,6 +279,24 @@ static void pxav3_set_uhs_signaling(struct sdhci_host
*host, unsigned int uhs)
break;
}
+ /*
+* Update SDIO3 Configuration register according to erratum
+* FE-2946959
+*/
+ if (pxa-sdio3_conf_reg) {
+ u8 reg_val = readb(pxa-sdio3_conf_reg);
+
+ if (uhs == MMC_TIMING_UHS_SDR50 ||
+ uhs == MMC_TIMING_UHS_DDR50) {
+ reg_val = ~SDIO3_CONF_CLK_INV;
+ reg_val |= SDIO3_CONF_SD_FB_CLK;
+ } else {
+ reg_val |= SDIO3_CONF_CLK_INV;
+ reg_val = ~SDIO3_CONF_SD_FB_CLK;
+ }
+ writeb(reg_val, pxa-sdio3_conf_reg);
+ }
+
sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
dev_dbg(mmc_dev(host-mmc),
%s uhs = %d, ctrl_2 = %04X\n,
--
2.1.0
--
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 7/7] ARM: mvebu: Add Device Tree description of SDHCI for Armada 388 RD
The Device Tree description of SDHCI on Armada 388 RD board was
missing. This commit adds the node for it.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
arch/arm/boot/dts/armada-388-rd.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/armada-388-rd.dts
b/arch/arm/boot/dts/armada-388-rd.dts
index c98a8f8d01a9..7dfede145ea3 100644
--- a/arch/arm/boot/dts/armada-388-rd.dts
+++ b/arch/arm/boot/dts/armada-388-rd.dts
@@ -51,6 +51,16 @@
clock-frequency = 10;
};
+ sdhci@d8000 {
+ pinctrl-names = default;
+ pinctrl-0 = sdhci_pins;
+ broken-cd;
+ no-1-8-v;
+ wp-inverted;
+ bus-width = 8;
+ status = okay;
+ };
+
serial@12000 {
status = okay;
};
--
2.1.0
--
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 2/7] mmc: sdhci-pxav3: Fix Armada 38x controller's caps according to erratum ERR-7878951
From: Marcin Wojtas m...@semihalf.com
According to erratum 'ERR-7878951' Armada 38x SDHCI controller has
different capabilities than the ones shown in its registers:
- it doesn't support the voltage switching: it can work either with
3.3V or 1.8V supply
- it doesn't support the SDR104 mode
- SDR50 mode doesn't need tuning
The SDHCI_QUIRK_MISSING_CAPS quirk is used for updating the
capabilities accordingly.
[gregory.clem...@free-electrons.com: port from 3.10]
Fixes: 5491ce3f79ee (mmc: sdhci-pxav3: add support for the Armada 38x SDHCI
controller)
Cc: sta...@vger.kernel.org # v3.15+
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
drivers/mmc/host/sdhci-pxav3.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index 5765015cc2e2..c6394d81e120 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -118,8 +118,11 @@ static int mv_conf_mbus_windows(struct platform_device
*pdev,
return 0;
}
-static int armada_38x_quirks(struct sdhci_host *host)
+static int armada_38x_quirks(struct platform_device *pdev,
+struct sdhci_host *host)
{
+ struct device_node *np = pdev-dev.of_node;
+
host-quirks |= SDHCI_QUIRK_MISSING_CAPS;
/*
* According to erratum 'FE-2946959' both SDR50 and DDR50
@@ -129,6 +132,21 @@ static int armada_38x_quirks(struct sdhci_host *host)
*/
host-caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
host-caps1 = ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
+
+ /*
+* According to erratum 'ERR-7878951' Armada 38x SDHCI
+* controller has different capabilities than the ones shown
+* in its registers
+*/
+ host-caps = sdhci_readl(host, SDHCI_CAPABILITIES);
+ if (of_property_read_bool(np, no-1-8-v)) {
+ host-caps = ~SDHCI_CAN_VDD_180;
+ host-mmc-caps = ~MMC_CAP_1_8V_DDR;
+ } else {
+ host-caps = ~SDHCI_CAN_VDD_330;
+ }
+ host-caps1 = ~(SDHCI_SUPPORT_SDR104 | SDHCI_USE_SDR50_TUNING);
+
return 0;
}
@@ -332,8 +350,11 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
if (!IS_ERR(pxa-clk_core))
clk_prepare_enable(pxa-clk_core);
+ /* enable 1/8V DDR capable */
+ host-mmc-caps |= MMC_CAP_1_8V_DDR;
+
if (of_device_is_compatible(np, marvell,armada-380-sdhci)) {
- ret = armada_38x_quirks(host);
+ ret = armada_38x_quirks(pdev, host);
if (ret 0)
goto err_clk_get;
ret = mv_conf_mbus_windows(pdev, mv_mbus_dram_info());
@@ -341,9 +362,6 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
goto err_mbus_win;
}
- /* enable 1/8V DDR capable */
- host-mmc-caps |= MMC_CAP_1_8V_DDR;
-
match = of_match_device(of_match_ptr(sdhci_pxav3_of_match), pdev-dev);
if (match) {
ret = mmc_of_parse(host-mmc);
--
2.1.0
--
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/7] mmc: sdhci-pxav3: Extend binding with SDIO3 conf reg for the Armada 38x
The SDHCI unit used on the Armada 38x needs using an extra register to
do specific clock adjustments in order to support the SDR50 and DDR50
modes. This patch extends the binding to allow using this register.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
Documentation/devicetree/bindings/mmc/sdhci-pxa.txt | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
index 4dd6deb90719..3d1b449d6097 100644
--- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
+++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.txt
@@ -9,9 +9,13 @@ Required properties:
- reg:
* for mrvl,pxav2-mmc and mrvl,pxav3-mmc, one register area for
the SDHCI registers.
- * for marvell,armada-380-sdhci, two register areas. The first one
-for the SDHCI registers themselves, and the second one for the
-AXI/Mbus bridge registers of the SDHCI unit.
+
+ * for marvell,armada-380-sdhci, three register areas. The first
+one for the SDHCI registers themselves, the second one for the
+AXI/Mbus bridge registers of the SDHCI unit, the third one for the
+SDIO3 Configuration register
+- reg names: should be sdhci, mbus, conf-sdio3. only mandatory
+ for marvell,armada-380-sdhci
- clocks: Array of clocks required for SDHCI; requires at least one for
I/O clock.
- clock-names: Array of names corresponding to clocks property; shall be
@@ -35,7 +39,10 @@ sdhci@d4280800 {
sdhci@d8000 {
compatible = marvell,armada-380-sdhci;
- reg = 0xd8000 0x1000, 0xdc000 0x100;
+ reg-names = sdhci, mbus, conf-sdio3;
+ reg = 0xd8000 0x1000,
+ 0xdc000 0x100;
+ 0x18454 0x4;
interrupts = 0 25 0x4;
clocks = gateclk 17;
clock-names = io;
--
2.1.0
--
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 0/7] Fixes and improvements for SDHCI on Armada 38x
Hi, this series brings fixes and improvements for the SDHCI controller of the Armada 38x SoCs. The changes for this forth version was done on the 1st and 4th patches, see the changelog for the details. The first two patches are fixes and should be also applied on the stable branch (I added stable in copy for this). The first one removes the SDR50 and DDR50 mode timing from the capabilities of the controller because the current implementation doesn't support it. The second one fix controller's caps according to the limitation of the hardware. The third one extends the Device Tree binding of the Armada 38x. It allows using the SDIO3 configuration register. The forth patch adds the support of this new register in the driver. Thanks to this one, specific clock adjustments can be done in order to support the SDR50 and DDR50 modes timing. The fifth patch is device tree clean-up. The sixth patch update the SDHCI node on Armada 38x in order to use the new register and then to be able to support the SDR50 and DDR50 modes timing. Finally, the seventh patch add the description of SDHCI for the Armada 388 RD board which was missing. Patches 1 to 4 should be merged through the mmc tree and patches 5 to 7 should be merged through mvebu and then arm-soc. Patch 4 depend on patch 2. Patch 2 depend on patch 1. And patch 1 depend on commit aa8165f91442 mmc: sdhci-pxav3: do the mbus window configuration after enabling clocks which have been merged. But as all this patch should be merged through the same tree it would not be a problem The patches 5 to 7 depend on the patches already merged in mvebu. As they are fixes, patches 1 and 2 should be merged in 3.18-rc or at least in 3.19 and then they will be part of 3.18.1. For the other patches it would be nice if they could be part of 3.19. Thanks, Gregory Changelog: v3 - v4: - Merge the 3 dev_wanr message in a single one - Remove err_quirks label v2 - v3: - Use of_property_read_bool() instead of of_get_property - Brace the else case according to the Documentation/CodingStyle - Move the setting of MMC_CAP_1_8V_DDR before the armada_38x_quirks calls v1 - v2: - Put back Marcin as author of patch 2 and 3 - Removed MMC_CAP_1_8V_DDR in the probe function Gregory CLEMENT (5): mmc: sdhci-pxav3: Fix SDR50 and DDR50 capabilities for the Armada 38x flavor mmc: sdhci-pxav3: Extend binding with SDIO3 conf reg for the Armada 38x ARM: mvebu: Use macros for interrupt flags on Armada 38x sdhci node ARM: mvebu: Update the SDHCI node on Armada 38x ARM: mvebu: Add Device Tree description of SDHCI for Armada 388 RD Gregory CLEMENT (5): mmc: sdhci-pxav3: Fix SDR50 and DDR50 capabilities for the Armada 38x flavor mmc: sdhci-pxav3: Extend binding with SDIO3 conf reg for the Armada 38x ARM: mvebu: Use macros for interrupt flags on Armada 38x sdhci node ARM: mvebu: Update the SDHCI node on Armada 38x ARM: mvebu: Add Device Tree description of SDHCI for Armada 388 RD Marcin Wojtas (2): mmc: sdhci-pxav3: Fix Armada 38x controller's caps according to erratum ERR-7878951 mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes .../devicetree/bindings/mmc/sdhci-pxa.txt | 15 ++-- arch/arm/boot/dts/armada-388-rd.dts| 10 +++ arch/arm/boot/dts/armada-38x.dtsi | 7 +- drivers/mmc/host/sdhci-pxav3.c | 83 +- 4 files changed, 106 insertions(+), 9 deletions(-) -- 2.1.0 -- 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/7] mmc: sdhci-pxav3: Fix SDR50 and DDR50 capabilities for the Armada 38x flavor
According to erratum 'FE-2946959' both SDR50 and DDR50 modes require
specific clock adjustments in SDIO3 Configuration register. However,
this register was not part of the device tree binding. Even if the
binding can (and will) be extended we still need handling the case
where this register was not available. In this case we use the
SDHCI_QUIRK_MISSING_CAPS quirk remove them from the capabilities.
This commit is based on the work done by Marcin Wojtasm...@semihalf.com
Fixes: 5491ce3f79ee (mmc: sdhci-pxav3: add support for the Armada 38x SDHCI
controller)
Cc: sta...@vger.kernel.org # v3.15+
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
Signed-off-by: Marcin Wojtas m...@semihalf.com
---
drivers/mmc/host/sdhci-pxav3.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/mmc/host/sdhci-pxav3.c b/drivers/mmc/host/sdhci-pxav3.c
index ca3424e7ef71..5765015cc2e2 100644
--- a/drivers/mmc/host/sdhci-pxav3.c
+++ b/drivers/mmc/host/sdhci-pxav3.c
@@ -118,6 +118,20 @@ static int mv_conf_mbus_windows(struct platform_device
*pdev,
return 0;
}
+static int armada_38x_quirks(struct sdhci_host *host)
+{
+ host-quirks |= SDHCI_QUIRK_MISSING_CAPS;
+ /*
+* According to erratum 'FE-2946959' both SDR50 and DDR50
+* modes require specific clock adjustments in SDIO3
+* Configuration register, if the adjustment is not done,
+* remove them from the capabilities.
+*/
+ host-caps1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+ host-caps1 = ~(SDHCI_SUPPORT_SDR50 | SDHCI_SUPPORT_DDR50);
+ return 0;
+}
+
static void pxav3_reset(struct sdhci_host *host, u8 mask)
{
struct platform_device *pdev = to_platform_device(mmc_dev(host-mmc));
@@ -319,6 +333,9 @@ static int sdhci_pxav3_probe(struct platform_device *pdev)
clk_prepare_enable(pxa-clk_core);
if (of_device_is_compatible(np, marvell,armada-380-sdhci)) {
+ ret = armada_38x_quirks(host);
+ if (ret 0)
+ goto err_clk_get;
ret = mv_conf_mbus_windows(pdev, mv_mbus_dram_info());
if (ret 0)
goto err_mbus_win;
--
2.1.0
--
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 5/7] ARM: mvebu: Use macros for interrupt flags on Armada 38x sdhci node
Instead of hardcoding the values of the interrupt flags, use the
macros provided by include/dt-bindings/interrupt-controller/irq.h
and include/dt-bindings/interrupt-controller/arm-gic.h for the
Armada 38x SDHCI node.
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
arch/arm/boot/dts/armada-38x.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-38x.dtsi
b/arch/arm/boot/dts/armada-38x.dtsi
index 79c4acf186e2..71d4eca5b497 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -516,7 +516,7 @@
sdhci@d8000 {
compatible = marvell,armada-380-sdhci;
reg = 0xd8000 0x1000, 0xdc000 0x100;
- interrupts = 0 25 0x4;
+ interrupts = GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH;
clocks = gateclk 17;
mrvl,clk-delay-cycles = 0x1F;
status = disabled;
--
2.1.0
--
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] dma: Add Xilinx AXI Direct Memory Access Engine driver support
Hi Vinod, -Original Message- From: Appana Durga Kedareswara Rao Sent: Monday, January 19, 2015 7:39 PM To: 'Arnd Bergmann'; vinod.k...@intel.com Cc: linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org; vinod.k...@intel.com; Srikanth Vemula; linux-ker...@vger.kernel.org; Srikanth Thokala; dmaeng...@vger.kernel.org; robh...@kernel.org; Michal Simek; Anirudha Sarangi; grant.lik...@linaro.org; dan.j.willi...@intel.com Subject: RE: [PATCH v4] dma: Add Xilinx AXI Direct Memory Access Engine driver support Hi Arnd, -Original Message- From: Arnd Bergmann [mailto:a...@arndb.de] Sent: Friday, October 24, 2014 7:29 PM To: Appana Durga Kedareswara Rao Cc: linux-arm-ker...@lists.infradead.org; devicetree@vger.kernel.org; vinod.k...@intel.com; Srikanth Vemula; linux-ker...@vger.kernel.org; Srikanth Thokala; dmaeng...@vger.kernel.org; robh...@kernel.org; Michal Simek; Anirudha Sarangi; grant.lik...@linaro.org; dan.j.willi...@intel.com Subject: Re: [PATCH v4] dma: Add Xilinx AXI Direct Memory Access Engine driver support On Friday 24 October 2014 12:08:26 Appana Durga Kedareswara Rao wrote: From: Arnd Bergmann [mailto:a...@arndb.de] On Tuesday 21 October 2014 09:06:13 Appana Durga Kedareswara Rao wrote: The above mentioned API's and structures will be used by the dma test client driver's to set hardware configuration information. The dma client drivers are not mainlined yet and it is Internally used by our git-tree to test the DMA functionality in loopback . I would suggest you add the test driver into the main dmaengine driver file directly then, so you don't need to export the symbols. If there are important reasons to keep that as separate files, just move the header to the drivers/dma/ directory and add the test driver there. Sorry I forgot to mention the below things in the mail .The Config API's and structures not only used by the dmaengine driver's but also used by the various IP's (Ex: Ethernet driver and SRIO driver these drivers are under development).For example the Ethernet driver is resides under drivers/net/ethernet but it needs to set some specific configuration parameters of the dma that's why created a separate header file for the h/w configurable parameters. That is a bug in the ethernet driver, and we should not merge such code. Please fix those drivers before submitting them, so they don't rely on additional interfaces beyond what the DMA engine API provides. If you need something that the common interface is missing, you can send a patch to extend the dmaengine core driver, but more likely it already does what you need and you are just not using it right. Sorry for the delay in the reply. We need that header file in the include/linux/ directory for various reasons. As you know the Xilinx DMA's have a set of configurable parameters which we expect the DMA users to take advantage of. For example: For Axi DMA we have the following parameters that we expect to be commonly used. Coalesce count -- Used to configure the coalesce value. Delay timer --- Used to set the delay value. We expect the Xilinx AXI Ethernet driver to use the Axi DMA driver in near furture. If so, using ethtool, we expect the driver users to play with the above parameters to do performance tuning. Hence AxiDMA driver must expose means to change coalese count or delay timer. Similarly For Axi VDMA we have the following parameters that will be used by the users of this driver. hsize -- Used to configure number of bytes per line. vsize --Number of lines per frame. stride -- Number of bytes per line. Earlier in the driver we are embedding dma_slave_config into custom structs But Lars suggested to modify it. please refer to the below thread for more details. http://www.spinics.net/lists/dmaengine/msg00010.html And later we thought of creating a separate private member in dma_slave_config for sharing additional configuration between slave device and dma engine Or a new dma_ctrl_cmd like FSLDMA_EXTERNAL_START(http://www.kernelhub.org/?msg=405535p=2 ) Finally Vinod was ok with the existing suggestion so we dropped the above thought. @Vinod : Could you please comment on this. Ping ? Regards, Kedar. Regards, Kedar. Arnd This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately. -- 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 3/6] iio: adc: fsl,imx25-gcq driver
On Tue, Jan 27, 2015 at 08:30:56PM +, Jonathan Cameron wrote:
On 24/01/15 14:01, 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
A couple of queries inline.
---
Notes:
Changes in v5:
- Fixed locking
- Removed module owner
.../devicetree/bindings/iio/adc/fsl,imx25-gcq.txt | 51 +++
drivers/iio/adc/Kconfig| 7 +
drivers/iio/adc/Makefile | 1 +
drivers/iio/adc/fsl-imx25-gcq.c| 369
+
include/dt-bindings/iio/adc/fsl-imx25-gcq.h| 11 +
5 files changed, 439 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
create mode 100644 drivers/iio/adc/fsl-imx25-gcq.c
create mode 100644 include/dt-bindings/iio/adc/fsl-imx25-gcq.h
diff --git a/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
new file mode 100644
index ..d55b6b751349
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
@@ -0,0 +1,51 @@
+Freescale i.MX25 ADC GCQ device
+
+This is a generic conversion queue device that can convert any of the
+analog inputs using the ADC unit of the i.MX25.
+
+Required properties:
+ - compatible: Should be fsl,imx25-gcq.
+ - reg: Should be the register range of the module.
+ - interrupts: Should be the interrupt number of the module.
+ Typically this is 1.
+ - interrupt-parent: phandle to the tsadc module of the i.MX25.
+ - #address-cells: Should be 1 (setting for the subnodes)
+ - #size-cells: Should be 0 (setting for the subnodes)
+
+Optional properties:
+ - vref-supply: The regulator supplying the ADC reference voltage.
+ Required when at least one subnode uses the external reference.
+
+Sub-nodes:
+Optionally you can define subnodes which define the reference voltage
+for the analog inputs.
+
+Required properties for subnodes:
+ - reg: Should be the number of the analog input.
+ 0: xp
+ 1: yp
+ 2: xn
+ 3: yn
+ 4: wiper
+ 5: inaux0
+ 6: inaux1
+ 7: inaux2
+ - fsl,adc-ref: specifies the reference input as defined in
+ dt-bindings/iio/adc/fsl-imx25-gcq.h
+ MX25_ADC_REF_INT and MX25_ADC_REF_EXT flags are supported.
+
+Example:
+
+ adc: adc@50030800 {
+ compatible = fsl,imx25-gcq;
+ reg = 0x50030800 0x60;
+ interrupt-parent = tscadc;
+ interrupts = 1;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ inaux@5 {
+ reg = 5;
+ fsl,adc-ref = MX25_ADC_REF_INT;
+ };
+ };
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 0f79e4725763..fccbb4bf44cc 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -143,6 +143,13 @@ config EXYNOS_ADC
of SoCs for drivers such as the touchscreen and hwmon to use to share
this resource.
+config FSL_MX25_ADC
+ tristate Freescale MX25 ADC driver
+ depends on MFD_MX25_TSADC
+ help
+ Generic Conversion Queue driver used for general purpose ADC in the
+ MX25. This driver supports single measurements using the MX25 ADC.
+
config LP8788_ADC
tristate LP8788 ADC driver
depends on MFD_LP8788
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 701fdb7c96aa..acab8d956371 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_AD799X) += ad799x.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
+obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
obj-$(CONFIG_MAX1027) += max1027.o
obj-$(CONFIG_MAX1363) += max1363.o
diff --git a/drivers/iio/adc/fsl-imx25-gcq.c
b/drivers/iio/adc/fsl-imx25-gcq.c
new file mode 100644
index ..c1ac5af41ec5
--- /dev/null
+++ b/drivers/iio/adc/fsl-imx25-gcq.c
@@ -0,0 +1,369 @@
+/*
+ * Copyright 2014 Markus Pargmann, Pengutronix m...@pengutronix.de
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of
[PATCH v4 2/5] irqchip: add virtual demultiplexer implementation
Some interrupt controllers are multiplexing several peripheral IRQs on
a single interrupt line.
While this is not a problem for most IRQs (as long as all peripherals
request the interrupt with IRQF_SHARED flag set), multiplexing timers and
other type of peripherals will generate a WARNING (mixing IRQF_NO_SUSPEND
and !IRQF_NO_SUSPEND is prohibited).
Create a dumb irq demultiplexer which simply forwards interrupts to all
peripherals (exactly what's happening with IRQ_SHARED) but keep a unique
irq number for each peripheral, thus preventing the IRQF_NO_SUSPEND
and !IRQF_NO_SUSPEND mix on a given interrupt.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
---
drivers/irqchip/Kconfig | 4 ++
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-virt-demux.c | 72
include/linux/irq.h | 38 +++
include/linux/irqdomain.h| 1 +
kernel/irq/Kconfig | 5 ++
kernel/irq/Makefile | 1 +
kernel/irq/chip.c| 41
kernel/irq/handle.c | 31 -
kernel/irq/internals.h | 3 +
kernel/irq/virt-demux-chip.c | 140 +++
11 files changed, 335 insertions(+), 2 deletions(-)
create mode 100644 drivers/irqchip/irq-virt-demux.c
create mode 100644 kernel/irq/virt-demux-chip.c
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index cc79d2a..268f01f 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -70,6 +70,10 @@ config BRCMSTB_L2_IRQ
select GENERIC_IRQ_CHIP
select IRQ_DOMAIN
+config VIRT_DEMUX_IRQ
+ bool
+ select VIRT_IRQ_DEMUX_CHIP
+
config DW_APB_ICTL
bool
select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 9516a32..ee81262 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_ARCH_MVEBU)+= irq-armada-370-xp.o
obj-$(CONFIG_ARCH_MXS) += irq-mxs.o
obj-$(CONFIG_ARCH_S3C24XX) += irq-s3c24xx.o
obj-$(CONFIG_DW_APB_ICTL) += irq-dw-apb-ictl.o
+obj-$(CONFIG_VIRT_DEMUX_IRQ) += irq-virt-demux.o
obj-$(CONFIG_METAG)+= irq-metag-ext.o
obj-$(CONFIG_METAG_PERFCOUNTER_IRQS) += irq-metag.o
obj-$(CONFIG_ARCH_MOXART) += irq-moxart.o
diff --git a/drivers/irqchip/irq-virt-demux.c b/drivers/irqchip/irq-virt-demux.c
new file mode 100644
index 000..501978e
--- /dev/null
+++ b/drivers/irqchip/irq-virt-demux.c
@@ -0,0 +1,72 @@
+/*
+ * Virtual irq demux chip driver
+ *
+ * Copyright (C) 2015 Atmel
+ *
+ * Author: Boris Brezillon boris.brezil...@free-electrons.com
+ *
+ * This file is licensed under GPLv2.
+ */
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/irqdomain.h
+#include linux/of_irq.h
+#include linux/slab.h
+
+#include irqchip.h
+
+static int __init virt_irq_demux_of_init(struct device_node *node,
+struct device_node *parent)
+{
+ struct irq_chip_virt_demux *demux;
+ unsigned int irq;
+ u32 valid_irqs;
+ int ret;
+
+ irq = irq_of_parse_and_map(node, 0);
+ if (!irq) {
+ pr_err(Failed to retrieve virt irq demuxer source\n);
+ return -EINVAL;
+ }
+
+ ret = of_property_read_u32(node, irqs, valid_irqs);
+ if (ret) {
+ pr_err(Invalid of missing 'irqs' property\n);
+ return ret;
+ }
+
+ demux = irq_alloc_virt_demux_chip(irq, valid_irqs,
+ IRQ_NOREQUEST | IRQ_NOPROBE |
+ IRQ_NOAUTOEN, 0);
+ if (!demux) {
+ pr_err(Failed to allocate virt irq demuxer struct\n);
+ return -ENOMEM;
+ }
+
+ demux-domain = irq_domain_add_linear(node, BITS_PER_LONG,
+ irq_virt_demux_domain_ops,
+ demux);
+ if (!demux-domain) {
+ ret = -ENOMEM;
+ goto err_free_demux;
+ }
+
+ ret = irq_set_handler_data(irq, demux);
+ if (ret) {
+ pr_err(Failed to assign handler data\n);
+ goto err_free_domain;
+ }
+
+ irq_set_chained_handler_nostartup(irq, irq_virt_demux_handler);
+
+ return 0;
+
+err_free_domain:
+ irq_domain_remove(demux-domain);
+
+err_free_demux:
+ kfree(demux);
+
+ return ret;
+}
+IRQCHIP_DECLARE(virt_irq_demux, virtual,irq-demux, virt_irq_demux_of_init);
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 247b2d1..b703093 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -445,6 +445,10 @@ extern void handle_fasteoi_irq(unsigned int irq, struct
irq_desc *desc);
extern void handle_edge_irq(unsigned int irq, struct
[PATCH v4 0/5] ARM: at91: fix irq_pm_install_action WARNING
Commit cab303be91dc47942bc25de33dc1140123540800 [1] introduced a WARN_ON test which triggers a WARNING backtrace on at91 platforms. While this WARN_ON is absolutely necessary to warn users that they should not mix request with and without IRQF_NO_SUSPEND flags on shared IRQs, there is no easy way to solve this issue on at91 platforms. The main reason is that the init timer is often using a shared irq line and thus request this irq with IRQF_NO_SUSPEND flag set, while other peripherals request the same irq line without this flag. As suggested by Thomas, the first 3 patches of this series add a dumb demultiplexer irqchip implementation. This demuxer registers to a source interrupt and then forwards all received interrupts to its children (it they are enabled). The last two patches rework at91 DTs and config to make use of this dumb demuxer implementation. Rob, I know you were not in favor of exposing this in the DT but we really need to quickly a solution: more and more people complain about this warning. If you see a better way to handle this case please share it. Best Regards, Boris Changes since v3: - replace dumb by virt Changes since v2: - removed unneeded dumb demux flags passed to irq_alloc_dumb_demux_chip - set nested lockdep class for all requested irqs - add some explanation to the DT binding doc - change the compatible string to clearly show that this chip is purely virtual - added dumb demuxer to all at91 impacted SoCs Changes since v1: - went for an dumb irq demuxer approach instead of trying to fix the current shared irq code Boris Brezillon (5): genirq: Authorize chained handlers to remain disabled when initialized irqchip: add virtual demultiplexer implementation irqchip: Add DT binding doc for the virtual irq demuxer chip ARM: at91/dt: select VIRT_IRQ_DEMUX for all at91 SoCs ARM: at91/dt: define a virtual irq demultiplexer chip connected on irq1 .../bindings/interrupt-controller/dumb-demux.txt | 41 ++ arch/arm/boot/dts/at91rm9200.dtsi | 20 ++- arch/arm/boot/dts/at91sam9260.dtsi | 26 +++- arch/arm/boot/dts/at91sam9261.dtsi | 26 +++- arch/arm/boot/dts/at91sam9263.dtsi | 29 - arch/arm/boot/dts/at91sam9g45.dtsi | 29 - arch/arm/boot/dts/at91sam9n12.dtsi | 25 +++- arch/arm/boot/dts/at91sam9rl.dtsi | 29 - arch/arm/boot/dts/at91sam9x5.dtsi | 26 +++- arch/arm/mach-at91/Kconfig | 2 + drivers/irqchip/Kconfig| 4 + drivers/irqchip/Makefile | 1 + drivers/irqchip/irq-virt-demux.c | 72 +++ include/linux/irq.h| 64 +- include/linux/irqdomain.h | 1 + kernel/irq/Kconfig | 5 + kernel/irq/Makefile| 1 + kernel/irq/chip.c | 53 +++- kernel/irq/handle.c| 31 - kernel/irq/internals.h | 3 + kernel/irq/irqdomain.c | 2 +- kernel/irq/msi.c | 3 +- kernel/irq/virt-demux-chip.c | 140 + 23 files changed, 580 insertions(+), 53 deletions(-) create mode 100644 Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt create mode 100644 drivers/irqchip/irq-virt-demux.c create mode 100644 kernel/irq/virt-demux-chip.c -- 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 4/5] ARM: at91/dt: select VIRT_IRQ_DEMUX for all at91 SoCs
Older at91 SoCs need a virtual irq demuxer to gracefully support the fact that irq1 is shared by several devices and a timer. Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com --- arch/arm/mach-at91/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig index 2395c68..ee4350d 100644 --- a/arch/arm/mach-at91/Kconfig +++ b/arch/arm/mach-at91/Kconfig @@ -28,6 +28,7 @@ config HAVE_AT91_H32MX config SOC_AT91SAM9 bool select ATMEL_AIC_IRQ + select VIRT_DEMUX_IRQ select COMMON_CLK_AT91 select CPU_ARM926T select GENERIC_CLOCKEVENTS @@ -98,6 +99,7 @@ if SOC_SAM_V4_V5 config SOC_AT91RM9200 bool AT91RM9200 select ATMEL_AIC_IRQ + select VIRT_DEMUX_IRQ select COMMON_CLK_AT91 select CPU_ARM920T select GENERIC_CLOCKEVENTS -- 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 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
Add documentation for the virtual irq demuxer.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
---
.../bindings/interrupt-controller/dumb-demux.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt
b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt
new file mode 100644
index 000..b9a7830
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/dumb-demux.txt
@@ -0,0 +1,41 @@
+* Virtual Interrupt Demultiplexer
+
+This virtual demultiplexer simply forward all incoming interrupts to its
+enabled/unmasked children.
+It is only intended to be used by hardware that do not provide a proper way
+to demultiplex a source interrupt, and thus have to wake all their children
+up so that they can possibly handle the interrupt (if needed).
+This can be seen as an alternative to shared interrupts when at least one
+of the interrupt children is a timer (and require the irq to stay enabled
+on suspend) while others are not. This will prevent calling irq handlers of
+non timer devices while they are suspended.
+
+Required properties:
+- compatible: Should be virtual,irq-demux.
+- interrupt-controller: Identifies the node as an interrupt controller.
+- interrupts-extended or interrupt-parent and interrupts: Reference the source
+ interrupt connected to this dumb demuxer.
+- #interrupt-cells: The number of cells to define the interrupts (should be 1).
+ The only cell is the IRQ number.
+- irqs: u32 bitfield specifying the interrupts provided by the demuxer.
+
+Examples:
+ /*
+* virtual demuxer controller
+*/
+ virt_irq1_demux: virt-irq-demux@1 {
+ compatible = virtual,irq-demux;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ interrupts-extended = aic 1 IRQ_TYPE_LEVEL_HIGH 7;
+ irqs = 0x3f;
+ };
+
+ /*
+* Device connected on this dumb demuxer
+*/
+ dma: dma-controller@ec00 {
+ compatible = atmel,at91sam9g45-dma;
+ reg = 0xec00 0x200;
+ interrupts-extended = virt_irq1_demux 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
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. 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. I think that I had to add reset handler, because device_shutdown() was not called if reset was triggered from magic sysrq, but I will check it again. 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. weather to use it always when mmc-pwrseq has been enabled or only if some additional property like 'reset-on-reboot' has been provided. Having a reset GPIO is optional AFAIK so I don't think there is a need for an additional reset-on-reboot propery. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland Best regards, Javier [0]: FYI, these are the relevant commits in linux-next: fe1922d5d4d0 mmc: pwrseq_simple: Add support for a reset GPIO pin ec2017f2491f mmc: pwrseq: Initial support for the simple MMC power sequence provider fe1686658f9c mmc: pwrseq: Document DT bindings for the simple MMC power sequence 1b745e8a4627 mmc: core: Initial support for MMC power sequences Ok, I will check it. 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 v3 1/7] extcon: usb-gpio: Introduce gpio usb extcon driver
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
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ *
[PATCH 0/2] dt: dma: Add DMA driver for jz4780
Hi, Here we have two patches that add a DMA driver for the Ingenic JZ4780 SoC. JZ4780 support is still in-flight. See http://patchwork.linux-mips.org/bundle/paulburton/ci20-v3.20/ These are based on 3.19-rc6. Apart from the channel numbers, jz4740 and jz4780 are quite different. jz4780 has many more features in hardware. Hence, we are unable to use the jz4740-dma driver. ZubairLK Alex Smith (2): dt: dma: Add DT binding document for jz4780-dma dma: jz4780: add driver for the Ingenic JZ4780 DMA controller .../devicetree/bindings/dma/jz4780-dma.txt | 59 ++ drivers/dma/Kconfig| 10 + drivers/dma/Makefile | 1 + drivers/dma/dma-jz4780.c | 856 + include/dt-bindings/dma/jz4780-dma.h | 49 ++ 5 files changed, 975 insertions(+) create mode 100644 Documentation/devicetree/bindings/dma/jz4780-dma.txt create mode 100644 drivers/dma/dma-jz4780.c create mode 100644 include/dt-bindings/dma/jz4780-dma.h -- 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 2/2] dma: jz4780: add driver for the Ingenic JZ4780 DMA controller
From: Alex Smith alex.sm...@imgtec.com This patch adds a driver for the DMA controller found in the Ingenic JZ4780. It currently does not implement any support for the programmable firmware feature of the controller - this is not necessary for most uses. It also does not take priority into account when allocating channels, it just allocates the first available channel. This can be implemented later. Signed-off-by: Alex Smith alex.sm...@imgtec.com --- drivers/dma/Kconfig | 10 + drivers/dma/Makefile | 1 + drivers/dma/dma-jz4780.c | 856 +++ include/dt-bindings/dma/jz4780-dma.h | 49 ++ 4 files changed, 916 insertions(+) create mode 100644 drivers/dma/dma-jz4780.c create mode 100644 include/dt-bindings/dma/jz4780-dma.h diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index f2b2c4e..379509e 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -358,6 +358,16 @@ config DMA_JZ4740 select DMA_ENGINE select DMA_VIRTUAL_CHANNELS +config DMA_JZ4780 + tristate JZ4780 DMA support + depends on MACH_JZ4780 + select DMA_ENGINE + select DMA_VIRTUAL_CHANNELS + help + This selects support for the DMA controller in Ingenic JZ4780 SoCs. + If you have a board based on such a SoC and wish to use DMA for + devices which can use the DMA controller, say Y or M here. + config K3_DMA tristate Hisilicon K3 DMA support depends on ARCH_HI3xxx diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile index 2022b54..609026c 100644 --- a/drivers/dma/Makefile +++ b/drivers/dma/Makefile @@ -41,6 +41,7 @@ obj-$(CONFIG_DMA_OMAP) += omap-dma.o obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o +obj-$(CONFIG_DMA_JZ4780) += dma-jz4780.o obj-$(CONFIG_TI_CPPI41) += cppi41.o obj-$(CONFIG_K3_DMA) += k3dma.o obj-$(CONFIG_MOXART_DMA) += moxart-dma.o diff --git a/drivers/dma/dma-jz4780.c b/drivers/dma/dma-jz4780.c new file mode 100644 index 000..2488e32 --- /dev/null +++ b/drivers/dma/dma-jz4780.c @@ -0,0 +1,856 @@ +/* + * Ingenic JZ4780 DMA controller + * + * Copyright (c) 2013 Imagination Technologies + * Author: Alex Smith alex.sm...@imgtec.com + * + * 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. + */ + +#include linux/clk.h +#include linux/dmapool.h +#include linux/init.h +#include linux/interrupt.h +#include linux/module.h +#include linux/of.h +#include linux/of_dma.h +#include linux/platform_device.h +#include linux/slab.h + +#include dmaengine.h +#include virt-dma.h + +#define JZ_DMA_NR_CHANNELS 32 + +/* Global registers. */ +#define JZ_DMA_REG_DMAC0x1000 +#define JZ_DMA_REG_DIRQP 0x1004 +#define JZ_DMA_REG_DDR 0x1008 +#define JZ_DMA_REG_DDRS0x100c +#define JZ_DMA_REG_DMACP 0x101c +#define JZ_DMA_REG_DSIRQP 0x1020 +#define JZ_DMA_REG_DSIRQM 0x1024 +#define JZ_DMA_REG_DCIRQP 0x1028 +#define JZ_DMA_REG_DCIRQM 0x102c + +/* Per-channel registers. */ +#define JZ_DMA_REG_DSA(n) (0x00 + (n) * 0x20) +#define JZ_DMA_REG_DTA(n) (0x04 + (n) * 0x20) +#define JZ_DMA_REG_DTC(n) (0x08 + (n) * 0x20) +#define JZ_DMA_REG_DRT(n) (0x0c + (n) * 0x20) +#define JZ_DMA_REG_DCS(n) (0x10 + (n) * 0x20) +#define JZ_DMA_REG_DCM(n) (0x14 + (n) * 0x20) +#define JZ_DMA_REG_DDA(n) (0x18 + (n) * 0x20) +#define JZ_DMA_REG_DSD(n) (0x1c + (n) * 0x20) + +#define JZ_DMA_DMAC_DMAE BIT(0) +#define JZ_DMA_DMAC_AR BIT(2) +#define JZ_DMA_DMAC_HLTBIT(3) +#define JZ_DMA_DMAC_FMSC BIT(31) + +#define JZ_DMA_DRT_AUTO0x8 + +#define JZ_DMA_DCS_CTE BIT(0) +#define JZ_DMA_DCS_HLT BIT(2) +#define JZ_DMA_DCS_TT BIT(3) +#define JZ_DMA_DCS_AR BIT(4) +#define JZ_DMA_DCS_DES8BIT(30) + +#define JZ_DMA_DCM_LINKBIT(0) +#define JZ_DMA_DCM_TIE BIT(1) +#define JZ_DMA_DCM_STDEBIT(2) +#define JZ_DMA_DCM_TSZ_SHIFT 8 +#define JZ_DMA_DCM_TSZ_MASK(0x7 JZ_DMA_DCM_TSZ_SHIFT) +#define JZ_DMA_DCM_DP_SHIFT12 +#define JZ_DMA_DCM_SP_SHIFT14 +#define JZ_DMA_DCM_DAI BIT(22) +#define JZ_DMA_DCM_SAI BIT(23) + +#define JZ_DMA_SIZE_4_BYTE 0x0 +#define JZ_DMA_SIZE_1_BYTE 0x1 +#define JZ_DMA_SIZE_2_BYTE 0x2 +#define JZ_DMA_SIZE_16_BYTE0x3 +#define JZ_DMA_SIZE_32_BYTE0x4 +#define JZ_DMA_SIZE_64_BYTE0x5 +#define JZ_DMA_SIZE_128_BYTE 0x6 + +#define JZ_DMA_WIDTH_32_BIT0x0 +#define JZ_DMA_WIDTH_8_BIT 0x1 +#define JZ_DMA_WIDTH_16_BIT0x2 + +/** + * struct jz4780_dma_hwdesc - descriptor structure read by the DMA controller. + * @dcm: value for
[PATCH 1/2] dt: dma: Add DT binding document for jz4780-dma
From: Alex Smith alex.sm...@imgtec.com
Add device tree bindings for the DMA controller on JZ4780 SoCs, used by
the dma-jz4780 driver.
Signed-off-by: Alex Smith alex.sm...@imgtec.com
---
.../devicetree/bindings/dma/jz4780-dma.txt | 59 ++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/jz4780-dma.txt
diff --git a/Documentation/devicetree/bindings/dma/jz4780-dma.txt
b/Documentation/devicetree/bindings/dma/jz4780-dma.txt
new file mode 100644
index 000..0e46056
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/jz4780-dma.txt
@@ -0,0 +1,59 @@
+* Ingenic JZ4780 DMA Controller
+
+Required properties:
+
+- compatible: Should be ingenic,jz4780-dma
+- reg: Should contain the DMA controller registers location and length.
+- interrupts: Should contain the interrupt specifier of the DMA controller.
+- clocks: Should contain a clock specifier for the JZ4780 PDMA clock.
+- #dma-cells: Must be 3. Number of integer cells in the dmas property of
+ DMA clients (see below).
+
+Optional properties:
+
+- ingenic,reserved-channels: Bitmask of channels to reserve for devices that
+ need a specific channel. These channels will only be assigned when explicitly
+ requested by a client. The primary use for this is channels 0 and 1, which
+ can be configured to have special behaviour for NAND/BCH when using
+ programmable firmware.
+
+Example:
+
+dma: dma@1342 {
+ compatible = ingenic,jz4780-dma;
+ reg = 0x1342 0x1;
+
+ interrupts = 10;
+
+ clocks = cgu JZ4780_CLK_PDMA;
+
+ #dma-cells = 3;
+
+ ingenic,reserved-channels = 0x3;
+};
+
+DMA clients must use the format described in dma.txt, giving a phandle to the
+DMA controller plus the following 3 integer cells:
+
+1. Transmit request type: The DMA request type for transfers to the device on
+ the allocated channel, as defined in the SoC documentation. If set to 0,
+ transfers to the device will not be allowed on the channel.
+
+2. Receive request type: The DMA request type for transfers from the device on
+ the allocated channel, as defined in the SoC documentation. If set to 0,
+ transfers from the device will not be allowed on the channel.
+
+3. Channel: If set to 0x, any available channel will be allocated for
+ the client. Otherwise, the exact channel specified will be used. The channel
+ should be reserved on the DMA controller using the ingenic,reserved-channels
+ property.
+
+Example:
+
+uart0: serial@1003 {
+ ...
+ dmas = dma 0x14 0 0x
+ dma 0 0x15 0x;
+ dma-names = tx, rx;
+ ...
+};
--
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 7/7] spi: spi-fsl-dspi: Add support for TCFQ transfer mode
On Thu, Jan 29, 2015 at 11:58:25AM +, BhuvanChandra.DV wrote: As far as i understood the major difference between the two modes are when the interrupt to trigger, as EOQ mode will trigger the interrupt at end of queue and TCF will trigger the interrupt at every frame transfer. Probably mode selection shouldn't be a device tree property, but i don't see any automatic way to choose between the modes. Maybe a config would be more appropriate? Or if there's either no particular reason to choose one over the other or one is always better then just pick one in the driver and don't worry about implementing both. signature.asc Description: Digital signature
Re: [PATCH 1/2] dt: dma: Add DT binding document for jz4780-dma
On Thursday 29 January 2015 12:19:38 Zubair Lutfullah Kakakhel wrote: +1. Transmit request type: The DMA request type for transfers to the device on + the allocated channel, as defined in the SoC documentation. If set to 0, + transfers to the device will not be allowed on the channel. + +2. Receive request type: The DMA request type for transfers from the device on + the allocated channel, as defined in the SoC documentation. If set to 0, + transfers from the device will not be allowed on the channel. It's fairly unusual to have separate fields for these two, most other driver just use one. What would be a use-case for passing both? Arnd -- 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] Devicetree binding for omap3-serial bcm2048 combination
On Wed, Jan 28, 2015 at 09:35:01AM +, Pavel Machek wrote: Nokia N900 contains bluetooth module connected on serial port. Unfortunately, serial and bluetooth are rather closely coupled, so standard serial driver can not be used, and we really don't want /dev/ttyS1 to be published for internal port of bluetooth stack... Hence solution below. How are they closely coupled? Signed-off-by: Pavel Machek pa...@ucw.cz diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt index 342eedd..e9fde42 100644 --- a/Documentation/devicetree/bindings/serial/omap_serial.txt +++ b/Documentation/devicetree/bindings/serial/omap_serial.txt @@ -4,7 +4,14 @@ Required properties: - compatible : should be ti,omap2-uart for OMAP2 controllers - compatible : should be ti,omap3-uart for OMAP3 controllers - compatible : should be ti,omap4-uart for OMAP4 controllers +- compatible : should be ti+brcm,omap3-uart,bcm2048 for bcm2048 +bluetooth connected to OMAP3 serial I'm very much not keen on munging the two devices into one. Elsewhere Neil Brown and others having been looking into allowing UARTs to function as busses for single devices, which to me seems to cover this case. Mark. - ti,hwmods : Must be uartn, n being the instance number (1-based) Optional properties: - clock-frequency : frequency of the clock input to the UART + +Required properties for ti+brcm,omap3-uart,bcm2048: +- reset-gpios : gpio for reset pin +- host-wakeup-gpios : gpio for host wakeup +- bluetooth-wakeup-gpios : gpio for bluetooth wakeup -- (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
[PATCH v4 5/5] ARM: at91/dt: define a virtual irq demultiplexer chip connected on irq1
IRQ1 is multiplexing several peripheral IRQs, but there's no way to
properly demultiplex those IRQs.
Use a virtual irq demux chip to achieve this demultiplexing operation.
Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
---
arch/arm/boot/dts/at91rm9200.dtsi | 20 +---
arch/arm/boot/dts/at91sam9260.dtsi | 26 +-
arch/arm/boot/dts/at91sam9261.dtsi | 26 +-
arch/arm/boot/dts/at91sam9263.dtsi | 29 +++--
arch/arm/boot/dts/at91sam9g45.dtsi | 29 +++--
arch/arm/boot/dts/at91sam9n12.dtsi | 25 +
arch/arm/boot/dts/at91sam9rl.dtsi | 29 +++--
arch/arm/boot/dts/at91sam9x5.dtsi | 26 +-
8 files changed, 170 insertions(+), 40 deletions(-)
diff --git a/arch/arm/boot/dts/at91rm9200.dtsi
b/arch/arm/boot/dts/at91rm9200.dtsi
index 6c97d4a..c5f673b 100644
--- a/arch/arm/boot/dts/at91rm9200.dtsi
+++ b/arch/arm/boot/dts/at91rm9200.dtsi
@@ -94,7 +94,7 @@
pmc: pmc@fc00 {
compatible = atmel,at91rm9200-pmc;
reg = 0xfc00 0x100;
- interrupts = 1 IRQ_TYPE_LEVEL_HIGH 7;
+ interrupts-extended = virt_irq1_demux 0;
interrupt-controller;
#address-cells = 1;
#size-cells = 0;
@@ -353,7 +353,7 @@
st: timer@fd00 {
compatible = atmel,at91rm9200-st;
reg = 0xfd00 0x100;
- interrupts = 1 IRQ_TYPE_LEVEL_HIGH 7;
+ interrupts-extended = virt_irq1_demux 1;
};
tcb0: timer@fffa {
@@ -820,7 +820,7 @@
dbgu: serial@f200 {
compatible = atmel,at91rm9200-usart;
reg = 0xf200 0x200;
- interrupts = 1 IRQ_TYPE_LEVEL_HIGH 7;
+ interrupts-extended = virt_irq1_demux 2;
pinctrl-names = default;
pinctrl-0 = pinctrl_dbgu;
clocks = mck;
@@ -944,4 +944,18 @@
#size-cells = 0;
status = disabled;
};
+
+ virt_irq1_demux: virt-irq-demux@1 {
+ compatible = virtual,irq-demux;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ interrupts = 1 IRQ_TYPE_LEVEL_HIGH 7;
+ /*
+* Interrupt lines:
+* 0: PMC
+* 1: ST
+* 2: DBGU
+*/
+ irqs = 0x7;
+ };
};
diff --git a/arch/arm/boot/dts/at91sam9260.dtsi
b/arch/arm/boot/dts/at91sam9260.dtsi
index dd1313c..bf7a6a2 100644
--- a/arch/arm/boot/dts/at91sam9260.dtsi
+++ b/arch/arm/boot/dts/at91sam9260.dtsi
@@ -97,7 +97,7 @@
pmc: pmc@fc00 {
compatible = atmel,at91sam9260-pmc;
reg = 0xfc00 0x100;
- interrupts = 1 IRQ_TYPE_LEVEL_HIGH 7;
+ interrupts-extended = virt_irq1_demux 0;
interrupt-controller;
#address-cells = 1;
#size-cells = 0;
@@ -364,7 +364,7 @@
pit: timer@fd30 {
compatible = atmel,at91sam9260-pit;
reg = 0xfd30 0xf;
- interrupts = 1 IRQ_TYPE_LEVEL_HIGH 7;
+ interrupts-extended = virt_irq1_demux 1;
clocks = mck;
};
@@ -750,7 +750,7 @@
dbgu: serial@f200 {
compatible = atmel,at91sam9260-usart;
reg = 0xf200 0x200;
- interrupts = 1 IRQ_TYPE_LEVEL_HIGH 7;
+ interrupts-extended = virt_irq1_demux 2;
pinctrl-names = default;
pinctrl-0 = pinctrl_dbgu;
clocks = mck;
@@ -959,7 +959,7 @@
rtc@fd20 {
compatible = atmel,at91sam9260-rtt;
reg = 0xfd20 0x10;
- interrupts = 1 IRQ_TYPE_LEVEL_HIGH 7;
+ interrupts-extended = virt_irq1_demux 3;
clocks = clk32k;
status = disabled;
};
@@ -967,7 +967,7
Re: [PATCH v10 2/2] tty/serial: Add Spreadtrum sc9836-uart driver support
Hi,
On Wednesday 28 January 2015 04:38 PM, Chunyan Zhang wrote:
Add a full sc9836-uart driver for SC9836 SoC which is based on the
spreadtrum sharkl64 platform.
This driver also support earlycon.
Originally-by: Lanqing Liu lanqing@spreadtrum.com
Signed-off-by: Orson Zhai orson.z...@spreadtrum.com
Signed-off-by: Chunyan Zhang chunyan.zh...@spreadtrum.com
Acked-by: Arnd Bergmann a...@arndb.de
Reviewed-by: Peter Hurley pe...@hurleysoftware.com
---
drivers/tty/serial/Kconfig | 18 +
drivers/tty/serial/Makefile |1 +
drivers/tty/serial/sprd_serial.c | 793 ++
include/uapi/linux/serial_core.h |3 +
4 files changed, 815 insertions(+)
create mode 100644 drivers/tty/serial/sprd_serial.c
(...)
+static int sprd_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ struct uart_port *up;
+ struct clk *clk;
+ int irq;
+ int index;
+ int ret;
+
+ for (index = 0; index ARRAY_SIZE(sprd_port); index++)
+ if (sprd_port[index] == NULL)
+ break;
+
+ if (index == ARRAY_SIZE(sprd_port))
+ return -EBUSY;
+
+ index = sprd_probe_dt_alias(index, pdev-dev);
+
+ sprd_port[index] = devm_kzalloc(pdev-dev,
+ sizeof(*sprd_port[index]), GFP_KERNEL);
+ if (!sprd_port[index])
+ return -ENOMEM;
+
+ up = sprd_port[index]-port;
+ up-dev = pdev-dev;
+ up-line = index;
+ up-type = PORT_SPRD;
+ up-iotype = SERIAL_IO_PORT;
+ up-uartclk = SPRD_DEF_RATE;
+ up-fifosize = SPRD_FIFO_SIZE;
+ up-ops = serial_sprd_ops;
+ up-flags = UPF_BOOT_AUTOCONF;
+
+ clk = devm_clk_get(pdev-dev, NULL);
+ if (!IS_ERR(clk))
+ up-uartclk = clk_get_rate(clk);
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(pdev-dev, not provide mem resource\n);
+ return -ENODEV;
+ }
This check is not required. It will be done by devm_ioremap_resource()
+ up-mapbase = res-start;
+ up-membase = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(up-membase))
+ return PTR_ERR(up-membase);
+
--
Thanks,
Varka Bhadram.
--
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 Thursday 29 January 2015 08:56 PM, Varka Bhadram wrote:
Hi,
On Wednesday 28 January 2015 04:38 PM, Chunyan Zhang wrote:
Add a full sc9836-uart driver for SC9836 SoC which is based on the
spreadtrum sharkl64 platform.
This driver also support earlycon.
Originally-by: Lanqing Liu lanqing@spreadtrum.com
Signed-off-by: Orson Zhai orson.z...@spreadtrum.com
Signed-off-by: Chunyan Zhang chunyan.zh...@spreadtrum.com
Acked-by: Arnd Bergmann a...@arndb.de
Reviewed-by: Peter Hurley pe...@hurleysoftware.com
---
drivers/tty/serial/Kconfig | 18 +
drivers/tty/serial/Makefile |1 +
drivers/tty/serial/sprd_serial.c | 793
++
include/uapi/linux/serial_core.h |3 +
4 files changed, 815 insertions(+)
create mode 100644 drivers/tty/serial/sprd_serial.c
(...)
+static int sprd_probe(struct platform_device *pdev)
+{
+struct resource *res;
+struct uart_port *up;
+struct clk *clk;
+int irq;
+int index;
+int ret;
+
+for (index = 0; index ARRAY_SIZE(sprd_port); index++)
+if (sprd_port[index] == NULL)
+break;
+
+if (index == ARRAY_SIZE(sprd_port))
+return -EBUSY;
+
+index = sprd_probe_dt_alias(index, pdev-dev);
+
+sprd_port[index] = devm_kzalloc(pdev-dev,
+sizeof(*sprd_port[index]), GFP_KERNEL);
+if (!sprd_port[index])
+return -ENOMEM;
+
+up = sprd_port[index]-port;
+up-dev = pdev-dev;
+up-line = index;
+up-type = PORT_SPRD;
+up-iotype = SERIAL_IO_PORT;
+up-uartclk = SPRD_DEF_RATE;
+up-fifosize = SPRD_FIFO_SIZE;
+up-ops = serial_sprd_ops;
+up-flags = UPF_BOOT_AUTOCONF;
+
+clk = devm_clk_get(pdev-dev, NULL);
+if (!IS_ERR(clk))
+up-uartclk = clk_get_rate(clk);
+
+res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+if (!res) {
+dev_err(pdev-dev, not provide mem resource\n);
+return -ENODEV;
+}
This check is not required. It will be done by devm_ioremap_resource()
+up-mapbase = res-start;
Accessing of 'res' has to be done after devm_ioremap_resource()
+up-membase = devm_ioremap_resource(pdev-dev, res);
+if (IS_ERR(up-membase))
+return PTR_ERR(up-membase);
+
--
Thanks,
Varka Bhadram.
--
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/7] Fixes and improvements for SDHCI on Armada 38x
On 29 January 2015 at 12:36, Gregory CLEMENT gregory.clem...@free-electrons.com wrote: Hi, this series brings fixes and improvements for the SDHCI controller of the Armada 38x SoCs. The changes for this forth version was done on the 1st and 4th patches, see the changelog for the details. The first two patches are fixes and should be also applied on the stable branch (I added stable in copy for this). The first one removes the SDR50 and DDR50 mode timing from the capabilities of the controller because the current implementation doesn't support it. The second one fix controller's caps according to the limitation of the hardware. The third one extends the Device Tree binding of the Armada 38x. It allows using the SDIO3 configuration register. The forth patch adds the support of this new register in the driver. Thanks to this one, specific clock adjustments can be done in order to support the SDR50 and DDR50 modes timing. The fifth patch is device tree clean-up. The sixth patch update the SDHCI node on Armada 38x in order to use the new register and then to be able to support the SDR50 and DDR50 modes timing. Finally, the seventh patch add the description of SDHCI for the Armada 388 RD board which was missing. Patches 1 to 4 should be merged through the mmc tree and patches 5 to 7 should be merged through mvebu and then arm-soc. Patch 4 depend on patch 2. Patch 2 depend on patch 1. And patch 1 depend on commit aa8165f91442 mmc: sdhci-pxav3: do the mbus window configuration after enabling clocks which have been merged. But as all this patch should be merged through the same tree it would not be a problem The patches 5 to 7 depend on the patches already merged in mvebu. As they are fixes, patches 1 and 2 should be merged in 3.18-rc or at least in 3.19 and then they will be part of 3.18.1. For the other patches it would be nice if they could be part of 3.19. Thanks, Gregory Changelog: v3 - v4: - Merge the 3 dev_wanr message in a single one - Remove err_quirks label v2 - v3: - Use of_property_read_bool() instead of of_get_property - Brace the else case according to the Documentation/CodingStyle - Move the setting of MMC_CAP_1_8V_DDR before the armada_38x_quirks calls v1 - v2: - Put back Marcin as author of patch 2 and 3 - Removed MMC_CAP_1_8V_DDR in the probe function Gregory CLEMENT (5): mmc: sdhci-pxav3: Fix SDR50 and DDR50 capabilities for the Armada 38x flavor mmc: sdhci-pxav3: Extend binding with SDIO3 conf reg for the Armada 38x ARM: mvebu: Use macros for interrupt flags on Armada 38x sdhci node ARM: mvebu: Update the SDHCI node on Armada 38x ARM: mvebu: Add Device Tree description of SDHCI for Armada 388 RD Gregory CLEMENT (5): mmc: sdhci-pxav3: Fix SDR50 and DDR50 capabilities for the Armada 38x flavor mmc: sdhci-pxav3: Extend binding with SDIO3 conf reg for the Armada 38x ARM: mvebu: Use macros for interrupt flags on Armada 38x sdhci node ARM: mvebu: Update the SDHCI node on Armada 38x ARM: mvebu: Add Device Tree description of SDHCI for Armada 388 RD Marcin Wojtas (2): mmc: sdhci-pxav3: Fix Armada 38x controller's caps according to erratum ERR-7878951 mmc: sdhci-pxav3: Modify clock settings for the SDR50 and DDR50 modes .../devicetree/bindings/mmc/sdhci-pxa.txt | 15 ++-- arch/arm/boot/dts/armada-388-rd.dts| 10 +++ arch/arm/boot/dts/armada-38x.dtsi | 7 +- drivers/mmc/host/sdhci-pxav3.c | 83 +- 4 files changed, 106 insertions(+), 9 deletions(-) -- 2.1.0 Thanks! Applied patch 1 - 4 for next. 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 1/3] dt: usb: jz4740: Add DT binding document for OHCI
On Wednesday 28 January 2015 13:26:03 Zubair Lutfullah Kakakhel wrote: + - clocks: Should contain a single clock specifier for the SoC UHC clock. + - clock-names: Must be uhc Same comment as for the watchdog binding, this should probably be removed. See what the other ohci drivers use and pick the most common clock name if you must have one. Arnd -- 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 4/6] mmc: pwrseq_simple: Add optional reference clock support
On 28 January 2015 at 19:15, 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 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 | 34 --
1 file changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/pwrseq_simple.c
b/drivers/mmc/core/pwrseq_simple.c
index e53d3c7e059c..5e34c77efa5e 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,7 @@
struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
+ struct clk *ext_clk;
You need to add a bool, maybe call it clk_enabled; See why below.
int nr_gpios;
struct gpio_desc *reset_gpios[0];
};
@@ -39,6 +41,9 @@ 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))
+ clk_prepare_enable(pwrseq-ext_clk);
+
There are no guarantee that the -mmc_pwrseq_simple_pre_power_on()
will be invoked prior -mmc_pwrseq_simple_power_off().
That means you need to keep track of if you have gated/ungated the
clock. In other words check pwrseq-clk_enabled. That will prevent
potential clk unbalance issues.
mmc_pwrseq_simple_set_gpios_value(pwrseq, 1);
}
@@ -50,6 +55,17 @@ 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 (!IS_ERR(pwrseq-ext_clk))
+ clk_disable_unprepare(pwrseq-ext_clk);
Same comment as above.
+}
+
static void mmc_pwrseq_simple_free(struct mmc_host *host)
{
struct mmc_pwrseq_simple *pwrseq = container_of(host-pwrseq,
@@ -60,6 +76,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 +86,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 +104,14 @@ 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
+ PTR_ERR(pwrseq-ext_clk) != -ENOSYS) {
I don't think you can get -ENOSYS.
+ 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 +123,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 +132,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
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 v2 2/2] leds: add Qualcomm PM8941 WLED driver
Hi Bjorn,
Just few nitpick comments.
On Fri, 2015-01-23 at 16:54 -0800, Bjorn Andersson wrote:
From: Courtney Cavin ca...@sonymobile.com
This adds support for the WLED ('White' LED) block on Qualcomm's
PM8941 PMICs.
Signed-off-by: Courtney Cavin ca...@sonymobile.com
Signed-off-by: Bjorn Andersson anders...@sonymobile.com
---
drivers/leds/Kconfig| 8 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-pm8941-wled.c | 459
3 files changed, 468 insertions(+)
create mode 100644 drivers/leds/leds-pm8941-wled.c
snip
+
+#define PM8941_WLED_REG_VAL_BASE 0x40
+#define PM8941_WLED_REG_VAL_MAX 0xFFF
+
+#define PM8941_WLED_REG_MOD_EN 0x46
+#define PM8941_WLED_REG_MOD_EN_BITBIT(7)
+#define PM8941_WLED_REG_MOD_EN_MASK BIT(7)
Is it possible bit definitions to have same indentation like registers offsets?
+struct pm8941_wled_config {
+ u32 i_boost_limit;
+ u32 ovp;
+ u32 switch_freq;
+ u32 num_strings;
+ u32 i_limit;
+ bool cs_out_en;
+ bool ext_gen;
+ bool cabc_en;
+};
+
Could this be further squashed to bellow structure?
+struct pm8941_wled {
+ struct regmap *regmap;
+ u16 addr;
+
+ struct led_classdev cdev;
+
+ struct pm8941_wled_config cfg;
+};
+
snip
+static void pm8941_wled_set_brightness(struct led_classdev *cdev,
+
enum
led_brightness value)
+{
+ if (pm8941_wled_set(cdev, value)) {
pm8941_wled_set() is used only here, could it be merged into this function?
+ dev_err(cdev-dev, Unable to set brightness\n);
+ return;
+ }
+ cdev-brightness = value;
+}
+
Otherwise it looks good. Driver is loaded and device is detected
properly (i have added readings for type and subtype registers).
Do you know where I can measure result from changing brightness
sysfs entry. I am using 8074 dragonboard?
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 v2 4/6] mmc: pwrseq_simple: Add optional reference clock support
Hello Ulf,
Thanks a lot for your feedback.
On 01/29/2015 02:05 PM, Ulf Hansson wrote:
struct mmc_pwrseq_simple {
struct mmc_pwrseq pwrseq;
+ struct clk *ext_clk;
You need to add a bool, maybe call it clk_enabled; See why below.
Ok
int nr_gpios;
struct gpio_desc *reset_gpios[0];
};
@@ -39,6 +41,9 @@ 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))
+ clk_prepare_enable(pwrseq-ext_clk);
+
There are no guarantee that the -mmc_pwrseq_simple_pre_power_on()
will be invoked prior -mmc_pwrseq_simple_power_off().
Got it, I didn't know that mmc_pwrseq_simple_power_off() could be invoked.
without mmc_pwrseq_simple_pre_power_on() not being called before.
That means you need to keep track of if you have gated/ungated the
clock. In other words check pwrseq-clk_enabled. That will prevent
potential clk unbalance issues.
Yes, I'll change to check for the boolean in _simple_power_off() and
_post_power_on() then.
@@ -85,6 +104,14 @@ 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
+ PTR_ERR(pwrseq-ext_clk) != -ENOSYS) {
I don't think you can get -ENOSYS.
You are right, I'll remove that.
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
[PATCH V2 RESEND 1/4] dt-bindings: Add vendor prefix for Raspberry Pi
Since the prefix is already in use, we need to add it in the vendor list. Signed-off-by: Stefan Wahren stefan.wah...@i2se.com --- .../devicetree/bindings/vendor-prefixes.txt|1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 5d2251a..0546f73 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -136,6 +136,7 @@ radxa Radxa raidsonic RaidSonic Technology GmbH ralink Mediatek/Ralink Technology Corp. ramtronRamtron International +raspberrypiRaspberry Pi Foundation realtek Realtek Semiconductor Corp. renesasRenesas Electronics Corporation ricoh Ricoh Co. Ltd. -- 1.7.9.5 -- 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 RESEND 4/4] ARM: bcm2835: Use pinctrl header
This patch converts all bcm2835 dts and dtsi files to use the pinctrl
header file.
Signed-off-by: Stefan Wahren stefan.wah...@i2se.com
---
arch/arm/boot/dts/bcm2835-rpi-b-plus.dts |4 ++--
arch/arm/boot/dts/bcm2835-rpi-b.dts |4 ++--
arch/arm/boot/dts/bcm2835-rpi.dtsi |8
arch/arm/boot/dts/bcm2835.dtsi |3 ++-
4 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
index e479515..668442b 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
@@ -1,5 +1,5 @@
/dts-v1/;
-/include/ bcm2835-rpi.dtsi
+#include bcm2835-rpi.dtsi
/ {
compatible = raspberrypi,model-b-plus, brcm,bcm2835;
@@ -25,6 +25,6 @@
/* I2S interface */
i2s_alt0: i2s_alt0 {
brcm,pins = 18 19 20 21;
- brcm,function = 4; /* alt0 */
+ brcm,function = BCM2835_FSEL_ALT0;
};
};
diff --git a/arch/arm/boot/dts/bcm2835-rpi-b.dts
b/arch/arm/boot/dts/bcm2835-rpi-b.dts
index bafa46f..ee89b79 100644
--- a/arch/arm/boot/dts/bcm2835-rpi-b.dts
+++ b/arch/arm/boot/dts/bcm2835-rpi-b.dts
@@ -1,5 +1,5 @@
/dts-v1/;
-/include/ bcm2835-rpi.dtsi
+#include bcm2835-rpi.dtsi
/ {
compatible = raspberrypi,model-b, brcm,bcm2835;
@@ -18,6 +18,6 @@
/* I2S interface */
i2s_alt2: i2s_alt2 {
brcm,pins = 28 29 30 31;
- brcm,function = 6; /* alt2 */
+ brcm,function = BCM2835_FSEL_ALT2;
};
};
diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index c706448..46780bb 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -1,4 +1,4 @@
-/include/ bcm2835.dtsi
+#include bcm2835.dtsi
/ {
memory {
@@ -21,17 +21,17 @@
gpioout: gpioout {
brcm,pins = 6;
- brcm,function = 1; /* GPIO out */
+ brcm,function = BCM2835_FSEL_GPIO_OUT;
};
alt0: alt0 {
brcm,pins = 0 1 2 3 4 5 7 8 9 10 11 14 15 40 45;
- brcm,function = 4; /* alt0 */
+ brcm,function = BCM2835_FSEL_ALT0;
};
alt3: alt3 {
brcm,pins = 48 49 50 51 52 53;
- brcm,function = 7; /* alt3 */
+ brcm,function = BCM2835_FSEL_ALT3;
};
};
diff --git a/arch/arm/boot/dts/bcm2835.dtsi b/arch/arm/boot/dts/bcm2835.dtsi
index 3342cb1..be9c914 100644
--- a/arch/arm/boot/dts/bcm2835.dtsi
+++ b/arch/arm/boot/dts/bcm2835.dtsi
@@ -1,4 +1,5 @@
-/include/ skeleton.dtsi
+#include dt-bindings/pinctrl/bcm2835.h
+#include skeleton.dtsi
/ {
compatible = brcm,bcm2835;
--
1.7.9.5
--
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 RESEND 0/4] ARM: bcm2835: DT improvements
This patch series contains DT improvements for the Raspberry Pi. Patch 1,2: Add missing vendor prefix and root compatible properties Patch 3,4: Use constants for pin function instead of error-prone numbers Changes in V2: - add all currently known Raspberry Pi boards to binding documentation as suggested by Stephen Warren Stefan Wahren (4): dt-bindings: Add vendor prefix for Raspberry Pi dt-bindings: Add root properties for Raspberry Pi ARM: bcm2835: Add header file for pinctrl constants ARM: bcm2835: Use pinctrl header Documentation/devicetree/bindings/arm/bcm2835.txt | 31 ++-- .../devicetree/bindings/vendor-prefixes.txt|1 + arch/arm/boot/dts/bcm2835-rpi-b-plus.dts |4 +-- arch/arm/boot/dts/bcm2835-rpi-b.dts|4 +-- arch/arm/boot/dts/bcm2835-rpi.dtsi |8 ++--- arch/arm/boot/dts/bcm2835.dtsi |3 +- include/dt-bindings/pinctrl/bcm2835.h | 27 + 7 files changed, 67 insertions(+), 11 deletions(-) create mode 100644 include/dt-bindings/pinctrl/bcm2835.h -- 1.7.9.5 -- 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 RESEND 2/4] dt-bindings: Add root properties for Raspberry Pi
This patch adds root compatible properties for the following boards: - Raspberry Pi Model A - Raspberry Pi Model A+ - Raspberry Pi Model B - Raspberry Pi Model B (no P5) - Raspberry Pi Model B rev2 - Raspberry Pi Model B+ - Raspberry Pi Compute Module Signed-off-by: Stefan Wahren stefan.wah...@i2se.com --- Documentation/devicetree/bindings/arm/bcm2835.txt | 31 +++-- 1 file changed, 29 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/arm/bcm2835.txt b/Documentation/devicetree/bindings/arm/bcm2835.txt index ac68348..c78576b 100644 --- a/Documentation/devicetree/bindings/arm/bcm2835.txt +++ b/Documentation/devicetree/bindings/arm/bcm2835.txt @@ -1,8 +1,35 @@ Broadcom BCM2835 device tree bindings --- -Boards with the BCM2835 SoC shall have the following properties: +Raspberry Pi Model A +Required root node properties: +compatible = raspberrypi,model-a, brcm,bcm2835; -Required root node property: +Raspberry Pi Model A+ +Required root node properties: +compatible = raspberrypi,model-a-plus, brcm,bcm2835; +Raspberry Pi Model B +Required root node properties: +compatible = raspberrypi,model-b, brcm,bcm2835; + +Raspberry Pi Model B (no P5) +early model B with I2C0 rather than I2C1 routed to the expansion header +Required root node properties: +compatible = raspberrypi,model-b-i2c0, brcm,bcm2835; + +Raspberry Pi Model B rev2 +Required root node properties: +compatible = raspberrypi,model-b-rev2, brcm,bcm2835; + +Raspberry Pi Model B+ +Required root node properties: +compatible = raspberrypi,model-b-plus, brcm,bcm2835; + +Raspberry Pi Compute Module +Required root node properties: +compatible = raspberrypi,compute-module, brcm,bcm2835; + +Generic BCM2835 board +Required root node properties: compatible = brcm,bcm2835; -- 1.7.9.5 -- 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 RESEND 3/4] ARM: bcm2835: Add header file for pinctrl constants
This new header file defines pincontrol constants to use from bcm2835 DTS files for pincontrol properties option. Signed-off-by: Stefan Wahren stefan.wah...@i2se.com --- include/dt-bindings/pinctrl/bcm2835.h | 27 +++ 1 file changed, 27 insertions(+) create mode 100644 include/dt-bindings/pinctrl/bcm2835.h diff --git a/include/dt-bindings/pinctrl/bcm2835.h b/include/dt-bindings/pinctrl/bcm2835.h new file mode 100644 index 000..6f0bc37 --- /dev/null +++ b/include/dt-bindings/pinctrl/bcm2835.h @@ -0,0 +1,27 @@ +/* + * Header providing constants for bcm2835 pinctrl bindings. + * + * Copyright (C) 2015 Stefan Wahren stefan.wah...@i2se.com + * + * The code contained herein is licensed under the GNU General Public + * License. You may obtain a copy of the GNU General Public License + * Version 2 at the following locations: + * + * http://www.opensource.org/licenses/gpl-license.html + * http://www.gnu.org/copyleft/gpl.html + */ + +#ifndef __DT_BINDINGS_PINCTRL_BCM2835_H__ +#define __DT_BINDINGS_PINCTRL_BCM2835_H__ + +/* brcm,function property */ +#define BCM2835_FSEL_GPIO_IN 0 +#define BCM2835_FSEL_GPIO_OUT 1 +#define BCM2835_FSEL_ALT5 2 +#define BCM2835_FSEL_ALT4 3 +#define BCM2835_FSEL_ALT0 4 +#define BCM2835_FSEL_ALT1 5 +#define BCM2835_FSEL_ALT2 6 +#define BCM2835_FSEL_ALT3 7 + +#endif /* __DT_BINDINGS_PINCTRL_BCM2835_H__ */ -- 1.7.9.5 -- 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 01/24] Documentation: DT: document compatible string existence requirement
On Thu, Jan 29, 2015 at 10:43 AM, Javier Martinez Canillas javier.marti...@collabora.co.uk wrote: Hello Paul, On 01/29/2015 12:49 AM, Paul Walmsley wrote: 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 I would had preferred if checkpatch.pl didn't warn about the most specific variants of the IP blocks tbh. Patches welcome. It would be hard because in cases where there are generic strings, we always need to have a specific one. Since afaiu those were only added to the compatible string as a way to make it future proof in case there is going to be needed later. So in that sense I thought they were not part of the DT ABI. Now, dumping the unused specific strings in binding docs only to make checkpatch happy, will have the effect of making those unused strings become part of the DT ABI. Which mean that couldn't be dropped later if those are found to not be needed since there won't be a way to know if an OS following the DT binding will be matching those or not. If they are in the DTS, then they are effectively already part of the ABI. You have some wiggle room if they are known not to be used whether they are documented or not. You can never prove they are not needed in the future to be able to drop them. Rob -- 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 4/5] iio: common: ssp_sensors: Add sensorhub accelerometer sensor
On 28/01/15 14:05, Karol Wrona wrote:
This patch adds accelerometer iio driver which uses sensorhub as data
provider.
Signed-off-by: Karol Wrona k.wr...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Applied
---
drivers/iio/accel/Makefile |1 +
drivers/iio/accel/ssp_accel_sensor.c | 169
++
2 files changed, 170 insertions(+)
create mode 100644 drivers/iio/accel/ssp_accel_sensor.c
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index de5b9cb..69c64b6 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
obj-$(CONFIG_KXSD9) += kxsd9.o
obj-$(CONFIG_MMA8452)+= mma8452.o
obj-$(CONFIG_MMA9551)+= mma9551.o
+obj-$(CONFIG_IIO_SSP_SENSORS_COMMONS) += ssp_accel_sensor.o
obj-$(CONFIG_IIO_ST_ACCEL_3AXIS) += st_accel.o
st_accel-y := st_accel_core.o
diff --git a/drivers/iio/accel/ssp_accel_sensor.c
b/drivers/iio/accel/ssp_accel_sensor.c
new file mode 100644
index 000..4ae05fc
--- /dev/null
+++ b/drivers/iio/accel/ssp_accel_sensor.c
@@ -0,0 +1,169 @@
+/*
+ * Copyright (C) 2014, 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/iio/common/ssp_sensors.h
+#include linux/iio/iio.h
+#include linux/iio/kfifo_buf.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include ../common/ssp_sensors/ssp_iio_sensor.h
+
+#define SSP_CHANNEL_COUNT 3
+
+#define SSP_ACCEL_NAME ssp-accelerometer
+static const char ssp_accel_device_name[] = SSP_ACCEL_NAME;
+
+enum ssp_accel_3d_channel {
+ SSP_CHANNEL_SCAN_INDEX_X,
+ SSP_CHANNEL_SCAN_INDEX_Y,
+ SSP_CHANNEL_SCAN_INDEX_Z,
+ SSP_CHANNEL_SCAN_INDEX_TIME,
+};
+
+static int ssp_accel_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val,
+ int *val2, long mask)
+{
+ u32 t;
+ struct ssp_data *data = dev_get_drvdata(indio_dev-dev.parent-parent);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ t = ssp_get_sensor_delay(data, SSP_ACCELEROMETER_SENSOR);
+ ssp_convert_to_freq(t, val, val2);
+ return IIO_VAL_INT_PLUS_MICRO;
+ default:
+ break;
+ }
+
+ return -EINVAL;
+}
+
+static int ssp_accel_write_raw(struct iio_dev *indio_dev,
+struct iio_chan_spec const *chan, int val,
+int val2, long mask)
+{
+ int ret;
+ struct ssp_data *data = dev_get_drvdata(indio_dev-dev.parent-parent);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ ret = ssp_convert_to_time(val, val2);
+ ret = ssp_change_delay(data, SSP_ACCELEROMETER_SENSOR, ret);
+ if (ret 0)
+ dev_err(indio_dev-dev, accel sensor enable fail\n);
+
+ return ret;
+ default:
+ break;
+ }
+
+ return -EINVAL;
+}
+
+static struct iio_info ssp_accel_iio_info = {
+ .read_raw = ssp_accel_read_raw,
+ .write_raw = ssp_accel_write_raw,
+};
+
+static const unsigned long ssp_accel_scan_mask[] = { 0x7, 0, };
+
+static const struct iio_chan_spec ssp_acc_channels[] = {
+ SSP_CHANNEL_AG(IIO_ACCEL, IIO_MOD_X, SSP_CHANNEL_SCAN_INDEX_X),
+ SSP_CHANNEL_AG(IIO_ACCEL, IIO_MOD_Y, SSP_CHANNEL_SCAN_INDEX_Y),
+ SSP_CHANNEL_AG(IIO_ACCEL, IIO_MOD_Z, SSP_CHANNEL_SCAN_INDEX_Z),
+ SSP_CHAN_TIMESTAMP(SSP_CHANNEL_SCAN_INDEX_TIME),
+};
+
+static int ssp_process_accel_data(struct iio_dev *indio_dev, void *buf,
+ int64_t timestamp)
+{
+ return ssp_common_process_data(indio_dev, buf, SSP_ACCELEROMETER_SIZE,
+timestamp);
+}
+
+static const struct iio_buffer_setup_ops ssp_accel_buffer_ops = {
+ .postenable = ssp_common_buffer_postenable,
+ .postdisable = ssp_common_buffer_postdisable,
+};
+
+static int ssp_accel_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct iio_dev *indio_dev;
+ struct ssp_sensor_data *spd;
+ struct iio_buffer *buffer;
+
+ indio_dev = devm_iio_device_alloc(pdev-dev, sizeof(*spd));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ spd = iio_priv(indio_dev);
+
+ spd-process_data =
Re: [PATCH v7 0/3] iio: Add Cosmic Circuits ADC support
On 29/01/15 16:29, Ezequiel Garcia wrote: Hi Jonathan, On 01/20/2015 05:37 PM, Jonathan Cameron wrote: [..] Hi, I'm afraid that I'm a little stalled on sending it on because Greg hasn't yet picked up my last pull request. In the mean time I've applied it to the branch that will get rebased once he's taken that and pushed it out as testing. I can't find your second pull anywhere. Any chance we can get this driver in v3.20? I've not sent it yet. Had a bit of a backlog of review to catch up with. + in theory should be fine for a pull in the next day or two... Also, I can't find the driver anywhere in your testing branch here: https://git.kernel.org/cgit/linux/kernel/git/jic23/iio.git/ Seems like patches 2 and 3 are there, but not patch 1/3 of the series: iio: adc: Cosmic Circuits 10001 ADC driver. you are quite right. I have no idea how that happened. Anyhow, it's there now. Please let me know if you need anything at all from me! Thanks a lot, -- 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 0/3] iio: Add Cosmic Circuits ADC support
On 01/29/2015 03:12 PM, Jonathan Cameron wrote: On 29/01/15 16:29, Ezequiel Garcia wrote: Hi Jonathan, On 01/20/2015 05:37 PM, Jonathan Cameron wrote: [..] Hi, I'm afraid that I'm a little stalled on sending it on because Greg hasn't yet picked up my last pull request. In the mean time I've applied it to the branch that will get rebased once he's taken that and pushed it out as testing. I can't find your second pull anywhere. Any chance we can get this driver in v3.20? I've not sent it yet. Had a bit of a backlog of review to catch up with. + in theory should be fine for a pull in the next day or two... Great, thanks! -- Ezequiel -- 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/5] iio: common: ssp_sensors: Add sensorhub driver
On 28/01/15 14:05, Karol Wrona wrote: Sensorhub is MCU dedicated to collect data and manage several sensors. Sensorhub is a spi device which provides a layer for IIO devices. It provides some data parsing and common mechanism for sensorhub sensors. Adds common sensorhub library for sensorhub driver and iio drivers which uses sensorhub MCU to communicate with sensors. Signed-off-by: Karol Wrona k.wr...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com A couple of build errors from this one... I've fixed them up and applied to the togreg branch of iio.git. Pushed out as testing. If you get a chance to check I didn't mess anything up that would be great. --- drivers/iio/common/Kconfig |1 + drivers/iio/common/Makefile |1 + drivers/iio/common/ssp_sensors/Kconfig | 26 ++ drivers/iio/common/ssp_sensors/Makefile |8 + drivers/iio/common/ssp_sensors/ssp.h | 257 +++ drivers/iio/common/ssp_sensors/ssp_dev.c | 712 ++ drivers/iio/common/ssp_sensors/ssp_spi.c | 608 + include/linux/iio/common/ssp_sensors.h | 82 8 files changed, 1695 insertions(+) create mode 100644 drivers/iio/common/ssp_sensors/Kconfig create mode 100644 drivers/iio/common/ssp_sensors/Makefile create mode 100644 drivers/iio/common/ssp_sensors/ssp.h create mode 100644 drivers/iio/common/ssp_sensors/ssp_dev.c create mode 100644 drivers/iio/common/ssp_sensors/ssp_spi.c create mode 100644 include/linux/iio/common/ssp_sensors.h diff --git a/drivers/iio/common/Kconfig b/drivers/iio/common/Kconfig index 0b6e97d..790f106 100644 --- a/drivers/iio/common/Kconfig +++ b/drivers/iio/common/Kconfig @@ -3,4 +3,5 @@ # source drivers/iio/common/hid-sensors/Kconfig +source drivers/iio/common/ssp_sensors/Kconfig source drivers/iio/common/st_sensors/Kconfig diff --git a/drivers/iio/common/Makefile b/drivers/iio/common/Makefile index 3112df0..b1e4d9c 100644 --- a/drivers/iio/common/Makefile +++ b/drivers/iio/common/Makefile @@ -8,4 +8,5 @@ # When adding new entries keep the list in alphabetical order obj-y += hid-sensors/ +obj-y += ssp_sensors/ obj-y += st_sensors/ diff --git a/drivers/iio/common/ssp_sensors/Kconfig b/drivers/iio/common/ssp_sensors/Kconfig new file mode 100644 index 000..0ea4faf --- /dev/null +++ b/drivers/iio/common/ssp_sensors/Kconfig @@ -0,0 +1,26 @@ +# +# SSP sensor drivers and commons configuration +# +menu SSP Sensor Common + +config IIO_SSP_SENSORS_COMMONS + tristate Commons for all SSP Sensor IIO drivers + depends on IIO_SSP_SENSORHUB + select IIO_BUFFER + select IIO_KFIFO_BUF + help + Say yes here to build commons for SSP sensors. + To compile this as a module, choose M here: the module + will be called ssp_iio. + +config IIO_SSP_SENSORHUB + tristate Samsung Sensorhub driver + depends on SPI + select MFD_CORE + help + SSP driver for sensorhub. + If you say yes here you get ssp support for sensorhub. + To compile this driver as a module, choose M here: the + module will be called sensorhub. + +endmenu diff --git a/drivers/iio/common/ssp_sensors/Makefile b/drivers/iio/common/ssp_sensors/Makefile new file mode 100644 index 000..1e0389e --- /dev/null +++ b/drivers/iio/common/ssp_sensors/Makefile @@ -0,0 +1,8 @@ +# +# Makefile for SSP sensor drivers and commons. +# + +sensorhub-objs := ssp_dev.o ssp_spi.o +obj-$(CONFIG_IIO_SSP_SENSORHUB) += sensorhub.o + +obj-$(CONFIG_IIO_SSP_SENSORS_COMMONS)+= ssp_iio.o This file isn't in this patch. diff --git a/drivers/iio/common/ssp_sensors/ssp.h b/drivers/iio/common/ssp_sensors/ssp.h new file mode 100644 index 000..b910e91 --- /dev/null +++ b/drivers/iio/common/ssp_sensors/ssp.h @@ -0,0 +1,257 @@ +/* + * Copyright (C) 2014, 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. + * + */ + +#ifndef __SSP_SENSORHUB_H__ +#define __SSP_SENSORHUB_H__ + +#include linux/delay.h +#include linux/gpio.h +#include linux/iio/common/ssp_sensors.h +#include linux/iio/iio.h +#include linux/spi/spi.h + +#define SSP_DEVICE_ID0x55 + +#ifdef SSP_DBG +#define ssp_dbg(format, ...) pr_info([SSP] format, ##__VA_ARGS__) +#else +#define ssp_dbg(format, ...) +#endif + +#define
Re: [PATCH v5 3/5] iio: common: ssp_sensors: Add sensorhub iio commons
On 28/01/15 14:05, Karol Wrona wrote:
This patch adds common library for sensorhub iio drivers.
Signed-off-by: Karol Wrona k.wr...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Applied with the make file line brought forward from patch 1.
Pushed out as testing for the autobuilders to play.
---
drivers/iio/common/ssp_sensors/ssp_iio.c| 107
+++
drivers/iio/common/ssp_sensors/ssp_iio_sensor.h | 70 +++
2 files changed, 177 insertions(+)
create mode 100644 drivers/iio/common/ssp_sensors/ssp_iio.c
create mode 100644 drivers/iio/common/ssp_sensors/ssp_iio_sensor.h
diff --git a/drivers/iio/common/ssp_sensors/ssp_iio.c
b/drivers/iio/common/ssp_sensors/ssp_iio.c
new file mode 100644
index 000..a3ae165
--- /dev/null
+++ b/drivers/iio/common/ssp_sensors/ssp_iio.c
@@ -0,0 +1,107 @@
+/*
+ * Copyright (C) 2014, 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/iio/common/ssp_sensors.h
+#include linux/iio/kfifo_buf.h
+#include linux/module.h
+#include linux/slab.h
+#include ssp_iio_sensor.h
+
+/**
+ * ssp_common_buffer_postenable() - generic postenable callback for ssp
buffer
+ *
+ * @indio_dev: iio device
+ *
+ * Returns 0 or negative value in case of error
+ */
+int ssp_common_buffer_postenable(struct iio_dev *indio_dev)
+{
+ struct ssp_sensor_data *spd = iio_priv(indio_dev);
+ struct ssp_data *data = dev_get_drvdata(indio_dev-dev.parent-parent);
+
+ /* the allocation is made in post because scan size is known in this
+ * moment
+ * */
+ spd-buffer = kmalloc(indio_dev-scan_bytes, GFP_KERNEL | GFP_DMA);
+ if (!spd-buffer)
+ return -ENOMEM;
+
+ return ssp_enable_sensor(data, spd-type,
+ ssp_get_sensor_delay(data, spd-type));
+}
+EXPORT_SYMBOL(ssp_common_buffer_postenable);
+
+/**
+ * ssp_common_buffer_postdisable() - generic postdisable callback for ssp
buffer
+ *
+ * @indio_dev: iio device
+ *
+ * Returns 0 or negative value in case of error
+ */
+int ssp_common_buffer_postdisable(struct iio_dev *indio_dev)
+{
+ int ret;
+ struct ssp_sensor_data *spd = iio_priv(indio_dev);
+ struct ssp_data *data = dev_get_drvdata(indio_dev-dev.parent-parent);
+
+ ret = ssp_disable_sensor(data, spd-type);
+ if (ret 0)
+ return ret;
+
+ kfree(spd-buffer);
+
+ return ret;
+}
+EXPORT_SYMBOL(ssp_common_buffer_postdisable);
+
+/**
+ * ssp_common_process_data() - Common process data callback for ssp sensors
+ *
+ * @indio_dev: iio device
+ * @buf: source buffer
+ * @len: sensor data length
+ * @timestamp: system timestamp
+ *
+ * Returns 0 or negative value in case of error
+ */
+int ssp_common_process_data(struct iio_dev *indio_dev, void *buf,
+ unsigned int len, int64_t timestamp)
+{
+ __le32 time;
+ int64_t calculated_time;
+ struct ssp_sensor_data *spd = iio_priv(indio_dev);
+
+ if (indio_dev-scan_bytes == 0)
+ return 0;
+
+ /*
+ * it always sends full set of samples, remember about available masks
+ */
+ memcpy(spd-buffer, buf, len);
+
+ if (indio_dev-scan_timestamp) {
+ memcpy(time, ((char *)buf)[len], SSP_TIME_SIZE);
+ calculated_time =
+ timestamp + (int64_t)le32_to_cpu(time) * 100;
+ }
+
+ return iio_push_to_buffers_with_timestamp(indio_dev, spd-buffer,
+ calculated_time);
+}
+EXPORT_SYMBOL(ssp_common_process_data);
+
+MODULE_AUTHOR(Karol Wrona k.wr...@samsung.com);
+MODULE_DESCRIPTION(Samsung sensorhub commons);
+MODULE_LICENSE(GPL);
diff --git a/drivers/iio/common/ssp_sensors/ssp_iio_sensor.h
b/drivers/iio/common/ssp_sensors/ssp_iio_sensor.h
new file mode 100644
index 000..dda267c
--- /dev/null
+++ b/drivers/iio/common/ssp_sensors/ssp_iio_sensor.h
@@ -0,0 +1,70 @@
+#ifndef __SSP_IIO_SENSOR_H__
+#define __SSP_IIO_SENSOR_H__
+
+#define SSP_CHANNEL_AG(_type, _mod, _index) \
+{ \
+ .type = _type,\
+ .modified = 1,\
+ .channel2 = _mod,\
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SAMP_FREQ),\
+ .scan_index = _index,\
+ .scan_type = {\
Re: [PATCH v5 2/5] iio: sensorhub: Add sensorhub bindings
On 28/01/15 14:05, Karol Wrona wrote:
Add sensorhub bindings for sensorhub on Galaxy Gear 2.
Signed-off-by: Karol Wrona k.wr...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
It's simple and hasn't changed in months, so applied to the togreg
branch of iio.git.
---
.../devicetree/bindings/iio/sensorhub.txt | 25
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/sensorhub.txt
diff --git a/Documentation/devicetree/bindings/iio/sensorhub.txt
b/Documentation/devicetree/bindings/iio/sensorhub.txt
new file mode 100644
index 000..8d57571
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/sensorhub.txt
@@ -0,0 +1,25 @@
+Samsung Sensorhub driver
+
+Sensorhub is a MCU which manages several sensors and also plays the role
+of a virtual sensor device.
+
+Required properties:
+- compatible: samsung,sensorhub-rinato or samsung,sensorhub-thermostat
+- spi-max-frequency: max SPI clock frequency
+- interrupt-parent: interrupt parent
+- interrupts: communication interrupt
+- ap-mcu-gpios: [out] ap to sensorhub line - used during communication
+- mcu-ap-gpios: [in] sensorhub to ap - used during communication
+- mcu-reset-gpios: [out] sensorhub reset
+
+Example:
+
+ shub_spi: shub {
+ compatible = samsung,sensorhub-rinato;
+ spi-max-frequency = 500;
+ interrupt-parent = gpx0;
+ interrupts = 2 0;
+ ap-mcu-gpios = gpx0 0 0;
+ mcu-ap-gpios = gpx0 4 0;
+ mcu-reset-gpios = gpx0 5 0;
+ };
--
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 7/7] spi: spi-fsl-dspi: Add support for TCFQ transfer mode
On 2015-01-29 13:53, BhuvanChandra.DV wrote: On 01/29/2015 05:43 PM, Mark Brown wrote: On Thu, Jan 29, 2015 at 11:58:25AM +, BhuvanChandra.DV wrote: As far as i understood the major difference between the two modes are when the interrupt to trigger, as EOQ mode will trigger the interrupt at end of queue and TCF will trigger the interrupt at every frame transfer. Probably mode selection shouldn't be a device tree property, but i don't see any automatic way to choose between the modes. Maybe a config would be more appropriate? Or if there's either no particular reason to choose one over the other or one is always better then just pick one in the driver and don't worry about implementing both. Among the two, EOQ would be better since with TCF, interrupts are generated at every frame transfer, which could be a problem at higher frequencies. I think we can omit this patch then. It would be interesting to know what the authors original motivation implementing this feature was. Reading the email of the original patchset indicates that there are platforms where only TCF is supported: quote For adopting of different platform, either of them is a way of DSPI transfer data. /quote However, I don't know which platform that would be. Also, it seems that Chao Fu's email is not valid anymore. @Xiubo Li, maybe you can shed some light on this? From the platform I am concerned about, Vybrid, it seems not very useful, so I'm fine with omitting that patch. -- Stefan -- 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 PATCH 0/1] PM / domains: Add support for virtual power domains
Hello, This patch adds virtual power domain handling. Some comments are needed if such approach has any sense. The goal is to know the state of devices residing in domain which is never gated or are gated only during sleep. I.e. in Exynos3250 SoC there is one domain which is only put into retention in LPD state and to enter it some devices (i.e. mmc host controller) have to be inactive. Using domains and runtime PM it would be able to give an information to PM core that the SoC is ready for deeper power state. TODO: binding doc, add child-parent hierarchy Thanks, Karol Karol Wrona (1): PM / domains: Add support for virtual power domains 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 -- 1.7.9.5 -- 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 PATCH 1/1] PM / domains: Add support for virtual power domains
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 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 02/24] Documentation: DT bindings: add more chip compatible strings for Tegra PCIe
On Thu, Jan 29, 2015 at 11:08 AM, Paul Walmsley p...@pwsan.com wrote: Hi Rob On Thu, 29 Jan 2015, Rob Herring wrote: On Thu, Jan 29, 2015 at 9:45 AM, Paul Walmsley p...@pwsan.com wrote: On Thu, 29 Jan 2015, Rob Herring wrote: On Wed, Jan 28, 2015 at 5:49 PM, Paul Walmsley p...@pwsan.com wrote: Add compatible strings for the PCIe IP blocks present on several Tegra chips. The primary objective here is to avoid checkpatch warnings, per: [...] + - nvidia,tegra132-pcie (not yet matched in the driver) + - nvidia,tegra210-pcie (not yet matched in the driver) Whether the driver matches or not is irrelevant to the binding and may change over time. Does this mean the driver matches on something else or Tegra132 is not yet supported in the driver? It means that the driver currently matches on one of the first three strings that don't carry that annotation. If the former, what is important is what are the valid combinations of compatible properties and that is not captured here. In other words, what is the fallback compatible string for each chip? The intention was to try to be helpful: to document that anyone adding a nvidia,tegra132-pcie compatible string would also need to add one of the other strings as a fallback. Would you like that to be documented in a different way, or removed? Then you should say something like 'must contain nvidia,tegra20-pcie and one of: ...' You can also use nvidia,chip-pcie if you want. checkpatch will check for that pattern too. Then your documentation can be something like: Must contain 'nvidia,chip-pcie, nvidia,tegra20-pcie' where chip is tegra30, tegra132, ... We don't enforce that the chip part is documented ATM and not likely until we have a schema if ever. OK, thanks for the explanation. So would it be acceptable to you to skip the attempt to document which strings are actually supported by the current driver, and to simply use the chip wildcard? I don't think the binding document should say anything about what the driver uses or not. It should describe what combinations of compatible strings in a dts are valid. I didn't look at every patch, but the ones like this one are. I'd be fine with most of this all in one patch BTW. You should attempt to document known values of chip if you use it (you could refer to another doc for the list). I was only highlighting what you can get away with if no one is paying attention, not that you don't need to add tegra132, etc. :) Rob -- 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 5/5] iio: common: ssp_sensors: Add sensorhub gyroscope sensor
On 28/01/15 14:05, Karol Wrona wrote:
This patch adds gyroscope iio driver which uses sensorhub as data
provider.
Signed-off-by: Karol Wrona k.wr...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Applied.
A nice driver - glad to have it in the tree!
Jonathan
---
drivers/iio/gyro/Makefile |2 +
drivers/iio/gyro/ssp_gyro_sensor.c | 168
2 files changed, 170 insertions(+)
create mode 100644 drivers/iio/gyro/ssp_gyro_sensor.c
diff --git a/drivers/iio/gyro/Makefile b/drivers/iio/gyro/Makefile
index 36a3877..f46341b 100644
--- a/drivers/iio/gyro/Makefile
+++ b/drivers/iio/gyro/Makefile
@@ -16,6 +16,8 @@ itg3200-y := itg3200_core.o
itg3200-$(CONFIG_IIO_BUFFER) += itg3200_buffer.o
obj-$(CONFIG_ITG3200) += itg3200.o
+obj-$(CONFIG_IIO_SSP_SENSORS_COMMONS) += ssp_gyro_sensor.o
+
obj-$(CONFIG_IIO_ST_GYRO_3AXIS) += st_gyro.o
st_gyro-y := st_gyro_core.o
st_gyro-$(CONFIG_IIO_BUFFER) += st_gyro_buffer.o
diff --git a/drivers/iio/gyro/ssp_gyro_sensor.c
b/drivers/iio/gyro/ssp_gyro_sensor.c
new file mode 100644
index 000..0a8afdd
--- /dev/null
+++ b/drivers/iio/gyro/ssp_gyro_sensor.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (C) 2014, 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/iio/common/ssp_sensors.h
+#include linux/iio/iio.h
+#include linux/iio/kfifo_buf.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include ../common/ssp_sensors/ssp_iio_sensor.h
+
+#define SSP_CHANNEL_COUNT 3
+
+#define SSP_GYROSCOPE_NAME ssp-gyroscope
+static const char ssp_gyro_name[] = SSP_GYROSCOPE_NAME;
+
+enum ssp_gyro_3d_channel {
+ SSP_CHANNEL_SCAN_INDEX_X,
+ SSP_CHANNEL_SCAN_INDEX_Y,
+ SSP_CHANNEL_SCAN_INDEX_Z,
+ SSP_CHANNEL_SCAN_INDEX_TIME,
+};
+
+static int ssp_gyro_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int *val,
+ int *val2, long mask)
+{
+ u32 t;
+ struct ssp_data *data = dev_get_drvdata(indio_dev-dev.parent-parent);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ t = ssp_get_sensor_delay(data, SSP_GYROSCOPE_SENSOR);
+ ssp_convert_to_freq(t, val, val2);
+ return IIO_VAL_INT_PLUS_MICRO;
+ default:
+ break;
+ }
+
+ return -EINVAL;
+}
+
+static int ssp_gyro_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan, int val,
+ int val2, long mask)
+{
+ int ret;
+ struct ssp_data *data = dev_get_drvdata(indio_dev-dev.parent-parent);
+
+ switch (mask) {
+ case IIO_CHAN_INFO_SAMP_FREQ:
+ ret = ssp_convert_to_time(val, val2);
+ ret = ssp_change_delay(data, SSP_GYROSCOPE_SENSOR, ret);
+ if (ret 0)
+ dev_err(indio_dev-dev, gyro sensor enable fail\n);
+
+ return ret;
+ default:
+ break;
+ }
+
+ return -EINVAL;
+}
+
+static struct iio_info ssp_gyro_iio_info = {
+ .read_raw = ssp_gyro_read_raw,
+ .write_raw = ssp_gyro_write_raw,
+};
+
+static const unsigned long ssp_gyro_scan_mask[] = { 0x07, 0, };
+
+static const struct iio_chan_spec ssp_gyro_channels[] = {
+ SSP_CHANNEL_AG(IIO_ANGL_VEL, IIO_MOD_X, SSP_CHANNEL_SCAN_INDEX_X),
+ SSP_CHANNEL_AG(IIO_ANGL_VEL, IIO_MOD_Y, SSP_CHANNEL_SCAN_INDEX_Y),
+ SSP_CHANNEL_AG(IIO_ANGL_VEL, IIO_MOD_Z, SSP_CHANNEL_SCAN_INDEX_Z),
+ SSP_CHAN_TIMESTAMP(SSP_CHANNEL_SCAN_INDEX_TIME),
+};
+
+static int ssp_process_gyro_data(struct iio_dev *indio_dev, void *buf,
+ int64_t timestamp)
+{
+ return ssp_common_process_data(indio_dev, buf, SSP_GYROSCOPE_SIZE,
+timestamp);
+}
+
+static const struct iio_buffer_setup_ops ssp_gyro_buffer_ops = {
+ .postenable = ssp_common_buffer_postenable,
+ .postdisable = ssp_common_buffer_postdisable,
+};
+
+static int ssp_gyro_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct iio_dev *indio_dev;
+ struct ssp_sensor_data *spd;
+ struct iio_buffer *buffer;
+
+ indio_dev = devm_iio_device_alloc(pdev-dev, sizeof(*spd));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ spd = iio_priv(indio_dev);
+
Re: Delays, clocks, timers, hrtimers, etc
[ I am aware that my message is way too long, and that few people would have
the time to answer all these questions. So maybe, if someone feels inclined
to answer just one or two, that might kickstart some discussion, and I might
learn something along the way. Regards. ]
FTR, I've been reading about DeviceTree:
http://lwn.net/Articles/573409/
http://www.carbondesignsystems.com/virtual-prototype-blog/bid/195122/Running-the-Latest-Linux-Kernel-on-a-Minimal-ARM-Cortex-A15-System
http://devicetree.org/Device_Tree_Usage
And I am resisting the urge to pile on a few more questions ;-/
Regards.
On 28/01/2015 14:16, Mason wrote:
Hello,
I am swimming in a sea of confusion, and am hoping someone would toss
me a life-jacket (of enlightenment). Please forgive me if some of my
questions are poorly asked or appear in seemingly random order.
Working on a Cortex A9 based SoC, I set out to clean up the platform
specific timer code, by using as much generic framework as possible.
(Right now, there's a lot of redundant code in the mach dir.)
Q1. the {n,u,m}delay function family
arch/arm/include/asm/delay.h mentions
Delay routines, using a pre-computed loops_per_second value.
*BUT* if the frequency changes dynamically (thanks to cpufreq)
the loops_per_second value cannot be pre-computed, as it would
change dynamically too, right?
Looking at arch/arm/lib/delay.c it seems the default implementation
is a busy loop (in delay-loop.S) which looks up loops_per_jiffy
in the prolog to determine the number of times to loop, right?
http://lxr.free-electrons.com/source/arch/arm/lib/delay-loop.S
(Side issue, why is the loop unrolled in __loop_delay? What is the
point of unrolling a busy loop? This is commented code however.)
What happens if loops_per_jiffy changes while one core is in the
busy loop? It seems we might exit the loop too early, which could
break some drivers with some weird heisenbug, no?
Also, is the update of loops_per_jiffy atomic? Is it possible that
if one core reads it while another updates it, we get garbage?
I suppose this is one reason why the default functions are overridden
by register_current_timer_delay(arch_delay_timer) right? I think the
property of a timer is that its frequency doesn't change, even if the
CPU's frequency changes? So we are still busy looping, but we are
checking the actual time spent in the loop, whatever the cpufreq?
Reference
https://www.kernel.org/doc/Documentation/timers/timers-howto.txt
Q2. Cortex A9 global and private timers
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0407f/CIHGECHJ.html
(What are private timers used for?)
In my platform-specific code, there is a config option to choose between
1) the ARM global timer
2) a platform-specific timer (timer0)
I noticed that there is generic code to support the global timer in
drivers/clocksource/arm_global_timer.c
config ARM_GLOBAL_TIMER
bool
select CLKSRC_OF if OF
help
This options enables support for the ARM global timer unit
config CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
bool
depends on ARM_GLOBAL_TIMER
default y
help
Use ARM global timer clock source as sched_clock
I was thinking it would be better to use the standard option (ARM global
timer)
as it is officially supported in the vanilla kernel. So less code to write and
to debug, and it has likely received more testing. Why would one rely on
platform-specific timers then?
Are high-resolution timers supported with the global timer?
Q3. Using the generic global timer implementation
So, how do I use that implementation?
(Is someone other than STMicro using it?)
I see:
static void __init global_timer_of_register(struct device_node *np)
CLOCKSOURCE_OF_DECLARE(arm_gt, arm,cortex-a9-global-timer,
global_timer_of_register);
OF stands for open firmware, yes?
So is this related to device tree?
http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/arm/global_timer.txt
This file makes no sense to me.
- interrupts : One interrupt to each core
interrupts = 1 13 0xf01;
what are 1 13 0xf01 ??
- clocks : Should be phandle to a clock.
clocks = arm_periph_clk;
For my (old) 3.14 kernel, I found this:
/*
* ARM Peripheral clock for timers
*/
arm_periph_clk: arm_periph_clk {
#clock-cells = 0;
compatible = fixed-clock;
clock-frequency = 6;
};
But it looks like the definitions have moved around since then?
This device tree concept is too much to swallow in a single serving.
Please tell me if I'm going down the correct rabbit hole, and I'll
do some LWN readings to try to wrap my mind around the concept.
Anyway, if anyone can help me out on some of these topics, I'd be
eternally grateful.
Regards.
--
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 v6 7/8] ARM: dts: imx25: Add TSC and ADC support
From: Denis Carikli de...@eukrea.com
Signed-off-by: Denis Carikli de...@eukrea.com
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
arch/arm/boot/dts/imx25.dtsi | 30 +++---
1 file changed, 27 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index e4d3aecc4ed2..4780926fa20e 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -265,13 +265,37 @@
status = disabled;
};
- tsc: tsc@5003 {
- compatible = fsl,imx25-adc, fsl,imx21-tsc;
- reg = 0x5003 0x4000;
+ tscadc: tscadc@5003 {
+ compatible = fsl,imx25-tsadc;
+ reg = 0x5003 0xc;
interrupts = 46;
clocks = clks 119;
clock-names = ipg;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
status = disabled;
+
+ adc: adc@50030800 {
+ compatible = fsl,imx25-gcq;
+ reg = 0x50030800 0x60;
+ interrupt-parent = tscadc;
+ interrupts = 1;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = disabled;
+ };
+
+ tsc: tcq@50030400 {
+ compatible = fsl,imx25-tcq;
+ reg = 0x50030400 0x60;
+ interrupt-parent = tscadc;
+ interrupts = 0;
+ fsl,wires = 4;
+ status = disabled;
+ };
};
ssi1: ssi@50034000 {
--
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
[PATCH v6 0/8] imx25 adc and touchscreen driver
This series adds a driver for the Freescale i.MX25 SoC internal ADC unit which is used for touchscreen and ADC. The driver consists of three parts, the MFD driver which handles interrupts and some central configuration registers, the ADC driver and the touchscreen driver. v6 splits the remaining DT binding documentation out into seperate patches. I reworked the dt bindings for the gcq unit and made some code improvements from comments. Best regards, Markus Denis Carikli (2): ARM: dts: imx25: Add TSC and ADC support ARM: imx_v4_v5_defconfig: Add I.MX25 Touchscreen controller and ADC support. Markus Pargmann (6): ARM: dt: Binding documentation for imx25 ADC/TSC ARM: dt: Binding documentation for imx25 GCQ ARM: dt: Binding documentation for imx25 touchscreen controller mfd: fsl imx25 Touchscreen ADC driver iio: adc: fsl,imx25-gcq driver input: touchscreen: imx25 tcq driver .../devicetree/bindings/iio/adc/fsl,imx25-gcq.txt | 54 ++ .../bindings/input/touchscreen/fsl-mx25-tcq.txt| 29 + .../devicetree/bindings/mfd/fsl-imx25-tsadc.txt| 46 ++ arch/arm/boot/dts/imx25.dtsi | 30 +- arch/arm/configs/imx_v4_v5_defconfig | 4 + drivers/iio/adc/Kconfig| 7 + drivers/iio/adc/Makefile | 1 + drivers/iio/adc/fsl-imx25-gcq.c| 361 + drivers/input/touchscreen/Kconfig | 6 + drivers/input/touchscreen/Makefile | 1 + drivers/input/touchscreen/fsl-imx25-tcq.c | 587 + drivers/mfd/Kconfig| 10 + drivers/mfd/Makefile | 2 + drivers/mfd/fsl-imx25-tsadc.c | 167 ++ include/dt-bindings/iio/adc/fsl-imx25-gcq.h| 18 + include/linux/mfd/imx25-tsadc.h| 143 + 16 files changed, 1463 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt create mode 100644 Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt create mode 100644 Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt create mode 100644 drivers/iio/adc/fsl-imx25-gcq.c create mode 100644 drivers/input/touchscreen/fsl-imx25-tcq.c create mode 100644 drivers/mfd/fsl-imx25-tsadc.c create mode 100644 include/dt-bindings/iio/adc/fsl-imx25-gcq.h create mode 100644 include/linux/mfd/imx25-tsadc.h -- 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
[PATCH v6 8/8] ARM: imx_v4_v5_defconfig: Add I.MX25 Touchscreen controller and ADC support.
From: Denis Carikli de...@eukrea.com Signed-off-by: Denis Carikli de...@eukrea.com Signed-off-by: Markus Pargmann m...@pengutronix.de --- arch/arm/configs/imx_v4_v5_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/configs/imx_v4_v5_defconfig b/arch/arm/configs/imx_v4_v5_defconfig index e6b0007355f8..e1bda0136f6c 100644 --- a/arch/arm/configs/imx_v4_v5_defconfig +++ b/arch/arm/configs/imx_v4_v5_defconfig @@ -89,6 +89,7 @@ CONFIG_KEYBOARD_IMX=y # CONFIG_INPUT_MOUSE is not set CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_ADS7846=m +CONFIG_TOUCHSCREEN_MX25=y CONFIG_TOUCHSCREEN_MC13783=y # CONFIG_LEGACY_PTYS is not set CONFIG_SERIAL_8250=m @@ -108,6 +109,7 @@ CONFIG_HWMON=m CONFIG_SENSORS_MC13783_ADC=m CONFIG_WATCHDOG=y CONFIG_IMX2_WDT=y +CONFIG_MFD_MX25_TSADC=y CONFIG_MFD_MC13XXX_SPI=y CONFIG_REGULATOR=y CONFIG_REGULATOR_FIXED_VOLTAGE=y @@ -173,6 +175,8 @@ CONFIG_DMADEVICES=y CONFIG_IMX_SDMA=y CONFIG_IMX_DMA=y # CONFIG_IOMMU_SUPPORT is not set +CONFIG_IIO=y +CONFIG_FSL_MX25_ADC=y CONFIG_EXT2_FS=y CONFIG_EXT3_FS=y CONFIG_EXT4_FS=y -- 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
[PATCH v6 4/8] mfd: fsl imx25 Touchscreen ADC driver
This is the core driver for imx25 touchscreen/adc driver. The module
has one shared ADC and two different conversion queues which use the
ADC. The two queues are identical. Both can be used for general purpose
ADC but one is meant to be used for touchscreens.
This driver is the core which manages the central components and
registers of the TSC/ADC unit. It manages the IRQs and forwards them to
the correct components.
Signed-off-by: Markus Pargmann m...@pengutronix.de
Signed-off-by: Denis Carikli de...@eukrea.com
Acked-by: Jonathan Cameron ji...@kernel.org
---
Notes:
Changes in v5:
- Remove ifdef CONFIG_OF as this driver is only for DT usage
- Remove module owner
- Add Kconfig dependencies ARCH_MX25 and OF
@Jonathan Cameron:
I left your acked-by on the patch as these were small changes. If it should
be
removed, please say so. Thanks
drivers/mfd/Kconfig | 10 +++
drivers/mfd/Makefile| 2 +
drivers/mfd/fsl-imx25-tsadc.c | 167
include/linux/mfd/imx25-tsadc.h | 143 ++
4 files changed, 322 insertions(+)
create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
create mode 100644 include/linux/mfd/imx25-tsadc.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 2e6b7311fabc..44fc15598a6a 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -232,6 +232,16 @@ config MFD_MC13XXX_I2C
help
Select this if your MC13xxx is connected via an I2C bus.
+config MFD_MX25_TSADC
+ tristate Freescale i.MX25 integrated Touchscreen and ADC unit
+ select REGMAP_MMIO
+ depends on SOC_IMX25
+ depends on OF
+ help
+ Enable support for the integrated Touchscreen and ADC unit of the
+ i.MX25 processors. They consist of a conversion queue for general
+ purpose ADC and a queue for Touchscreens.
+
config MFD_HI6421_PMIC
tristate HiSilicon Hi6421 PMU/Codec IC
depends on OF
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 53467e211381..3feeb29f5938 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -78,6 +78,8 @@ obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
obj-$(CONFIG_MFD_TWL4030_AUDIO)+= twl4030-audio.o
obj-$(CONFIG_TWL6040_CORE) += twl6040.o
+obj-$(CONFIG_MFD_MX25_TSADC) += fsl-imx25-tsadc.o
+
obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o
obj-$(CONFIG_MFD_MC13XXX_SPI) += mc13xxx-spi.o
obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o
diff --git a/drivers/mfd/fsl-imx25-tsadc.c b/drivers/mfd/fsl-imx25-tsadc.c
new file mode 100644
index ..8e4013d57500
--- /dev/null
+++ b/drivers/mfd/fsl-imx25-tsadc.c
@@ -0,0 +1,167 @@
+/*
+ * Copyright 2014 Markus Pargmann, Pengutronix m...@pengutronix.de
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include linux/clk.h
+#include linux/interrupt.h
+#include linux/irqchip/chained_irq.h
+#include linux/irqdesc.h
+#include linux/irqdomain.h
+#include linux/irq.h
+#include linux/mfd/imx25-tsadc.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/platform_device.h
+#include linux/regmap.h
+
+static struct regmap_config mx25_tsadc_regmap_config = {
+ .fast_io = true,
+ .max_register = 8,
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+};
+
+static void mx25_tsadc_irq_handler(u32 irq, struct irq_desc *desc)
+{
+ struct mx25_tsadc *tsadc = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip = irq_get_chip(irq);
+ u32 status;
+
+ chained_irq_enter(chip, desc);
+
+ regmap_read(tsadc-regs, MX25_TSC_TGSR, status);
+
+ if (status MX25_TGSR_GCQ_INT)
+ generic_handle_irq(irq_find_mapping(tsadc-domain, 1));
+
+ if (status MX25_TGSR_TCQ_INT)
+ generic_handle_irq(irq_find_mapping(tsadc-domain, 0));
+
+ chained_irq_exit(chip, desc);
+}
+
+static int mx25_tsadc_domain_map(struct irq_domain *d, unsigned int irq,
+irq_hw_number_t hwirq)
+{
+ struct mx25_tsadc *tsadc = d-host_data;
+
+ irq_set_chip_data(irq, tsadc);
+ irq_set_chip_and_handler(irq, dummy_irq_chip,
+handle_level_irq);
+ set_irq_flags(irq, IRQF_VALID);
+
+ return 0;
+}
+
+static struct irq_domain_ops mx25_tsadc_domain_ops = {
+ .map = mx25_tsadc_domain_map,
+ .xlate = irq_domain_xlate_onecell,
+};
+
+static int mx25_tsadc_setup_irq(struct platform_device *pdev,
+ struct mx25_tsadc *tsadc)
+{
+ struct device *dev = pdev-dev;
+ struct device_node *np = dev-of_node;
+ int irq;
+
+ irq =
[PATCH v6 3/8] ARM: dt: Binding documentation for imx25 touchscreen controller
This is the touchscreen conversion queue binding documentation. It uses
the shared imx25 ADC.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
Notes:
Changes in v5:
- Fix signed/unsigned comparison
- Fix unused variable settling_time by putting it in the correct argument
list
- Use continous conversion queue with the repeat feature and a proper
repeat-wait. Previously the touchscreen caused massive number of
interrupts.
.../bindings/input/touchscreen/fsl-mx25-tcq.txt| 29 ++
1 file changed, 29 insertions(+)
create mode 100644
Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
diff --git
a/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
new file mode 100644
index ..4214a99d197a
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
@@ -0,0 +1,29 @@
+Freescale mx25 TS conversion queue module
+
+mx25 touchscreen conversion queue module which controls the ADC unit of the
+mx25 for attached touchscreens.
+
+Required properties:
+ - compatible: Should be fsl,imx25-tcq.
+ - reg: Memory range of the device.
+ - interrupts: Should be the interrupt number associated with this module
within
+ the tscadc unit (0).
+ - interrupt-parent: Should be a phandle to the tscadc unit.
+ - fsl,wires: Should be '4' or '5'
+
+Optional properties:
+ - fsl,pen-debounce: Pen debounce time.
+ - fsl,pen-threshold: Pen-down threshold for the touchscreen.
+ - fsl,settling-time: Settling time in nanoseconds.
+
+This device includes two conversion queues which can be added as subnodes.
+The first queue is for the touchscreen, the second for general purpose ADC.
+
+Example:
+ tsc: tcq@50030400 {
+ compatible = fsl,imx25-tcq;
+ reg = 0x50030400 0x60;
+ interrupt-parent = tscadc;
+ interrupts = 0;
+ fsl,wires = 4;
+ };
--
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
[PATCH v6 5/8] iio: adc: fsl,imx25-gcq driver
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
diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index 0f79e4725763..fccbb4bf44cc 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -143,6 +143,13 @@ config EXYNOS_ADC
of SoCs for drivers such as the touchscreen and hwmon to use to share
this resource.
+config FSL_MX25_ADC
+ tristate Freescale MX25 ADC driver
+ depends on MFD_MX25_TSADC
+ help
+ Generic Conversion Queue driver used for general purpose ADC in the
+ MX25. This driver supports single measurements using the MX25 ADC.
+
config LP8788_ADC
tristate LP8788 ADC driver
depends on MFD_LP8788
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index 701fdb7c96aa..acab8d956371 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_AD799X) += ad799x.o
obj-$(CONFIG_AT91_ADC) += at91_adc.o
obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
+obj-$(CONFIG_FSL_MX25_ADC) += fsl-imx25-gcq.o
obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
obj-$(CONFIG_MAX1027) += max1027.o
obj-$(CONFIG_MAX1363) += max1363.o
diff --git a/drivers/iio/adc/fsl-imx25-gcq.c b/drivers/iio/adc/fsl-imx25-gcq.c
new file mode 100644
index ..398e40c0e4fd
--- /dev/null
+++ b/drivers/iio/adc/fsl-imx25-gcq.c
@@ -0,0 +1,361 @@
+/*
+ * Copyright 2014 Markus Pargmann, Pengutronix m...@pengutronix.de
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ *
+ * This is the driver for the imx25 GCQ (Generic Conversion Queue)
+ * connected to the imx25 ADC.
+ */
+
+#include dt-bindings/iio/adc/fsl-imx25-gcq.h
+#include linux/clk.h
+#include linux/iio/iio.h
+#include linux/interrupt.h
+#include linux/mfd/imx25-tsadc.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/regulator/consumer.h
+
+#define MX25_GCQ_TIMEOUT (msecs_to_jiffies(2000))
+
+enum mx25_gcq_cfgs {
+ MX25_CFG_XP = 0,
+ MX25_CFG_YP,
+ MX25_CFG_XN,
+ MX25_CFG_YN,
+ MX25_CFG_WIPER,
+ MX25_CFG_INAUX0,
+ MX25_CFG_INAUX1,
+ MX25_CFG_INAUX2,
+ MX25_NUM_CFGS,
+};
+
+struct mx25_gcq_priv {
+ struct regmap *regs;
+ struct completion completed;
+ unsigned int settling_time;
+ struct clk *clk;
+ int irq;
+ struct regulator *ext_vref;
+ u32 channel_vref_mv[MX25_NUM_CFGS];
+};
+
+#define MX25_CQG_CHAN(chan, id) {\
+ .type = IIO_VOLTAGE,\
+ .indexed = 1,\
+ .channel = chan,\
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),\
+ .info_mask_shared_by_type = BIT(IIO_CHAN_INFO_SCALE),\
+ .datasheet_name = id,\
+}
+
+static const struct iio_chan_spec mx25_gcq_channels[MX25_NUM_CFGS] = {
+ MX25_CQG_CHAN(0, xp),
+ MX25_CQG_CHAN(1, yp),
+ MX25_CQG_CHAN(2, xn),
+ MX25_CQG_CHAN(3, yn),
+ MX25_CQG_CHAN(4, wiper),
+ MX25_CQG_CHAN(5, inaux0),
+ MX25_CQG_CHAN(6, inaux1),
+ MX25_CQG_CHAN(7, inaux2),
+};
+
+static void mx25_gcq_disable_eoq(struct mx25_gcq_priv *priv)
+{
+ regmap_update_bits(priv-regs, MX25_ADCQ_MR, MX25_ADCQ_MR_EOQ_IRQ,
+ MX25_ADCQ_MR_EOQ_IRQ);
+}
+
+static void mx25_gcq_enable_eoq(struct mx25_gcq_priv *priv)
+{
+ regmap_update_bits(priv-regs, MX25_ADCQ_MR,
+ MX25_ADCQ_MR_EOQ_IRQ, 0);
+}
+
+static irqreturn_t mx25_gcq_irq(int irq, void *data)
+{
+ struct mx25_gcq_priv *priv = data;
+ u32 stats;
+
+ regmap_read(priv-regs, MX25_ADCQ_SR, stats);
+
+ if (stats MX25_ADCQ_SR_EOQ) {
+ mx25_gcq_disable_eoq(priv);
+
[PATCH v6 2/8] ARM: dt: Binding documentation for imx25 GCQ
The documentation describes the bindings for the imx25 GCQ unit which is
essentially a generic conversion queue using the imx25 ADC.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
Notes:
Changes in v6:
- Moved the raw_read code out to a different function to cleanup the code
- Changed bindings to use adc-refp and adc-refn. Also a bit of cleanup in
the
setup routine.
- Added defines for a complete list of references in the dt binding macros
Changes in v5:
- Fixed locking
- Removed module owner
.../devicetree/bindings/iio/adc/fsl,imx25-gcq.txt | 54 ++
1 file changed, 54 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
diff --git a/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
new file mode 100644
index ..9f7c08990034
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
@@ -0,0 +1,54 @@
+Freescale i.MX25 ADC GCQ device
+
+This is a generic conversion queue device that can convert any of the
+analog inputs using the ADC unit of the i.MX25.
+
+Required properties:
+ - compatible: Should be fsl,imx25-gcq.
+ - reg: Should be the register range of the module.
+ - interrupts: Should be the interrupt number of the module.
+ Typically this is 1.
+ - interrupt-parent: phandle to the tsadc module of the i.MX25.
+ - #address-cells: Should be 1 (setting for the subnodes)
+ - #size-cells: Should be 0 (setting for the subnodes)
+
+Optional properties:
+ - vref-supply: The regulator supplying the ADC reference voltage.
+ Required when at least one subnode uses the external reference.
+
+Sub-nodes:
+Optionally you can define subnodes which define the reference voltage
+for the analog inputs.
+
+Required properties for subnodes:
+ - reg: Should be the number of the analog input.
+ 0: xp
+ 1: yp
+ 2: xn
+ 3: yn
+ 4: wiper
+ 5: inaux0
+ 6: inaux1
+ 7: inaux2
+Optional properties for subnodes:
+ - fsl,adc-refp: specifies the positive reference input as defined in
+ dt-bindings/iio/adc/fsl-imx25-gcq.h
+ - fsl,adc-refn: specifies the negative reference input as defined in
+ dt-bindings/iio/adc/fsl-imx25-gcq.h
+
+Example:
+
+ adc: adc@50030800 {
+ compatible = fsl,imx25-gcq;
+ reg = 0x50030800 0x60;
+ interrupt-parent = tscadc;
+ interrupts = 1;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ inaux@5 {
+ reg = 5;
+ fsl,adc-refp = MX25_ADC_REF_INT;
+ fsl,adc-refn = MX25_ADC_REF_NGND;
+ };
+ };
--
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
[PATCH v6 1/8] ARM: dt: Binding documentation for imx25 ADC/TSC
This documentation describes the devicetree bindings for the
ADC/Touchscreen unit of the i.MX25 SoC.
Signed-off-by: Markus Pargmann m...@pengutronix.de
---
Notes:
Changes in v6:
- Removed adc-ref property and replaced it with refp and refn for positive
and
negative references. The properties are optional now as the default
behaviour is a positive internal reference voltage and ADC GND as
negative
reference.
.../devicetree/bindings/mfd/fsl-imx25-tsadc.txt| 46 ++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
diff --git a/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
b/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
new file mode 100644
index ..a857af0eb68c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
@@ -0,0 +1,46 @@
+Freescale mx25 ADC/TSC multifunction device
+
+This device combines two general purpose conversion queues one used for general
+ADC and the other used for touchscreens.
+
+Required properties:
+ - compatible: Should be fsl,imx25-tsadc.
+ - reg: Memory range of the device.
+ - interrupts: Interrupt for this device as described in
+ interrupts/interrupts.txt
+ - clocks: An 'ipg' clock defined as described in clocks/clock.txt
+ - interrupt-controller: This device is an interrupt controller. It controls
+ the interrupts of both conversion queues.
+ - #interrupt-cells: Should be '1'.
+ - #address-cells: Should be '1'.
+ - #size-cells: Should be '1'.
+ - ranges
+
+This device includes two conversion queues which can be added as subnodes.
+The first queue is for the touchscreen, the second for general purpose ADC.
+
+Example:
+ tscadc: tscadc@5003 {
+ compatible = fsl,imx25-tsadc;
+ reg = 0x5003 0xc;
+ interrupts = 46;
+ clocks = clks 119;
+ clock-names = ipg;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ tsc: tcq@50030400 {
+ compatible = fsl,imx25-tcq;
+ reg = 0x50030400 0x60;
+ ...
+ };
+
+ adc: gcq@50030800 {
+ compatible = fsl,imx25-gcq;
+ reg = 0x50030800 0x60;
+ ...
+ };
+ };
--
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
[PATCH v6 6/8] input: touchscreen: imx25 tcq driver
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
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 58917525126e..f1534a0cd23f 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -748,6 +748,12 @@ config TOUCHSCREEN_USB_COMPOSITE
To compile this driver as a module, choose M here: the
module will be called usbtouchscreen.
+config TOUCHSCREEN_MX25
+ tristate Freescale i.MX25 touchscreen input driver
+ depends on MFD_MX25_TSADC
+ help
+ Enable support for touchscreen connected to your i.MX25.
+
config TOUCHSCREEN_MC13783
tristate Freescale MC13783 touchscreen input driver
depends on MFD_MC13XXX
diff --git a/drivers/input/touchscreen/Makefile
b/drivers/input/touchscreen/Makefile
index 0242fea2102a..bbb55a69c33c 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_TOUCHSCREEN_INEXIO) += inexio.o
obj-$(CONFIG_TOUCHSCREEN_INTEL_MID)+= intel-mid-touch.o
obj-$(CONFIG_TOUCHSCREEN_LPC32XX) += lpc32xx_ts.o
obj-$(CONFIG_TOUCHSCREEN_MAX11801) += max11801_ts.o
+obj-$(CONFIG_TOUCHSCREEN_MX25) += fsl-imx25-tcq.o
obj-$(CONFIG_TOUCHSCREEN_MC13783) += mc13783_ts.o
obj-$(CONFIG_TOUCHSCREEN_MCS5000) += mcs5000_ts.o
obj-$(CONFIG_TOUCHSCREEN_MIGOR)+= migor_ts.o
diff --git a/drivers/input/touchscreen/fsl-imx25-tcq.c
b/drivers/input/touchscreen/fsl-imx25-tcq.c
new file mode 100644
index ..2eb3bd00d56c
--- /dev/null
+++ b/drivers/input/touchscreen/fsl-imx25-tcq.c
@@ -0,0 +1,587 @@
+/*
+ * Copyright 2014 Markus Pargmann, Pengutronix m...@pengutronix.de
+ * Based on driver from 2011:
+ * Juergen Beisert, Pengutronix ker...@pengutronix.de
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ *
+ * This is the driver for the imx25 TCQ (Touchscreen Conversion Queue)
+ * connected to the imx25 ADC.
+ */
+
+#include linux/clk.h
+#include linux/input.h
+#include linux/interrupt.h
+#include linux/mfd/imx25-tsadc.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/regmap.h
+
+static const char mx25_tcq_name[] = mx25-tcq;
+
+enum mx25_tcq_mode {
+ MX25_TS_4WIRE,
+};
+
+struct mx25_tcq_priv {
+ struct regmap *regs;
+ struct regmap *core_regs;
+ struct input_dev *idev;
+ enum mx25_tcq_mode mode;
+ unsigned int pen_threshold;
+ unsigned int sample_count;
+ unsigned int expected_samples;
+ unsigned int pen_debounce;
+ unsigned int settling_time;
+ struct clk *clk;
+ int irq;
+};
+
+static struct regmap_config mx25_tcq_regconfig = {
+ .fast_io = true,
+ .max_register = 0x5c,
+ .reg_bits = 32,
+ .val_bits = 32,
+ .reg_stride = 4,
+};
+
+static struct of_device_id mx25_tcq_ids[] = {
+ { .compatible = fsl,imx25-tcq, },
+ { /* Sentinel */ }
+};
+
+#define TSC_4WIRE_PRE_INDEX 0
+#define TSC_4WIRE_X_INDEX 1
+#define TSC_4WIRE_Y_INDEX 2
+#define TSC_4WIRE_POST_INDEX 3
+#define TSC_4WIRE_LEAVE 4
+
+#define MX25_TSC_DEF_THRESHOLD 80
+#define TSC_MAX_SAMPLES 16
+
+#define MX25_TSC_REPEAT_WAIT 14
+
+enum mx25_adc_configurations {
+ MX25_CFG_PRECHARGE = 0,
+ MX25_CFG_TOUCH_DETECT,
+ MX25_CFG_X_MEASUREMENT,
+ MX25_CFG_Y_MEASUREMENT,
+};
+
+#define MX25_PRECHARGE_VALUE (\
+ MX25_ADCQ_CFG_YPLL_OFF | \
+ MX25_ADCQ_CFG_XNUR_OFF | \
+ MX25_ADCQ_CFG_XPUL_HIGH | \
+ MX25_ADCQ_CFG_REFP_INT | \
+ MX25_ADCQ_CFG_IN_XP | \
+ MX25_ADCQ_CFG_REFN_NGND2 | \
+ MX25_ADCQ_CFG_IGS)
+
+#define MX25_TOUCH_DETECT_VALUE (\
+
Re: [PATCH v6 6/8] input: touchscreen: imx25 tcq driver
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
+err_clk_unprepare:
+ clk_disable_unprepare(priv-clk);
+ return ret;
+}
+
+static int mx25_tcq_remove(struct platform_device *pdev)
+{
+ struct mx25_tcq_priv *priv = platform_get_drvdata(pdev);
+
+ free_irq(priv-irq, priv);
This also..
--
Regards,
Varka Bhadram.
--
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 3/3] pinctrl: qcom: Add msm8916 pinctrl driver
Hi Andy, On 01/29/2015 01:18 AM, Andy Gross wrote: On Tue, Jan 20, 2015 at 11:17:56AM +0200, Stanimir Varbanov wrote: snip +MSM_MUX_blsp1_spi, +MSM_MUX_blsp2_spi, +MSM_MUX_blsp3_spi, The above three need to be renamed to blsp_spiX_csX to denote which SPI and chip select they modify. I catch the idea, thanks for the tips. I will address all comments. -- regards, Stan -- 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 V9 04/14] drm/bridge: ptn3460: Convert to i2c driver model
Hi Ajay, 2015-01-20 Ajay Kumar ajaykumar...@samsung.com: Use drm_bridge helpers to modify the driver to support i2c driver model. 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/bridge/Kconfig |2 + drivers/gpu/drm/bridge/ptn3460.c| 124 +-- drivers/gpu/drm/exynos/exynos_dp_core.c | 22 -- 3 files changed, 86 insertions(+), 62 deletions(-) diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 884923f..4254c2b 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -1,5 +1,7 @@ config DRM_PTN3460 tristate PTN3460 DP/LVDS bridge depends on DRM + depends on OF I2C Adding I2C here is causing this circular dependency: scripts/kconfig/conf --silentoldconfig Kconfig drivers/video/fbdev/Kconfig:5:error: recursive dependency detected! drivers/video/fbdev/Kconfig:5: symbol FB is selected by DRM_KMS_FB_HELPER drivers/gpu/drm/Kconfig:34: symbol DRM_KMS_FB_HELPER depends on DRM_KMS_HELPER drivers/gpu/drm/Kconfig:28: symbol DRM_KMS_HELPER is selected by DRM_PTN3460 drivers/gpu/drm/bridge/Kconfig:1: symbol DRM_PTN3460 depends on I2C drivers/i2c/Kconfig:7: symbol I2C is selected by FB_DDC drivers/video/fbdev/Kconfig:59: symbol FB_DDC is selected by FB_CYBER2000_DDC drivers/video/fbdev/Kconfig:374:symbol FB_CYBER2000_DDC depends on FB_CYBER2000 drivers/video/fbdev/Kconfig:362:symbol FB_CYBER2000 depends on FB To solve this we just need to remove I2C from depends as DRM already selects I2C. This was already fixed by: commit 90bde571ad194adb039cb92a11a5b346f15eb610 Author: Arnd Bergmann a...@arndb.de Date: Tue Mar 25 12:06:46 2014 +0100 drm/bridge: PTN3460 needs DRM_KMS_HELPER The recently added PTN3460 device driver uses interfaces that are provided by the KMS helper infrastructure, so we should explicitly select that to avoid this linker error: ERROR: drm_helper_probe_single_connector_modes [drivers/gpu/drm/bridge/ptn3460.ko] undefined! ERROR: drm_helper_connector_dpms [drivers/gpu/drm/bridge/ptn3460.ko] undefined! We have to drop the I2C dependency to avoid a circular dependency chain, but that's ok because DRM already selects I2C. Signed-off-by: Arnd Bergmann a...@arndb.de Signed-off-by: Dave Airlie airl...@redhat.com But you may have introduced it again on a rebase. The following patch fixes it: diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig index 990b4b2..946d1ef 100644 --- a/drivers/gpu/drm/bridge/Kconfig +++ b/drivers/gpu/drm/bridge/Kconfig @@ -1,7 +1,6 @@ config DRM_PTN3460 tristate PTN3460 DP/LVDS bridge - depends on DRM - depends on OF I2C + depends on DRM OF select DRM_KMS_HELPER select DRM_PANEL ---help--- Gustavo -- 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
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? Rob -- 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 V9 12/14] drm/bridge: Add i2c based driver for ps8622/ps8625 bridge
Hi Thierry,
I think you forgot to take this patch!
Can you check this?
Regards,
Ajay Kumar
On Tue, Jan 20, 2015 at 10:08 PM, Ajay Kumar ajaykumar...@samsung.com wrote:
From: Vincent Palatin vpala...@chromium.org
This patch adds drm_bridge driver for parade DisplayPort
to LVDS bridge chip.
Signed-off-by: Vincent Palatin vpala...@chromium.org
Signed-off-by: Andrew Bresticker abres...@chromium.org
Signed-off-by: Sean Paul seanp...@chromium.org
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
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/bridge/Kconfig |9 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/ps8622.c | 684
+++
3 files changed, 694 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/ps8622.c
diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 8b426e2..d06eda3 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -6,3 +6,12 @@ config DRM_PTN3460
select DRM_PANEL
---help---
ptn3460 eDP-LVDS bridge chip driver.
+
+config DRM_PS8622
+ tristate Parade eDP/LVDS bridge
+ depends on OF I2C
+ select DRM_PANEL
+ select BACKLIGHT_LCD_SUPPORT
+ select BACKLIGHT_CLASS_DEVICE
+ ---help---
+ parade eDP-LVDS bridge chip driver.
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index b4733e1..105da3e 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,3 +1,4 @@
ccflags-y := -Iinclude/drm
+obj-$(CONFIG_DRM_PS8622) += ps8622.o
obj-$(CONFIG_DRM_PTN3460) += ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ps8622.c b/drivers/gpu/drm/bridge/ps8622.c
new file mode 100644
index 000..5474a39
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ps8622.c
@@ -0,0 +1,684 @@
+/*
+ * Parade PS8622 eDP/LVDS bridge driver
+ *
+ * Copyright (C) 2014 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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/backlight.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/fb.h
+#include linux/gpio.h
+#include linux/i2c.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_graph.h
+#include linux/pm.h
+#include linux/regulator/consumer.h
+
+#include drm/drm_panel.h
+
+#include drmP.h
+#include drm_crtc.h
+#include drm_crtc_helper.h
+
+/* Brightness scale on the Parade chip */
+#define PS8622_MAX_BRIGHTNESS 0xff
+
+/* Timings taken from the version 1.7 datasheet for the PS8622/PS8625 */
+#define PS8622_POWER_RISE_T1_MIN_US 10
+#define PS8622_POWER_RISE_T1_MAX_US 1
+#define PS8622_RST_HIGH_T2_MIN_US 3000
+#define PS8622_RST_HIGH_T2_MAX_US 3
+#define PS8622_PWMO_END_T12_MS 200
+#define PS8622_POWER_FALL_T16_MAX_US 1
+#define PS8622_POWER_OFF_T17_MS 500
+
+#if ((PS8622_RST_HIGH_T2_MIN_US + PS8622_POWER_RISE_T1_MAX_US) \
+ (PS8622_RST_HIGH_T2_MAX_US + PS8622_POWER_RISE_T1_MIN_US))
+#error T2.min + T1.max must be less than T2.max + T1.min
+#endif
+
+struct ps8622_bridge {
+ struct drm_connector connector;
+ struct i2c_client *client;
+ struct drm_bridge bridge;
+ struct drm_panel *panel;
+ struct regulator *v12;
+ struct backlight_device *bl;
+
+ struct gpio_desc *gpio_slp;
+ struct gpio_desc *gpio_rst;
+
+ u32 max_lane_count;
+ u32 lane_count;
+
+ bool enabled;
+};
+
+static inline struct ps8622_bridge *
+ bridge_to_ps8622(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct ps8622_bridge, bridge);
+}
+
+static inline struct ps8622_bridge *
+ connector_to_ps8622(struct drm_connector *connector)
+{
+ return container_of(connector, struct ps8622_bridge, connector);
+}
+
+static int ps8622_set(struct i2c_client *client, u8 page, u8 reg, u8 val)
+{
+ int ret;
+ struct i2c_adapter *adap = client-adapter;
+ struct i2c_msg msg;
+ u8 data[] = {reg, val};
+
+ msg.addr = client-addr + page;
+ msg.flags = 0;
+ msg.len = sizeof(data);
+ msg.buf = data;
+
+ ret =
