Re: [PATCH] staging:iio:adc: Add SPEAr ADC driver
On Wednesday 11 April 2012 15:40:52 Jonathan Cameron wrote: On 4/11/2012 2:19 PM, Stefan Roese wrote: This patch implements the basic single data conversion support for the SPEAr600 SoC ADC. The register layout of SPEAr600 differs a bit from other SPEAr SoC variants (e.g. SPEAr3xx). These differences are handled via DT compatible testing. Resuling in a multi-arch binary. Resulting This driver is currently tested only on SPEAr600. Futur patches may add support for other SoC variants (SPEAr3xx) and features like software buffer or DMA. Future Ironically that's about it wrt to comments. Couple of totally trivial bits inline. Basically I'm happy, so if/when someone acks the device tree side of things, please clean up the trivial bits and send on to GregKH. Nice short, clean driver. The small line count lured me into reviewing it ahead of some others in my review pile! Jonathan, thanks for the quick review. I'll address you comments and send an updated patch shortly. Stefan ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] staging:iio:adc: Add SPEAr ADC driver
On 4/11/2012 6:49 PM, Stefan Roese wrote:
+static int __devinit spear_adc_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ struct spear_adc_info *info;
+ struct resource *res;
+ int retval = -ENODEV;
+ struct iio_dev *iodev = NULL;
+ int irq;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(pdev-dev, failed to get platform I/O memory\n);
+ retval = -EBUSY;
+ goto errout1;
+ }
+
+ iodev = iio_allocate_device(sizeof(struct spear_adc_info));
+ if (!iodev) {
+ dev_err(pdev-dev, failed allocating iio device\n);
+ retval = -ENOMEM;
+ goto errout1;
+ }
+
+ info = iio_priv(iodev);
+ info-np = np;
+
+ /*
+* SPEAr600 has a different register layout than other SPEAr SoC's
+* (e.g. SPEAr3xx). Let's provide two register base addresses
+* to support multi-arch kernels.
+*/
+ info-adc_base_spear6xx = ioremap(res-start, resource_size(res));
+ if (!info-adc_base_spear6xx) {
+ dev_err(pdev-dev, failed mapping memory\n);
+ retval = -EBUSY;
+ goto errout2;
+ }
This must be a DT only driver and so you can use of_iomap() instead of
ioremap() and platform_get_resource()
+ info-adc_base_spear3xx =
+ (struct adc_regs_spear3xx *)info-adc_base_spear6xx;
+
+ info-clk = clk_get(pdev-dev, NULL);
+ if (IS_ERR(info-clk)) {
+ dev_err(pdev-dev, failed getting clock\n);
+ goto errout3;
+ }
patch for devm_* variant of clk is also there.
+ clk_enable(info-clk);
clk_prepare() is required now, before enable.
+
+ irq = platform_get_irq(pdev, 0);
+ if ((irq 0) || (irq = NR_IRQS)) {
+ dev_err(pdev-dev, failed getting interrupt resource\n);
+ retval = -EINVAL;
+ goto errout4;
+ }
+
+ retval = request_irq(irq, spear_adc_isr, 0, MOD_NAME, info);
+ if (retval 0) {
+ dev_err(pdev-dev, failed requesting interrupt\n);
+ goto errout4;
+ }
+
can use devm_* variants wherever possible.
--
viresh
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] staging:iio:adc: Add SPEAr ADC driver
On Thursday 12 April 2012 08:12:02 Viresh Kumar wrote:
On 4/11/2012 6:49 PM, Stefan Roese wrote:
+static int __devinit spear_adc_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ struct spear_adc_info *info;
+ struct resource *res;
+ int retval = -ENODEV;
+ struct iio_dev *iodev = NULL;
+ int irq;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ dev_err(pdev-dev, failed to get platform I/O
memory\n); + retval = -EBUSY;
+ goto errout1;
+ }
+
+ iodev = iio_allocate_device(sizeof(struct spear_adc_info));
+ if (!iodev) {
+ dev_err(pdev-dev, failed allocating iio device\n);
+ retval = -ENOMEM;
+ goto errout1;
+ }
+
+ info = iio_priv(iodev);
+ info-np = np;
+
+ /*
+* SPEAr600 has a different register layout than other SPEAr
SoC's +* (e.g. SPEAr3xx). Let's provide two register base
addresses +* to support multi-arch kernels.
+*/
+ info-adc_base_spear6xx = ioremap(res-start,
resource_size(res)); + if (!info-adc_base_spear6xx) {
+ dev_err(pdev-dev, failed mapping memory\n);
+ retval = -EBUSY;
+ goto errout2;
+ }
This must be a DT only driver and so you can use of_iomap() instead of
ioremap() and platform_get_resource()
Yes, thanks for spotting.
+ info-adc_base_spear3xx =
+ (struct adc_regs_spear3xx *)info-adc_base_spear6xx;
+
+ info-clk = clk_get(pdev-dev, NULL);
+ if (IS_ERR(info-clk)) {
+ dev_err(pdev-dev, failed getting clock\n);
+ goto errout3;
+ }
patch for devm_* variant of clk is also there.
Where is it? Is it already in next? Do you have a link for the patch?
+ clk_enable(info-clk);
clk_prepare() is required now, before enable.
Ahh, I didn't follow the clk updates lately. Will update.
+
+ irq = platform_get_irq(pdev, 0);
+ if ((irq 0) || (irq = NR_IRQS)) {
+ dev_err(pdev-dev, failed getting interrupt
resource\n); + retval = -EINVAL;
+ goto errout4;
+ }
+
+ retval = request_irq(irq, spear_adc_isr, 0, MOD_NAME, info);
+ if (retval 0) {
+ dev_err(pdev-dev, failed requesting interrupt\n);
+ goto errout4;
+ }
+
can use devm_* variants wherever possible.
Okay.
Thanks,
Stefan
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
* Arnd Bergmann wrote: On Wednesday 11 April 2012, Thierry Reding wrote: Daniel Vetter wrote: Well, you use the iommu api to map/unmap memory into the iommu for tegra, whereas usually device drivers just use the dma api to do that. The usual interface is dma_map_sg/dma_unmap_sg, but there are quite a few variants around. I'm just wondering why this you've choosen this. I don't think this works on ARM. Maybe I'm not seeing the whole picture but judging by a quick look through the kernel tree there aren't any users that map DMA memory through an IOMMU. dma_map_sg is certainly the right interface to use, and Marek Szyprowski has patches to make that work on ARM, hopefully going into v3.5, so you could use those. I've looked at Marek's patches but I don't think they'll work for Tegra 2 or Tegra 3. The corresponding iommu_map() functions only set one PTE, regardless of the number of bytes passed to them. However, the Tegra TRM indicates that mapping needs to be done on a per-page basis so contiguous regions cannot be combined. I suppose the IOMMU driver would have to be fixed to program more than a single page in that case. Also this doesn't yet solve the vmap() problem that is needed for the kernel virtual mapping. I did try using dma_alloc_writecombine(), but that only works for chunks of 2 MB or smaller, unless I use init_consistent_dma_size() during board setup, which isn't provided for in a DT setup. I couldn't find a better alternative, but I admit I'm not very familiar with all the VM APIs. Do you have any suggestions on how to solve this? Otherwise I'll try and dig in some more. Thierry pgpvwmfXfBSxK.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
* Stephen Warren wrote:
On 04/11/2012 06:10 AM, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
currently has rudimentary GEM support and can run a console on the
framebuffer as well as X using the xf86-video-modesetting driver.
Only the RGB output is supported. Quite a lot of things still need
to be worked out and there is a lot of room for cleanup.
I'll let Jon Mayo comment on the actual driver implementation, since
he's a lot more familiar with Tegra's display hardware. However, I have
some general comments below.
.../devicetree/bindings/gpu/drm/tegra.txt | 24 +
arch/arm/mach-tegra/board-dt-tegra20.c |3 +
arch/arm/mach-tegra/tegra2_clocks.c|8 +-
drivers/gpu/drm/Kconfig|2 +
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/tegra/Kconfig | 10 +
drivers/gpu/drm/tegra/Makefile |5 +
drivers/gpu/drm/tegra/tegra_drv.c | 2241
drivers/gpu/drm/tegra/tegra_drv.h | 184 ++
include/drm/tegra_drm.h| 44 +
Splitting this patch into two, between arch/arm and drivers/gpu would be
a good idea.
I can certainly do that.
diff --git a/Documentation/devicetree/bindings/gpu/drm/tegra.txt
b/Documentation/devicetree/bindings/gpu/drm/tegra.txt
+ drm@5420 {
+ compatible = nvidia,tegra20-drm;
This doesn't seem right; there isn't a DRM hardware module on Tegra,
since DRM is a Linux/software-specific term.
I'd at least expect to see this compatible flag be renamed to something
more like nvidia,tegra20-dc (dc==display controller).
Since Tegra has two display controller modules (I believe identical?),
and numerous other independent(?) blocks, I'd expect to see multiple
nodes in device tree, one per hardware block, such that each block gets
its own device and driver. That said, I'm not familiar enough with
Tegra's display and graphics HW to know if this makes sense. Jon, what's
your take here? The clock change below, and in particular the original
code there that we use downstream, lends weight to my argument.
+ reg = 0x5420 0x0004/* display A */
+ 0x5424 0x0004/* display B */
+ 0x5800 0x0200 ; /* GART aperture */
+ interrupts = 0 73 0x04/* display A */
+ 0 74 0x04 ; /* display B */
+
+ lvds {
+ type = rgb;
These sub-nodes probably want a compatible property rather than a
type property.
compatible suggests that a driver would bind to it. However the data really
is only passed to the DC driver for configuration.
+ size = 345 194;
+
+ default-mode {
+ pixel-clock = 61715000;
+ vertical-refresh = 50;
+ resolution = 1366 768;
+ bits-per-pixel = 16;
+ horizontal-timings = 4 136 2 36;
+ vertical-timings = 2 4 21 10;
+ };
+ };
I imagine that quite a bit of thought needs to be put into the output
part of the binding in order to:
* Model the outputs/connectors separately from display controllers.
* Make sure that the basic infra-structure for representing an output is
general enough to be extensible to all the kinds of outputs we support,
not just the LVDS output.
I haven't played around with HDMI at all yet, so I don't know of the
requirements. I'm pretty sure the above isn't anywhere near complete
though.
* We were wondering about putting an EDID into the DT to represent the
display modes, so that all outputs had EDIDs rather than real monitors
having EDIDs, and fixed internal displays having some other
representation of capabilities.
That's an interesting approach. I like it.
I'm hoping that Jon will drive this.
diff --git a/arch/arm/mach-tegra/tegra2_clocks.c
b/arch/arm/mach-tegra/tegra2_clocks.c
- PERIPH_CLK(disp1, tegradc.0,NULL, 27, 0x138,
6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and
process_id */
- PERIPH_CLK(disp2, tegradc.1,NULL, 26, 0x13c,
6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and
process_id */
+ PERIPH_CLK(disp1, tegra-drm,NULL, 27, 0x138,
6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and
process_id */
+ PERIPH_CLK(disp2, tegra-drm,NULL, 26, 0x13c,
6, mux_pllp_plld_pllc_clkm, MUX), /* scales with voltage and
process_id */
This doesn't seem right, and couples back to my assertion above that the
two
Re: [RFC 2/4] iommu: tegra/gart: Add device tree support
* Stephen Warren wrote: On 04/11/2012 06:10 AM, Thierry Reding wrote: This commit adds device tree support for the GART hardware available on NVIDIA Tegra 20 SoCs. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- arch/arm/boot/dts/tegra20.dtsi |6 ++ arch/arm/mach-tegra/board-dt-tegra20.c |1 + drivers/iommu/tegra-gart.c | 10 ++ 3 files changed, 17 insertions(+) I think I'd prefer at least the tegra20.dtsi change split out into a separate patch so I can queue it in a dt topic branch in the Tegra repo. It might be a good idea to split this into two on an arch/arm vs. drivers/iommu boundary. Looking at Olof's branches for 3.4, that split is what happened there. Finally, there should be a binding documentation file in Documentation/devicetree/bindings in order to specify the number of reg property entries needed, and their meaning, since there's more than 1 (even though you did comment it nicely in the .dtsi file) Okay, I'll do that. Thierry pgpnA4tuqVqu8.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V2 1/2] staging: iio: add driver for isl29028
On Thu, Apr 12, 2012 at 12:38:11PM +0530, Laxman Dewangan wrote: Intersil's ISL29028 is concurrent Ambient Light and Proximity Sensor device. Add driver to access the light and IR intensity and proximity value via iio interface. Signed-off-by: Laxman Dewangan ldewan...@nvidia.com --- Taken care of all review comment from Dan. Looks nice. You went above and beyond and cleaned up a couple things I didn't mention. Thanks. regards, dan carpenter ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] staging:iio:adc: Add SPEAr ADC driver
On 4/12/2012 12:33 PM, Stefan Roese wrote: patch for devm_* variant of clk is also there. Where is it? Is it already in next? Do you have a link for the patch? Probably not in next till now. https://lkml.org/lkml/2012/4/1/56 -- viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 17/17] pwm: Take over maintainership of the PWM subsystem
* Arnd Bergmann wrote: On Tuesday 10 April 2012, Thierry Reding wrote: I'm taking over the maintainership of the PWM subsystem. This commit also adds the URLs to the gitorious project and repository as well as any missing files related to the PWM subsystem. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- Note: I guess this patch in particular could use some Acked-by, maybe from Arnd and Sascha so that people will know this happens with their blessing. Acked-by: Arnd Bergmann a...@arndb.de As far as I can tell the series is in pretty good shape. I've integrated Shawn's latest comments and I think we could get this into 3.5. Does it make sense to take the PWM tree through Linux next before having it pulled into mainline during the next merge window? Thierry pgpXWkTmo2Z9l.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] staging:iio:adc: Add SPEAr ADC driver
On Thursday 12 April 2012 09:41:45 Viresh Kumar wrote: On 4/12/2012 12:33 PM, Stefan Roese wrote: patch for devm_* variant of clk is also there. Where is it? Is it already in next? Do you have a link for the patch? Probably not in next till now. https://lkml.org/lkml/2012/4/1/56 I just checked, it's not in next. IIUC, there should be an updated patch version for this coming soon. So basing my patch on this one seems a bit too early from my point of view. Perhaps its best to update all iio drivers, once this devm_clk_* stuff in really available. Thanks, Stefan ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] staging:iio:adc: Add SPEAr ADC driver
On 4/12/2012 1:45 PM, Stefan Roese wrote: I just checked, it's not in next. IIUC, there should be an updated patch version for this coming soon. So basing my patch on this one seems a bit too early from my point of view. Perhaps its best to update all iio drivers, once this devm_clk_* stuff in really available. correct. -- viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2] staging:iio:adc: Add SPEAr ADC driver
This patch implements the basic single data conversion support for
the SPEAr600 SoC ADC. The register layout of SPEAr600 differs a bit
from other SPEAr SoC variants (e.g. SPEAr3xx). These differences are
handled via DT compatible testing. Resulting in a multi-arch binary.
This driver is currently tested only on SPEAr600. Future patches may add
support for other SoC variants (SPEAr3xx) and features like software
buffer or DMA.
Signed-off-by: Stefan Roese s...@denx.de
Acked-by: Jonathan Cameron ji...@kernel.org
Cc: Greg KH g...@kroah.com
Cc: Viresh Kumar viresh.ku...@st.com
---
v2:
- Minor spelling fixes pointed out by Jonathan
- Renamed scale_uv to scale_mv
- Used defines for constants (CLK_MIN, CLK_MAX)
- Used of_iomap() instead of ioremap() and platform_get_resource()
- Added clk_prepare()
- Added error checking to clk_enable()
.../bindings/staging/iio/adc/spear-adc.txt | 26 ++
drivers/staging/iio/adc/Kconfig|7 +
drivers/staging/iio/adc/Makefile |1 +
drivers/staging/iio/adc/spear_adc.c| 444
4 files changed, 478 insertions(+)
create mode 100644
Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
create mode 100644 drivers/staging/iio/adc/spear_adc.c
diff --git a/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
b/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
new file mode 100644
index 000..02ea23a
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
@@ -0,0 +1,26 @@
+* ST SPEAr ADC device driver
+
+Required properties:
+- compatible: Should be st,spear600-adc
+- reg: Address and length of the register set for the device
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- interrupts: Should contain the ADC interrupt
+- sampling-frequency: Default sampling frequency
+
+Optional properties:
+- vref-external: External voltage reference in milli-volts. If omitted
+ the internal voltage reference will be used.
+- average-samples: Number of samples to generate an average value. If
+ omitted, single data conversion will be used.
+
+Examples:
+
+ adc: adc@d820 {
+ compatible = st,spear600-adc;
+ reg = 0xd820 0x1000;
+ interrupt-parent = vic1;
+ interrupts = 6;
+ sampling-frequency = 500;
+ vref-external = 2500; /* 2.5V VRef */
+ };
diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig
index 592eabd..ec006e7 100644
--- a/drivers/staging/iio/adc/Kconfig
+++ b/drivers/staging/iio/adc/Kconfig
@@ -202,4 +202,11 @@ config LPC32XX_ADC
touchscreen driver, so you can only select one of the two drivers
(lpc32xx_adc or lpc32xx_ts). Provides direct access via sysfs.
+config SPEAR_ADC
+ tristate ST SPEAr ADC
+ depends on PLAT_SPEAR
+ help
+ Say yes here to build support for the integrated ADC inside the
+ ST SPEAr SoC. Provides direct access via sysfs.
+
endmenu
diff --git a/drivers/staging/iio/adc/Makefile b/drivers/staging/iio/adc/Makefile
index f83ab95..14e98b6 100644
--- a/drivers/staging/iio/adc/Makefile
+++ b/drivers/staging/iio/adc/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_ADT7310) += adt7310.o
obj-$(CONFIG_ADT7410) += adt7410.o
obj-$(CONFIG_AD7280) += ad7280a.o
obj-$(CONFIG_LPC32XX_ADC) += lpc32xx_adc.o
+obj-$(CONFIG_SPEAR_ADC) += spear_adc.o
diff --git a/drivers/staging/iio/adc/spear_adc.c
b/drivers/staging/iio/adc/spear_adc.c
new file mode 100644
index 000..d5b6730
--- /dev/null
+++ b/drivers/staging/iio/adc/spear_adc.c
@@ -0,0 +1,444 @@
+/*
+ * ST SPEAr ADC driver
+ *
+ * Copyright 2012 Stefan Roese s...@denx.de
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/completion.h
+#include linux/of.h
+#include linux/of_address.h
+
+#include ../iio.h
+#include ../sysfs.h
+
+/*
+ * SPEAR registers definitions
+ */
+
+#define SCAN_RATE_LO(x)((x) 0x)
+#define SCAN_RATE_HI(x)(((x) 0x10) 0x)
+#define CLK_LOW(x) (((x) 0xf) 0)
+#define CLK_HIGH(x)(((x) 0xf) 4)
+
+/* Bit definitions for SPEAR_ADC_STATUS */
+#define START_CONVERSION (1 0)
+#define CHANNEL_NUM(x) ((x) 1)
+#define ADC_ENABLE (1 4)
+#define AVG_SAMPLE(x) ((x) 5)
+#define VREF_INTERNAL (1 9)
+
+#define DATA_MASK 0x03ff
+#define DATA_BITS 10
+
+#define MOD_NAME spear-adc
+
+#define ADC_CHANNEL_NUM8
+
+#define CLK_MIN250
+#define CLK_MAX2000
+
+struct adc_regs_spear3xx {
+ u32
Re: [PATCH v2] staging:iio:adc: Add SPEAr ADC driver
On 4/12/2012 2:06 PM, Stefan Roese wrote:
+static int __devinit spear_adc_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ struct spear_adc_info *info;
+ struct iio_dev *iodev = NULL;
+ int ret = -ENODEV;
+ int irq;
+
+ iodev = iio_allocate_device(sizeof(struct spear_adc_info));
+ if (!iodev) {
+ dev_err(pdev-dev, failed allocating iio device\n);
+ ret = -ENOMEM;
+ goto errout1;
+ }
+
+ info = iio_priv(iodev);
+ info-np = np;
+
+ /*
+* SPEAr600 has a different register layout than other SPEAr SoC's
+* (e.g. SPEAr3xx). Let's provide two register base addresses
+* to support multi-arch kernels.
+*/
+ info-adc_base_spear6xx = of_iomap(np, 0);
+ if (!info-adc_base_spear6xx) {
+ dev_err(pdev-dev, failed mapping memory\n);
+ ret = -ENOMEM;
+ goto errout2;
+ }
+ info-adc_base_spear3xx =
+ (struct adc_regs_spear3xx *)info-adc_base_spear6xx;
+
+ info-clk = clk_get(pdev-dev, NULL);
+ if (IS_ERR(info-clk)) {
+ dev_err(pdev-dev, failed getting clock\n);
+ goto errout3;
+ }
+
+ ret = clk_prepare(info-clk);
+ if (ret) {
+ dev_err(pdev-dev, failed preparing clock\n);
+ goto errout3;
+ }
+
+ ret = clk_enable(info-clk);
+ if (ret) {
+ dev_err(pdev-dev, failed enabling clock\n);
+ goto errout3;
+ }
+
+ irq = platform_get_irq(pdev, 0);
+ if ((irq 0) || (irq = NR_IRQS)) {
+ dev_err(pdev-dev, failed getting interrupt resource\n);
+ ret = -EINVAL;
+ goto errout4;
+ }
+
+ ret = request_irq(irq, spear_adc_isr, 0, MOD_NAME, info);
devm_ ??
Otherwise:
Acked-by: Viresh Kumar viresh.ku...@st.com
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Booting DT support without U-Boot supporting it
hi Guo: I guess CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT are ARM soc specific? So, what if I want to boot MIPS kernel, but without bootloader support DT? Thanks Dennis On Thu, Apr 12, 2012 at 1:19 PM, Shawn Guo shawn@linaro.org wrote: On Thu, Apr 12, 2012 at 09:50:39AM +0530, Viresh Kumar wrote: Hi, My U-boot is on an older version and that doesn't have DT support for ARM. Now, is there any way of booting Linux with DT, without U-Boot supporting DT? This is how I responded to Fabio on the same query a few hours ago :) - Turn on CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT - cat zImage mx27pdk.dtb zImage_dtb - Boot zImage_dtb as you do with zImage Regards, Shawn ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [RFC 4/4] drm: Add NVIDIA Tegra support
Hi Thierry, On Thursday, April 12, 2012 9:18 AM Thierry Reding wrote: * Arnd Bergmann wrote: On Wednesday 11 April 2012, Thierry Reding wrote: Daniel Vetter wrote: Well, you use the iommu api to map/unmap memory into the iommu for tegra, whereas usually device drivers just use the dma api to do that. The usual interface is dma_map_sg/dma_unmap_sg, but there are quite a few variants around. I'm just wondering why this you've choosen this. I don't think this works on ARM. Maybe I'm not seeing the whole picture but judging by a quick look through the kernel tree there aren't any users that map DMA memory through an IOMMU. dma_map_sg is certainly the right interface to use, and Marek Szyprowski has patches to make that work on ARM, hopefully going into v3.5, so you could use those. I've looked at Marek's patches but I don't think they'll work for Tegra 2 or Tegra 3. The corresponding iommu_map() functions only set one PTE, regardless of the number of bytes passed to them. However, the Tegra TRM indicates that mapping needs to be done on a per-page basis so contiguous regions cannot be combined. I suppose the IOMMU driver would have to be fixed to program more than a single page in that case. I assume you want to map a set of pages into contiguous chunk in io address space. This can be done with dma_map_sg() call once IOMMU aware implementation has been assigned to the given device. DMA-mapping implementation is able to merge consecutive chunks of the scatter list in the dma/io address space if possible (i.e. there are no in-page offsets between the chunks). With my implementation of IOMMU aware dma-mapping you usually you get a single DMA chunk from the provided scatter-list. I know that this approach causes a lot of confusion at the first look, but that how dma mapping api has been designed. The scatter list based approach has some drawbacks - it is a bit oversized for most of the typical use cases for the gfx/multimedia buffers, but that's all we have now. Scatter lists were initially designed for the disk based block io operations, hence the presence of the in-page offsets and lengths for each chunk. For multimedia use cases providing an array of struct pages and asking dma-mapping to map them into contiguous memory is probably all we need. I wonder if introducing such new calls is a good idea. Anrd, what do think? It will definitely simplify the drivers and improve the code understanding. On the other hand it requires a significant amount of work in the dma-mapping framework for all architectures, but that's not a big issue for me. Also this doesn't yet solve the vmap() problem that is needed for the kernel virtual mapping. I did try using dma_alloc_writecombine(), but that only works for chunks of 2 MB or smaller, unless I use init_consistent_dma_size() during board setup, which isn't provided for in a DT setup. I couldn't find a better alternative, but I admit I'm not very familiar with all the VM APIs. Do you have any suggestions on how to solve this? Otherwise I'll try and dig in some more. Yes, I'm aware of this issue I'm currently working on solving it. I hope to use standard vmalloc range for all coherent/writecombine allocations and get rid of the custom 'consistent_dma' region at all. Best regards -- Marek Szyprowski Samsung Poland RD Center ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3] staging:iio:adc: Add SPEAr ADC driver
This patch implements the basic single data conversion support for
the SPEAr600 SoC ADC. The register layout of SPEAr600 differs a bit
from other SPEAr SoC variants (e.g. SPEAr3xx). These differences are
handled via DT compatible testing. Resulting in a multi-arch binary.
This driver is currently tested only on SPEAr600. Future patches may add
support for other SoC variants (SPEAr3xx) and features like software
buffer or DMA.
Signed-off-by: Stefan Roese s...@denx.de
Acked-by: Jonathan Cameron ji...@kernel.org
Acked-by: Viresh Kumar viresh.ku...@st.com
Cc: Greg KH g...@kroah.com
---
v3:
- Used devm_request_irq() instead of request_irq and removed free_irq()
- Added clk_disable() and clk_unprepare() in error path and
spear_adc_remove()
v2:
- Minor spelling fixes pointed out by Jonathan
- Renamed scale_uv to scale_mv
- Used defines for constants (CLK_MIN, CLK_MAX)
- Used of_iomap() instead of ioremap() and platform_get_resource()
- Added clk_prepare()
- Added error checking to clk_enable()
.../bindings/staging/iio/adc/spear-adc.txt | 26 ++
drivers/staging/iio/adc/Kconfig|7 +
drivers/staging/iio/adc/Makefile |1 +
drivers/staging/iio/adc/spear_adc.c| 447
4 files changed, 481 insertions(+)
create mode 100644
Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
create mode 100644 drivers/staging/iio/adc/spear_adc.c
diff --git a/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
b/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
new file mode 100644
index 000..02ea23a
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/iio/adc/spear-adc.txt
@@ -0,0 +1,26 @@
+* ST SPEAr ADC device driver
+
+Required properties:
+- compatible: Should be st,spear600-adc
+- reg: Address and length of the register set for the device
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- interrupts: Should contain the ADC interrupt
+- sampling-frequency: Default sampling frequency
+
+Optional properties:
+- vref-external: External voltage reference in milli-volts. If omitted
+ the internal voltage reference will be used.
+- average-samples: Number of samples to generate an average value. If
+ omitted, single data conversion will be used.
+
+Examples:
+
+ adc: adc@d820 {
+ compatible = st,spear600-adc;
+ reg = 0xd820 0x1000;
+ interrupt-parent = vic1;
+ interrupts = 6;
+ sampling-frequency = 500;
+ vref-external = 2500; /* 2.5V VRef */
+ };
diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig
index 592eabd..ec006e7 100644
--- a/drivers/staging/iio/adc/Kconfig
+++ b/drivers/staging/iio/adc/Kconfig
@@ -202,4 +202,11 @@ config LPC32XX_ADC
touchscreen driver, so you can only select one of the two drivers
(lpc32xx_adc or lpc32xx_ts). Provides direct access via sysfs.
+config SPEAR_ADC
+ tristate ST SPEAr ADC
+ depends on PLAT_SPEAR
+ help
+ Say yes here to build support for the integrated ADC inside the
+ ST SPEAr SoC. Provides direct access via sysfs.
+
endmenu
diff --git a/drivers/staging/iio/adc/Makefile b/drivers/staging/iio/adc/Makefile
index f83ab95..14e98b6 100644
--- a/drivers/staging/iio/adc/Makefile
+++ b/drivers/staging/iio/adc/Makefile
@@ -38,3 +38,4 @@ obj-$(CONFIG_ADT7310) += adt7310.o
obj-$(CONFIG_ADT7410) += adt7410.o
obj-$(CONFIG_AD7280) += ad7280a.o
obj-$(CONFIG_LPC32XX_ADC) += lpc32xx_adc.o
+obj-$(CONFIG_SPEAR_ADC) += spear_adc.o
diff --git a/drivers/staging/iio/adc/spear_adc.c
b/drivers/staging/iio/adc/spear_adc.c
new file mode 100644
index 000..bea5778
--- /dev/null
+++ b/drivers/staging/iio/adc/spear_adc.c
@@ -0,0 +1,447 @@
+/*
+ * ST SPEAr ADC driver
+ *
+ * Copyright 2012 Stefan Roese s...@denx.de
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/device.h
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/clk.h
+#include linux/err.h
+#include linux/completion.h
+#include linux/of.h
+#include linux/of_address.h
+
+#include ../iio.h
+#include ../sysfs.h
+
+/*
+ * SPEAR registers definitions
+ */
+
+#define SCAN_RATE_LO(x)((x) 0x)
+#define SCAN_RATE_HI(x)(((x) 0x10) 0x)
+#define CLK_LOW(x) (((x) 0xf) 0)
+#define CLK_HIGH(x)(((x) 0xf) 4)
+
+/* Bit definitions for SPEAR_ADC_STATUS */
+#define START_CONVERSION (1 0)
+#define CHANNEL_NUM(x) ((x) 1)
+#define ADC_ENABLE (1 4)
+#define AVG_SAMPLE(x) ((x) 5)
+#define VREF_INTERNAL (1 9)
+
+#define DATA_MASK 0x03ff
+#define DATA_BITS 10
+
+#define MOD_NAME spear-adc
+
+#define
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
On Wed, Apr 11, 2012 at 12:12:14PM -0600, Stephen Warren wrote:
On 04/11/2012 06:10 AM, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
currently has rudimentary GEM support and can run a console on the
framebuffer as well as X using the xf86-video-modesetting driver.
Only the RGB output is supported. Quite a lot of things still need
to be worked out and there is a lot of room for cleanup.
I'll let Jon Mayo comment on the actual driver implementation, since
he's a lot more familiar with Tegra's display hardware. However, I have
some general comments below.
.../devicetree/bindings/gpu/drm/tegra.txt | 24 +
arch/arm/mach-tegra/board-dt-tegra20.c |3 +
arch/arm/mach-tegra/tegra2_clocks.c|8 +-
drivers/gpu/drm/Kconfig|2 +
drivers/gpu/drm/Makefile |1 +
drivers/gpu/drm/tegra/Kconfig | 10 +
drivers/gpu/drm/tegra/Makefile |5 +
drivers/gpu/drm/tegra/tegra_drv.c | 2241
drivers/gpu/drm/tegra/tegra_drv.h | 184 ++
include/drm/tegra_drm.h| 44 +
Splitting this patch into two, between arch/arm and drivers/gpu would be
a good idea.
diff --git a/Documentation/devicetree/bindings/gpu/drm/tegra.txt
b/Documentation/devicetree/bindings/gpu/drm/tegra.txt
+ drm@5420 {
+ compatible = nvidia,tegra20-drm;
This doesn't seem right; there isn't a DRM hardware module on Tegra,
since DRM is a Linux/software-specific term.
I'd at least expect to see this compatible flag be renamed to something
more like nvidia,tegra20-dc (dc==display controller).
Since Tegra has two display controller modules (I believe identical?),
and numerous other independent(?) blocks, I'd expect to see multiple
nodes in device tree, one per hardware block, such that each block gets
its own device and driver. That said, I'm not familiar enough with
Tegra's display and graphics HW to know if this makes sense. Jon, what's
your take here? The clock change below, and in particular the original
code there that we use downstream, lends weight to my argument.
+ reg = 0x5420 0x0004/* display A */
+ 0x5424 0x0004/* display B */
+ 0x5800 0x0200 ; /* GART aperture */
+ interrupts = 0 73 0x04/* display A */
+ 0 74 0x04 ; /* display B */
+
+ lvds {
+ type = rgb;
These sub-nodes probably want a compatible property rather than a
type property.
+ size = 345 194;
+
+ default-mode {
+ pixel-clock = 61715000;
+ vertical-refresh = 50;
+ resolution = 1366 768;
+ bits-per-pixel = 16;
+ horizontal-timings = 4 136 2 36;
+ vertical-timings = 2 4 21 10;
+ };
+ };
I imagine that quite a bit of thought needs to be put into the output
part of the binding in order to:
* Model the outputs/connectors separately from display controllers.
* Make sure that the basic infra-structure for representing an output is
general enough to be extensible to all the kinds of outputs we support,
not just the LVDS output.
* We were wondering about putting an EDID into the DT to represent the
display modes, so that all outputs had EDIDs rather than real monitors
having EDIDs, and fixed internal displays having some other
representation of capabilities.
You might want to have a look at the sdrm patches I recently posted to
dri-devel and arm Linux Kernel. Among other things they allow to
register crtcs/connectors/encoders seperately so that each of them can
have its own representation in the devicetree. I haven't looked into
devicetree support for DRM, but with or without devicetree the problem
that we do not have a single PCI card for registering all DRM components
is the same.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
On Thursday 12 April 2012, Marek Szyprowski wrote: Scatter lists were initially designed for the disk based block io operations, hence the presence of the in-page offsets and lengths for each chunk. For multimedia use cases providing an array of struct pages and asking dma-mapping to map them into contiguous memory is probably all we need. I wonder if introducing such new calls is a good idea. Anrd, what do think? It will definitely simplify the drivers and improve the code understanding. On the other hand it requires a significant amount of work in the dma-mapping framework for all architectures, but that's not a big issue for me. My feeling is that it's too much like the existing _sg version, so I wouldn't add yet another variant. While having a simple page array is definitely simpler and potentially faster, I think the API is already too complex and we need to be very careful with new additions. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] of: Add Avionic Design vendor prefix
This commit adds a device tree vendor prefix for Avionic Design GmbH. Cc: Grant Likely grant.lik...@secretlab.ca Cc: Rob Herring rob.herr...@calxeda.com Cc: devicetree-discuss@lists.ozlabs.org Cc: Linus Walleij linus.wall...@stericsson.com Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- Documentation/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 82ac057..6b6e465 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -3,6 +3,7 @@ Device tree binding vendor prefix registry. Keep list in alphabetical order. This isn't an exhaustive list, but you should add new prefixes to it before using them to avoid name-space collisions. +ad Avionic Design GmbH adiAnalog Devices, Inc. amcc Applied Micro Circuits Corporation (APM, formally AMCC) apmApplied Micro Circuits Corporation (APM) -- 1.7.10 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v6 17/17] pwm: Take over maintainership of the PWM subsystem
On Thursday 12 April 2012, Thierry Reding wrote: * Arnd Bergmann wrote: On Tuesday 10 April 2012, Thierry Reding wrote: I'm taking over the maintainership of the PWM subsystem. This commit also adds the URLs to the gitorious project and repository as well as any missing files related to the PWM subsystem. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- Note: I guess this patch in particular could use some Acked-by, maybe from Arnd and Sascha so that people will know this happens with their blessing. Acked-by: Arnd Bergmann a...@arndb.de As far as I can tell the series is in pretty good shape. I've integrated Shawn's latest comments and I think we could get this into 3.5. Does it make sense to take the PWM tree through Linux next before having it pulled into mainline during the next merge window? Yes, that's the way to go. Just ask Stephen Rothwell to include it right away if you are sufficiently happy with the contents and believe that they don't break stuff. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: Booting DT support without U-Boot supporting it
On Thursday 12 April 2012, Viresh Kumar wrote: My U-boot is on an older version and that doesn't have DT support for ARM. Now, is there any way of booting Linux with DT, without U-Boot supporting DT? Like, if we can compile dtb somehow with Linux or something else? Yes, see CONFIG_ARM_APPENDED_DTB and CONFIG_ARM_ATAG_DTB_COMPAT. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/2] of: Add Semtech Corp. vendor prefix
This commit adds a device tree vendor prefix for Semtech Corp. Cc: Grant Likely grant.lik...@secretlab.ca Cc: Rob Herring rob.herr...@calxeda.com Cc: devicetree-discuss@lists.ozlabs.org Signed-off-by: Thierry Reding thierry.red...@avionic-design.de --- Documentation/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 6b6e465..19af408 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -44,6 +44,7 @@ simtek sirf SiRF Technology, Inc. st STMicroelectronics stericsson ST-Ericsson +sx Semtech Corp. ti Texas Instruments wlfWolfson Microelectronics xlnx Xilinx -- 1.7.10 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/2] input: Add support for the Semtech SX8634 controller
This commit adds support for the Semtech SX8634 Capacitive Button and
Slider Touch controller.
Cc: Dmitry Torokhov dmitry.torok...@gmail.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Rob Herring rob.herr...@calxeda.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
---
Documentation/devicetree/bindings/input/sx8634.txt | 58 ++
drivers/input/misc/Kconfig | 10 +
drivers/input/misc/Makefile|1 +
drivers/input/misc/sx8634.c| 745
include/linux/input/sx8634.h | 32 +
5 files changed, 846 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/sx8634.txt
create mode 100644 drivers/input/misc/sx8634.c
create mode 100644 include/linux/input/sx8634.h
diff --git a/Documentation/devicetree/bindings/input/sx8634.txt
b/Documentation/devicetree/bindings/input/sx8634.txt
new file mode 100644
index 000..149da9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/sx8634.txt
@@ -0,0 +1,58 @@
+Semtech SX8634 Capacitive Button and Slider Touch Controller
+
+The SX8634 controller is configured with the following properties:
+
+ Required properties:
+ - compatible: sx,sx8634
+ - reg: I2C bus address of the device
+ - interrupts: interrupt number of the device
+ - #address-cells: must be 1
+ - #size-cells: must be 0
+
+ Optional Properties:
+ - threshold: number of ticks required to detect a touch/release
+- range: 0x00 to 0xff
+- default: 0xa0
+ - sensitivity: sensitivity of the sensors
+- range: 0x0 to 0x7
+- default: 0x0
+
+Each capacitive sensor is configured via a separate sub-node:
+
+ Required Properties:
+ - reg: sensor index
+ - label: name of the sensor
+ - linux,code: Keycode to emit for buttons. If absent, the capacitive sensor
+is part of the slider element.
+
+ Optional Properties:
+ - threshold: overrides the global threshold setting
+ - sensitivity: overrides the global sensitivity setting
+
+Example:
+
+ keypad: sx8634@2b {
+ compatible = sx,sx8634;
+ reg = 0x2b;
+
+ interrupt-parent = gpioext;
+ interrupts = 3;
+
+ #address-cells = 1;
+ #size-cells = 0;
+
+ threshold = 0xa0;
+ sensitivity = 7;
+
+ cap@1 {
+ reg = 1;
+ label = Up;
+ linux,code = 103; /* KEY_UP */
+ };
+
+ cap@2 {
+ reg = 2;
+ label = Down;
+ linux,code = 108; /* KEY_DOWN */
+ };
+ };
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 2d78779..00815f5 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -578,6 +578,16 @@ config INPUT_CMA3000_I2C
To compile this driver as a module, choose M here: the
module will be called cma3000_d0x_i2c.
+config INPUT_SX8634
+ tristate Semtech SX8634
+ depends on I2C
+ default n
+ help
+ Say Y here if you want to use the Semtech SX8634 controller.
+
+ To compile this driver as a module, choose M here: the module will
+ be called sx8634.
+
config INPUT_XEN_KBDDEV_FRONTEND
tristate Xen virtual keyboard and mouse support
depends on XEN
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index f55cdf4..7a86fac 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -53,5 +53,6 @@ obj-$(CONFIG_INPUT_TWL6040_VIBRA) += twl6040-vibra.o
obj-$(CONFIG_INPUT_UINPUT) += uinput.o
obj-$(CONFIG_INPUT_WISTRON_BTNS) += wistron_btns.o
obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
+obj-$(CONFIG_INPUT_SX8634) += sx8634.o
obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND)+= xen-kbdfront.o
obj-$(CONFIG_INPUT_YEALINK)+= yealink.o
diff --git a/drivers/input/misc/sx8634.c b/drivers/input/misc/sx8634.c
new file mode 100644
index 000..4241bdd
--- /dev/null
+++ b/drivers/input/misc/sx8634.c
@@ -0,0 +1,745 @@
+/*
+ * Copyright (C) 2011-2012 Avionic Design GmbH
+ *
+ * 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.
+ */
+
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/input.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/of_irq.h
+#include linux/slab.h
+
+#include linux/input/sx8634.h
+
+#define I2C_IRQ_SRC 0x00
+#define I2C_IRQ_SRC_MODE (1 0)
+#define I2C_IRQ_SRC_COMPENSATION (1 1)
+#define I2C_IRQ_SRC_BUTTONS (1 2)
+#define I2C_IRQ_SRC_SLIDER (1 3)
+#define I2C_IRQ_SRC_GPI (1 4)
+#define I2C_IRQ_SRC_SPM (1 5)
+#define I2C_IRQ_SRC_NVM (1 6)
+#define I2C_IRQ_SRC_READY
Re: [PATCH 3/9] ARM: at91: add at91sam9g20ek boards dt support
On 12:14 Thu 12 Apr , Mohammed, Afzal wrote: Hi Jean, On Thu, Apr 12, 2012 at 17:15:59, Jean-Christophe PLAGNIOL-VILLARD wrote: If ATMEL is also going driver way, then probably our voice together may be heard and hopefully it will expedite the matter. I'm going to add it too my idea was to create something similiar as the pintrl you register the ddifferent bank supported buy the SoC and then the driver request the bank for the dev_name at soc level you will set the default timings and then the drvier may manipulate them I already update the API of sam9_smc to abstract the access to the register. Is SMC code being converted to driver ? no I'm busy on pinctrl I just cereate an abstracted API Best Regards, J. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
* Alex Deucher wrote: On Thu, Apr 12, 2012 at 5:33 AM, Thierry Reding thierry.red...@avionic-design.de wrote: In other words I would like to use the Tegra hardware to render content into a framebuffer (using potentially the 3D engine or HW accelerated video decoding blocks) but display that framebuffer with a CRTC registered by a different driver (perhaps provided by a PCIe or USB device). I think such a setup would be possible if the CRTC registration can be decoupled from the DRM driver. Perhaps sdrm even supports that already? You should be able to do something like that already with dma_buf and the drm prime infrastructure. There's even a drm driver for the udl USB framebuffer devices. Using DRM PRIME requires user-space to be involved. I was thinking more along the lines of allowing a dumb DRM driver that only provides a CRTC to register with another driver so that it shows up as an output for the latter DRM device. Then again, having user-space control this may be more flexible. Performance- wise both should be about the same, right? What I don't quite understand yet is how the DMABUF would be synchronized on both ends. Is there some infra- structure to account for it or would I have to export two buffers and flip them during the vblank of the consumer? Thierry pgpa7LMXBkPwG.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [RFC 4/4] drm: Add NVIDIA Tegra support
Hi Thierry, On Thursday, April 12, 2012 3:42 PM Thierry Reding wrote: Also this doesn't yet solve the vmap() problem that is needed for the kernel virtual mapping. I did try using dma_alloc_writecombine(), but that only works for chunks of 2 MB or smaller, unless I use init_consistent_dma_size() during board setup, which isn't provided for in a DT setup. I couldn't find a better alternative, but I admit I'm not very familiar with all the VM APIs. Do you have any suggestions on how to solve this? Otherwise I'll try and dig in some more. Yes, I'm aware of this issue I'm currently working on solving it. I hope to use standard vmalloc range for all coherent/writecombine allocations and get rid of the custom 'consistent_dma' region at all. Does your work aim at removing the 2 MB limitation or at remapping non- contiguous memory to a virtually linear buffer? I have some trouble understanding how removing the 2 MB limit would help, because if all buffers can be allocated contiguously then there wouldn't be any need for the IOMMU, right? I would like to remove 2MiB limitation by moving these mapping to generic vmalloc area. Please notice that this 2MiB limit is only applied to CPU virtual address space and no physical memory is preallocated for consistent dma. ARM linear dma mapping implementation allocates coherent buffers by calling alloc_pages() and then creating a coherent mapping for the allocated buffer. With IOMMU you can allocate chunks of memory and create a contiguous DMA mapping. To fulfill dma mapping request you also need to create a cpu coherent mapping for them and right now my core uses the same remapping function as linear version. The only limitation here will be vmalloc space and its fragmentation. Best regards -- Marek Szyprowski Samsung Poland RD Center ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V4 2/2] staging: iio: add driver for isl29028
On 04/12/2012 08:01 AM, Laxman Dewangan wrote:
Intersil's ISL29028 is concurrent Ambient Light and
Proximity Sensor device.
Add driver to access the light and IR intensity and
+static const struct regmap_config isl29028_regmap_config = {
...
+ .max_register = ISL29028_MAX_REGS - 1,
+ .num_reg_defaults_raw = ISL29028_MAX_REGS,
This should really be ISL29028_NUM_REGS, since you don't have a maximum
number of registers, just a number of regs.
However, if there's no other reason to respin the patch, don't worry
about it.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
On 04/12/2012 12:50 AM, Thierry Reding wrote:
* Stephen Warren wrote:
On 04/11/2012 06:10 AM, Thierry Reding wrote:
This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
currently has rudimentary GEM support and can run a console on the
framebuffer as well as X using the xf86-video-modesetting driver.
Only the RGB output is supported. Quite a lot of things still need
to be worked out and there is a lot of room for cleanup.
...
diff --git a/Documentation/devicetree/bindings/gpu/drm/tegra.txt
b/Documentation/devicetree/bindings/gpu/drm/tegra.txt
...
This doesn't seem right, and couples back to my assertion above that the
two display controller modules probably deserve separate device objects,
named e.g. tegradc.*.
I think I understand where you're going with this. Does the following look
more correct?
disp1 : dc@5420 {
compatible = nvidia,tegra20-dc;
reg = 0x5420, 0x0004;
interrupts = 0 73 0x04;
};
disp2 : dc@5424 {
compatible = nvidia,tegra20-dc;
reg = 0x5424, 0x0004;
interrupts = 0 74 0x04;
};
Those look good.
drm {
compatible = nvidia,tegra20-drm;
I'm don't think having an explicit drm node is the right approach; drm
is after all a SW term and the DT should be describing HW. Having some
kind of top-level node almost certainly makes sense, but naming it
something related to tegra display than drm would be appropriate.
lvds {
compatible = ...;
dc = disp1;
};
Aren't the outputs separate HW blocks too, such that they would have
their own compatible/reg properties and their own drivers, and be
outside the top-level drm/display node?
I believe the mapping between the output this node represents and the
display controller (dc above) that it uses is not static; the
connectivity should be set up at runtime, and possibly dynamically
alterable via xrandr or equivalent.
hdmi {
compatible = ...;
dc = disp2;
};
};
+static int tegra_drm_parse_dt(struct platform_device *pdev)
+{
...
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
...
+ dev-platform_data = pdata;
I don't think you should assign to dev-platform_data. If you do, then I
think the following could happen:
* During first probe, the assignment above happens
* Module is removed, hence device removed, hence dev-platform_data
freed, but not zero'd out
* Module is re-inserted, finds that dev-platform_data!=NULL and
proceeds to use it.
Actually the code does zero out platform_data in tegra_drm_remove(). In fact
I did test module unloading and reloading and it works properly. But it
should probably be zeroed in case drm_platform_init() fails as well.
Instead, the active platform data should probably be stored in a
tegra_drm struct that's stored in the dev's private data.
tegra_drm_probe() might then look more like:
struct tegra_drm *tdev;
tdev = devm_kzalloc();
tdev-pdata = pdev-dev.platform_data;
if (!tdev-pdata)
tdev-pdata = tegra_drm_parse_dt();
if (!tdev-pdata)
return -EINVAL;
dev_set_drvdata(dev, tdev);
This is safe, since probe() will never assume that dev_get_drvdata()
might contain something valid before probe() sets it.
I prefer my approach over storing the data in an extra field because the
device platform_data field is where everybody would expect it. Furthermore
this wouldn't be relevant if we decided not to support non-DT setups.
Drivers are expected to use pre-existing platform data, if provided.
This might happen in order to work around bugs in device tree content.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
* Alex Deucher wrote: On Thu, Apr 12, 2012 at 10:09 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Apr 12, 2012 at 9:25 AM, Thierry Reding Then again, having user-space control this may be more flexible. Performance- wise both should be about the same, right? What I don't quite understand yet is how the DMABUF would be synchronized on both ends. Is there some infra- structure to account for it or would I have to export two buffers and flip them during the vblank of the consumer? Performance should be about the same. Â The tricky part is synchronization. Â dma_buf is for sharing. Â There are ideas to make generic sync objects, but for now, it's up to the userspace components to handle it. Some example code: http://lists.freedesktop.org/archives/dri-devel/2012-April/021182.html I saw that post too and it looks really nice. From what you're saying there really doesn't seem to be any advantage to making the connection in the DRM framework. Using DRM PRIME seems like a promising option and it seems to have quite a lot of momentum. Of course I'll need to get the DRM driver up and running properly first. Thierry pgpdZeeKw7Klw.pgp Description: PGP signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
* Stephen Warren wrote:
On 04/12/2012 12:50 AM, Thierry Reding wrote:
drm {
compatible = nvidia,tegra20-drm;
I'm don't think having an explicit drm node is the right approach; drm
is after all a SW term and the DT should be describing HW. Having some
kind of top-level node almost certainly makes sense, but naming it
something related to tegra display than drm would be appropriate.
In this case there really isn't a HW device that can be represented. But in
the end it's still the DRM driver that needs to bind to the device. However
the other graphics devices (MPE, VI/CSI, EPP, GR2D and GR3D) probably need
to be bound against.
Would it be possible for someone at NVIDIA to provide some more details about
what those other devices are? GR2D and GR3D seem obvious, MPE might be video
decoding, VI/CSI video input and camera interface? As to EPP I have no idea.
Maybe one solution would be to have a top-level DRM device with a register
map from 0x5400 to 0x547f, which the TRM designates as host
registers. Then subnodes could be used for the subdevices.
lvds {
compatible = ...;
dc = disp1;
};
Aren't the outputs separate HW blocks too, such that they would have
their own compatible/reg properties and their own drivers, and be
outside the top-level drm/display node?
The RGB output is programmed via the display controller registers. For HDMI,
TVO and DSI there are indeed separate sets of registers in addition to the
display controller's. So perhaps for those more nodes would be required:
hdmi : hdmi@5428 {
compatible = nvidia,tegra20-hdmi;
reg = 0x5428 0x0004;
};
And hook that up with the HDMI output node of the DRM node:
drm {
hdmi {
compatible = ...;
connector = hdmi;
dc = disp2;
};
};
Maybe with this setup we no longer need the compatible property since it
will already be inherent in the connector property. There will have to be
special handling for the RGB output, which could be the default if the
connector property is missing.
I believe the mapping between the output this node represents and the
display controller (dc above) that it uses is not static; the
connectivity should be set up at runtime, and possibly dynamically
alterable via xrandr or equivalent.
I think the mapping is always static for a given board. There is no way to
switch an HDMI port to LVDS at runtime. But maybe I misunderstand what you're
saying.
Instead, the active platform data should probably be stored in a
tegra_drm struct that's stored in the dev's private data.
tegra_drm_probe() might then look more like:
struct tegra_drm *tdev;
tdev = devm_kzalloc();
tdev-pdata = pdev-dev.platform_data;
if (!tdev-pdata)
tdev-pdata = tegra_drm_parse_dt();
if (!tdev-pdata)
return -EINVAL;
dev_set_drvdata(dev, tdev);
This is safe, since probe() will never assume that dev_get_drvdata()
might contain something valid before probe() sets it.
I prefer my approach over storing the data in an extra field because the
device platform_data field is where everybody would expect it. Furthermore
this wouldn't be relevant if we decided not to support non-DT setups.
Drivers are expected to use pre-existing platform data, if provided.
This might happen in order to work around bugs in device tree content.
Okay I see. I'll have to store it in a separate field in the private
structure then.
Thierry
pgpVEjAqQZSMX.pgp
Description: PGP signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC/PATCH 00/13] ARM: Exynos4: Add DTS for Samsung's Nuri board
[ This is just an RFC for those interested DT-support progress on samsung boards. ] This patchset provides up to date patches for drivers used on Samsung's Nuri board. Additionally, expermiental (and incomplete) .dts is also provided. Included .dts provides description for many, but not all devices found in mach-nuri.c. Currently mmc, fimc and mfc aren't supported. This patch series is based on mainline v3.4-rc2 with following patches applied: 1. [PATCH v5 0/2] ARM: Exynos: Add irq_domain and device tree support for combiner http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/10296 2. [PATCH v4 0/4] ARM: Exynos4: Add irq domain and device tree support for wakeup interrupts http://permalink.gmane.org/gmane.linux.kernel.samsung-soc/10302 3. [PATCH v4 0/2] regulator: add irq domain and device tree support for MAX8997 http://permalink.gmane.org/gmane.linux.drivers.devicetree/13995 4. [PATCH v3 0/3] i2c-s3c2410: Updates for exynos4210 and DT-based systems http://permalink.gmane.org/gmane.linux.drivers.i2c/10380 [ In this patch series I have also included tiny fix for i2c-gpio, rebased for v3.4-rc2, originally found here: http://permalink.gmane.org/gmane.linux.drivers.i2c/10414 ] Karol Lewandowski (13): regulator: Fix DT node name checking in max8997-pmic ARM: Add document to list devices with trivial DT description s5p-g2d: Make it possible to instantiate driver from DT i2c-pxa: Drop leftover comment i2c: Dynamically assign adapter id if it wasn't explictly specified s5p-tv: Add initial DT-support for SiI9234 s5p-tv: Add initial DT-support for TV mixer s5p-tv: Add initial DT-support for HDMIPHY s5p-tv: Move HDMIPHY and MHL subdev probing to dedicated function s5p-tv: Add DT-support for HDMI driver ARM: Exynos4: dts: Specify address and size cells for i2c controllers ARM: Exynos4: Add few more i2c OF compat definitions ARM: dts: Add initial dts for Samsung's NURI board based on Exynos4210 .../devicetree/bindings/arm/exynos/tvmixer.txt | 26 + .../devicetree/bindings/arm/trivial-devices.txt| 11 + .../devicetree/bindings/i2c/sil-mhl9234.txt| 14 + .../devicetree/bindings/i2c/trivial-devices.txt|1 + arch/arm/boot/dts/exynos4210-nuri.dts | 527 arch/arm/boot/dts/exynos4210.dtsi | 16 + arch/arm/mach-exynos/mach-exynos4-dt.c | 10 + drivers/i2c/busses/i2c-gpio.c |7 +- drivers/i2c/busses/i2c-pca-platform.c |2 +- drivers/i2c/busses/i2c-pxa.c |5 - drivers/i2c/busses/i2c-versatile.c |9 +- drivers/media/video/s5p-g2d/g2d.c | 10 + drivers/media/video/s5p-tv/hdmi_drv.c | 158 +-- drivers/media/video/s5p-tv/hdmiphy_drv.c | 10 + drivers/media/video/s5p-tv/mixer_drv.c |9 + drivers/media/video/s5p-tv/sii9234_drv.c | 21 +- drivers/regulator/max8997.c|7 + 17 files changed, 781 insertions(+), 62 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/exynos/tvmixer.txt create mode 100644 Documentation/devicetree/bindings/arm/trivial-devices.txt create mode 100644 Documentation/devicetree/bindings/i2c/sil-mhl9234.txt create mode 100644 arch/arm/boot/dts/exynos4210-nuri.dts -- 1.7.9.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 06/13] s5p-tv: Add initial DT-support for SiI9234
Make it possible to instantiate SiI9234, Mobile HD Link driver (MHL),
from regular device tree description.
Signed-off-by: Karol Lewandowski k.lewando...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Tomasz Stanislawski t.stanisl...@samsung.com
---
.../devicetree/bindings/i2c/sil-mhl9234.txt| 14 +
drivers/media/video/s5p-tv/sii9234_drv.c | 21 +++-
2 files changed, 34 insertions(+), 1 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/sil-mhl9234.txt
diff --git a/Documentation/devicetree/bindings/i2c/sil-mhl9234.txt
b/Documentation/devicetree/bindings/i2c/sil-mhl9234.txt
new file mode 100644
index 000..b5d92ea
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/sil-mhl9234.txt
@@ -0,0 +1,14 @@
+* Silicon Image Mobile HD Link (MHL) 9234
+
+Required properties :
+ - compatible : sil,mhl-9234
+ - reg: i2c device address
+ - gpio-reset : gpio line used to reset IC
+
+Example:
+
+ mhl@39 {
+ compatible = sil,mhl-9234;
+ reg = 0x39;
+ gpio-reset = gpf3 4 0 0 0;
+ };
diff --git a/drivers/media/video/s5p-tv/sii9234_drv.c
b/drivers/media/video/s5p-tv/sii9234_drv.c
index 0f31ecc..05df5e8 100644
--- a/drivers/media/video/s5p-tv/sii9234_drv.c
+++ b/drivers/media/video/s5p-tv/sii9234_drv.c
@@ -22,6 +22,8 @@
#include linux/pm_runtime.h
#include linux/regulator/machine.h
#include linux/slab.h
+#include linux/of.h
+#include linux/of_gpio.h
#include mach/gpio.h
#include plat/gpio-cfg.h
@@ -338,7 +340,16 @@ static int __devinit sii9234_probe(struct i2c_client
*client,
goto fail_ctx;
}
- ctx-gpio_n_reset = pdata-gpio_n_reset;
+ if (dev-of_node) {
+ ctx-gpio_n_reset = of_get_named_gpio(dev-of_node,
gpio-reset, 0);
+ if (!gpio_is_valid(ctx-gpio_n_reset)) {
+ ret = -ENODEV;
+ goto fail_power;
+ }
+ } else {
+ ctx-gpio_n_reset = pdata-gpio_n_reset;
+ }
+
ret = gpio_request(ctx-gpio_n_reset, MHL_RST);
if (ret) {
dev_err(dev, failed to acquire MHL_RST gpio\n);
@@ -401,6 +412,13 @@ static int __devexit sii9234_remove(struct i2c_client
*client)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id sii9234_dt_match[] = {
+ { .compatible = sil,mhl-9234 },
+ { },
+};
+MODULE_DEVICE_TABLE(of, sii9234_dt_match);
+#endif
static const struct i2c_device_id sii9234_id[] = {
{ SII9234, 0 },
@@ -413,6 +431,7 @@ static struct i2c_driver sii9234_driver = {
.name = sii9234,
.owner = THIS_MODULE,
.pm = sii9234_pm_ops,
+ .of_match_table = of_match_ptr(sii9234_dt_match),
},
.probe = sii9234_probe,
.remove = __devexit_p(sii9234_remove),
--
1.7.9.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 05/13] i2c: Dynamically assign adapter id if it wasn't explictly specified
Commit 488bf314b (i2c: Allow i2c_add_numbered_adapter() to assign a
bus id) reworked i2c_add_numbered_adapter() to call i2c_add_adapter()
if requested bus was -1.
This allows to simplify driver's initialization procedure by using
just one function for static and dynamic adapter id registration.
This patch updates few more drivers (missed out in original patch)
to use this functionality.
Signed-off-by: Karol Lewandowski k.lewando...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Wolfram Sang w.s...@pengutronix.de
---
drivers/i2c/busses/i2c-gpio.c |7 +--
drivers/i2c/busses/i2c-pca-platform.c |2 +-
drivers/i2c/busses/i2c-versatile.c|9 ++---
3 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/busses/i2c-gpio.c b/drivers/i2c/busses/i2c-gpio.c
index c0330a4..e62d2d9 100644
--- a/drivers/i2c/busses/i2c-gpio.c
+++ b/drivers/i2c/busses/i2c-gpio.c
@@ -190,12 +190,7 @@ static int __devinit i2c_gpio_probe(struct platform_device
*pdev)
adap-dev.parent = pdev-dev;
adap-dev.of_node = pdev-dev.of_node;
- /*
-* If dev-id is negative we consider it as zero.
-* The reason to do so is to avoid sysfs names that only make
-* sense when there are multiple adapters.
-*/
- adap-nr = (pdev-id != -1) ? pdev-id : 0;
+ adap-nr = pdev-id;
ret = i2c_bit_add_numbered_bus(adap);
if (ret)
goto err_add_bus;
diff --git a/drivers/i2c/busses/i2c-pca-platform.c
b/drivers/i2c/busses/i2c-pca-platform.c
index 2adbf1a..675878f 100644
--- a/drivers/i2c/busses/i2c-pca-platform.c
+++ b/drivers/i2c/busses/i2c-pca-platform.c
@@ -171,7 +171,7 @@ static int __devinit i2c_pca_pf_probe(struct
platform_device *pdev)
i2c-io_size = resource_size(res);
i2c-irq = irq;
- i2c-adap.nr = pdev-id = 0 ? pdev-id : 0;
+ i2c-adap.nr = pdev-id;
i2c-adap.owner = THIS_MODULE;
snprintf(i2c-adap.name, sizeof(i2c-adap.name),
PCA9564/PCA9665 at 0x%08lx,
diff --git a/drivers/i2c/busses/i2c-versatile.c
b/drivers/i2c/busses/i2c-versatile.c
index f585aea..eec20db 100644
--- a/drivers/i2c/busses/i2c-versatile.c
+++ b/drivers/i2c/busses/i2c-versatile.c
@@ -104,13 +104,8 @@ static int i2c_versatile_probe(struct platform_device *dev)
i2c-algo = i2c_versatile_algo;
i2c-algo.data = i2c;
- if (dev-id = 0) {
- /* static bus numbering */
- i2c-adap.nr = dev-id;
- ret = i2c_bit_add_numbered_bus(i2c-adap);
- } else
- /* dynamic bus numbering */
- ret = i2c_bit_add_bus(i2c-adap);
+ i2c-adap.nr = dev-id;
+ ret = i2c_bit_add_numbered_bus(i2c-adap);
if (ret = 0) {
platform_set_drvdata(dev, i2c);
of_i2c_register_devices(i2c-adap);
--
1.7.9.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 04/13] i2c-pxa: Drop leftover comment
Commit 488bf314b (i2c: Allow i2c_add_numbered_adapter() to assign a bus id) reworked i2c-pxa driver leaving obsolete comment. This commit simply drops it. Signed-off-by: Karol Lewandowski k.lewando...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Wolfram Sang w.s...@pengutronix.de --- drivers/i2c/busses/i2c-pxa.c |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c index f673326..a997c7d 100644 --- a/drivers/i2c/busses/i2c-pxa.c +++ b/drivers/i2c/busses/i2c-pxa.c @@ -1131,11 +1131,6 @@ static int i2c_pxa_probe(struct platform_device *dev) spin_lock_init(i2c-lock); init_waitqueue_head(i2c-wait); - /* -* If dev-id is negative we consider it as zero. -* The reason to do so is to avoid sysfs names that only make -* sense when there are multiple adapters. -*/ i2c-adap.nr = dev-id; snprintf(i2c-adap.name, sizeof(i2c-adap.name), pxa_i2c-i2c.%u, i2c-adap.nr); -- 1.7.9.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 01/13] regulator: Fix DT node name checking in max8997-pmic
Avoid hard lockup when someone provides non-supported regulator
name.
Signed-off-by: Karol Lewandowski k.lewando...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Thomas Abraham thomas.abra...@linaro.org
---
drivers/regulator/max8997.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/regulator/max8997.c b/drivers/regulator/max8997.c
index dce8aaf..c20fd72 100644
--- a/drivers/regulator/max8997.c
+++ b/drivers/regulator/max8997.c
@@ -1011,6 +1011,13 @@ static int max8997_pmic_dt_parse_pdata(struct
max8997_dev *iodev,
for (i = 0; i ARRAY_SIZE(regulators); i++)
if (!of_node_cmp(reg_np-name, regulators[i].name))
break;
+
+ if (i == ARRAY_SIZE(regulators)) {
+ dev_warn(iodev-dev, don't know how to configure
regulator %s\n,
+reg_np-name);
+ continue;
+ }
+
rdata-id = i;
rdata-initdata = of_get_regulator_init_data(
iodev-dev, reg_np);
--
1.7.9.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 07/13] s5p-tv: Add initial DT-support for TV mixer
Signed-off-by: Karol Lewandowski k.lewando...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Tomasz Stanislawski t.stanisl...@samsung.com
---
.../devicetree/bindings/arm/exynos/tvmixer.txt | 26
drivers/media/video/s5p-tv/mixer_drv.c |9 +++
2 files changed, 35 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/exynos/tvmixer.txt
diff --git a/Documentation/devicetree/bindings/arm/exynos/tvmixer.txt
b/Documentation/devicetree/bindings/arm/exynos/tvmixer.txt
new file mode 100644
index 000..5b4f02e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/exynos/tvmixer.txt
@@ -0,0 +1,26 @@
+* Samsung video/graphics mixer and blender
+
+Mixer blends graphics data from multiple sources and sends resulting
+data to TVOUT module.
+
+
+Required properties:
+
+ - compatible : samsung,s5pv210-tvmixer
+ - reg : shall contain memory addresses and sizes of mixer and video
+ processor devices
+ - reg-names : mxr for mixer's address/size and vp to for video
+ processor's.
+ - interrupt-names : shall contain irq
+
+
+Example:
+
+ tvmixer@12c1 {
+ compatible = samsung,s5pv210-tvmixer;
+ reg = 0x12c1 0x1,
+ 0x12c0 0x1;
+ reg-names = mxr, vp;
+ interrupts = 0 123 0;
+ interrupt-names = irq;
+ };
diff --git a/drivers/media/video/s5p-tv/mixer_drv.c
b/drivers/media/video/s5p-tv/mixer_drv.c
index a2c0c25..80b7755 100644
--- a/drivers/media/video/s5p-tv/mixer_drv.c
+++ b/drivers/media/video/s5p-tv/mixer_drv.c
@@ -448,6 +448,14 @@ static int __devexit mxr_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id mxr_dt_match[] = {
+ { .compatible = samsung,s5pv210-tvmixer },
+ { },
+};
+MODULE_DEVICE_TABLE(of, mxr_dt_match);
+#endif
+
static struct platform_driver mxr_driver __refdata = {
.probe = mxr_probe,
.remove = __devexit_p(mxr_remove),
@@ -455,6 +463,7 @@ static struct platform_driver mxr_driver __refdata = {
.name = MXR_DRIVER_NAME,
.owner = THIS_MODULE,
.pm = mxr_pm_ops,
+ .of_match_table = of_match_ptr(mxr_dt_match),
}
};
--
1.7.9.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 02/13] ARM: Add document to list devices with trivial DT description
Add arm/trivial-devices.txt to enumerate devices for which only basic resources are provided (compat, address and irq line). This is based on i2c's trivial-devices.txt by Olof Johansson. Signed-off-by: Karol Lewandowski k.lewando...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Cc: Grant Likely grant.lik...@secretlab.ca --- .../devicetree/bindings/arm/trivial-devices.txt| 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/trivial-devices.txt diff --git a/Documentation/devicetree/bindings/arm/trivial-devices.txt b/Documentation/devicetree/bindings/arm/trivial-devices.txt new file mode 100644 index 000..443814a --- /dev/null +++ b/Documentation/devicetree/bindings/arm/trivial-devices.txt @@ -0,0 +1,10 @@ +This is a list of trivial devices that have simple device tree +bindings, consisting only of a compatible field, an address and +possibly an interrupt line. + +If a device needs more specific bindings, such as properties to +describe some aspect of it, there needs to be a specific binding +document for it just like any other devices. + +Compatible Vendor / Chip += -- 1.7.9.1 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 10/13] s5p-tv: Add DT-support for HDMI driver
Includes v4l2/dt helper function (hdmi_of_get_i2c_subdev() that probably
should be implemented in v4l2 core itself.
Signed-off-by: Karol Lewandowski k.lewando...@samsung.com
Cc: Tomasz Stanislawski t.stanisl...@samsung.com
---
drivers/media/video/s5p-tv/hdmi_drv.c | 68 -
1 files changed, 67 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/s5p-tv/hdmi_drv.c
b/drivers/media/video/s5p-tv/hdmi_drv.c
index fff3cab..a402e8f 100644
--- a/drivers/media/video/s5p-tv/hdmi_drv.c
+++ b/drivers/media/video/s5p-tv/hdmi_drv.c
@@ -29,6 +29,8 @@
#include linux/pm_runtime.h
#include linux/clk.h
#include linux/regulator/consumer.h
+#include linux/of.h
+#include linux/of_i2c.h
#include media/s5p_hdmi.h
#include media/v4l2-common.h
@@ -712,6 +714,56 @@ static int hdmi_enum_dv_presets(struct v4l2_subdev *sd,
return v4l_fill_dv_preset_info(hdmi_conf[preset-index].preset, preset);
}
+#ifdef CONFIG_OF
+/* Heavily based[1] on v4l2_i2c_new_subdev_board()
+ *
+ * [1] Copy-pasted, that is
+ */
+struct v4l2_subdev *hdmi_of_get_i2c_subdev(struct v4l2_device *v4l2_dev,
+ struct device_node *np, const char *propname)
+{
+ struct v4l2_subdev *sd = NULL;
+ struct i2c_client *client;
+ struct device_node *cnp;
+
+ BUG_ON(!v4l2_dev);
+
+ cnp = of_parse_phandle(np, propname, 0);
+ if (!cnp) {
+ dev_err(v4l2_dev-dev, Can't find subdev %s\n, propname);
+ goto err;
+ }
+
+ client = of_find_i2c_device_by_node(cnp);
+ if (!client) {
+ dev_err(v4l2_dev-dev, subdev %s doesn't reference correct
node\n,
+ propname);
+ goto err;
+ }
+
+ if (client == NULL || client-driver == NULL)
+ goto err;
+
+ /* Lock the module so we can safely get the v4l2_subdev pointer */
+ if (!try_module_get(client-driver-driver.owner))
+ goto err;
+ sd = i2c_get_clientdata(client);
+
+ /* Register with the v4l2_device which increases the module's
+ use count as well. */
+ if (v4l2_device_register_subdev(v4l2_dev, sd)) {
+ printk(KERN_ERR %s: failed to register subdev\n, __func__);
+ sd = NULL;
+ }
+ /* Decrease the module use count to match the first try_module_get. */
+ module_put(client-driver-driver.owner);
+err:
+ of_node_put(cnp);
+
+ return sd;
+}
+#endif
+
static const struct v4l2_subdev_core_ops hdmi_sd_core_ops = {
.s_power = hdmi_s_power,
};
@@ -875,6 +927,12 @@ static struct v4l2_subdev *hdmi_get_subdev(
struct i2c_adapter *adapter;
struct device *dev = hdmi_dev-dev;
+#ifdef CONFIG_OF
+ if (dev-of_node)
+ return hdmi_of_get_i2c_subdev(hdmi_dev-v4l2_dev,
+ dev-of_node, propname);
+#endif
+
if (!bdinfo) {
dev_err(dev, %s info is missing in platform data\n,
propname);
@@ -913,7 +971,7 @@ static int __devinit hdmi_probe(struct platform_device
*pdev)
dev_dbg(dev, probe start\n);
- if (!pdata) {
+ if (!pdata !dev-of_node) {
dev_err(dev, platform data is missing\n);
ret = -ENODEV;
goto fail;
@@ -1037,6 +1095,13 @@ static int __devexit hdmi_remove(struct platform_device
*pdev)
return 0;
}
+#ifdef CONFIG_OF
+static struct of_device_id hdmi_dt_match[] = {
+ { .compatible = samsung,s5pv210-hdmi },
+ { },
+};
+#endif
+
static struct platform_driver hdmi_driver __refdata = {
.probe = hdmi_probe,
.remove = __devexit_p(hdmi_remove),
@@ -1045,6 +1110,7 @@ static struct platform_driver hdmi_driver __refdata = {
.name = s5p-hdmi,
.owner = THIS_MODULE,
.pm = hdmi_pm_ops,
+ .of_match_table = of_match_ptr(hdmi_dt_match),
}
};
--
1.7.9.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 11/13] ARM: Exynos4: dts: Specify address and size cells for i2c controllers
Signed-off-by: Karol Lewandowski k.lewando...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/boot/dts/exynos4210.dtsi | 16
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi
index a1dd2ee..be3c57c 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -100,48 +100,64 @@
};
i2c@1386 {
+ #address-cells = 1;
+ #size-cells = 0;
compatible = samsung,s3c2440-i2c;
reg = 0x1386 0x100;
interrupts = 0 58 0;
};
i2c@1387 {
+ #address-cells = 1;
+ #size-cells = 0;
compatible = samsung,s3c2440-i2c;
reg = 0x1387 0x100;
interrupts = 0 59 0;
};
i2c@1388 {
+ #address-cells = 1;
+ #size-cells = 0;
compatible = samsung,s3c2440-i2c;
reg = 0x1388 0x100;
interrupts = 0 60 0;
};
i2c@1389 {
+ #address-cells = 1;
+ #size-cells = 0;
compatible = samsung,s3c2440-i2c;
reg = 0x1389 0x100;
interrupts = 0 61 0;
};
i2c@138A {
+ #address-cells = 1;
+ #size-cells = 0;
compatible = samsung,s3c2440-i2c;
reg = 0x138A 0x100;
interrupts = 0 62 0;
};
i2c@138B {
+ #address-cells = 1;
+ #size-cells = 0;
compatible = samsung,s3c2440-i2c;
reg = 0x138B 0x100;
interrupts = 0 63 0;
};
i2c@138C {
+ #address-cells = 1;
+ #size-cells = 0;
compatible = samsung,s3c2440-i2c;
reg = 0x138C 0x100;
interrupts = 0 64 0;
};
i2c@138D {
+ #address-cells = 1;
+ #size-cells = 0;
compatible = samsung,s3c2440-i2c;
reg = 0x138D 0x100;
interrupts = 0 65 0;
--
1.7.9.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 12/13] ARM: Exynos4: Add few more i2c OF compat definitions
These are needed for clk_get() to work properly in respective
drivers.
Signed-off-by: Karol Lewandowski k.lewando...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/mach-exynos/mach-exynos4-dt.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/mach-exynos4-dt.c
b/arch/arm/mach-exynos/mach-exynos4-dt.c
index 8245f1c..989b35a 100644
--- a/arch/arm/mach-exynos/mach-exynos4-dt.c
+++ b/arch/arm/mach-exynos/mach-exynos4-dt.c
@@ -55,6 +55,16 @@ static const struct of_dev_auxdata
exynos4210_auxdata_lookup[] __initconst = {
exynos4-sdhci.3, NULL),
OF_DEV_AUXDATA(samsung,s3c2440-i2c, EXYNOS4_PA_IIC(0),
s3c2440-i2c.0, NULL),
+ OF_DEV_AUXDATA(samsung,s3c2440-i2c, EXYNOS4_PA_IIC(3),
+ s3c2440-i2c.3, NULL),
+ OF_DEV_AUXDATA(samsung,s3c2440-i2c, EXYNOS4_PA_IIC(5),
+ s3c2440-i2c.5, NULL),
+ OF_DEV_AUXDATA(samsung,s3c2440-i2c, EXYNOS4_PA_IIC(6),
+ s3c2440-i2c.6, NULL),
+ OF_DEV_AUXDATA(samsung,s3c2440-i2c, EXYNOS4_PA_IIC_HDMIPHY,
+ s3c2440-hdmiphy-i2c, NULL),
+ OF_DEV_AUXDATA(samsung,s5pv210-hdmi, S5P_PA_HDMI, exynos4-hdmi,
NULL),
+ OF_DEV_AUXDATA(samsung,s5pv210-tvmixer, S5P_PA_MIXER, s5p-mixer,
NULL),
OF_DEV_AUXDATA(arm,pl330, EXYNOS4_PA_PDMA0, dma-pl330.0, NULL),
OF_DEV_AUXDATA(arm,pl330, EXYNOS4_PA_PDMA1, dma-pl330.1, NULL),
{},
--
1.7.9.1
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 13/13] ARM: dts: Add initial dts for Samsung's NURI board based on Exynos4210
This commit is combination of following patches squashed together to
produce one patch which provides complete DTS for NURI
- ARM: dts: Add sdhci nodes for NURI
- ARM: dts: Add i2c-gpio entry for max17042_battery
- ARM: dts: Add nodes for fixed regulators available on NURI
- ARM: dts: Add device entry for s5p-g2d on Nuri
- ARM: dts: Add device node for MFC to Nuri
- ARM: dts: Add Exynos' wakeup_eint interrupt controller
- ARM: dts: Add basic max8997-pmic description to NURI's dts
- ARM: dts: Add special max8997-pmic regulators
[ This adds non-buck, non-ldo special purpose regulators
like CHARGER* as well as 32kHz oscillator. ]
- ARM: dts: Add node for s3c-udc to NURI's dts
- ARM: dts: Add nodes for s5p-tv drivers (hdmi, hdmiphy, sii9234, tvmixer)
- ARM: dts: Add node for atmel's mxt224 to NURI's dts
- ARM: dts: Specify EINT controller base address
Signed-off-by: Karol Lewandowski k.lewando...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Cc: Thomas Abraham thomas.abra...@linaro.org
---
arch/arm/boot/dts/exynos4210-nuri.dts | 527 +
1 files changed, 527 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4210-nuri.dts
diff --git a/arch/arm/boot/dts/exynos4210-nuri.dts
b/arch/arm/boot/dts/exynos4210-nuri.dts
new file mode 100644
index 000..6e8d68b
--- /dev/null
+++ b/arch/arm/boot/dts/exynos4210-nuri.dts
@@ -0,0 +1,527 @@
+/*
+ * Samsung Nuri board device tree source
+ *
+ * Copyright (C) 2012 Samsung Electronics Co., Ltd.
+ * Author: Karol Lewandowski k.lewando...@samsung.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.
+ */
+
+/dts-v1/;
+/include/ exynos4210.dtsi
+
+/ {
+ model = Samsung Nuri based on Exynos4210;
+ compatible = samsung,nuri, samsung,exynos4210;
+
+ memory {
+ reg = 0x4000 0x4000;
+ };
+
+ chosen {
+ bootargs =console=ttySAC2,115200 fbmem=24M@0x6680
lcd=nt39411 lpj=3981312;
+ };
+
+ wakeup_eint: interrupt-controller-wakeup-eint {
+ compatible = samsung,exynos4210-wakeup-eint;
+ reg = 0x1100 0x1000;
+ #interrupt-cells = 2;
+ interrupt-controller;
+ interrupts =0 16 0, 0 17 0, 0 18 0, 0 19 0,
+ 0 20 0, 0 21 0, 0 22 0, 0 23 0,
+ 0 24 0, 0 25 0, 0 26 0, 0 27 0,
+ 0 28 0, 0 29 0, 0 30 0, 0 31 0,
+ 0 32 0;
+ };
+
+ /* fixed regulators */
+
+ vemmc_reg: voltage-regulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = VMEM_VDD_2.8V;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ gpio = gpl1 1 1 0 0;
+ };
+
+ max8903_reg: voltage-regulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = VOUT_CHARGER;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ gpio = gpy4 5 1 0 0;
+ };
+
+ camvdda_reg: voltage-regulator@2 {
+ compatible = regulator-fixed;
+ regulator-name = CAM_IO_EN;
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ enable-active-high;
+ gpio = gpe2 1 1 0 0;
+ };
+
+ camv1_2_reg: voltage-regulator@3 {
+ compatible = regulator-fixed;
+ regulator-name = 8M_1.2V;
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ enable-active-high;
+ gpio = gpe2 2 1 0 0;
+ };
+
+ camv1_5_reg: voltage-regulator@4 {
+ compatible = regulator-fixed;
+ regulator-name = VT_CAM_1.5V;
+ regulator-min-microvolt = 150;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ enable-active-high;
+ gpio = gpe2 5 1 0 0;
+ };
+
+ hdmi_reg: voltage-regulator@5 {
+ compatible = regulator-fixed;
+ regulator-name = HDMI_5V;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpx2 4 1 0 0;
+ enable-active-high;
+ };
+
+ sdhci_emmc: sdhci@1251 {
+ /* eMMC */
+ samsung,sdhci-cd-permanent;
+ gpio-cd = gpk0 2 2 3 3;
+
+
Re: [PATCH 1/1] Add support 2 SATA ports for Maui and change filename from sata_dwc_460ex.c to sata_dwc_4xx.c
On 04/03/2012 07:56 AM, Sergei Shtylyov wrote:
Hello.
On 03-04-2012 14:12, Thang Q. Nguyen wrote:
Signed-off-by: Thang Q. Nguyentqngu...@apm.com
---
Changes for v2:
- Use git rename feature to change the driver to the newname and for
easier review.
arch/powerpc/boot/dts/bluestone.dts | 21 +
drivers/ata/Makefile | 2 +-
drivers/ata/{sata_dwc_460ex.c = sata_dwc_4xx.c} | 1371
++
3 files changed, 904 insertions(+), 490 deletions(-)
rename drivers/ata/{sata_dwc_460ex.c = sata_dwc_4xx.c} (56%)
You submitted a magapatch doing several things at once (some even
needlessly) and even in two areas of the kernel. This needs proper
splitting/description.
Agreed...
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 0/2] i2c/of: Populate multiplexed i2c busses from the device tree.
From: David Daney david.da...@cavium.com v3: Integrate changes from Lars-Peter Clausen to make better use of the of_*() infrastructure. Get rid of ugly #ifdefs. v2: Update bindings to use reg insutead of cell-index v1: Unchanged from the original RFC where I said: We need to populate our I2C devices from the device tree, but some of our systems have multiplexers which currently break this process. The basic idea is to have the generic i2c-mux framework propagate the device_node for the child bus into the corresponding i2c_adapter, and then call of_i2c_register_devices(). This means that the device tree bindings for *all* i2c muxes must have some common properties. I try to document these in mux.txt. This is now tested against 3.4-rc2 and is still working well. David Daney (2): i2c: Add a struct device * parameter to i2c_add_mux_adapter() i2c/of: Automatically populate i2c mux busses from device tree data. Documentation/devicetree/bindings/i2c/mux.txt | 60 + drivers/i2c/i2c-mux.c | 43 ++ drivers/i2c/muxes/gpio-i2cmux.c |3 +- drivers/i2c/muxes/pca9541.c |3 +- drivers/i2c/muxes/pca954x.c |2 +- include/linux/i2c-mux.h |3 +- 6 files changed, 101 insertions(+), 13 deletions(-) create mode 100644 Documentation/devicetree/bindings/i2c/mux.txt Cc: Lars-Peter Clausen l...@metafoo.de -- 1.7.2.3 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 2/2] i2c/of: Automatically populate i2c mux busses from device tree data.
From: David Daney david.da...@cavium.com
For 'normal' i2c bus drivers, we can call of_i2c_register_devices()
and have the device tree framework automatically populate the bus with
the devices specified in the device tree.
This patch adds a common code to the i2c mux framework to have the mux
sub-busses be populated by the of_i2c_register_devices() too. If the
mux device has an of_node, we populate the sub-bus' of_node so that
the subsequent call to of_i2c_register_devices() will find the
corresponding devices.
It seemed better to put this logic in i2c_add_mux_adapter() rather
than the individual mux drivers, as they will all probably want to do
the same thing.
Signed-off-by: David Daney david.da...@cavium.com
Cc: Lars-Peter Clausen l...@metafoo.de
---
Documentation/devicetree/bindings/i2c/mux.txt | 60 +
drivers/i2c/i2c-mux.c | 24 ++
2 files changed, 84 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/i2c/mux.txt
diff --git a/Documentation/devicetree/bindings/i2c/mux.txt
b/Documentation/devicetree/bindings/i2c/mux.txt
new file mode 100644
index 000..af84cce
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/mux.txt
@@ -0,0 +1,60 @@
+Common i2c bus multiplexer/switch properties.
+
+An i2c bus multiplexer/switch will have several child busses that are
+numbered uniquely in a device dependent manner. The nodes for an i2c bus
+multiplexer/switch will have one child node for each child
+bus.
+
+Required properties:
+- #address-cells = 1;
+- #size-cells = 0;
+
+Required properties for child nodes:
+- #address-cells = 1;
+- #size-cells = 0;
+- reg : The sub-bus number.
+
+Optional properties for child nodes:
+- Other properties specific to the multiplexer/switch hardware.
+- Child nodes conforming to i2c bus binding
+
+
+Example :
+
+ /*
+ An NXP pca9548 8 channel I2C multiplexer at address 0x70
+ with two NXP pca8574 GPIO expanders attached, one each to
+ ports 3 and 4.
+*/
+
+ mux@70 {
+ compatible = nxp,pca9548;
+ reg = 0x70;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ i2c@3 {
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 3;
+
+ gpio1: gpio@38 {
+ compatible = nxp,pca8574;
+ reg = 0x38;
+ #gpio-cells = 2;
+ gpio-controller;
+ };
+ };
+ i2c@4 {
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 4;
+
+ gpio2: gpio@38 {
+ compatible = nxp,pca8574;
+ reg = 0x38;
+ #gpio-cells = 2;
+ gpio-controller;
+ };
+ };
+ };
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 26ab31d..609794b 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -24,6 +24,8 @@
#include linux/slab.h
#include linux/i2c.h
#include linux/i2c-mux.h
+#include linux/of.h
+#include linux/of_i2c.h
/* multiplexer per channel data */
struct i2c_mux_priv {
@@ -125,6 +127,26 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter
*parent,
priv-adap.algo_data = priv;
priv-adap.dev.parent = parent-dev;
+ /*
+* Try to get populate the mux adapter's of_node, expands to
+* nothing if !CONFIG_OF.
+*/
+ if (mux_dev-of_node) {
+ struct device_node *child;
+ u32 reg;
+ int ret;
+
+ for_each_child_of_node(mux_dev-of_node, child) {
+ ret = of_property_read_u32(child, reg, reg);
+ if (ret)
+ continue;
+ if (chan_id == reg) {
+ priv-adap.dev.of_node = child;
+ break;
+ }
+ }
+ }
+
if (force_nr) {
priv-adap.nr = force_nr;
ret = i2c_add_numbered_adapter(priv-adap);
@@ -142,6 +164,8 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter
*parent,
dev_info(parent-dev, Added multiplexed i2c bus %d\n,
i2c_adapter_id(priv-adap));
+ of_i2c_register_devices(priv-adap);
+
return priv-adap;
}
EXPORT_SYMBOL_GPL(i2c_add_mux_adapter);
--
1.7.2.3
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 1/2] i2c: Add a struct device * parameter to i2c_add_mux_adapter()
From: David Daney david.da...@cavium.com
And adjust all callers.
The new device parameter is used in the next patch to initialize the
mux's of_node so that its children may be automatically populated.
Signed-off-by: David Daney david.da...@cavium.com
Cc: Lars-Peter Clausen l...@metafoo.de
---
drivers/i2c/i2c-mux.c | 19 ++-
drivers/i2c/muxes/gpio-i2cmux.c |3 ++-
drivers/i2c/muxes/pca9541.c |3 ++-
drivers/i2c/muxes/pca954x.c |2 +-
include/linux/i2c-mux.h |3 ++-
5 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index d7a4833..26ab31d 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -31,11 +31,11 @@ struct i2c_mux_priv {
struct i2c_algorithm algo;
struct i2c_adapter *parent;
- void *mux_dev; /* the mux chip/device */
+ void *mux_priv; /* the mux chip/device */
u32 chan_id; /* the channel id */
- int (*select)(struct i2c_adapter *, void *mux_dev, u32 chan_id);
- int (*deselect)(struct i2c_adapter *, void *mux_dev, u32 chan_id);
+ int (*select)(struct i2c_adapter *, void *mux_priv, u32 chan_id);
+ int (*deselect)(struct i2c_adapter *, void *mux_priv, u32 chan_id);
};
static int i2c_mux_master_xfer(struct i2c_adapter *adap,
@@ -47,11 +47,11 @@ static int i2c_mux_master_xfer(struct i2c_adapter *adap,
/* Switch to the right mux port and perform the transfer. */
- ret = priv-select(parent, priv-mux_dev, priv-chan_id);
+ ret = priv-select(parent, priv-mux_priv, priv-chan_id);
if (ret = 0)
ret = parent-algo-master_xfer(parent, msgs, num);
if (priv-deselect)
- priv-deselect(parent, priv-mux_dev, priv-chan_id);
+ priv-deselect(parent, priv-mux_priv, priv-chan_id);
return ret;
}
@@ -67,12 +67,12 @@ static int i2c_mux_smbus_xfer(struct i2c_adapter *adap,
/* Select the right mux port and perform the transfer. */
- ret = priv-select(parent, priv-mux_dev, priv-chan_id);
+ ret = priv-select(parent, priv-mux_priv, priv-chan_id);
if (ret = 0)
ret = parent-algo-smbus_xfer(parent, addr, flags,
read_write, command, size, data);
if (priv-deselect)
- priv-deselect(parent, priv-mux_dev, priv-chan_id);
+ priv-deselect(parent, priv-mux_priv, priv-chan_id);
return ret;
}
@@ -87,7 +87,8 @@ static u32 i2c_mux_functionality(struct i2c_adapter *adap)
}
struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter *parent,
- void *mux_dev, u32 force_nr, u32 chan_id,
+ struct device *mux_dev,
+ void *mux_priv, u32 force_nr, u32 chan_id,
int (*select) (struct i2c_adapter *,
void *, u32),
int (*deselect) (struct i2c_adapter *,
@@ -102,7 +103,7 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter
*parent,
/* Set up private adapter data */
priv-parent = parent;
- priv-mux_dev = mux_dev;
+ priv-mux_priv = mux_priv;
priv-chan_id = chan_id;
priv-select = select;
priv-deselect = deselect;
diff --git a/drivers/i2c/muxes/gpio-i2cmux.c b/drivers/i2c/muxes/gpio-i2cmux.c
index e5fa695..fc5c1ef 100644
--- a/drivers/i2c/muxes/gpio-i2cmux.c
+++ b/drivers/i2c/muxes/gpio-i2cmux.c
@@ -105,7 +105,8 @@ static int __devinit gpiomux_probe(struct platform_device
*pdev)
for (i = 0; i pdata-n_values; i++) {
u32 nr = pdata-base_nr ? (pdata-base_nr + i) : 0;
- mux-adap[i] = i2c_add_mux_adapter(parent, mux, nr, i,
+ mux-adap[i] = i2c_add_mux_adapter(parent, pdev-dev, mux,
+ nr, i,
gpiomux_select, deselect);
if (!mux-adap[i]) {
ret = -ENODEV;
diff --git a/drivers/i2c/muxes/pca9541.c b/drivers/i2c/muxes/pca9541.c
index e0df9b6..8aacde1 100644
--- a/drivers/i2c/muxes/pca9541.c
+++ b/drivers/i2c/muxes/pca9541.c
@@ -353,7 +353,8 @@ static int pca9541_probe(struct i2c_client *client,
force = 0;
if (pdata)
force = pdata-modes[0].adap_id;
- data-mux_adap = i2c_add_mux_adapter(adap, client, force, 0,
+ data-mux_adap = i2c_add_mux_adapter(adap, client-dev, client,
+force, 0,
pca9541_select_chan,
pca9541_release_chan);
diff --git a/drivers/i2c/muxes/pca954x.c b/drivers/i2c/muxes/pca954x.c
index 0e37ef2..f2dfe0d 100644
--- a/drivers/i2c/muxes/pca954x.c
+++ b/drivers/i2c/muxes/pca954x.c
@@ -226,7 +226,7 @@ static
Re: [RFC 4/4] drm: Add NVIDIA Tegra support
On 04/12/2012 11:44 AM, Thierry Reding wrote:
* Stephen Warren wrote:
On 04/12/2012 12:50 AM, Thierry Reding wrote:
drm {
compatible = nvidia,tegra20-drm;
I'm don't think having an explicit drm node is the right approach; drm
is after all a SW term and the DT should be describing HW. Having some
kind of top-level node almost certainly makes sense, but naming it
something related to tegra display than drm would be appropriate.
In this case there really isn't a HW device that can be represented. But in
the end it's still the DRM driver that needs to bind to the device. However
the other graphics devices (MPE, VI/CSI, EPP, GR2D and GR3D) probably need
to be bound against.
Well, everything graphics-related appears to be grouped within some
container. In the memory map, there's the range 0x5400-547f, and
in the Tegra20 TRM, the first diagram in section 29 Display Controller
again lumps all the modules together into one box.
I'd say it's perfectly legitimate to create a device tree node to
represent this aggregate display/graphics-related engine. So, I think
that yes there is a real HW device to represent.
And given that, I don't think we should name the node after some
OS-specific software concept. Device tree is intended to model hardware.
Would it be possible for someone at NVIDIA to provide some more details about
what those other devices are? GR2D and GR3D seem obvious, MPE might be video
decoding, VI/CSI video input and camera interface? As to EPP I have no idea.
MPE is something video encode/decode related. VI/CSI are indeed camera
related. I'm afraid I don't personally know any more details than that,
and even if I did, I'm only allowed to discuss what's in the TRM:-(
I don't think those modules should have much impact on the DRM driver
design if that's what you're worried about. I /believe/ they all just
interact directly with memory rather than the other components,
irrespective of what that first diagram in section 29 might imply.
Maybe one solution would be to have a top-level DRM device with a register
map from 0x5400 to 0x547f, which the TRM designates as host
registers. Then subnodes could be used for the subdevices.
Ah yes, just what I was thinking above:-)
I don't think you'd /have/ to make the nodes sub-nodes; you could use
phandles to refer from the top-level node to the other components. One
might end up having to use phandles anyway to represent the routing from
DCA or DCB to MIPI or HDMI anyway, so it's possible that using phandles
everywhere might be simpler and more consistent than parent/child
relationships for some things and phandles for other things.
lvds {
compatible = ...;
dc = disp1;
};
Aren't the outputs separate HW blocks too, such that they would have
their own compatible/reg properties and their own drivers, and be
outside the top-level drm/display node?
The RGB output is programmed via the display controller registers. For HDMI,
TVO and DSI there are indeed separate sets of registers in addition to the
display controller's. So perhaps for those more nodes would be required:
hdmi : hdmi@5428 {
compatible = nvidia,tegra20-hdmi;
reg = 0x5428 0x0004;
};
Yes, looks reasonable.
And hook that up with the HDMI output node of the DRM node:
drm {
hdmi {
compatible = ...;
connector = hdmi;
dc = disp2;
};
};
Maybe with this setup we no longer need the compatible property since it
will already be inherent in the connector property. There will have to be
special handling for the RGB output, which could be the default if the
connector property is missing.
I suspect you'd have something more like:
tegra-graphics {
output-resources = hdmi tvo dsi ... ;
display-controllers = disp1 disp2;
};
i.e. just a list of all extant devices. Each should provide some common
API so you could just map from phandle to of_node to device object, and
call the appropriate APIs on it.
Finally note that although I didn't really represent it correct above,
there are at least 3 levels of object/hierarchy here:
Display controllers reads from RAM and form a set of pixels to display.
I believe things like cursors, overlays, pan-scan, etc. are resolved
entirely at this level.
Output resources drive certain pins on Tegra in some specific format
such as HDMI, VGA, etc. I think all output resources can actually
display the data from either display controller. Probably even 2 ORs can
show an image from the same DC at once for mirrored display.
Finally, there are the user connectors. I suspect it's plausible for
muxes to exist between the ORs and user connectors, although that's
probably a lot less likely. I believe this is the level at which to
represent things like which I2C bus is used for
[PATCH 1/2] MIPS: OCTEON: Select ARCH_REQUIRE_GPIOLIB
From: David Daney david.da...@cavium.com ... and create asm/mach-cavium-octeon/gpio.h so that things continue to build. This allows us to use the existing I2C connected GPIO expanders. Signed-off-by: David Daney david.da...@cavium.com --- arch/mips/Kconfig |1 + arch/mips/include/asm/mach-cavium-octeon/gpio.h | 21 + 2 files changed, 22 insertions(+), 0 deletions(-) create mode 100644 arch/mips/include/asm/mach-cavium-octeon/gpio.h diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index d0011ef..3134457 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -744,6 +744,7 @@ config CAVIUM_OCTEON_REFERENCE_BOARD select USB_ARCH_HAS_OHCI select USB_ARCH_HAS_EHCI select HOLES_IN_ZONE + select ARCH_REQUIRE_GPIOLIB help This option supports all of the Octeon reference boards from Cavium Networks. It builds a kernel that dynamically determines the Octeon diff --git a/arch/mips/include/asm/mach-cavium-octeon/gpio.h b/arch/mips/include/asm/mach-cavium-octeon/gpio.h new file mode 100644 index 000..34e9f7a --- /dev/null +++ b/arch/mips/include/asm/mach-cavium-octeon/gpio.h @@ -0,0 +1,21 @@ +#ifndef __ASM_MACH_CAVIUM_OCTEON_GPIO_H +#define __ASM_MACH_CAVIUM_OCTEON_GPIO_H + +#ifdef CONFIG_GPIOLIB +#define gpio_get_value __gpio_get_value +#define gpio_set_value __gpio_set_value +#define gpio_cansleep __gpio_cansleep +#else +int gpio_request(unsigned gpio, const char *label); +void gpio_free(unsigned gpio); +int gpio_direction_input(unsigned gpio); +int gpio_direction_output(unsigned gpio, int value); +int gpio_get_value(unsigned gpio); +void gpio_set_value(unsigned gpio, int value); +#endif + +#include asm-generic/gpio.h + +#define gpio_to_irq__gpio_to_irq + +#endif /* __ASM_MACH_GENERIC_GPIO_H */ -- 1.7.2.3 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/2] gpio/MIPS/OCTEON: Add GPIO support for OCTEON.
From: David Daney david.da...@cavium.com There are two patches needed to add OCTEON GPIO support: 1) Select ARCH_REQUIRE_GPIOLIB. This allows standard I2C GPIO expanders to function, as well as being a prerequisite for the driver for the on-chip pins. 2) The on-chip pin driver. I'm not sure the best way to merge these, they are part MIPS and part GPIO. Via either maintainer is fine by me. Thanks, David Daney (2): MIPS: OCTEON: Select ARCH_REQUIRE_GPIOLIB gpio/MIPS/OCTEON: Add a driver for OCTEON's on-chip GPIO pins. arch/mips/Kconfig |1 + arch/mips/include/asm/mach-cavium-octeon/gpio.h | 21 +++ drivers/gpio/Kconfig|8 + drivers/gpio/Makefile |1 + drivers/gpio/gpio-octeon.c | 166 +++ 5 files changed, 197 insertions(+), 0 deletions(-) create mode 100644 arch/mips/include/asm/mach-cavium-octeon/gpio.h create mode 100644 drivers/gpio/gpio-octeon.c -- 1.7.2.3 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/2] gpio/MIPS/OCTEON: Add a driver for OCTEON's on-chip GPIO pins.
From: David Daney david.da...@cavium.com
The SOCs in the OCTEON family have 16 (or in some cases 20) on-chip
GPIO pins, this driver handles them all. Configuring the pins as
interrupt sources is handled elsewhere (OCTEON's irq handling code).
Signed-off-by: David Daney david.da...@cavium.com
---
drivers/gpio/Kconfig |8 ++
drivers/gpio/Makefile |1 +
drivers/gpio/gpio-octeon.c | 166
3 files changed, 175 insertions(+), 0 deletions(-)
create mode 100644 drivers/gpio/gpio-octeon.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index edadbda..d9d924c 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -136,6 +136,14 @@ config GPIO_MXS
select GPIO_GENERIC
select GENERIC_IRQ_CHIP
+config GPIO_OCTEON
+ tristate Cavium OCTEON GPIO
+ depends on GPIOLIB CPU_CAVIUM_OCTEON
+ default y
+ help
+ Say yes here to support the on-chip GPIO lines on the OCTEON
+ family of SOCs.
+
config GPIO_PL061
bool PrimeCell PL061 GPIO support
depends on ARM_AMBA
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 007f54b..ce0348c 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_GPIO_MSM_V2) += gpio-msm-v2.o
obj-$(CONFIG_GPIO_MXC) += gpio-mxc.o
obj-$(CONFIG_GPIO_MXS) += gpio-mxs.o
obj-$(CONFIG_PLAT_NOMADIK) += gpio-nomadik.o
+obj-$(CONFIG_GPIO_OCTEON) += gpio-octeon.o
obj-$(CONFIG_ARCH_OMAP)+= gpio-omap.o
obj-$(CONFIG_GPIO_PCA953X) += gpio-pca953x.o
obj-$(CONFIG_GPIO_PCF857X) += gpio-pcf857x.o
diff --git a/drivers/gpio/gpio-octeon.c b/drivers/gpio/gpio-octeon.c
new file mode 100644
index 000..e679b44
--- /dev/null
+++ b/drivers/gpio/gpio-octeon.c
@@ -0,0 +1,166 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2011,2012 Cavium Inc.
+ */
+
+#include linux/platform_device.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/gpio.h
+#include linux/io.h
+
+#include asm/octeon/octeon.h
+#include asm/octeon/cvmx-gpio-defs.h
+
+#define DRV_VERSION 1.0
+#define DRV_DESCRIPTION Cavium Inc. OCTEON GPIO Driver
+
+#define RX_DAT 0x80
+#define TX_SET 0x88
+#define TX_CLEAR 0x90
+/*
+ * The address offset of the GPIO configuration register for a given
+ * line.
+ */
+static unsigned int bit_cfg_reg(unsigned int gpio)
+{
+ if (gpio 16)
+ return 8 * gpio;
+ else
+ return 8 * (gpio - 16) + 0x100;
+}
+
+struct octeon_gpio {
+ struct gpio_chip chip;
+ u64 register_base;
+};
+
+static int octeon_gpio_dir_in(struct gpio_chip *chip, unsigned offset)
+{
+ struct octeon_gpio *gpio = container_of(chip, struct octeon_gpio, chip);
+
+ cvmx_write_csr(gpio-register_base + bit_cfg_reg(offset), 0);
+ return 0;
+}
+
+static void octeon_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+ struct octeon_gpio *gpio = container_of(chip, struct octeon_gpio, chip);
+ u64 mask = 1ull offset;
+ u64 reg = gpio-register_base + (value ? TX_SET : TX_CLEAR);
+ cvmx_write_csr(reg, mask);
+}
+
+static int octeon_gpio_dir_out(struct gpio_chip *chip, unsigned offset,
+ int value)
+{
+ struct octeon_gpio *gpio = container_of(chip, struct octeon_gpio, chip);
+ union cvmx_gpio_bit_cfgx cfgx;
+
+
+ octeon_gpio_set(chip, offset, value);
+
+ cfgx.u64 = 0;
+ cfgx.s.tx_oe = 1;
+
+ cvmx_write_csr(gpio-register_base + bit_cfg_reg(offset), cfgx.u64);
+ return 0;
+}
+
+static int octeon_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+ struct octeon_gpio *gpio = container_of(chip, struct octeon_gpio, chip);
+ u64 read_bits = cvmx_read_csr(gpio-register_base + RX_DAT);
+
+ return ((1ull offset) read_bits) != 0;
+}
+
+static int __init octeon_gpio_probe(struct platform_device *pdev)
+{
+ struct octeon_gpio *gpio;
+ struct gpio_chip *chip;
+ struct resource *res_mem;
+ int err = 0;
+
+ gpio = devm_kzalloc(pdev-dev, sizeof(*gpio), GFP_KERNEL);
+ if (!gpio)
+ return -ENOMEM;
+ chip = gpio-chip;
+
+ res_mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res_mem == NULL) {
+ dev_err(pdev-dev, found no memory resource\n);
+ err = -ENXIO;
+ goto out;
+ }
+ if (!devm_request_mem_region(pdev-dev, res_mem-start,
+ resource_size(res_mem),
+res_mem-name)) {
+ dev_err(pdev-dev, request_mem_region failed\n);
+ err = -ENXIO;
+ goto out;
+ }
+ gpio-register_base = (u64)devm_ioremap(pdev-dev, res_mem-start,
+
adding devicetree support for an interrupt controller
So I am working on adding DT support for the tps65910 pmic. It (amongst other things) is an interrupt controller. I am looking to convert that code as well, and I am curious if there is a good example to work off. The driver's irq_base is not set, so it needs to use a dynamic domain. The examples I saw seemed to be all platform devices and then used something like irq_setup_generic_chip_domain, but since the tps65910 is an i2c device, its device doesn't have resources associated with it, and can't therefore pass them to this function. Is there already a defined path for i2c interrupt controllers like this? thanks, Rhyland --- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. --- ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] Add integer expressions files to .gitignore
On Thu, Apr 12, 2012 at 10:50:25AM -0700, Simon Glass wrote: Several files were added, and should be in .gitignore. The *.test.dts pattern should catch future source files which are generated by tests. Also move things back into alphabetical order, which I think is the intent. Hm, probably, but I'd prefer not to put fixups for that in the same patch as an actual change. Makes the real change harder to spot. Signed-off-by: Simon Glass s...@chromium.org --- tests/.gitignore |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/tests/.gitignore b/tests/.gitignore index 0b71bcf..2833582 100644 --- a/tests/.gitignore +++ b/tests/.gitignore @@ -1,6 +1,7 @@ *.dtb *.dtb.test.dts *.dts.test.s +*.test.dts The new pattern subsumes *.dtb.test.dts, so it should replace it. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] USB: Add DT probing support to ehci-spear and ohci-spear
On 3/22/2012 9:20 PM, Stefan Roese wrote: This patch adds support to configure the SPEAr EHCI OHCI driver via device-tree instead of platform_data. Signed-off-by: Stefan Roese s...@denx.de Cc: Viresh Kumar viresh.ku...@st.com --- .../devicetree/bindings/usb/spear-usb.txt | 39 drivers/usb/host/ehci-spear.c | 32 +--- drivers/usb/host/ohci-spear.c | 32 +--- 3 files changed, 91 insertions(+), 12 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/spear-usb.txt Hi Greg, Have you applied this patch? -- viresh ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
